Re: *don't* fail when bck-i-search is over

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Wow, this got a bit longer than I expected.

On Nov 23,  4:40pm, darwin wrote:
} Subject: Re: *don't* fail when bck-i-search is over
}
} On Tue, Nov 23, 2010 at 12:12:25AM -0800, Bart Schaefer wrote:
} > Once you are in isearch mode, there isn't any way out except to accept
} > the line or hit an undefined key; a failed search won't do it. 
} 
} for my first question, what i'm asking is how to get isearch to go
} through $PATH once it's done looking up the history for possible
} matches.

Well, you can't *literally* do that, except maybe by creating a dummy
history that contains every command in the path as if you've at some
past time executed all of them.  The very definition of [i]search in
the line editor is that previously-input lines (aka history) are what
it is searching.

Consequently I took your question to be "how can I create a keybinding
that first searches the history and, if nothing is found there, goes
on to search the path?"

} i.e. don't limit the search to .histfile

I ignored this before but as you've now repeated it several times ...
the history *file* is *not* what is searched, and you're going to
confuse yourself eventually if you think of it that way.  What is
searched is zsh's in-memory image of the history, which may not have
any resemblance to the file contents.

} > The effect you want is similar to what the insert-and-predict function
} > does, but it handles it by staying away from isearch mode, instead
} > calling history-beginning-search-backward as each character is typed;
} > so if the search doesn't find anything the wrapper widget is still in
} > control and can try something else.
} 
} that seems more like what i'm looking for but do i still need to tell it
} what to do, say search the $PATH or take me to vicmd, when it doesn't
} find anything in hist? 

The "something else" that insert-and-predict does when history search
fails, is to invoke completion.  There are some styles you can set to
give it hints, but for the most part the completion system figures it
out from context.

} > If you want to end up in vicmd mode when you hit ESC, you shouldn't
} > need to bind it at all.  An unbound key takes you out of isearch and
} > then performs the normal function of that key.  So *if* you have
} > "bindkey -v" and you don't bind ESC in the isearch map, ESC will
} > take you out of isearch, to viins, and then have it's normal effect
} > in viins, which is to take you to vicmd where you wanted.
} 
} almost. with "bindkey -v" and with or without ESC bount in isearch i
} have to hit ESC twice to get to vicmd. first one only takes me to viins.

Hrm.  The doc for isearch mode says:

     A restricted set of editing functions is available in the
     mini-buffer.  Keys are looked up in the special isearch keymap,
     and if not found there in the main keymap (note that by default
     the 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.  [...]

    ...

    vi-cmd-mode
          Toggle between the `main' and `vicmd' keymaps; the `main'
          keymap (insert mode) will be selected initially.

    ...

     Any character that is not bound to one of the above functions, or
     self-insert or self-insert-unmeta, will cause the mode to be
     exited.  The character is then looked up and executed in the
     keymap in effect at that point.

So what happens with ESC is actually as follows:

0. isearch mode starts.  This selects the "main" keymap which, if you
use "bindkey -v" is actually the "viins" keymap.  The keymap from
which isearch was started is stored for later reference.

1. ESC is pressed ...

2. ... and is looked up in the isearch map.  It's not there ...

3. ... so instead it's looked up in the main (really viins) keymap,
where it is found to be vi-cmd-mode.

4. The action for vi-cmd-mode is looked up in the internal "widget"
list implemented by isearch mode.

5. This action is to toggle the two keymaps, so the main keymap is
swapped for the vicmd keymap, but isearch mode does not exit (this
is where I went wrong -- I forgot that isearch inexplicably allows
you to swap keymaps even though doing so doesn't allow you to move
around and edit the search string).

6. ESC is pressed again ...

7. ... it's still not found in the isearch map ...

8. ... but this time it's not found in vicmd either ...

9. ... so isearch mode exits, restoring the old keymap that was
remembered back at (0).

10. ESC is looked up in the old keymap and the widget is executed,
which (if the old keymap was viins) takes you to vicmd mode.

The point is that at step 6, any key you press that isn't bound in one
of isearch or vicmd will take you out of isearch mode.  As will any
key that isn't bound to one of isearch's limited set of actions.  So
the right answer seems to be that if you want ESC to take you from
isearch to vicmd, you have to bind it to something "illegal"; for
example:

    bindkey -M isearch '^[' beep