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

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

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> } 
> } [...]  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.
> 
> That's what I meant in 10921 when I said:
> > 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.

I had a look at the other parameters used by complist again
(esp. ZLS_COLO(|U)RS) and made bot LISTPROMPT and MENUPROMPT (the
former SELECTPROMPT) use a default value when they are set to the
empty string.

So, the patch below:

- changes the names of the parameters as you suggested, i.e. SELECTMIN 
  is now MENUSELECT, SELECTPROMPT is now MENUPROMPT and SELECTSCROLL
  is now MENUSCROLL
- removes the special value `scroll' from LISTMAX and turns that into
  an integer again; to turn on list-scrolling, only the LISTPROMPT
  parameter has to be set

It doesn't use menu-slection-like listing instead of normal listing...

> } > } 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.
> 
> ?!?! If the screen is so short (or the prompt so huge) that you can't fit
> in both the listing and the prompt, you couldn't do anything useful with
> list-scrolling as it is now anyway, could you?

You could use it to scroll screen-wise through the listing, as usual,
because listing still only prints the stuff below the prompt as it
always did. It just stops every once in a while.

Even with scrolling, listing still allows to see previous lines if
your terminal (like an xterm) allows to scroll to previous lines.

If we change listing to be menu-selection-like and there is a large
command line prompt, we can't display both the list and the prompt at
the same time, so we can't use menu-selection and, with the change, no 
list-scrolling. We could use normal listing (below the prompt and
scrolling it out of the screen as we do now) as a fallback. One
question would then be: in this fallback, do we support scrolling
screen-wise or not?

> If you're worried about the configuration that allows menu-selection to
> scroll without printing a select prompt:  I don't think that's at issue.
> If menu-selection is invoked, then menu-selection is invoked; don't try
> to force a prompt to appear just because it got invoked "in place of" a
> listing.

No, I wasn't worried about that.

> } Oh, and by `getting rid of LISTPROMPT', did you mean getting rid of
> } scrolling in completion lists?
> 
> I did.

I see.

> } Scrolling through lists with TAB is
> } currently so much easier than moving screen-wise in menu-selection,
> 
> How DO you move screen-wise in menu-selection, anyway?  I can't figure
> it out.  Obviously that would have to be made simpler.

The manual now contains a itemised list for the widgets with special
meaning in menu-selection. Scrolling screen-wise is done by the
word-movement functions (except for the vi-*-blank-* functions which
move group-wise). Going to the top/bottom line is done with
{beginning,end}-of-history.

I'd be thankful for every suggestion to make these special widget
meanings better understandable.

> Hmm, I just tried using {beginning,end}-of-buffer-or-history in a menu-
> selection and found that they act like {beginning,end}-of-line.  I would
> have expected to jump to the top/bottom of the column instead.

Yes, all widgets that first move to the beginning or end of the buffer/line
always moved to the beginning/end of the current line in the list.

> } where it is nice to have TAB go to the next match.
> 
> When scrolling is necessary, cycling through many matches with TAB looks
> a lot better when LIST_ROWS_FIRST is set -- no jumping from the bottom
> of one column to the top of the next, which causes a scroll.

The behaviour of TAB is, of course, a kind of logical movement, rather 
than screen-oriented. It makes menu selection a better replacement for 
normal menu completion. As you know.

> BTW, have we considered having up/down and left/right motions wrap to
> the previous/next column/line, as happens in e.g. the Pine mailbox
> browser?  To illustrate the effect I mean, in a menu-selection with
> LIST_ROWS_FIST, arrow right to the end of the line and then press TAB.
> Now imagine that the TAB had just been another press of the arrow key.

I hadn't thought of that. Doesn't seem to hard to implement, I'll have 
a look.

Bye
 Sven

