Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: scrolling completion lists (was: Re: Questions)
- X-seq: zsh-workers 10792
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: scrolling completion lists (was: Re: Questions)
- Date: Mon, 17 Apr 2000 12:47:09 +0100
- In-reply-to: "Your message of Mon, 17 Apr 2000 13:10:41 +0200." <200004171110.NAA15088@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
> 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.
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.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author