From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11135 invoked by alias); 23 Nov 2010 21:46:41 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15573 Received: (qmail 3098 invoked from network); 23 Nov 2010 21:46:30 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.212.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=0JMpN8qeD2ODqaKdtJ97fyi4MGBl937Y/KeLg+q9Sr4=; b=unifumoLnc/VzF3HNVfIe1zrwaeKUMiwH86vhXRXyK1Q0NuV4YmknKNs1KkcGgRxQg F+V3tQTAtVQ4I9HU2QFWPZDP8vYwumUYCRYUfBnl2pN3HeAJnh3ApJkqcKxpQplnpQib 8qDrRDyz0OXI4xPH2KleC8hH6sF15MLxOmI6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=hwkD7mmx21HN1oSuMx/U0kxpwd9Ra+YXOpieTbjMecGrAHMegXTKKvqwe0v18twJnl 5oNgbSNdgFCR8NnRWt7GOuUzL2A5sZTqw4ORKL2Q+psNCsAxhkknZQKbBtSdwTl++wgE I7WeaEeocM+V6H6DnJ1CPKJBqnWxZ2T7abU/w= Date: Tue, 23 Nov 2010 16:46:25 -0500 From: darwin To: Bart Schaefer , zsh-users@zsh.org Subject: Re: *don't* fail when bck-i-search is over Message-ID: <20101123214625.GB1841@WALL-E> References: <20101122163447.GA2658@WALL-E> <101123001225.ZM14178@torch.brasslantern.com> <20101123214048.GA8029@WALL-E> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101123214048.GA8029@WALL-E> User-Agent: Mutt/1.5.18-muttng (2008-05-17) 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.