history substring search a bit too aggressive sometimes

history substring search a bit too aggressive sometimes

[John Covici]

Hi.  I am having a very annoying problem properly using history
substring search.  It works great if I do up arrow after typing a
string, it will find a string which is not at the beginning which is
great, but if I type a command line and type a string for file name
completion and hit the tab key, it will find items which don't begin
with that string, but do contain a substring.  Then, more annoying, it
will give me the first file it found as my answer, which I do not
want.

I am using version 5.2 and I have the following in my .zshrc
...
autoload -U compinit
compinit -C
zstyle ':completion:*' completer _complete _match _approximate
zstyle ':completion:*:match:*' original only
zstyle ':completion:*:approximate:*' max-errors 1 numeric
zstyle ':completion:*' squeeze-slashes true
HISTFILE="${ZDOTDIR:-$HOME}/.zhistory"       # The path to the history
file.
HISTSIZE=10000                   # The maximum number of events to
save in the internal history.
SAVEHIST=10000                   # The maximum number of events to
save in the history file.

#
# Options
#

setopt BANG_HIST                 # Treat the '!' character specially
during expansion.
setopt EXTENDED_HISTORY          # Write the history file in the
':start:elapsed;command' format.
setopt INC_APPEND_HISTORY        # Write to the history file
immediately, not when the shell exits.
setopt SHARE_HISTORY             # Share history between all sessions.
setopt HIST_EXPIRE_DUPS_FIRST    # Expire a duplicate event first when
trimming history.
setopt HIST_IGNORE_DUPS          # Do not record an event that was
just recorded again.
setopt HIST_IGNORE_ALL_DUPS      # Delete an old recorded event if a
new event is a duplicate.
setopt HIST_FIND_NO_DUPS         # Do not display a previously found
event.
setopt HIST_IGNORE_SPACE         # Do not record an event starting
with a space.
setopt HIST_SAVE_NO_DUPS         # Do not write a duplicate event to
the history file.
setopt HIST_VERIFY               # Do not execute immediately upon
history expansion.
setopt HIST_BEEP                 # Beep when accessing non-existent
history.
 source ~/zsh-history-substring-search.zsh

I am sure its me as I am rather new at this, so could someone tell me
what I am doing wrong here.

Thanks in advance for any suggestions.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: history substring search a bit too aggressive sometimes

[Peter Stephenson]

On Sun, 28 Aug 2016 09:01:56 -0400
John Covici <covici@ccs.covici.com> wrote:
> Hi.  I am having a very annoying problem properly using history
> substring search.  It works great if I do up arrow after typing a
> string, it will find a string which is not at the beginning which is
> great, but if I type a command line and type a string for file name
> completion and hit the tab key, it will find items which don't begin
> with that string, but do contain a substring.

Completion behaves differently from history searching --- it's a
completely different system with very little in common.  If your problem
is really with completion the history substring search is irrelevant as
far as the zsh settings are concerned.

It sounds like you're complanining that e.g. (all examples fictitious):

% mycommand wot-i-typed<TAB>

can be expanded to

% mycommand stuff-at-start-wot-i-typed-stuff-at-end

whereas you don't want to see matches beginning with anything other than
"wot-i-typed", right?

> Then, more annoying, it
> will give me the first file it found as my answer, which I do not
> want.

I think you're saying it inserts the first file on the command line even
if it is ambiguous, whereas you just want (presumably) the unambiguous
prefix.  It might have been put into menu completion mode, which you can
test because then TAB cycles through matches (you don't have to live
with this, however).

If I've understood these correctly, they are both down to configuration
for the completion system.  You'll need to do a bit more research, but
we can probably explain the results.

I don't see anything in the .zshrc you posted that helps, but I do see

 source ~/zsh-history-substring-search.zsh

which could have anything in it (it is not something supplied by the zsh
development team).  That's probably the first thing to look at.

For the first problem, I suggest running "zstyle -L" and seeing if there
are any styles referring to "matcher" or "matcher-list".  One thing this
can do is allow wildcards at the start of the string, i.e. the effect
you have.  (There are other ways of controlling matching but they're not
as general so less likely to be causing the effect.)

For the second, there are various ways of getting into menu completion,
if that's what it is.  "setopt" will tell you if the menucomplete option
is on, and the "zstlye -L" list might reveal styles that refer to
"menu".

pws