From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 618 invoked by alias); 3 Mar 2014 05:44:20 -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: 18548 Received: (qmail 14146 invoked from network); 3 Mar 2014 05:44:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 From: Bart Schaefer Message-id: <140302214400.ZM1868@torch.brasslantern.com> Date: Sun, 02 Mar 2014 21:44:00 -0800 In-reply-to: Comments: In reply to Jan Larres "Local/global history with pattern isearch" (Mar 3, 5:19pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Local/global history with pattern isearch MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 3, 5:19pm, Jan Larres wrote: } Subject: Local/global history with pattern isearch } } zle -N history-incremental-pattern-search-backward } bindkey '^r' history-incremental-pattern-search-backward } } Unfortunately this still isn't quite working for me. It does use the } shared history when starting the search, but when pressing ^r again it } fails to find any other results, neither in the shared nor in the local } history. This *seems* to be working for me in zsh-5.0.5-71-g965d730 (the latest pull from git as of my writing this). I find multiple results with repeated presses of ^R, and adding zle -M "$ZLE_STATE" to the zle-isearch-update function shows "globalhistory insert" as expected. I also tried removing zle set-local-history from zle-isearch-update and found that $ZLE_STATE still reports "globalhistory", so the update hook may not be needed. } The custom function also doesn't get called again in that case, } I don't know if that's normal behaviour or not. As I think was mentioned in the thread when this first came around, the isearch routines don't use true keymaps; they use the widget names of regular keymaps but substitute their own widget actions. This is why the custom name must be "history-incremental-pattern-search-backward" in order for this to work at all. So yes, this is expected. (Actually you could probably get away with naming it something else as long as you explicitly bound the search-again key in the isearch keymap to history-incremental-pattern-search-backward.) HOWEVER, I think this may be the source of the bug. Repeating the search does not exit from the isearch keymap, so zle-isearch-exit is always called between any two calls of the custom widget. Thus the [[ $LASTWIDGET != history-incremental-pattern-search-backward ]] test is probably incorrect part of the time. Try changing to history-incremental-pattern-search-backward() { NUMERIC=0 zle set-local-history zle .history-incremental-pattern-search-backward "$@" } and see if that clears it up?