jyp/boon

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

Opened this issue · 4 comments

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 commented

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 commented

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 commented

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

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.