You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.)
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.
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.
Activity
jyp commentedon 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:
ron qwerty. (I have rebound this toswiper, and hardly ever useisearch). Maybe this should be done by default? So, you should have now a top-row mostly allocated for searching in the buffer (see below).next-errorandprevious-error.next-errorandprevious-errorwere 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.).eandwshould 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).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-mapandboon-backward-search-map; so you can rebind them in the interim.)jyp commentedon 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 leavingwandefree (they could simply be left alone for now). I fact I am thinking to apply this change right now.jyp commentedon Sep 4, 2019
Ok, I committed the proposed revert. But let's leave this open as a notice that the discussion is open.
[-]What became of the search prefixes[/-][+]Discussion: what to do with (qwerty) `e` and `w`?[/+]aspiwack commentedon Sep 4, 2019
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(gis my project-wide mnemonic…)). I also usedes(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.