Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: what to do with (qwerty) e and w? #72

Open
aspiwack opened this issue Sep 2, 2019 · 4 comments
Open

Discussion: what to do with (qwerty) e and w? #72

aspiwack opened this issue Sep 2, 2019 · 4 comments

Comments

@aspiwack
Copy link
Collaborator

aspiwack commented Sep 2, 2019

There used to be two prefixes (e and w) which lead to a number of search commands. E.g. e was bound to isearch.

After an update to the latest build, today, they appear to have been replaced by boon-navigate-forward (resp backward). And I can't locate bindings for isearch, for instance.

@jyp
Copy link
Owner

jyp commented Sep 4, 2019

That was a breaking change --- also I should have experimented more before pushing to the master branch maybe. So here's my recounting of events in bullet points:

  • Simple searches are meant to be bound to r on qwerty. (I have rebound this to swiper, and hardly ever use isearch). Maybe this should be done by default? So, you should have now a top-row mostly allocated for searching in the buffer (see below).
  • I found that I never used the search commands except for next-error and previous-error.
  • I figured that next-error and previous-error were very versatile context-dependent commands. When properly configured, emacs packages will let you navigate several different things with that (occur, x-refs, grep results, etc.).
  • Then it seemed to me that e and w should be simply bound to these commands --- but I added even more context sensitivity (if you have a search term highlighted it'll navigate between occurences).
  • But, it's only marginally better to have a single keystroke rather than 2. It was in particular possible to have common commands bound to easy rolls.

I'd be happy to ponder the design with you (and others). Reverting is always an option. We could also have "boon-classic" and "boon-new-generation" frontends.

(Right now I've resurrected boon-forward-search-map and boon-backward-search-map; so you can rebind them in the interim.)

@jyp
Copy link
Owner

jyp commented Sep 4, 2019

Some other things that I forgot: for this kind of navigation to be most useful, it should be bound to a right-hand keystroke (I am thinking [ and ]). Doing this would have the advantage of leaving w and e free (they could simply be left alone for now). I fact I am thinking to apply this change right now.

@jyp
Copy link
Owner

jyp commented Sep 4, 2019

Ok, I committed the proposed revert. But let's leave this open as a notice that the discussion is open.

@jyp jyp changed the title What became of the search prefixes Discussion: what to do with (qwerty) e and w? Sep 4, 2019
@aspiwack
Copy link
Collaborator Author

aspiwack commented Sep 4, 2019

for this kind of navigation to be most useful, it should be bound to a right-hand keystroke (I am thinking [ and ]).

For what kind of navigation?

On the main topic: I'd rather keep some search prefix for the reason that I added some search options, and it was all neatly arranged, I liked it (mostly: I have a project-wide search bound to eg (g is my project-wide mnemonic…)). I also used es (resp. ws) (search symbol at point) rather frequently.

I don't have a strong opinion about what the prefixes should be. But it made sense, for me, to group the various search facilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants