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

[darwin <darwinskernel@xxxxxxxxx>]

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.