P.S.: We're still invalidating parts of the Guide. Peter, I already
      found some other things that need fixing there, I'll send you
      some more information when I've finished looking through it.

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.10
diff -u -r1.10 _main_complete
--- Completion/Core/_main_complete	2000/04/26 06:26:49	1.10
+++ Completion/Core/_main_complete	2000/04/27 07:57:38
@@ -47,25 +47,27 @@
 _setup default
 _def_menu_style=( "$_last_menu_style[@]"
 
-# We can't really do that because the current value of $SELECTMIN
+# We can't really do that because the current value of $MENUSELECT
 # may be the one set by this function.
 # There is a similar problem with $ZLS_COLORS in _setup.
 
-#                  ${SELECTMIN+select${SELECTMIN:+\=$SELECTMIN}}
+#                  ${MENUSELECT+select${MENUSELECT:+\=$MENUSELECT}}
 
                 )
 _last_menu_style=()
 
-zstyle -s ":completion:${curcontext}:default" list-prompt LISTPROMPT ||
-    LISTPROMPT='%SAt %p: Hit TAB for more, or the character to insert%s'
-if [[ -n "$LISTPROMPT" ]]; then
+if zstyle -s ":completion:${curcontext}:default" list-prompt tmp; then
+  LISTPROMPT="$tmp"
   zmodload -i zsh/complist
-  compstate[list_max]=scroll
 fi
-zstyle -s ":completion:${curcontext}:default" select-prompt SELECTPROMPT ||
-    SELECTPROMPT='%SScrolling active: current selection at %p%s'
-zstyle -s ":completion:${curcontext}:default" select-scroll SELECTSCROLL ||
-    SELECTSCROLL=1
+if zstyle -s ":completion:${curcontext}:default" select-prompt tmp; then
+  MENUPROMPT="$tmp"
+  zmodload -i zsh/complist
+fi
+if zstyle -s ":completion:${curcontext}:default" select-scroll tmp; then
+  MENUSCROLL="$tmp"
+  zmodload -i zsh/complist
+fi
 
 # Get the names of the completers to use in the positional parameters.
 
@@ -148,7 +150,7 @@
 
   if [[ "$compstate[insert]" = *menu* ]]; then
     if [[ -n "$_menu_style[(r)no-select*]" ]]; then
-      unset SELECTMIN
+      unset MENUSELECT
     else
       sel=( "${(@M)_menu_style:#select*}" )
 
@@ -168,7 +170,7 @@
         done
 
         zmodload -i zsh/complist
