zsh-workers
 help / color / mirror / code / Atom feed
* Re: compconfig[list_condition]
@ 1999-10-25  8:14 Sven Wischnowsky
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 1999-10-25  8:14 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> 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.

Ahem.

Bye
 Sven

diff -u olddoc/Zsh/zle.yo Doc/Zsh/zle.yo
--- olddoc/Zsh/zle.yo	Thu Oct 21 08:59:22 1999
+++ Doc/Zsh/zle.yo	Mon Oct 25 09:58:21 1999
@@ -141,8 +141,8 @@
 If it is assigned to, only that part of the buffer is replaced, and the
 cursor remains between the old tt($LBUFFER) and the new tt($RBUFFER).
 )
-vindex(BLINES)
-item(tt(BLINES))(
+vindex(BUFFERLINES)
+item(tt(BUFFERLINES))(
 The number of screen lines needed for the edit buffer currently
 displayed on screen (i.e. without any changes to the preceding
 parameters done after the last redisplay).

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: compconfig[list_condition]
@ 1999-10-25  8:11 Sven Wischnowsky
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 1999-10-25  8:11 UTC (permalink / raw)
  To: zsh-workers


[ 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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-10-25  8:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-10-25  8:14 compconfig[list_condition] Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
1999-10-25  8:11 compconfig[list_condition] Sven Wischnowsky

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).