* changing bindings in isearch mode? @ 2009-01-17 6:54 Greg Klanderman 2009-01-17 17:56 ` Peter Stephenson 2009-01-17 19:17 ` Bart Schaefer 0 siblings, 2 replies; 11+ messages in thread From: Greg Klanderman @ 2009-01-17 6:54 UTC (permalink / raw) To: Zsh list It looks like the isearch mode bindings are hardcoded, is that right? I'd really like to have <return> bound to exit isearch, like it does in emacs.. Would it make sense to have an isearch keymap and use that? Is there a key in isearch mode that will just exit isearch at the current position, and nothing else? thanks, Greg ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-17 6:54 changing bindings in isearch mode? Greg Klanderman @ 2009-01-17 17:56 ` Peter Stephenson 2009-01-17 18:23 ` Greg Klanderman 2009-01-17 19:17 ` Bart Schaefer 1 sibling, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2009-01-17 17:56 UTC (permalink / raw) To: Zsh list On Sat, 17 Jan 2009 01:54:55 -0500 Greg Klanderman <gak@klanderman.net> wrote: > Would it make sense to have an isearch keymap and use that? Absolutely, but it's a very tricky change to push the behaviour into functions. Translation: it's not clear anyone knows how to do this and it's very clear no one has the time to find out. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-17 17:56 ` Peter Stephenson @ 2009-01-17 18:23 ` Greg Klanderman 2009-01-19 9:44 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Greg Klanderman @ 2009-01-17 18:23 UTC (permalink / raw) To: zsh-workers >>>>> Peter Stephenson <p.w.stephenson@ntlworld.com> writes: > Absolutely, but it's a very tricky change to push the behaviour into > functions. Translation: it's not clear anyone knows how to do this and > it's very clear no one has the time to find out. I don't think you need (or even want) to push the behavior into functions; the menu-select widget already uses the "menuselect" keymap. It looks like it's just casing on the commands that are bound, not executing them necessarily, and this seems to also be how the isearch code is written, using tests of the form cmd == Th(z_****) Just glancing over the code, it would appear not too hard to create a keymap for isearch, add an isearch-exit widget, and add a case for it in doisearch. Does that seem like a reasonable solution? thanks, Greg ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-17 18:23 ` Greg Klanderman @ 2009-01-19 9:44 ` Peter Stephenson 2009-01-19 12:12 ` Peter Stephenson 0 siblings, 1 reply; 11+ messages in thread From: Peter Stephenson @ 2009-01-19 9:44 UTC (permalink / raw) To: zsh-workers On Sat, 17 Jan 2009 13:23:53 -0500 Greg Klanderman <gak@klanderman.net> wrote: > > >>>>> Peter Stephenson <p.w.stephenson@ntlworld.com> writes: > > > Absolutely, but it's a very tricky change to push the behaviour into > > functions. Translation: it's not clear anyone knows how to do this and > > it's very clear no one has the time to find out. > > I don't think you need (or even want) to push the behavior into > functions; the menu-select widget already uses the "menuselect" > keymap. It looks like it's just casing on the commands that are > bound, not executing them necessarily, and this seems to also be how > the isearch code is written, using tests of the form > > cmd == Th(z_****) > > Just glancing over the code, it would appear not too hard to create a > keymap for isearch, add an isearch-exit widget, and add a case for it > in doisearch. Does that seem like a reasonable solution? Yes, it looks like you're right. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-19 9:44 ` Peter Stephenson @ 2009-01-19 12:12 ` Peter Stephenson 2009-01-19 17:17 ` Bart Schaefer 2009-01-21 20:43 ` Greg Klanderman 0 siblings, 2 replies; 11+ messages in thread From: Peter Stephenson @ 2009-01-19 12:12 UTC (permalink / raw) To: zsh-workers On Mon, 19 Jan 2009 09:44:53 +0000 Peter Stephenson <pws@csr.com> wrote: > On Sat, 17 Jan 2009 13:23:53 -0500 > Greg Klanderman <gak@klanderman.net> wrote: > > Just glancing over the code, it would appear not too hard to create a > > keymap for isearch, add an isearch-exit widget, and add a case for it > > in doisearch. Does that seem like a reasonable solution? > > Yes, it looks like you're right. I was indeed thinking about this over the weekend and why no one had done it before. It really does look like it's that simple; this is quite a lot of oomph for a small patch. I've added the "isearch" keymap and the "accept-search" thingy: there's no corresponding widget, it's tested for directly in isearch mode. The name "accept-search" exercised me a bit. I called the latter that (rather than something with "i" or "incremental") because the search method in use is logically irrelevant, even if for now it's only useful in isearch mode, just as there isn't any point in having "accept-emacs-line" or "accept-vi-line" if you're in emacs or vi mode. (You could bind it for use in your own search mode, for example.) I kept the word "search" even if logically it should be something like "result" to avoid ambiguity with what you're accepting. I thought about "exit-search", but "accept-" is already used to mean "keep the value you've just arrived at and return to higher level processing", so it seemed a natural extension and made it clear that you were keeping the result. Index: Doc/Zsh/zle.yo =================================================================== RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v retrieving revision 1.75 diff -u -r1.75 zle.yo --- Doc/Zsh/zle.yo 9 Dec 2008 17:37:01 -0000 1.75 +++ Doc/Zsh/zle.yo 19 Jan 2009 11:58:07 -0000 @@ -60,12 +60,13 @@ findex(bindkey, use of) tt(bindkey) can be used to manipulate keymap names. -Initially, there are four keymaps: +Initially, there are five keymaps: startsitem() sitem(tt(emacs))(EMACS emulation) sitem(tt(viins))(vi emulation - insert mode) sitem(tt(vicmd))(vi emulation - command mode) +sitem(tt(isearch))(incremental search mode) sitem(tt(.safe))(fallback keymap) endsitem() @@ -76,7 +77,7 @@ vindex(VISUAL) vindex(EDITOR) -In addition to these four names, either `tt(emacs)' or `tt(viins)' is +In addition to these names, either `tt(emacs)' or `tt(viins)' is also linked to the name `tt(main)'. If one of the tt(VISUAL) or tt(EDITOR) environment variables contain the string `tt(vi)' when the shell starts up then it will be `tt(viins)', otherwise it will be `tt(emacs)'. @@ -1115,7 +1116,10 @@ search to the beginning of the line. A restricted set of editing functions -is available in the mini-buffer. An interrupt signal, as defined by the stty +is available in the mini-buffer. Keys are looked up in the special +tt(isearch) keymap, and if not found there in the main keymap (note +that by default the tt(isearch) keymap is empty). +An interrupt signal, as defined by the stty setting, will stop the search and go back to the original line. An undefined key will have the same effect. The supported functions are: @@ -1133,6 +1137,11 @@ repeated this does not immediately erase a character in the minibuffer. ) +item(tt(accept-search))( +Exit incremental search, retaining the command line but performing no +further action. Note that this function is not bound by default +and has no effect outside incremental search. +) xitem(tt(backward-delete-word)) xitem(tt(backward-kill-word)) item(tt(vi-backward-kill-word))( Index: Src/Zle/iwidgets.list =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/iwidgets.list,v retrieving revision 1.11 diff -u -r1.11 iwidgets.list --- Src/Zle/iwidgets.list 26 Apr 2008 19:51:09 -0000 1.11 +++ Src/Zle/iwidgets.list 19 Jan 2009 11:58:07 -0000 @@ -13,6 +13,7 @@ "accept-and-menu-complete", acceptandmenucomplete, ZLE_MENUCMP | ZLE_KEEPSUFFIX "accept-line", acceptline, 0 "accept-line-and-down-history", acceptlineanddownhistory, 0 +"accept-search", NULL, 0 "argument-base", argumentbase, ZLE_MENUCMP | ZLE_KEEPSUFFIX | ZLE_LASTCOL | ZLE_NOTCOMMAND "auto-suffix-remove", handlesuffix, ZLE_NOTCOMMAND "auto-suffix-retain", handlesuffix, ZLE_KEEPSUFFIX | ZLE_NOTCOMMAND Index: Src/Zle/zle_hist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_hist.c,v retrieving revision 1.59 diff -u -r1.59 zle_hist.c --- Src/Zle/zle_hist.c 30 Oct 2008 01:47:32 -0000 1.59 +++ Src/Zle/zle_hist.c 19 Jan 2009 11:58:07 -0000 @@ -49,6 +49,10 @@ /**/ int previous_search_len = 0; +/* Local keymap in isearch mode */ + +/**/ +Keymap isearch_keymap; /*** History text manipulation utilities ***/ @@ -1141,6 +1145,8 @@ if (!(he = quietgethist(hl))) return; + selectlocalmap(isearch_keymap); + clearlist = 1; if (*args) { @@ -1572,6 +1578,8 @@ feep = 1; else goto ins; + } else if (cmd == Th(z_acceptsearch)) { + break; } else { if(cmd == Th(z_selfinsertunmeta)) { fixunmeta(); @@ -1640,6 +1648,8 @@ */ if (savekeys >= 0 && kungetct > savekeys) kungetct = savekeys; + + selectlocalmap(NULL); } static Histent Index: Src/Zle/zle_keymap.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_keymap.c,v retrieving revision 1.30 diff -u -r1.30 zle_keymap.c --- Src/Zle/zle_keymap.c 11 Nov 2008 22:40:17 -0000 1.30 +++ Src/Zle/zle_keymap.c 19 Jan 2009 11:58:07 -0000 @@ -1176,6 +1176,8 @@ char buf[3], *ed; int i; + isearch_keymap = newkeymap(NULL, "isearch"); + /* vi insert mode and emacs mode: * * 0-31 taken from the tables * * 32-126 self-insert * @@ -1274,6 +1276,8 @@ else linkkeymap(emap, "main", 0); + linkkeymap(isearch_keymap, "isearch", 0); + /* the .safe map cannot be modified or deleted */ smap->flags |= KM_IMMUTABLE; } -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-19 12:12 ` Peter Stephenson @ 2009-01-19 17:17 ` Bart Schaefer 2009-01-22 4:01 ` Greg Klanderman 2009-01-21 20:43 ` Greg Klanderman 1 sibling, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2009-01-19 17:17 UTC (permalink / raw) To: zsh-workers On Jan 19, 12:12pm, Peter Stephenson wrote: } } I was indeed thinking about this over the weekend and why no one had } done it before. It really does look like it's that simple; this is } quite a lot of oomph for a small patch. The keymap is a good thing, but I suspect the reasons no one's bothered before include (1) accept-search is no different than undefined-key in this context, (2) if the keymap exists, it's possible to do something moderately stupid like "bindkey -A main isearch", and (3) the *real* oomph would come if user-defined widgets were usable in isearch mode (and the widgets in that mode had distinct names). } The name "accept-search" exercised me a bit. [...] (You could bind it } for use in your own search mode, for example.) You'd also have to define it with "zle -N" in that case, though, and there follows the confusion as to why your custom widget doesn't get called when the accept-search key is struck in isearch mode. -- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-19 17:17 ` Bart Schaefer @ 2009-01-22 4:01 ` Greg Klanderman 2009-01-22 9:57 ` Bart Schaefer 0 siblings, 1 reply; 11+ messages in thread From: Greg Klanderman @ 2009-01-22 4:01 UTC (permalink / raw) To: zsh-workers >>>>> Bart Schaefer <schaefer@brasslantern.com> writes: > accept-search is no different than undefined-key in this context, Actually, that's not true. If a key is undefined in the isearch map, it is looked up in the main map, whereas if a key is bound to accept-search in the isearch map, it has the desired effect. Greg ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-22 4:01 ` Greg Klanderman @ 2009-01-22 9:57 ` Bart Schaefer 2009-01-22 21:25 ` Greg Klanderman 0 siblings, 1 reply; 11+ messages in thread From: Bart Schaefer @ 2009-01-22 9:57 UTC (permalink / raw) To: zsh-workers On Jan 21, 11:01pm, Greg Klanderman wrote: } Subject: Re: changing bindings in isearch mode? } } >>>>> Bart Schaefer <schaefer@brasslantern.com> writes: } } > accept-search is no different than undefined-key in this context, } } Actually, that's not true. What I wrote was: : the reasons no one's bothered : before include (1) accept-search is no different than undefined-key : in this context Please note the word "before". It's hardly fair to wait until the implementation changes and then call me a liar for describing the previous implementation. } If a key is undefined in the isearch map, it is looked up in the main } map, whereas if a key is bound to accept-search in the isearch map, it } has the desired effect. True for zsh where there is such a thing as the isearch map. Before that existed, the only way to have an undefined key in isearch mode was to *change the main keymap* to one where that key was undefined. Which I believe it would work to do with a wrapper as I explained in workers/26350. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-22 9:57 ` Bart Schaefer @ 2009-01-22 21:25 ` Greg Klanderman 0 siblings, 0 replies; 11+ messages in thread From: Greg Klanderman @ 2009-01-22 21:25 UTC (permalink / raw) To: zsh-workers >>>>> Bart Schaefer <schaefer@brasslantern.com> writes: > What I wrote was: > : the reasons no one's bothered > : before include (1) accept-search is no different than undefined-key > : in this context > Please note the word "before". It's hardly fair to wait until the > implementation changes and then call me a liar for describing the > previous implementation. Hi Bart, Sorry, I wasn't trying to imply you are a liar, just pointing out that for the implementation Peter checked in that your statement isn't correct. Your email was a response to Peter's patch, and I wanted to clarify any confusion. > Which I believe it would work to do with a wrapper as I explained in > workers/26350. I haven't tried it, but I have no reason to believe that's not the case. I agree with you that this is not an earth-shattering fix, but it is nice to have the separate local map and not have to muck with user defined widgets. Greg ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-19 12:12 ` Peter Stephenson 2009-01-19 17:17 ` Bart Schaefer @ 2009-01-21 20:43 ` Greg Klanderman 1 sibling, 0 replies; 11+ messages in thread From: Greg Klanderman @ 2009-01-21 20:43 UTC (permalink / raw) To: zsh-workers >>>>> Peter Stephenson <pws@csr.com> writes: > I've added the "isearch" keymap and the "accept-search" thingy: there's no > corresponding widget, it's tested for directly in isearch mode. Thank you so much, Peter; I was going to work on this last weekend but ran out of time.. just updated from CVS and it is working perfectly. Greg ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: changing bindings in isearch mode? 2009-01-17 6:54 changing bindings in isearch mode? Greg Klanderman 2009-01-17 17:56 ` Peter Stephenson @ 2009-01-17 19:17 ` Bart Schaefer 1 sibling, 0 replies; 11+ messages in thread From: Bart Schaefer @ 2009-01-17 19:17 UTC (permalink / raw) To: Zsh list On Jan 17, 1:54am, Greg Klanderman wrote: } } It looks like the isearch mode bindings are hardcoded, is that right? Sort of. isearch was implemented before zsh had the concept of keymaps, so instead of using a keymap with its own set of widgets, it hijacks the names of the widgets from the original keymap and does its own internal thing when it sees you attempt to execute one of those widgets. } I'd really like to have <return> bound to exit isearch, like it does } in emacs.. } } Would it make sense to have an isearch keymap and use that? I believe you should be able to accomplish this with a user-defined wrapper widget that selects the keymap you want and then invokes the appropriate built-in incremental-search widget. I agree that's not the best solution and that it would be better to re-implement isearch with real widgets. } Is there a key in isearch mode that will just exit isearch at the } current position, and nothing else? Yes: Any undefined key. So to make <enter> do that, you just have to "bindkey -r ^M" (and possibly also ^J) in the keymap used by the aforementioned wrapper widget. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-01-22 21:25 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-01-17 6:54 changing bindings in isearch mode? Greg Klanderman 2009-01-17 17:56 ` Peter Stephenson 2009-01-17 18:23 ` Greg Klanderman 2009-01-19 9:44 ` Peter Stephenson 2009-01-19 12:12 ` Peter Stephenson 2009-01-19 17:17 ` Bart Schaefer 2009-01-22 4:01 ` Greg Klanderman 2009-01-22 9:57 ` Bart Schaefer 2009-01-22 21:25 ` Greg Klanderman 2009-01-21 20:43 ` Greg Klanderman 2009-01-17 19:17 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).