zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
To: zsh-workers@sunsite.auc.dk
Subject: Re: match again
Date: Tue, 01 Feb 2000 18:45:30 +0000	[thread overview]
Message-ID: <E12FiFx-0004P6-00.2000-02-01-18-42-29@mail4.svr.pol.co.uk> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Mon, 31 Jan 2000 14:01:49 +0100." <200001311301.OAA03360@beta.informatik.hu-berlin.de>

Sven Wischnowsky wrote:
> But, before we start modifying docs are something like this, I'd like
> to repeat the question: would it be ok for everyone to make completer
> names be preceeded by two colons? With that we could use this kind of
> pattern:
> 
> > That means this example from the doc is wrong, does it not?
> > 
> >      To be able to share the same specifications one has set up for the
> >      GNU version of the ls command one can use:
> > 
> >           zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
> >                              ^^^
> 
> ... which is indeed wrong for the current state of the code. And I
> really, really don't like having to use patterns like `:completion*:...'.
> The only reason I didn't do that was because I had added the `::cmd:'
> thing at that time already.

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.

> And: any suggestion for how to test the completer style with a tag?
> Use the `default' tag (that just sounds weird, somehow, but maybe this 
> is only my problem).

Well, with the way described above it becomes much clearer what an empty
tag means.  You'd have something like `:completion::::'.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>


  reply	other threads:[~2000-02-01 18:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-31 13:01 Sven Wischnowsky
2000-02-01 18:45 ` Peter Stephenson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-02-02  9:21 Sven Wischnowsky
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=E12FiFx-0004P6-00.2000-02-01-18-42-29@mail4.svr.pol.co.uk \
    --to=pws@pwstephenson.fsnet.co.uk \
    --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).