zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@berkom.de>
To: zsh-workers@sunsite.dk
Subject: Re: new fake style, completion grouping etc
Date: Wed, 6 Feb 2002 11:49:18 +0100	[thread overview]
Message-ID: <15457.2606.979526.636966@wischnow.berkom.de> (raw)
In-Reply-To: <20020206093357.40994.qmail@web9305.mail.yahoo.com>


Oliver Kiddle wrote:

> ...
> Sven wrote:
> 
> > > I'm not sure that I like the idea of using the group name - seems a
> bit
> > > hacky. I'd be more inclined to make _arguments call _guard for some
> > > special action syntax, e.g. :-/pattern/.
> > 
> > That's why I didn't do it yet.
> 
> I'm fairly convinced _guard needs to be using _message's -e so we need
> something.

I need to think some more then.

> ...
> 
> > since I'm far from sure (actually, I doubt) we'll ever be able to
> > cleanly fix this, we should probably re-think this.
> > 
> > The problem isn't just that the layout might be `not ideal', it may
> > become completely messed up or without duplicates removed.
> 
> The only places we do anything special with the layout that I can think
> of, it is purely to get a numerically sorted list. A compadd option for
> numerically sorted groups as per my suggestion would handle that nicely
> as the sorting only takes place after all matches, including fakes have
> been added.
> 
> As far as I can tell, the only case where duplicates are removed is if
> neither match has a description. I suppose the ideal would be for the
> fake match to replace the normal match so as to potentially change it's
> description. So with fake matches being added first, the first of a
> duplicate could be kept within a group.
> 
> Do we ever want to have duplicates with the same description in a
> group? And, do you know of any cases where the layout is anything other
> than a sorted or numerically sorted list?

Layout manipulation is at the core of _describe, used for options and
values, as in the cvs-admin-k-case we were discussing. It's what
allows the nicely aligned displays of options with the same
description. Those descriptions aren't added to the matches
themselves, they are basically added as separate string to be shown
and those strings have to be added together with the matches in just
the right order. That's why we need -V-groups there.

One solution would be to put some more work into lookup of the fake
style, i.e.: change some of our utility function to look it up
themselves so that they can correctly merge the faked matches into the
normal matches they are handling. _describe, probably _arguments and
others would be candidates for special treatment. for those we could
probably add an option to _description and friends meaning that the
fake style shouldn't be handled there.

Distributing lookup of the fake style over seeral functions isn't
nice, but the treatment in some functions is so special that it
probably allows exceptions. The stuff we have now would then be used
in normal cases where it should work good enough. And if the faked
matches stick out a bit in custom-sorted lists I'm not too concerned
(or at least think that a solution for this could be postponed until
we run into problems).

> ...
> 
> Looks good. I wasn't expecting the different behaviour for
> f() { _wanted -x foos expl foo compadd } and
> f() { _message -e foos foo }
> 
> The former gives both the description (foo) and the `No matches for'
> message. This seems to be _message setting _comp_mesg. I don't think
> the No matches for message is relevant when we are listing the foo
> description so I think _description should also set _comp_mesg when
> $xopt is -x.

Actually, I don't think so. The first one tells me that we try to
complete something but there are no matches, wheres in the second case
we only display a message, not trying to complete anything.

Another option? -s for `silent' or `-q' or something?

> I also think it might be a good idea to optionally allow a different
> format string for -x descriptions - it'd just be another style lookup.

Suggestions for a name? Looks like a relatively simple change, indeed.


Bye
  Sven

-- 
Sven Wischnowsky                    wischnow@informatik.hu-berlin.de


  reply	other threads:[~2002-02-06 10:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-18 18:24 Re PATCH _file_systems & Re zstyle for _arguments feature request Oliver Kiddle
2002-01-22 10:19 ` Sven Wischnowsky
2002-02-01 17:03   ` new fake style, completion grouping etc Oliver Kiddle
2002-02-04  8:57     ` Sven Wischnowsky
2002-02-05 16:13       ` Oliver Kiddle
2002-02-05 16:24         ` Sven Wischnowsky
2002-02-06  9:33           ` Oliver Kiddle
2002-02-06 10:49             ` Sven Wischnowsky [this message]
2002-02-06 15:57               ` Oliver Kiddle
2002-02-25  9:07             ` Sven Wischnowsky
2002-02-25  9:10               ` Sven Wischnowsky

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=15457.2606.979526.636966@wischnow.berkom.de \
    --to=wischnow@berkom.de \
    --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).