From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Completing parameter names that have yet to be set.
Date: Mon, 14 Aug 2000 10:01:57 +0200 (MET DST) [thread overview]
Message-ID: <200008140801.KAA02101@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Felix Rosencrantz's message of Sun, 13 Aug 2000 22:51:43 -0700 (PDT)
Felix Rosencrantz wrote:
> I was unaware of the "fake" style. I just looked at _parameter before
> posting. It seems that "fake" covers the functionality I was thinking
> about for files. It seems that _parameters also needs the ability to
> fake values as my copy does. There probably are other places where fake
> could be used.
As I said, that's why I used a generic name (I haven't thought of
other places where it may be useful yet, though).
> ...
>
> It seems whatever format is used for "fake-parameters", it should allow
> the user to specify descriptions. Also type information would be nice.
That may be another difference, I think. I.e., I'm not sure if the
descriptions are useful everywhere. In the case of the fake-style-for-
files, listing them separately may get a bit complicated (control-flow-
wise in _path_files).
Question to everyone: should we change `fake' to `fake-files' now?
And how important do you consider allowing users to give a (optional)
description for them? (I.e.: for the faked *files*.)
> One thing I really like about the fake style used for files is that
> it provides a mechanism for context based on the directory of the
> completion. I've wondered if there is a way to generalize this so that
> other styles could be based on the directory of completion (or other
> information).
>
> The completion system has so many styles that allow the user to tweak
> completion. All these different styles provide hooks to the various
> tools of the completion. Different situations require different tools.
Note the word `tools'. Isn't that synonym for `commands' here?
Anyway, one can always program that with `zstyle -e', I think.
(But yes, in this case at least, the directory where we complete in is
indeed context information. I don't have the slightest idea where we
could make that information available for easy matching, though. I
mean, a completion-context with a pathname in it looks weird. And to
allow to specify the glob patterns based in it we would have to test
it in _files, and _path_files (if it was called directly). Hm.)
> ...
>
> It seems that the ability to configure styles based on additional
> information not found in the context requires the ability to treat a
> group of styles as a single whole, and quickly set/unset a group of
> styles. I vaguely remember something like this was talked about, but
> don't remember what was decided.
I only said several times that I would wish I had an idea how to do
that ;-)
This kind of feeling comes from the times when I wished we had easy
ways to support multiple sets of <insert-your-favorite-feature>,
e.g. histories, key bindings, etc.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-08-14 8:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-14 8:01 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-09-06 7:41 Sven Wischnowsky
2000-09-06 7:00 Felix Rosencrantz
2000-08-14 8:03 Sven Wischnowsky
2000-08-14 5:51 Felix Rosencrantz
2000-08-14 7:15 ` Bart Schaefer
2000-08-11 7:54 Sven Wischnowsky
2000-08-11 6:30 Felix Rosencrantz
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=200008140801.KAA02101@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@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).