zsh-workers
 help / color / mirror / code / Atom feed
From: "Oliver Kiddle" <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: new fake style, completion grouping etc
Date: Wed, 6 Feb 2002 15:57:13 +0000 (GMT)	[thread overview]
Message-ID: <20020206155713.35364.qmail@web9307.mail.yahoo.com> (raw)
In-Reply-To: <15457.2606.979526.636966@wischnow.berkom.de>

 --- Sven Wischnowsky <wischnow@berkom.de> wrote: > 

> Layout manipulation is at the core of _describe, used for options and

I need to have a closer look at what _describe is doing. I thought the
layout was more done in C.

> 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

Sounds like a reasonable possibility.

> > 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.

I disagree. Because _wanted has -x, I'd interpret it as
being that it possibly adds a few matches as a convenience but
is not adding all the possibilities. The _message is just a more
readable syntax for those cases where we haven't even attempted
to generate matches.

The void below the description communicates that the system is
unable to offer useful matches for the tag. The name of the tag
is the useful information and that is already displayed (in the
description). A "No matches for" message is useful as a way of
communicating tags which could go in the current context if any
possibilities matched. Perhaps, better phrasing would be
"No possible ".

My intention for -x was that it could be used wherever added
matches are not a complete list, e.g. hostname completion,
destination filename from the mv command.

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

It isn't clear to me in what cases they would/wouldn't be used.
And I'd want them in every place where -x is.

> > 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.

If I'd been able to think of a good name, I might have done a patch
myself. The best I can think of is probably `held-descriptions'. I
can think of better words than `held' but they are all a bit long
resulting in a very long tag name. It should probably fall back on
whatever format is set for the `descriptions' tag. Actually, I think
the `descriptions' tag would be better named `heading' but I suppose
it is too late now.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


  reply	other threads:[~2002-02-06 15:57 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
2002-02-06 15:57               ` Oliver Kiddle [this message]
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=20020206155713.35364.qmail@web9307.mail.yahoo.com \
    --to=okiddle@yahoo.co.uk \
    --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).