-        SELECTMIN="$min"
+        MENUSELECT="$min"
       fi
     fi
   fi
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.22
diff -u -r1.22 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/25 09:48:09	1.22
+++ Doc/Zsh/compsys.yo	2000/04/27 07:57:39
@@ -1273,12 +1273,14 @@
 )
 kindex(list-prompt, completion style)
 item(tt(list-prompt))(
-If this style is set to a non-empty value for the tt(default) tag,
+If this style is set for the tt(default) tag,
 completion lists that don't fit on the screen can be scrolled (see
 ifzman(the description of the tt(zsh/complist) module in zmanref(zshmodules))\
 ifnzman(noderef(The zsh/complist Module))\
-). The value will be displayed after every screenful, prompting for a
-key press. It may contain the escape `tt(%l)' or `tt(%L)' which will be
+). The value, if not the empty string, will be displayed after every
+screenful, prompting for a key press. If the value is the empty
+string, a default prompt will be used. It may contain the escape
+`tt(%l)' or `tt(%L)' which will be
 replaced by the number of the last line displayed and the total number
 of lines. A `tt(%m)' or `tt(%M)' will be replaced by the number of the 
 last match shown and the total number of matches and `tt(%p)' and
@@ -1588,11 +1590,13 @@
 )
 kindex(select-prompt, completion style)
 item(tt(select-prompt))(
-If this is set to a non-empty string for the tt(default) tag, its
+If this is set for the tt(default) tag, its
 value will be displayed during menu-selection (see the tt(menu) style
 above) when the completion list does not fit on the screen as a
 whole. The same escapes as for the tt(list-prompt) style are
-understood, but give the number of the match or line the mark is on.
+understood, but give the number of the match or line the mark is
+on. As for tt(list-prompt), a default prompt is used when the value is 
+the empty string.
 )
 kindex(select-scroll, completion style)
 item(tt(select-scroll))(
Index: Doc/Zsh/mod_complist.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_complist.yo,v
retrieving revision 1.5
diff -u -r1.5 mod_complist.yo
--- Doc/Zsh/mod_complist.yo	2000/04/19 06:49:37	1.5
+++ Doc/Zsh/mod_complist.yo	2000/04/27 07:57:39
@@ -128,12 +128,25 @@
 ).
 
 subsect(Scrolling in completion listings)
-vindex(LISTMAX)
-To be able to scroll through a completion list, the tt(LISTMAX)
-parameter has to be set to the string `tt(scroll)'. If it has this
-value, the completion code will not ask if the list should be
-shown. Instead it immediately starts displaying the list, stopping
-after the first screenful, showing a prompt at the bottom,
+To be able to scroll through a completion list, the tt(LISTPROMPT)
+parameter has to be set. Its value will be used as the prompt, if it
+is the empty string, a default prompt will be used.  The value may
+contain escapes of the form `tt(%x)'. It supports the escapes
+`tt(%B)', `tt(%b)', `tt(%S)', `tt(%s)', `tt(%U)', `tt(%u)' and
+`tt(%{...%})' known from the shell prompts and three pairs of
+additional sequences. A `tt(%l)' or `tt(%L)' is replaced by the number
+of the last line shown and the total number of lines in the form
+`var(number)tt(/)var(total)'. A `tt(%m)' or `tt(%M)' is replaced with
+the number of the last match shown and the total number of matches and 
+`tt(%p)' or `tt(%P)' is replaced with `tt(Top)', `tt(Bottom)' or the
+position of the first line shown in percent of the total number of
+lines, respectively. In each of these cases the one with the uppercase
+letter will be replaced with a string of fixed width, padded to the
+right with spaces.
+
+If tt(LISTPROMPT) is set, the completion code will not ask if the list
+should be shown. Instead it immediately starts displaying the list,
+stopping after the first screenful, showing the prompt at the bottom,
 waiting for a keypress after temporarily switching to the
 tt(listscroll) keymap. Some of the zle functions have special meaning:
 
@@ -156,20 +169,6 @@
 that is bound to tt(undefined-key) is looked up in the keymap
 currently selected.
 
-If the parameter tt(LISTPROMPT) is set, its value will be used as the
-prompt.  The value may contain escapes of the form `tt(%x)'. It
-supports the escapes `tt(%B)', `tt(%b)', `tt(%S)', `tt(%s)', `tt(%U)',
-`tt(%u)' and `tt(%{...%})' known from the shell prompts and three
-pairs of additional sequences. A `tt(%l)' or `tt(%L)' is replaced by
-the number of the last line shown and the total number of lines in the form
-`var(number)tt(/)var(total)'. A `tt(%m)' or `tt(%M)' is replaced with
-the number of the last match shown and the total number of matches and 
-`tt(%p)' or `tt(%P)' is replaced with `tt(Top)', `tt(Bottom)' or the
-position of the first line shown in percent of the total number of
-lines, respectively. In each of these cases the one with the uppercase 
-letter will be replaced with a string of fixed width, padded to the
-right with spaces.
-
 As for the tt(ZLS_COLORS) and tt(ZLS_COLOURS) parameters,
 tt(LISTPROMPT) should not be set directly when using the shell
 function based completion system. Instead, the tt(list-prompt) style
@@ -177,7 +176,7 @@
 
 subsect(Menu selection)
 cindex(completion, selecting by cursor)
-vindex(SELECTMIN)
+vindex(MENUSELECT)
 tindex(menu-select)
 The tt(zsh/complist) module also offers an alternative style of selecting
 matches from a list, called menu-selection, which can be used if the
@@ -187,16 +186,16 @@
 ifnzman(noderef(Options))\
 ). It can be invoked directly by
 the widget tt(menu-select) defined by the module.  Alternatively,
-the parameter tt(SELECTMIN) can be set to an integer, which give the
+the parameter tt(MENUSELECT) can be set to an integer, which give the
 minimum number of matches that must be present before menu selection is
 automatically turned on.  This second method requires that menu completion
 be started, either directly from a widget such as tt(menu-complete), or due
 to one of the options tt(MENU_COMPLETE) or tt(AUTO_MENU) being set.  If
-tt(SELECTMIN) is set, but is 0, 1 or empty, menu selection will always be
+tt(MENUSELECT) is set, but is 0, 1 or empty, menu selection will always be
 started during an ambiguous menu completion.
 
 When using the shell function based completion system, the
-tt(SELECTMIN) parameter should not be used (like the tt(ZLS_COLORS)
+tt(MENUSELECT) parameter should not be used (like the tt(ZLS_COLORS)
 and tt(ZLS_COLOURS) parameters described above). Instead, the tt(menu) 
 style should be used.
 
@@ -212,12 +211,13 @@
 control sequence as for the `tt(%S)' escape in prompts is used.
 
 If there are more matches than fit on the screen and the parameter
