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

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> However, I'm confused.  I don't want scrolling.  I have LISTMAX=100, not
> LISTMAX=scroll.  Yet still I get scrolling.

That's why I first didn't give the list-prompt style a default
value. It specifies both the prompt to use and that scrolling is used
at all. It just didn't seem worth it to add another style to turn
scrolling on or off. Maybe that should be changed.

You can always set the list-prompt style to an empty string to turn
scrolling off.

> Minor nit:  The prompt ending in "... continue?" makes me think I should
> hit `n' to stop.  But that inserts an `n'.  The prompt shouldn't ask a
> question, it should make a statement about what to do next, which is a
> bit difficult in the space that's left after "Current position at top:".
> How about something like
> 
> LISTPROMPT='%SAt %p: Hit TAB for more, or the character to insert%s'
> SELECTPROMPT='%SScrolling: current selection at %p%s'

Yes, that's better. Patch below.

> Finally, I'm a bit worried that SELECTPROMPT is going to be confused with
> PROMPT3/PS3.  Not greatly worried, but worried.  Hmm; radical suggestion:
> let's rename some variables:
> 
> 	SELECTMIN	-->	MENUSELECT
> 	SELECTPROMPT	-->	MENUPROMPT
> 	SELECTSCROLL	-->	MENUSCROLL
> 
> I realize the first breaks symmetry with LISTMAX, but of course even
> LISTMAX is now a misnomer since it doesn't have to have a numeric value.
> Since LISTMAX is used by compctl, it'd probably be better to not overload
> it in that way, and instead add another variable (or a style) for scroll.

If it's going to be a style, then we also need a parameter so that
complist is able to find out about it.

No patch for any of this yet, but I'm beginning to think that we could 
do it because SELECTMIN has been set by a style for quite some time now.

> } I would like to hear what you think about this going-back in
> } completion lists (non-menu-selection) and about the make-listing-look-
> } like-menu-selection-probably-even-keeping-the-prompt-on-the-line
> } thing. As opposed to the current should-work-on-almost-every-terminal
> } version we have now. Or maybe you don't care?
> 
> You're going to have to explain a bit more, or point me at article numbers.
> There was a lot of stuff from the week I was gone that I just skimmed over.
> I suspect I'm going to say that I think it should stay as it is (modulo my
> being able to turn it off), but ...

We had the suggestion to allow going back in completion lists. The
easiest way to implement it would be to just use the code we now use
for menu-selection, so that the two would look very much alike. The
only differences would be that menu-select would use a different
keymap with different defaults and that, of course, normal listing
doesn't allow to select a match. We could then use the listing code we 
have now as a fallback for terminals that don't support moving the
cursor up. (See also: 10816)

Bye
 Sven

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.9
diff -u -r1.9 _main_complete
--- Completion/Core/_main_complete	2000/04/25 12:19:45	1.9
+++ Completion/Core/_main_complete	2000/04/26 06:16:20
@@ -57,7 +57,7 @@
 _last_menu_style=()
 
 zstyle -s ":completion:${curcontext}:default" list-prompt LISTPROMPT ||
-    LISTPROMPT='%SCurrent position at %p: continue? %s'
+    LISTPROMPT='%SAt %p: Hit TAB for more, or the character to insert%s'
 if [[ -n "$LISTPROMPT" ]]; then
   zmodload -i zsh/complist
   compstate[list_max]=scroll

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx