From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21139 invoked from network); 25 Oct 1999 08:11:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Oct 1999 08:11:48 -0000 Received: (qmail 21601 invoked by alias); 25 Oct 1999 08:11:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8399 Received: (qmail 21592 invoked from network); 25 Oct 1999 08:11:38 -0000 Date: Mon, 25 Oct 1999 10:11:35 +0200 (MET DST) Message-Id: <199910250811.KAA05065@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 24 Oct 1999 22:32:38 +0000 Subject: Re: compconfig[list_condition] [ 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