Re: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion listings

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx