zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-users@zsh.org
Subject: Re: history substring search a bit too aggressive sometimes
Date: Tue, 30 Aug 2016 11:17:53 +0100	[thread overview]
Message-ID: <20160830111753.4d116fbf@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <m3wpj1qc6z.wl-covici@ccs.covici.com>

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


      reply	other threads:[~2016-08-30 10:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-28 13:01 John Covici
2016-08-30 10:17 ` Peter Stephenson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160830111753.4d116fbf@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).