From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@math.gatech.edu
Subject: Re: Compctl completion tweaking
Date: Tue, 30 Jun 1998 07:49:21 +0200 (MET DST) [thread overview]
Message-ID: <199806300549.HAA20725@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Mon, 29 Jun 1998 08:48:10 -0700
Bart Schaefer wrote:
> ...
>
> I do not advocate changing the current meaning of `+'. I don't think
> we should use a shell option. I'm not very excited about `++' as the
> choice for inclusive-or, though; the compctl syntax is already too
> cryptic (which I suppose might be an argument for not worrying about
> making it more so, but ...).
>
> It'd be nice to choose something that currently produces an error, so
> as not to co-opt anything from any existing working compctl. (`++' is
> now taken as a command name.)
>
I would like to agree, but the problem is that there are currently
only few things that produce an error with compctl and I wouldn't like
to use an unused option character for something is behaves more like
`+' (separating option lists) than like an option.
> } Btw: when implementing this, we also could cleanup the code a bit by
> } storing more than just the string to insert for each match, e.g.:
> }
> } - some kind of prefix/suffix and the whole string
> } (this would allow us to make the `-/' flag accept multiple directories)
>
> I'm confused. You mean make the -W flag accept multiple directories?
>
Yes, sorry, little confusion in my internal hash tables...
> } - a weight (for sorting the matches as the user wishes, see above)
>
> Hrm. I'd rather just list the matches in the order they're specified
> in the compctl command, without re-sorting. And similarly, don't sort
> the value of $reply. Just one control flag to say "don't sort" would
> be sufficient, I think.
>
Maybe I should have been more precise here. I didn't meant that the
user would have to worry about giving weights to the compctl options
(I can't even think of a compctl-syntax for that). What I meant was
that the user may say for different option lists (those separated by
inclusive-or's) that the results of this lists should be sorted
separately. Of course that could be changed to: not sorted at all, and
especially not sorted into the whole list.
The completion code would derive the weights from this automatically.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1998-06-30 6:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-06-30 5:49 Sven Wischnowsky [this message]
1998-06-30 19:02 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
1998-07-06 6:37 Sven Wischnowsky
1998-07-01 6:13 Sven Wischnowsky
1998-07-03 19:33 ` Bart Schaefer
1998-06-29 8:40 Sven Wischnowsky
1998-06-29 15:48 ` Bart Schaefer
1998-06-26 5:44 Sven Wischnowsky
1998-06-26 18:59 ` Bart Schaefer
1998-06-24 11:00 Andrej Borsenkow
1998-06-24 7:13 Sven Wischnowsky
1998-06-25 19:08 ` Bart Schaefer
1998-06-24 6:19 Sven Wischnowsky
[not found] <358FC264.1C7A9EFA@bigfoot.com>
1998-06-23 19:04 ` Bart Schaefer
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=199806300549.HAA20725@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@math.gatech.edu \
/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).