-tt(SELECTPROMPT) is set, its value will be shown below the
-matches. It supports the sames escape sequences as tt(LISTPROMPT), but 
-the number of the match or line shown will be that of the one where
-the mark is placed.
+tt(MENUPROMPT) is set, its value will be shown below the matches. It
+supports the sames escape sequences as tt(LISTPROMPT), but the number
+of the match or line shown will be that of the one where the mark is
+placed. If its value is the empty string, a default prompt will be
+used.
 
-The tt(SELECTSCROLL) parameter can be used to specify how the list is
+The tt(MENUSCROLL) parameter can be used to specify how the list is
 scrolled. If the parameter is unset, this is done line by line, if it
 is set to `tt(0)' (zero), the list will scrolled half the number of
 lines of the screen. If the value is positive, it gives the number of
@@ -225,7 +225,7 @@
 the number of lines of the screen minus the (absolute) value.
 
 As for the tt(ZLS_COLORS), tt(ZLS_COLOURS) and tt(LISTPROMPT)
-parameters, neither tt(SELECTPROMPT) nor tt(SELECTSCROLL) should be
+parameters, neither tt(MENUPROMPT) nor tt(MENUSCROLL) should be
 set directly when using the shell function based completion
 system. Instead, the tt(select-prompt) and tt(select-scroll) styles
 should be used.
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.6
diff -u -r1.6 params.c
--- Src/params.c	2000/04/17 11:17:10	1.6
+++ Src/params.c	2000/04/27 07:57:40
@@ -483,10 +483,10 @@
     setiparam("MAILCHECK", 60);
     setiparam("LOGCHECK", 60);
     setiparam("KEYTIMEOUT", 40);
+    setiparam("LISTMAX", 100);
 #ifdef HAVE_SELECT
     setiparam("BAUD", getbaudrate(&shttyinfo));  /* get the output baudrate */
 #endif
-    setsparam("LISTMAX", ztrdup("100"));
     setsparam("FCEDIT", ztrdup(DEFAULT_FCEDIT));
     setsparam("TMPPREFIX", ztrdup(DEFAULT_TMPPREFIX));
     setsparam("TIMEFMT", ztrdup(DEFAULT_TIMEFMT));
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.10
diff -u -r1.10 compcore.c
--- Src/Zle/compcore.c	2000/04/25 10:28:11	1.10
+++ Src/Zle/compcore.c	2000/04/27 07:57:40
@@ -296,8 +296,7 @@
     comppatinsert = ztrdup("menu");
     forcelist = 0;
     haspattern = 0;
-    zsfree(complistmax);
-    complistmax = ztrdup(getsparam("LISTMAX"));
+    complistmax = getiparam("LISTMAX");
     zsfree(complastprompt);
     complastprompt = ztrdup(((isset(ALWAYSLASTPROMPT) && zmult == 1) ||
 			     (unset(ALWAYSLASTPROMPT) && zmult != 1)) ?
Index: Src/Zle/complete.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v
retrieving revision 1.4
diff -u -r1.4 complete.c
--- Src/Zle/complete.c	2000/04/26 06:54:27	1.4
+++ Src/Zle/complete.c	2000/04/27 07:57:40
@@ -33,7 +33,9 @@
 /* global variables for shell parameters in new style completion */
 
 /**/
-mod_export zlong compcurrent;
+mod_export
+zlong compcurrent,
+      complistmax;
 /**/
 zlong complistlines,
       compignored;
@@ -49,8 +51,7 @@
      *compquote,
      *compqstack,
      *comppatmatch,
-     *complastprompt,
-     *complistmax;
+     *complastprompt;
 /**/
 char *compiprefix,
      *compcontext,
@@ -924,7 +925,7 @@
     { "unambiguous", PM_SCALAR | PM_READONLY, NULL, NULL, VAL(get_unambig) },
     { "unambiguous_cursor", PM_INTEGER | PM_READONLY, NULL, NULL,
       VAL(get_unambig_curs) },
-    { "list_max", PM_SCALAR, VAL(complistmax), NULL, NULL },
+    { "list_max", PM_INTEGER, VAL(complistmax), NULL, NULL },
     { "last_prompt", PM_SCALAR, VAL(complastprompt), NULL, NULL },
     { "to_end", PM_SCALAR, VAL(comptoend), NULL, NULL },
     { "old_list", PM_SCALAR, VAL(compoldlist), NULL, NULL },
@@ -1312,13 +1313,13 @@
     comprpms = compkpms = NULL;
     compwords = NULL;
     compprefix = compsuffix = compiprefix = compisuffix = 
-	compqiprefix = compqisuffix = complistmax = 
+	compqiprefix = compqisuffix =
 	compcontext = compparameter = compredirect = compquote =
 	compquoting = comprestore = complist = compinsert =
 	compexact = compexactstr = comppatmatch = comppatinsert =
 	complastprompt = comptoend = compoldlist = compoldins =
 	compvared = compqstack = NULL;
-
+    complistmax = 0;
     hascompmod = 1;
 
     return 0;
@@ -1367,7 +1368,6 @@
 {
     if (compwords)
 	freearray(compwords);
-    zsfree(complistmax);
     zsfree(compprefix);
     zsfree(compsuffix);
     zsfree(compiprefix);
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.7
diff -u -r1.7 complist.c
--- Src/Zle/complist.c	2000/04/25 13:54:09	1.7
+++ Src/Zle/complist.c	2000/04/27 07:57:41
@@ -384,7 +384,7 @@
 static int noselect, mselect, inselect, mcol, mline, mcols, mlines, mmlen;
 static int selected, mlbeg = -1, mlend = 9999999, mscroll, mrestlines;
 static int mnew, mlastcols, mlastlines, mhasstat, mfirstl, mlastm;
-static char *mstatus;
+static char *mstatus, *mlistp;
 static Cmatch **mtab, **mmtabp;
 static Cmgroup *mgtab, *mgtabp;
 static struct listcols mcolors;
@@ -730,8 +730,8 @@
 	    if (!(fmt = mstatus))
 		return 0;
 	    cc = -1;
-	} else if (!(fmt = getsparam("LISTPROMPT")))
-	    fmt = "Continue? ";
+	} else
+	    fmt = mlistp;
     }
     for (p = fmt; *p; p++) {
 	if (doesc && *p == '%') {
@@ -1437,7 +1437,6 @@
 complistmatches(Hookdef dummy, Chdata dat)
 {
     Cmgroup oamatches = amatches;
-    char *p = NULL;
 
     amatches = dat->matches;
 
@@ -1463,24 +1462,30 @@
 	clearflag = 0;
 
     mscroll = 0;
+    mlistp = NULL;
 
     if (mselect >= 0 || mlbeg >= 0 ||
-	((p = complistmax) && !strcmp(p, "scroll"))) {
+	(mlistp = getsparam("LISTPROMPT"))) {
+	if (!*mlistp)
+	    mlistp = "%SAt %p: Hit TAB for more, or the character to insert%s";
 	trashzle();
 	showinglist = listshown = 0;
 
 	lastlistlen = 0;
 
-	if (p) {
+	if (mlistp) {
 	    clearflag = (isset(USEZLE) && !termflags && dolastprompt);
 	    mscroll = 1;
 	} else {
 	    clearflag = 1;
 	    minfo.asked = (listdat.nlines + nlnct <= lines);
 	}
-    } else if (asklist()) {
-	amatches = oamatches;
-	return (noselect = 1);
+    } else {
+	mlistp = NULL;
+	if (asklist()) {
+	    amatches = oamatches;
+	    return (noselect = 1);
+	}
     }
     if (mlbeg >= 0) {
 	mlend = mlbeg + lines - nlnct - mhasstat;
@@ -1569,7 +1574,7 @@
     int space, lbeg = 0, step = 1;
     char *s;
 
-    if (fdat || (dummy && (!(s = getsparam("SELECTMIN")) ||
+    if (fdat || (dummy && (!(s = getsparam("MENUSELECT")) ||
 			   (dat && dat->num < atoi(s))))) {
 	if (fdat) {
 	    fdat->matches = dat->matches;
@@ -1577,14 +1582,15 @@
 	}
 	return 0;
     }
-    if ((s = getsparam("SELECTSCROLL"))) {
+    if ((s = getsparam("MENUSCROLL"))) {
 	if (!(step = mathevali(s)))
 	    step = (lines - nlnct) >> 1;
 	else if (step < 0)
 	    if ((step += lines - nlnct) < 0)
 		step = 1;
     }
-    mstatus = getsparam("SELECTPROMPT");
+    if ((mstatus = getsparam("MENUPROMPT")) && !*mstatus)
+	mstatus = "%SScrolling active: current selection at %p%s";
     mhasstat = (mstatus && *mstatus);
     fdat = dat;
     selectlocalmap(mskeymap);
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.11
diff -u -r1.11 compresult.c
--- Src/Zle/compresult.c	2000/04/25 13:54:09	1.11
+++ Src/Zle/compresult.c	2000/04/27 07:57:41
@@ -1590,8 +1590,6 @@
 mod_export int
 asklist(void)
 {
-    int lmax = (complistmax ? (int) mathevali(complistmax) : 0);
-
     /* Set the cursor below the prompt. */
     trashzle();
     showinglist = listshown = 0;
@@ -1601,9 +1599,9 @@
 
     /* Maybe we have to ask if the user wants to see the list. */
     if ((!minfo.cur || !minfo.asked) &&
-	((lmax > 0 && listdat.nlist >= lmax) ||
-	 (lmax < 0 && listdat.nlines <= -lmax) ||
-	 (!lmax && listdat.nlines >= lines))) {
+	((complistmax > 0 && listdat.nlist >= complistmax) ||
+	 (complistmax < 0 && listdat.nlines <= -complistmax) ||
+	 (!complistmax && listdat.nlines >= lines))) {
 	int qup, l;
 
 	zsetterm();

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Peter Stephenson]

> 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?

It would be fine to keep it simple, my only query was whether having simple
paging for completion lists and something different for menu selection was
too confusing.  However, on reflection they're doing rather different
things anyway, so I don't suppose it's a problem.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

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

[Bart Schaefer]

On Apr 26, 11:01am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > } 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).

Ah, sorry, missed that.

} > 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.
} 
} [...]  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.

That's what I meant in 10921 when I said:
> 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.

} > } 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.

?!?! If the screen is so short (or the prompt so huge) that you can't fit
in both the listing and the prompt, you couldn't do anything useful with
list-scrolling as it is now anyway, could you?

If you're worried about the configuration that allows menu-selection to
scroll without printing a select prompt:  I don't think that's at issue.
If menu-selection is invoked, then menu-selection is invoked; don't try
to force a prompt to appear just because it got invoked "in place of" a
listing.

} Oh, and by `getting rid of LISTPROMPT', did you mean getting rid of
} scrolling in completion lists?

