From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: match again
Date: Wed, 2 Feb 2000 10:21:09 +0100 (MET) [thread overview]
Message-ID: <200002020921.KAA10135@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Tue, 01 Feb 2000 18:45:30 +0000
Peter Stephenson wrote:
> It looks better, but is it enough to sort out all possible cases where you
> might want to use `:*:'? Or are there even more cases where we might get
> into trouble with that? I'm worried we could be barking up the wrong tree,
> and should, for example, fix the fields of the pattern to
> e.g. :completion:completer:command-or-context:arguments:tag (this may not
> even be complete) with unrequired fields set to null strings but retaining
> the colons, so you can always guarantee to pick out the appropriate
> bit (unless there are extra colons inside the fields). This will mean a
> lot of multiple colons, but I don't think that's a major problem (in fact,
> that's where we're heading anyway).
>
> Any other uses of colons in the pattern --- e.g. to indicate a command name
> --- would have to be rethought, but replacing the second `:' by a `-' might
> be enough. Or just have commands and other contexts specified in different
> fields (i.e. one is ...::command:... and the other ...:context::).
>
> Probably the big headache would be enforcing consistency in the code as it
> stands --- virtually every use of styles would have to be rewritten. But
> I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
> a particular word of $acontext to check.
Yes, I'd like that, too -- and changing almost every function has been
done before. I don't think that we would need to change that many
functions anyway.
The problem is with `nested' completions a la `cvs add ...' where it
is very convenient to be able to stuff the `add' into the context
name, but maybe `cvs-add' is just as good. And in cases like
`find . -exec cvs add <TAB>' we probably don't need to have both
`find' and `cvs' in the final context name.
All this has been suggested before, btw (by Bart). He even suggested
using an array. I'd prefer to still use a simple string to make
testing and re-defining faster and cheaper, but if we don't use extra
fields for the `nested' cases above, it would be nice to be able to
access fields directly -- which suggests using a tied array at least
in those functions that modify some fields (instead of just
saving/restoring $curcontext or appending one of the basic name
components).
We may need another field: my suggested nslookup function sticks a
`:nslookup' after the `:completion' -- but maybe we don't really need
that. For things like the `cvs-add' above and the number of errors
accepted by correct and approximate using another separation character
might be a good idea... opinions?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-02-02 9:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-02 9:21 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-01-31 13:01 Sven Wischnowsky
2000-02-01 18:45 ` Peter Stephenson
2000-01-31 9:13 Sven Wischnowsky
2000-01-31 9:06 Sven Wischnowsky
2000-01-31 11:01 ` Bart Schaefer
2000-01-28 10:05 Sven Wischnowsky
2000-01-28 16:47 ` Alexandre Duret-Lutz
2000-01-30 1:27 ` Bart Schaefer
2000-02-01 10:48 ` Alexandre Duret-Lutz
2000-01-27 16:31 Andrej Borsenkow
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=200002020921.KAA10135@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).