Re: PATCH: scrolling completion lists (was: Re: Questions)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> > I had been thinking about doing this, but the patch below uses a
> > simple statusline below the menu when it is too big to fit on the
> > screen and the $SELECTSTATUS parameter is set. That may contain some
> > %-escaped (%l - line information, %m - match information, %p -
> > Top/Bottom/%).
> 
> This is fine, but it should probably have some default value, which could
> be set in the shell functions if that's possible, e.g.
>   SELECTSTATUS='Scrolling active: current selection at %p'
> although I've put a %B at the front.

As you have seen I haven't added styles for any of this yet, but I'm
planning to do so. Maybe just the obvious `select-status' (or should
that be in the menu style with `status=...'? harder to parse...),
`list-status' (`list-prompt' might be a better name, for the
parameter, too), and `select-scroll' (or maybe put that into the
menu-style, too). I'm not yet decided if we should support setting
this per-tag or only for the default tag. The former is probably more
consistent (and silly).
Default values could then be defined as defaults for the style(s),
that's probably what you suggested.

> At the moment it doesn't alter the default LISTMAX.  That's tricky, since
> LISTMAX is set in params.c.  But it would be preferable to have that
> reflect the fact that scrolling is going to be used instead of limiting the
> display.  More precisely, it would be preferable for LISTMAX not to be set
> if it's going to be used, and to be used if it's explicitly set, I suppose.
> One problem is that until zsh/complist is loaded, LISTMAX *will* be used.
> Maybe that means we just document the fact it will be ignored when using
> complist.

Hm, actually complist uses it as usual, it only adds a new
interpretation to the value `scroll'. And that is documented. But yes, 
maybe we should explicitly point out that in that case the completion
code won't ask if one wants to see the list.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx