From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4008 invoked from network); 26 Apr 2000 09:01:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Apr 2000 09:01:47 -0000 Received: (qmail 19545 invoked by alias); 26 Apr 2000 09:01:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10931 Received: (qmail 19514 invoked from network); 26 Apr 2000 09:01:32 -0000 Date: Wed, 26 Apr 2000 11:01:31 +0200 (MET DST) Message-Id: <200004260901.LAA10513@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 26 Apr 2000 08:49:08 +0000 Subject: Re: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion listings Bart Schaefer wrote: > On Apr 26, 10:23am, Sven Wischnowsky wrote: > } > } Bart Schaefer wrote: > } > } > This looks like a case of the doc reflecting the C code in the complist > } > module, but the completion system establishing a different default. > } > } Maybe we could change the C code to do the same the shell code does > } now. I.e.: we turn LISTMAX back into a integer, remove the `scroll' > } special value and turn list scrolling on only if $LISTPROMPT is set. > > Would you then also remove the SELECTSCROLL variable and turn on select > scrolling only if SELECTPROMPT is set? But SELECTSCROLL doesn't turn scrolling on or off, it says how scrolling is done (like Emacs' scroll-step variable). > } That plus the parameter renaming you suggested... would that make > } everyone happy? > > It'd be better than the current situation, I think. As for "happy": > > } It would also make $LISTPROMPT more like $SELECTPROMPT: not set = no > } prompt. > > Not set == _main_complete sets them for you. (Or at least that's what > happens now.) That's the bit I don't like: The variables are documented, > but unless you also set a style they get clobbered. I understand that. Peter wanted the default values, I don't have any strong opinions here. Hm, we could do this entirely by some style magic, i.e. add a style to turn scrolling on and only if that is set, are the default prompts used. > } > } We had the suggestion to allow going back in completion lists. > } > > } > I told you it was a bad idea to start implementing a pager. > } > } One idea might be to add something that allows to turn on menu > } selection when the list doesn't fit on the screen. > > If we did this, could we -replace- scrolling of listings with it, and get > rid of LISTPROMPT entirely? Yes, almost. The only problem is that the prompt may take up more lines then there are on the screen so that we can't use menu-selection (or this kind of listing) because there is no space where we could put the list. Oh, and by `getting rid of LISTPROMPT', did you mean getting rid of scrolling in completion lists? Scrolling through lists with TAB is currently so much easier than moving screen-wise in menu-selection, where it is nice to have TAB go to the next match. Hm, maybe a two-mode menu-selection with different keymaps (current mode could be displayed in the SELECTPROMPT). Or something. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de