From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.dk
Subject: Re: Two missing completion functions that bug me
Date: Fri, 30 Mar 2001 10:21:08 +0200 (MET DST) [thread overview]
Message-ID: <200103300821.KAA22411@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Thu, 29 Mar 2001 16:24:03 +0000
Bart Schaefer wrote:
> On Mar 29, 11:09am, Oliver Kiddle wrote:
> }
> } > '-c+[create parameter or change type]' \
> }
> } I'm not sure you need the + after -c, or at least that is the only
> } difference to my function (other than wording for the help info).
>
> You're right; upon another attempt, none of -c, -e, nor -h need the `+'.
> I was thinking it was needed to get other options to be completed in the
> same word, because of:
>
> % vared -a<TAB>
> % vared -a
> ^cursor silently moves here
>
> but in fact that's because -a takes an argument, not (only) because it
> does not have the `+'. (Is there a way *other than* adding a ->state
> machine to get other options to complete in the same word but arguments
> in the next for an option like -a? I was thinking not, and in fact I
> was thinking that I was one who asserted that ->state was a sufficient
> solution for this, a position I'm not inclined to change.)
You could try the patch below, which does that (automatically) for
me. I'll commit it if we don't find any nasty side effect (or should
I apply it and take it back if we find problems? feel free to commit
it if you like it...)
> ... [ comp* funcs ]
>
> I suppose one could provide completions for them anyway, in case one is
> editing a new completion function on the fly, but it seems a lot of work
> for not a lot of benefit.
Yes, I thought the same.
> These don't need completions because they're keywords:
>
> break continue
>
> Which leaves:
>
> : echo pushln suspend umask
> [ exit pwd test zformat
> bye getln r ttyctl zparseopts
> dirs logout return ulimit zprof
zparseopts and zformat aren't of much use interactively either.
And completion for bye, exit and return seems weird, too. Although
that would probably just be `_message "${${words[1]#bye}:-exit} value"'.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2001-03-30 8:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-30 8:21 Sven Wischnowsky [this message]
2001-03-30 16:11 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
2001-04-02 9:15 Sven Wischnowsky
2001-04-02 12:04 ` Oliver Kiddle
2001-03-30 8:23 Sven Wischnowsky
2001-03-29 7:59 Bart Schaefer
2001-03-29 10:09 ` Oliver Kiddle
2001-03-29 16:24 ` Bart Schaefer
2001-03-30 9:16 ` Oliver Kiddle
2001-03-30 15:38 ` Bart Schaefer
2001-03-30 15:59 ` Bart Schaefer
2001-03-30 16:35 ` Oliver Kiddle
2001-03-30 16:53 ` Bart Schaefer
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=200103300821.KAA22411@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.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).