From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-users@sunsite.auc.dk
Subject: Re: Getting completion to tell the user what to do
Date: Tue, 20 Jul 1999 11:16:06 +0200 (MET DST) [thread overview]
Message-ID: <199907200916.LAA01365@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Tue, 20 Jul 1999 08:53:51 +0000
Bart Schaefer wrote:
> On Jul 20, 9:08am, Sven Wischnowsky wrote:
> } Subject: Re: Getting completion to tell the user what to do
> }
> } Bart Schaefer wrote:
> }
> } > What I want is to offer no completions at all [...]
> } > but print a hint to the user as to what he's supposed to type.
> } >
> } > What obvious thing have I forgotten/overlooked here? Is there an entirely
> } > better alternative to using compadd -X ?
> }
> } Time for dirty tricks:
> }
> } compadd -UX 'Please...' -n ''
> } compstate[insert]=''
>
> Oho -- undocumented dirty tricks, no less. The compstate[insert] doc
> doesn't give any hint that it can be set but empty. Of which case that
> is documented is this a degenerate?
Unsetting compstate[insert].
> } compstate[list]=list
> } compstate[force_list]=yes
> }
> } You need the -U because otherwise the empty string never matches
> } what's on the line (not even the empty string on the line).
>
> Really? When I first tried
>
> compadd -X 'Please ...' ''
>
> (without the -S) then every time I pressed TAB a single space got inserted
> (the suffix). If the empty string isn't a match, why did that happen?
Ugh, right, sorry.
> } Then we can switch off insertion completely.
>
> So that's what compstate[insert]='' means?
Exactly that.
> } If you want the string to be listed only on a TAB with an empty string
> } you can do `compadd -X "Please..." -n dummy' -- i.e. add a string with
> } matching.
>
> Presumably then "dummy" should be something that can't possibly match?
> Or does that not matter?
That would be better, yes. Unless you also have `compstate[insert]=""' or
`unset "compstate[insert]"', in which case it doesn't matter.
> } The -n, of course, is just to be sure that the matches are not visible.
> }
> } Is that good enough?
>
> It's just marvelous, thanks. One question, though -- I thought that we
> made kill-whole-line erase the completion listing, but it doesn't seem to
> do that in this case:
>
> zagzig% mail -s <TAB><C-u>
>
> leaves me with
>
> zagzig%
> Please enter a descriptive subject
>
> which is rather annoying when I start in typing some completely different
> command and doing completions for it that don't themselves produce a list.
Nasty side-effect of 7161.
Bye
Sven
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c Tue Jul 20 10:42:27 1999
+++ Src/Zle/zle_tricky.c Tue Jul 20 11:08:31 1999
@@ -6743,8 +6743,9 @@
listmatches();
if (validlist)
freematches();
- lastambig = menucmp = menuacc = validlist = showinglist =
- fromcomp = listshown = 0;
+ lastambig = menucmp = menuacc = validlist = showinglist = fromcomp = 0;
+ if (listshown < 0)
+ listshown = 0;
minfo.cur = NULL;
minfo.asked = 0;
compwidget = NULL;
diff -u od/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- od/Zsh/compwid.yo Mon Jul 19 15:54:31 1999
+++ Doc/Zsh/compwid.yo Tue Jul 20 11:14:45 1999
@@ -236,7 +236,8 @@
behaviour of the tt(MENU_COMPLETE) or tt(AUTO_MENU) options, respectively,
is to be used.
-On exit it may be set to any of the values above, or to a number, in which
+On exit it may be set to any of the values above (where setting it to
+the empty string is the same as unsetting it), or to a number, in which
case the match whose number is given will be inserted into the command line.
It may also be set to a string of the form `var(group):var(match)' which
specifies a match from a group of matches to be inserted, counting from 1
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-07-20 9:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-07-20 9:16 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-07-20 7:08 Sven Wischnowsky
1999-07-20 8:53 ` Bart Schaefer
1999-07-19 17:38 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=199907200916.LAA01365@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-users@sunsite.auc.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).