I did.

} Scrolling through lists with TAB is
} currently so much easier than moving screen-wise in menu-selection,

How DO you move screen-wise in menu-selection, anyway?  I can't figure
it out.  Obviously that would have to be made simpler.

Hmm, I just tried using {beginning,end}-of-buffer-or-history in a menu-
selection and found that they act like {beginning,end}-of-line.  I would
have expected to jump to the top/bottom of the column instead.

} where it is nice to have TAB go to the next match.

When scrolling is necessary, cycling through many matches with TAB looks
a lot better when LIST_ROWS_FIRST is set -- no jumping from the bottom
of one column to the top of the next, which causes a scroll.

BTW, have we considered having up/down and left/right motions wrap to
the previous/next column/line, as happens in e.g. the Pine mailbox
browser?  To illustrate the effect I mean, in a menu-selection with
LIST_ROWS_FIST, arrow right to the end of the line and then press TAB.
Now imagine that the TAB had just been another press of the arrow key.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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

[Sven Wischnowsky]

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

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

[Bart Schaefer]

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?

} 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.

} > } 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?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 26,  8:25am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion list
> }
> } > 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.
> 
> But the doc still says to set LISTMAX=scroll (mod_complist.yo, lines
> 130-136) and doesn't say anything about _main_complete forcing it on
> (via compstate[list_max]=scroll) just because LISTPROMPT isn't empty,
> which appears to be what happens.
> 
> This looks like a case of the doc reflecting the C code in the complist
> module, but the completion system establishing a different default.  This
> is not good; there's no right way to document it.

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. For $LISTPROMPT we already have the pointer to the new completion 
system and there we have documentation that it has a default value.
It would also make $LISTPROMPT more like $SELECTPROMPT: not set = no
prompt.

