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

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

[darwin]

hello,

i've this in .zshrc

zle-line-init(){
	zle history-incremental-search-backward }
	#zle -K vicmd;}
zle -N zle-line-init
bindkey -M isearch "^I" vi-repeat-search
# bindkey -M isearch "^I" history-incremental-search-forward

1. it _almost_ does what i want it to do which is to start off on bck-i-search. the idea is that with cli as the main interface, user have issued his most commonly used commands already and so it makes more sense to look into .histfile (or whereever) first. as a result the system is now screaming. well, it's all great util user wants to issue a never-issued-before command. one way to do this is to get out of bck-i-search and do it there (viins, vicmd, what have you). but a more elegent solution, i think, is to have shell start digging the $PATH for possible completions once it's done with the .histfile. that way performance wouldn't be comprimised and user is still doing the same thing (keep begging the tab) to get to where he wants to go. is there a way to do that? 

2. the commented lines are what i had before. with all my _elegant_ solutions there are still situations when i would still want to edit a command and that's when i would prefer to go back to vicmd (it's a matter of muscle mm really). but with my current setting:
	bindkey -M isearch '^[' send-break
hitting esc gets me out of bck-i-search and dumps me into emacs! i even tried with
	bindkey -v
but that's half-baked because i esc bck-i-search into viins and not vicmd. i would appreciate any help with this one also and thanks in advance.

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

[Bart Schaefer]

On Nov 22, 11:34am, darwin wrote:
}
} i've this in .zshrc
} 
} zle-line-init(){
} 	zle history-incremental-search-backward }
} 	#zle -K vicmd;}
} zle -N zle-line-init
} bindkey -M isearch "^I" vi-repeat-search
} # bindkey -M isearch "^I" history-incremental-search-forward
} 
} 1. it _almost_ does what i want it to do which is to start off on
} bck-i-search.

If I understand correctly what you're going for here, then I'd suggest
that you try the predictive typing widgets (Functions/Zle/predict-on);
except that you seem to be a vi-mode user, and I'm not confident that
insert-and-predict will work well in that context.

} well, it's all great util user wants to issue a never-issued-before
} command. one way to do this is to get out of bck-i-search and do it
} there (viins, vicmd, what have you). but a more elegent solution,
} i think, is to have shell start digging the $PATH for possible
} completions once it's done with the .histfile.

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.  If you
want TAB to go straight out of isearch mode and into completion, then
you must not bind TAB to something else in the isearch map; you can't
have it both ways.

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.

} 2. the commented lines are what i had before. with all my _elegant_
} solutions there are still situations when i would still want to edit
} a command and that's when i would prefer to go back to vicmd (it's
} a matter of muscle mm really). but with my current setting:
} 	bindkey -M isearch '^[' send-break
} hitting esc gets me out of bck-i-search and dumps me into emacs!

That can only mean you don't have "bindkey -v" in effect globally.
*With* bindkey -v, send-break should take you from isearch to viins,
as you note here:

} i even tried with bindkey -v but that's
} half-baked because i esc bck-i-search into viins and not vicmd.

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.

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

[darwin]

On Tue, Nov 23, 2010 at 04:40:48PM -0500, darwin wrote:
> On Tue, Nov 23, 2010 at 12:12:25AM -0800, Bart Schaefer wrote:
> > On Nov 22, 11:34am, darwin wrote:
> > }
> > } i've this in .zshrc
> > } 
> > } zle-line-init(){
> > } 	zle history-incremental-search-backward }
> > } 	#zle -K vicmd;}
> > } zle -N zle-line-init
> > } bindkey -M isearch "^I" vi-repeat-search
> > } # bindkey -M isearch "^I" history-incremental-search-forward
> > } 
> > } 1. it _almost_ does what i want it to do which is to start off on
> > } bck-i-search.
> > 
> > If I understand correctly what you're going for here, then I'd suggest
> > that you try the predictive typing widgets (Functions/Zle/predict-on);
> > except that you seem to be a vi-mode user, and I'm not confident that
> > insert-and-predict will work well in that context.
> 
> let me look into that.
> 
> > 
> > } well, it's all great util user wants to issue a never-issued-before
> > } command. one way to do this is to get out of bck-i-search and do it
> > } there (viins, vicmd, what have you). but a more elegent solution,
> > } i think, is to have shell start digging the $PATH for possible
> > } completions once it's done with the .histfile.
> > 
> > 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. i.e. don't limit the search to .histfile but also don't lump $PATH
> into history because match is most likely in .histfile. this is not the 
> situation where i want to get out of isearch. that's mostly my second question.
> 
> > If you
> > want TAB to go straight out of isearch mode and into completion, then
> > you must not bind TAB to something else in the isearch map; you can't
> > have it both ways.
> 
> i didn't ask for TAB to take me out of isearch. but come to think of it,
> it's a neat idea to have TAB take the user to viins once isearch has exhausted
> the $PATH.
> 
> > 
> > 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? 
> 
> > 
> > } 2. the commented lines are what i had before. with all my _elegant_
> > } solutions there are still situations when i would still want to edit
> > } a command and that's when i would prefer to go back to vicmd (it's
> > } a matter of muscle mm really). but with my current setting:
> > } 	bindkey -M isearch '^[' send-break
> > } hitting esc gets me out of bck-i-search and dumps me into emacs!
> > 
> > That can only mean you don't have "bindkey -v" in effect globally.
> > *With* bindkey -v, send-break should take you from isearch to viins,
> > as you note here:
> > 
> > } i even tried with bindkey -v but that's
> > } half-baked because i esc bck-i-search into viins and not vicmd.
> > 
> > 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.

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

[Bart Schaefer]

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