From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14729 invoked by alias); 24 Nov 2010 08:25:15 -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: 15574 Received: (qmail 10228 invoked from network); 24 Nov 2010 08:25:13 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <101124002459.ZM16680@torch.brasslantern.com> Date: Wed, 24 Nov 2010 00:24:59 -0800 In-reply-to: <20101123214048.GA8029@WALL-E> Comments: In reply to darwin "Re: *don't* fail when bck-i-search is over" (Nov 23, 4:40pm) References: <20101122163447.GA2658@WALL-E> <101123001225.ZM14178@torch.brasslantern.com> <20101123214048.GA8029@WALL-E> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: *don't* fail when bck-i-search is over MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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