That plus the parameter renaming you suggested... would that make
everyone happy?

> } We had the suggestion to allow going back in completion lists.
> 
> I told you it was a bad idea to start implementing a pager. 

:-} Yes. We had requests from Andrej and Peter. But I prefer it, too,
makes my life easier.

One idea might be to add something that allows to turn on menu
selection when the list doesn't fit on the screen. A bit like
a mixture of SELECTMIN and LISTMAX, but not only meaning `*if* menu
completion is started *and*  there are at least N matches, start menu
selection', but meaning: `in any case (even if menu completion
wouldn't be started normally), if there are at least N matches or the
list takes N lines, start menu selection'.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Bart Schaefer]

On Apr 26,  8:25am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion list
}
} > 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.

But the doc still says to set LISTMAX=scroll (mod_complist.yo, lines
130-136) and doesn't say anything about _main_complete forcing it on
(via compstate[list_max]=scroll) just because LISTPROMPT isn't empty,
which appears to be what happens.

This looks like a case of the doc reflecting the C code in the complist
module, but the completion system establishing a different default.  This
is not good; there's no right way to document it.

} We had the suggestion to allow going back in completion lists.

I told you it was a bad idea to start implementing a pager.  Drive a stake
through it's heart right now or you'll pay in blood later.  Leave it as is.
I'm tempted to say we should even file it as a bug on SourceForge and then
mark it closed with a "won't fix" status.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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

