From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: compconfig[list_condition]
Date: Mon, 25 Oct 1999 10:11:35 +0200 (MET DST) [thread overview]
Message-ID: <199910250811.KAA05065@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Sun, 24 Oct 1999 22:32:38 +0000
[ List changed to -workers, I /think/ this is more appropriate. If you
don't agree, forward it to -users... ]
Bart Schaefer wrote:
> I'm still fooling around with insert-and-predict. In its present state, it
> attempts regular completion on any self-inserted key (other than space) that
> does not result in a history-beginning-search match. With autolist set,
> however, this tends to produce things like this:
>
> zagzig[28] echo $
> zsh: do you wish to see all 128 possibilities?
>
> This means I have to type an extra character, which if I'm typing quickly
> enough I fail to do, causing a character that I wanted to have on the line
> to be consumed instead. This was previously discussed (in zsh-users/2641)
> and the result seems to have been the addition of compstate[list_lines] and
> BUFFERLINES (mis-documented as BLINES, by the way) in 8227.
Oops. I first used `BLINES' and then thought someone might complain
that it's too short or not different enough from `LINES'. The patch
below fixes this.
> So I've added
>
> compconfig[list_condition]='compstate[list_lines]+BUFFERLINES < LINES'
> compconfig[completer]='_list:_complete'
>
> to my completion configuration, and set LISTMAX very large. However, this
> doesn't do what I thought it would. I tried reversing the order of the
> completers, and setting and unsetting autolist, but either I get listings
> that scroll off the screen or I don't get any listings at all.
The list completer does something entirely different (I guess nobody
uses it, btw). I was thinking about changing it so that it would
support this kind of stuff, but it may be better to add another
completer for this, because: for its real purpose it has to be called
before `_complete' and such (because we have to make sure that it *is*
called). But this decide-if-we-should-list stuff has to be called at
the end, because, of course, we can only calculate the number of lines
needed *after* all matches have been added. That's what causing you
problems, here, `$[compstate[list_lines]+BUFFERLINES < LINES]' is
always true because there are no matches yet.
> What *should* I be doing to get listings if and only if they fit on the
> screen?
In the same patch that brought you `list_lines' (or was it one patch
after that?), I added the post-completion functions which are
guarenteed to be executed after the completers have been run. Just
have a look at `incremental-complete-word'. It adds a simple function:
icw-list-helper() {
# +1 for the status line we will add...
if [[ compstate[list_lines]+BUFFERLINES+1 -gt LINES ]]; then
compstate[list]='list explanations'
if [[ compstate[list_lines]+BUFFERLINES+1 -gt LINES ]]; then
compstate[list]=''
compstate[force_list]=yes
fi
toolong='...'
fi
}
and starts completion with (the equivalent of):
comppostfuncs=( icw-list-helper )
zle $wid "$@"
The helper function can decide if the list fits on the screen and
shows it only then. The `toolong' is used in the i-c-w prompt (so you
won't need it) and the `+1' is needed to calculate the number of lines
needed including the status line used by i-c-w (so you won't need it
either).
And remember to set `comppostfuncs' before every call to the
completion system, because it will be reset there.
Ok?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-10-25 8:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-25 8:11 Sven Wischnowsky [this message]
1999-10-25 8:14 compconfig[list_condition] 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=199910250811.KAA05065@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@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).