changing bindings in isearch mode?

changing bindings in isearch mode?

[Greg Klanderman]

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

Re: changing bindings in isearch mode?

[Peter Stephenson]

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/

Re: changing bindings in isearch mode?

[Greg Klanderman]

>>>>> 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

Re: changing bindings in isearch mode?

[Peter Stephenson]

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

Re: changing bindings in isearch mode?

[Peter Stephenson]

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

Re: changing bindings in isearch mode?

[Bart Schaefer]

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.

-- 

Re: changing bindings in isearch mode?

[Greg Klanderman]

>>>>> 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

Re: changing bindings in isearch mode?

[Bart Schaefer]

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.

Re: changing bindings in isearch mode?

[Greg Klanderman]

>>>>> 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

Re: changing bindings in isearch mode?

[Greg Klanderman]

>>>>> 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

Re: changing bindings in isearch mode?

[Bart Schaefer]

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.