[Sven Wischnowsky]

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@informatik.hu-berlin.de

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

[Bart Schaefer]

On Apr 25,  2:17pm, Sven Wischnowsky wrote:
} Subject: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion listings
}
} Bart Schaefer wrote:
} 
} > that the selection disappears, and you're now stuck repeatedly selecting
} > the file name that would be visible if only the status line weren't there.
} 
} I forgot to re-calculate the number of the line the mark is on for the 
} completion widgets inside menu-selection.

This works now, thanks.

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

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'

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.

} 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 ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> (in reverse video).  Hit TAB repeatedly (21 times, to be exact) and note
> that the selection disappears, and you're now stuck repeatedly selecting
> the file name that would be visible if only the status line weren't there.
> The status line now says something like
> 
>   Scrolling active: current selection at 62%
> 
> Pressing one of the arrow keys restores sanity.

I forgot to re-calculate the number of the line the mark is on for the 
completion widgets inside menu-selection.

> Aside: Why is "Current position ... Continue?" NOT in reverse video?  Why
> whitespace rather than a colon between "Top" and "Continue" ?  Am I just
> being a foolishly consistent hobgoblin to want these to look similar?

You aren't. I'm pretty sure I wanted to that and then was confused by
the flurry of patches. Maybe I'm beginning to break down...


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?

