Re: Local/global history with pattern isearch

[Bart Schaefer <schaefer@brasslantern.com>]

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?