From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>,
<zsh-users@sunsite.auc.dk>
Subject: Re: completion with globbing, take 2
Date: Tue, 19 Sep 2000 02:02:50 +0000 [thread overview]
Message-ID: <1000919020251.ZM30124@candle.brasslantern.com> (raw)
In-Reply-To: <000401c0219b$6fc3e310$21c9ca95@mow.siemens.ru>
On Sep 18, 10:08pm, Andrej Borsenkow wrote:
} Subject: RE: completion with globbing, take 2
}
} > Not quite; he's written a stripped-down version of "_expand with the
} > completions style defaulted to true, followed by _match".
}
} I tentatively disagree. The main difference between _expand and
} _match is who generates matches. Completion aside, _expand generates
} "matches" (that are actually expansions in this case) itself.
Not when the completions style is set. Then it assigns compstate[insert]
and returns, leaving it to the following completers to generate matches.
} _match takes all possible completions and tries to match them against
} given pattern. See the difference?
Yes, but ... _match doesn't "take" anything; it, too, calls _complete,
maybe more than once, with different values of compstate[pattern_match].
Try this in zsh -f:
zstyle ':completion:*' completer _expand _match
zstyle ':completion:*' completions true
autoload -U compinit ; compinit -D
and then look at a trace from ^X?. The only interesting things that
happen before _complete is called are assignments to compstate[insert]
and compstate[pattern_match], exactly as in Jay's little function.
} To write stripped-down version of _expand means [...]
I didn't say "stripped-down version of _expand", I said "stripped-down
version of _expand with the completions style defaulted to true", which
takes a completely different code branch.
} As I wrote, it is just a coincidence that file completion is using the same
} pattern from command line, hence _expand and _match look alike.
I'd mostly agree with you if _match were replaced by _complete in the
style above.
} BTW thank you all for finally making it clear to me :-)))
It's getting a lot clearer to me, too ...
} > The most obvious thing would be to have _match itself recognize the
} > completions style.
}
} Is is not enough. See later.
Not enough for what?
} O.K. about adding completions style to _match. Note, that if
} completions style is set for _expand it just calls _complete.
No. If the completions style is set for _expand it doesn't call anything.
It only calls _complete in the expand-word:* context; we're talking about
the :completion:* context.
} If no matches were generated, it does it itself and now has full
} control over possible tags.
No, it always returns without doing anything itself when the completions
style is set. expand-word:* just determines whether it returns success,
otherwise it always returns failure.
} But what we actually need, is to get completions that _complete just
} generated
No, we just need to call complete and let it generate things, just like
_match always does. We just have to tell _complete to insert everything
that it generates. Try the following patch with
zstyle ':completion:*' completer _match
zstyle ':completion:*' completions true
bindkey '\t' complete-word
(Arguably "completions" is not the best name for this style as it's used
here, but for purposes of example ...)
Index: Completion/Core/_match
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/_match,v
retrieving revision 1.14
diff -c -r1.14 _match
--- Completion/Core/_match 2000/04/11 15:07:44 1.14
+++ Completion/Core/_match 2000/09/19 01:58:57
@@ -20,6 +20,7 @@
zstyle -s ":completion:${curcontext}:" match-original orig
zstyle -b ":completion:${curcontext}:" insert-unambiguous ins
+zstyle -t ":completion:${curcontext}:" completions && compstate[insert]=all
# Try completion without inserting a `*'?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
next prev parent reply other threads:[~2000-09-19 2:10 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
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 [this message]
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=1000919020251.ZM30124@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=Andrej.Borsenkow@mow.siemens.ru \
--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).