zsh-users
 help / color / mirror / code / Atom feed
From: "E. Jay Berkenbilt" <ejb@ql.org>
To: schaefer@candle.brasslantern.com
Cc: zsh-users@sunsite.auc.dk
Subject: Re: completion with globbing, take 2
Date: Sun, 17 Sep 2000 19:03:05 -0400	[thread overview]
Message-ID: <200009172303.TAA07756@soup.ql.org> (raw)
In-Reply-To: <1000917184320.ZM19505@candle.brasslantern.com> (schaefer@candle.brasslantern.com)


Okay, with everyone's help, my problem is solved, but the solution
brings up lots of questions.


>   } Several days ago, I wanted to know how I could get zsh to respond to 
>   } 
>   } something *TAB
>   } 
>   } by replacing the * with the list everything that the completion system
>   } would return instead of everything * would match in the current
>   } directory.  I was told to do this:
>   } 
>   } zstyle ':completion:*' completer _oldlist _complete _match
>   } bindkey "^I" complete-word
>
>   More precisely, you were told that Andrej does that.
>
>   Andrej probably wasn't expecting you to use it verbatim, though, because
>   he didn't show you what his settings for the matcher-list style are.  

Right.

>   You
>   didn't say whether you have any settings for matcher-list; if you don't,
>   the _match completer won't do anything.

Sorry -- my original message failed to say that I was starting with
zsh -f with only the completion system loaded and no additional
customization.  This is why I was much more explicit in my second
message.

Also, after reading the code, I don't believe it is true that _match
won't do anything without matcher-list set -- see analysis and
questions below.

>   } I want behavior more like what expand-or-complete does except that I
>   } want only what the completion system would return to be substituted.
>
>   That's what the _expand completer is for.  I believe you want:
>
>   zstyle ':completion:*' completer _oldlist _expand _complete _match
>   zstyle ':completion::expand:*' completions true

This almost worked, and it gave me enough additional information to
get the rest of the way there.  I now have the following:

  zstyle ':completion:*' completer _oldlist _complete _expand _match
  zstyle ':completion::expand:*' completions true
  bindkey "^I" complete-word

This seems to do exactly what I'm looking for.  We'll see whether I've
broken anything.

Removing any of _complete, _expand, or _match or changing the order in
which they appear breaks things.

Now I've analyzed the code and think I understand why this works, but
I'm not 100% certain.  Interestingly, ^X? doesn't work when I do

rmdir *^X?

but that's okay -- I just did setopt xtrace and then

rmdir *TAB

Again, I have just 1, 2, 3, a, b, and c in the currently directory
where 1, 2, and 3 are directories and a, b, and c are files.

Looking at the trace and the code, here's what I think is happening:

_main_complete is called.  It looks up my completers (_oldlist,
_complete, _expand, and _match) and calls then in order.  _oldlist
returns nothing, _complete returns nothing (since no files start with
'*').  Now it starts getting interesting.  _expand is called.  Since I
have set the completions style for expand to true, it sets
compstate[insert]=all which gives me the behavior I'm looking for with
respect to the replacement.  However, since the current context is not
expand-word:*, it does not call _complete and thus just returns 1.
Finally, _match is called.  I don't follow exactly what's going on at
the top of _match, but it doesn't matter.  Since I don't have
match-original set, _match sets compstate[pattern_match]='*' and calls
_complete again.  This time, since compstate[pattern_match] is set,
_complete actually does find matches.

So the right thing happens, but the path to the desired end seems
quite convoluted and counterintuitive to me.  I would never have
figured this out without the significant hints without having to spend
a lot of time grokking this code.

So there end up being two important commands here.  Without this one:

  zstyle ':completion::expand:*' completions true

the call to _expand doesn't set compstate[insert]=all.  Now if I look
at this:

  zstyle ':completion:*' completer _oldlist _complete _expand _match

If we remove _match, then _complete never gets called again with
compstate[pattern_match]='*', so it is essential.  If _expand appears
before _complete, then 

rmdir TAB

by itself inserts all the matches.

So, in summary, it seems that the only thing I'm using expand for is
to get compstate[insert]=all.  The only thing I'm using _match for is
to get _complete to be called with with compstate[pattern_match]='*'.
I can't do this with setopt glob_complete because if I do, then the
first call to _complete will generate matches when it is called before
the call to _expand, so I'll get the menu behavior instead of what I
wanted.  If I put _expand before _complete with these settings, I
always get all matches substituted (as if I had typed the *), which
renders the completion system pretty useless.

So, is my analysis correct?  Am I getting behavior that was intended
here, or have I just stumbled upon a way to do this?  I feel like I'm
getting the desired behavior through a series of coincidences and that
this could change or break pretty easily in the future....

Thanks for all the help.

                                Jay


  reply	other threads:[~2000-09-17 23:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-17 17:50 E. Jay Berkenbilt
2000-09-17 18:43 ` Bart Schaefer
2000-09-17 23:03   ` E. Jay Berkenbilt [this message]
2000-09-18  0:17     ` completion and globbing, part 2 E. Jay Berkenbilt
2000-09-18  6:53       ` Andrej Borsenkow
2000-09-18  9:59         ` insert-all-matches example " Andrej Borsenkow
2000-09-18 17:28           ` completion with globbing, take 2 Bart Schaefer
2000-09-18 18:08             ` Andrej Borsenkow
2000-09-19  2:02               ` Bart Schaefer
2000-09-20 15:06                 ` Andrej Borsenkow
2000-09-20 16:12                   ` Bart Schaefer
2000-09-18 22:07             ` E. Jay Berkenbilt
2000-09-19  2:14               ` Bart Schaefer
2001-02-20  9:55                 ` Job Table Nick Cross
2000-09-18  6:07   ` completion with globbing, take 2 Andrej Borsenkow
2000-10-04 11:14 Sven Wischnowsky

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=200009172303.TAA07756@soup.ql.org \
    --to=ejb@ql.org \
    --cc=schaefer@candle.brasslantern.com \
    --cc=zsh-users@sunsite.auc.dk \
    /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).