zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk, 258431@bugs.debian.org
Subject: Re: default tag-order (was Re: zsh 4.2.1-test-A)
Date: Sun, 08 Aug 2004 19:25:39 +0200	[thread overview]
Message-ID: <17811.1091985939@trentino.logica.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.61.0408080837190.16667@toltec.zanshin.com>

You wrote:

> I'm confused by this suggestion.  If there's no options tag, the tag-order 
> doesn't make any difference, because it's in the second group of tags.  
> And in the case of cdrecord, there _is_ an options tag.  How would that
> proposed change help?

Well the options aren't completed in the same tag loop so it doesn't
affect _cdrecord. _arguments just doesn't get used that way. Checking
for the other tags ((|*-)argument-* (|*-)option[-+]* or values) doesn't
particularly help given that there is only a problem when they (or
values to be precise) are there.

> > Default tag-orders really need thinking about in general. It'd be nice
> > to be able to specify them from completion functions themself.
> 
> Why is that not possible?  For example, several completion functions set 
> the cache-policy style if it's not already set.

Doing it that way is ugly. And not just because the function has to
lookup the style before setting it. It just seems wrong to me for
completion functions to set styles. There's quite a lot of places where
default tag orders would be useful so it would potentially clutter the
style list. For all other styles, we don't set the style to achieve a
default so why should we make an exception for tag-order. It is also the
case that a certain zstyle context will apply to more than one tag loop
so you can't always give them different defaults.

I think the cache-policy stuff would be far better handled by guarding
the policy functions with (( $+functions[_foo_caching_policy] )) ||
I don't see why they should have a style when anything else you want to
override is just done by having a replacement function. Judging by
20211, the cache stuff isn't used much anyway.

Oliver


  parent reply	other threads:[~2004-08-08 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200408061350.i76DovBi028948@news01.csr.com>
2004-08-06 18:03 ` zsh 4.2.1-test-A Clint Adams
2004-08-07 13:40   ` Oliver Kiddle
2004-08-08  4:45     ` Clint Adams
2004-08-08 14:40       ` default tag-order (was Re: zsh 4.2.1-test-A) Oliver Kiddle
2004-08-08 16:03         ` Bart Schaefer
2004-08-08 16:46           ` Bart Schaefer
2004-08-08 17:25           ` Oliver Kiddle [this message]
2004-08-08 17:54         ` Oliver Kiddle
2004-08-10 18:16         ` Oliver Kiddle

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=17811.1091985939@trentino.logica.co.uk \
    --to=okiddle@yahoo.co.uk \
    --cc=258431@bugs.debian.org \
    --cc=zsh-workers@sunsite.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).