From: Felix Rosencrantz <f_rosencrantz@yahoo.com>
To: Oliver Kiddle <okiddle@yahoo.co.uk>,
zsh-workers <zsh-workers@sunsite.dk>
Subject: Re: zstyle for _arguments feature request
Date: Mon, 10 Dec 2001 15:24:40 -0800 (PST) [thread overview]
Message-ID: <20011210232440.51352.qmail@web10403.mail.yahoo.com> (raw)
In-Reply-To: <3C10B570.35567EEF@yahoo.co.uk>
Oliver Kiddle wrote:
>Yes, this could be useful. The form in which I'd like to see it in is a
>more general version of the fake-files and fake-parameters styles and
>available in all contexts as opposed to just in _arguments.
I think that would be ok. Though it would also be nice to remove
some|all entries from the list being provided to the user. Also, it
would be nice to provide help text for items. I don't think that can be
currently done with the fake-* styles.
Also, since I was limiting the scope to _arguments, it would be possible
to provide alternative action function or state.
>> _find the -fstype flag spec is missing ext2 used by linux:
>>
>> '*-fstype:filesystem type:(ufs 4.2 4.3 nfs tmp mfs S51K S52K)' \
>
>In the case of this specific issue, should we maybe factor the
>filesystem completion out of _mount into a new _filesystems that can
>also be used here?
Yes, something like that could be done for this specific case. Playing
with the completion generation stuff, I find that I want to use code
from the "state" actions of existing completion functions a lot. It's
not possible. It seems that unless a state is very specific to a
particular command, we should recommend people create new action
functions over action states.
>> It seemed that this would be a new use for zstyle, and people
>> might have some comments wrt using zstyle to define the completion
>> rather than just modifying the behavior of completion.
>
>We should be careful how we document this. It should be a way of
>tweaking available completions to fake extra matches and should not be
>a substitute for writing functions.
This is the sort of feedback I was interested in. Though, it's not
clear to me why a completion function is better. I've sort of thought
that making a completer that got much of it's information via styles
might be easy to create.
>> * A completer for printf format strings using the "%" string. I
>> think the real benefit would be the ability to see documentation for
>> the different format characters.
>
>Yes it would be useful but perhaps a little messy to implement. I
>thought about doing printf completion for printf as opposed to find
>which is less useful. I suspect that this might be a good place to use
>_regex_arguments but I've yet to look in any detail.
I believe _regex_arguments is more for complex groups of flags/arguments
not for dealing with completion within a string, but could be wrong.
-FR.
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
next prev parent reply other threads:[~2001-12-10 23:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 20:12 Felix Rosencrantz
2001-12-07 12:26 ` Oliver Kiddle
2001-12-10 23:24 ` Felix Rosencrantz [this message]
2001-12-11 12:35 Wischnowsky, Sven
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=20011210232440.51352.qmail@web10403.mail.yahoo.com \
--to=f_rosencrantz@yahoo.com \
--cc=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).