zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Sven Wischnowsky <wischnow@berkom.de>, zsh-workers@sunsite.dk
Subject: Re: Test failures in artih and arguments
Date: Wed, 30 Jan 2002 17:37:26 +0000	[thread overview]
Message-ID: <1020130173726.ZM12752@candle.brasslantern.com> (raw)
In-Reply-To: <15447.46235.229244.15033@wischnow.berkom.de>

On Jan 30,  9:53am, Sven Wischnowsky wrote:
} 
} Bart Schaefer wrote:
} 
} > So it seems to me that we need a wildcard indicator of some kind, so
} > that _arguments can add the match `-<wild>'.  This would allow the `-'
} > to be treated as a prefix of the two matches `-x' and `-<wild>'.
} 
} Good analysis. And now I'm back at thinking: do we really want that?
} 
} If we don't want to be able to complete the options, we would just
} have to add `$PREFIX' or some such as a possible match.

That would work provided that it was added with the equilvalent of

	compadd -S '' $PREFIX

so that no space would be added after it.
 
} Sometimes I think that in such cases we should only force the message
} to be displayed, even if a match was accepted.

Correct me if I'm wrong, but that would result in something like

zsh% foo -<TAB>
zsh% foo -x 
Completing arg

(assuming "zstyle :completion:* format 'Completing %d'")

That seems a bit confusing.  Or did you mean that, if there was a message
to be forced, then the accepted match would not be completed? That would
be OK, I think.

} And this is also affected by the fake style thing we are discussing
} (which might turn a case of `displaying a message' into `adding some
} matches').

Right, the question becomes how to tell when the message really should
be forced out, and when the faked matches should be used as the possible
completions instead.

Perhaps the thing to do is to treat <wild> as a style context rather than
as a possible match, and determine how to behave based on a style set in
that context.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2002-01-30 17:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-23 14:51 Felix Rosencrantz
2002-01-23 16:17 ` Peter Stephenson
2002-01-25  8:58 ` Sven Wischnowsky
2002-01-27 19:20   ` Bart Schaefer
2002-01-30  8:53     ` Sven Wischnowsky
2002-01-30 17:37       ` Bart Schaefer [this message]
2002-02-25  9:14         ` 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=1020130173726.ZM12752@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=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).