Bye
 Sven

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.8
diff -u -r1.8 _main_complete
--- Completion/Core/_main_complete	2000/04/19 06:49:36	1.8
+++ Completion/Core/_main_complete	2000/04/25 12:13:31
@@ -57,13 +57,13 @@
 _last_menu_style=()
 
 zstyle -s ":completion:${curcontext}:default" list-prompt LISTPROMPT ||
-    LISTPROMPT='Current position at %P    Continue? '
+    LISTPROMPT='%SCurrent position at %p: continue? %s'
 if [[ -n "$LISTPROMPT" ]]; then
   zmodload -i zsh/complist
   compstate[list_max]=scroll
 fi
 zstyle -s ":completion:${curcontext}:default" select-prompt SELECTPROMPT ||
-    SELECTPROMPT='%SScrolling active: current selection at %p'
+    SELECTPROMPT='%SScrolling active: current selection at %p%s'
 zstyle -s ":completion:${curcontext}:default" select-scroll SELECTSCROLL ||
     SELECTSCROLL=1
 
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.5
diff -u -r1.5 complist.c
--- Src/Zle/complist.c	2000/04/20 11:03:16	1.5
+++ Src/Zle/complist.c	2000/04/25 12:13:33
@@ -1594,6 +1594,20 @@
     mlines = 999999;
     mlbeg = 0;
     for (;;) {
+	if (mline < 0) {
+	    int x, y;
+	    Cmatch **p = mtab;
+
+	    for (y = 0; y < mlines; y++) {
+		for (x = mcols; x; x--, p++)
+		    if (*p && **p && mselect == (**p)->gnum)
+			break;
+		if (x)
+		    break;
+	    }
+	    if (y < mlines)
+		mline = y;
+	}
 	space = lines - nlnct - mhasstat;
 	while (mline < mlbeg)
 	    if ((mlbeg -= step) < 0)
@@ -1999,12 +2013,14 @@
 	    do_menucmp(0);
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
+	    mline = -1;
 	    continue;
 	} else if (cmd == Th(z_reversemenucomplete) ||
 		   !strcmp(cmd->nam, "reverse-menu-complete")) {
 	    reversemenucomplete(zlenoargs);
 	    mselect = (*(minfo.cur))->gnum;
 	    setwish = 1;
+	    mline = -1;
 	    continue;
 	} else {
 	    ungetkeycmd();

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de