PATCH: Re: "Cancel" menu selection & Co?

PATCH: Re: "Cancel" menu selection & Co?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Currently, as soon as menu selection is started, there seems to be no way
> to cancel it - that is, revert input line to original state. The closest
> it, exit menu selection and hit Undo.
> 
> Does anybody really use ^G to switch from menu selection to menu
> completion? I hardly see any point here. So, the suggestion is, to make ^G
> really cancel selection and revert line to it's original state (before
> match was inserted). This is also consistent behaviour for ^G, that
> normally cancels actions in other places.

Like Bart I prefer this, too. I just didn't want to make incompatible
changes, but since menu-selection is now completely different from
what it was when it started...

> As a related (to me at least) question or request - is it possible to
> enter menu selection immediately if list does not fit on screen? May be,
> not always (if somebody just wants a list with ^D he prkbably does not
> want menu selection). OTOH if menu selection can be quit with ^G it can be
> used as replacement for listing, but replacement that supports scrolling,
> paging, going back etc.

That's quite simple to add to the `menu' style. The patch makes
`scroll=long' mean: use selection if list does not fit on screen. It
also makes `scroll=long-list' mean: use selection if list is too long
for screen, in all cases, even if the widget is d-c-o-l or something
like that which would normally not start menu selection. (Well, it did 
before this patch, but this was a bug.)


Bye
 Sven

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.16
diff -u -r1.16 _main_complete
--- Completion/Core/_main_complete	2000/05/10 04:55:10	1.16
+++ Completion/Core/_main_complete	2000/05/11 08:35:45
@@ -129,11 +129,20 @@
 nm=$compstate[nmatches]
 
 if [[ $compstate[old_list] = keep || nm -gt 1 ]]; then
-  [[ _last_nmatches -ge 0 && _last_nmatches -ne $compstate[nmatches] ]] &&
+  [[ _last_nmatches -ge 0 && _last_nmatches -ne nm ]] &&
       _menu_style=( "$_last_menu_style[@]" "$_menu_style[@]" )
 
-  if [[ "$compstate[insert]" = "$_saved_insert" ]]; then
-    if [[ -n "$_menu_style[(r)(yes|true|1|on)]" ||
+  tmp=$(( compstate[list_lines] + BUFFERLINES + 1 ))
+
+  _menu_style=( "$_menu_style[@]" "$_def_menu_style[@]" )
+
+  if [[ -z "$compstate[insert]" ]]; then
+    [[ -n "$_menu_style[(r)select=long-list]" && tmp -gt LINES ]] &&
+        compstate[insert]=menu
+  elif [[ "$compstate[insert]" = "$_saved_insert" ]]; then
+    if [[ -n "$_menu_style[(r)select=long]" && tmp -gt LINES ]]; then
+        compstate[insert]=menu
+    elif [[ -n "$_menu_style[(r)(yes|true|1|on)]" ||
           ( -n "$_menu_style[(r)auto*]" &&
             "$compstate[insert]" = automenu ) ]]; then
       compstate[insert]=menu
@@ -154,11 +163,12 @@
     fi
   fi
 
-  _menu_style=( "$_menu_style[@]" "$_def_menu_style[@]" )
-
   if [[ "$compstate[insert]" = *menu* ]]; then
     if [[ -n "$_menu_style[(r)no-select*]" ]]; then
       unset MENUSELECT
+    elif [[ -n "$_menu_style[(r)select=long*]" && tmp -gt LINES ]]; then
+      zmodload -i zsh/complist
+      MENUSELECT=0
     else
       sel=( "${(@M)_menu_style:#select*}" )
 
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.43
diff -u -r1.43 compsys.yo
--- Doc/Zsh/compsys.yo	2000/05/11 00:01:03	1.43
+++ Doc/Zsh/compsys.yo	2000/05/11 08:35:51
@@ -1498,6 +1498,13 @@
 smallest one is taken). Starting menuselection can explicitly be
 turned off by defining a value containing the string
 `tt(no-select)'.
+
+There is also support to start menu-selection only when the list of
+matches does not fit on the screen, turned on by using the string
+`tt(select=long)' in the value. However, this will only start
+menu-selection if the widget invoked does completion and not only
+listing (like tt(delete-char-or-list)). To start menu-selection even
+for such widgets one can include the string `tt(select=long-list)'.
 )
 kindex(numbers, completion style)
 item(tt(numbers))(
Index: Doc/Zsh/mod_complist.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_complist.yo,v
retrieving revision 1.7
diff -u -r1.7 mod_complist.yo
--- Doc/Zsh/mod_complist.yo	2000/05/11 00:01:03	1.7
+++ Doc/Zsh/mod_complist.yo	2000/05/11 08:35:52
@@ -253,7 +253,8 @@
 accepts the current match and leaves menu selection
 )
 item(tt(send-break))(
-leaves menu selection and continues with normal menu completion
+leaves menu selection and restores the previous contents of the
+command line
 )
 item(tt(redisplay), tt(clear-screen))(
 execute their normal function without leaving menu selection
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.17
diff -u -r1.17 compcore.c
--- Src/Zle/compcore.c	2000/05/09 11:04:45	1.17
+++ Src/Zle/compcore.c	2000/05/11 08:35:55
@@ -499,12 +499,22 @@
 {
     if (menucmp && !oldmenucmp) {
 	struct chdata dat;
+	int ret;
 
 	dat.matches = amatches;
 	dat.num = nmatches;
 	dat.cur = NULL;
-	if (runhookdef(MENUSTARTHOOK, (void *) &dat))
+	if ((ret = runhookdef(MENUSTARTHOOK, (void *) &dat))) {
 	    menucmp = menuacc = 0;
+	    if (ret == 2) {
+		cs = 0;
+		foredel(ll);
+		inststr(origline);
+		cs = origcs;
+		clearlist = 1;
+		invalidatelist();
+	    }
+	}
     }
     return 0;
 }
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.14
diff -u -r1.14 complist.c
--- Src/Zle/complist.c	2000/05/08 08:16:33	1.14
+++ Src/Zle/complist.c	2000/05/11 08:35:57
@@ -2135,7 +2135,7 @@
 	showinglist = -2;
 	minfo.asked = 0;
     }
-    if (!noselect) {
+    if (!noselect && (!dat || acc)) {
 	showinglist = -2;
 	onlyexpl = oe;
 	if (!smatches)
@@ -2145,7 +2145,7 @@
     mlbeg = -1;
     fdat = NULL;
 
-    return (!noselect ^ acc);
+    return (dat ? (acc ? 1 : 2) : (!noselect ^ acc));
 }
 
 /* The widget function. */

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

Re: PATCH: Re: "Cancel" menu selection & Co?

[Andrej Borsenkow]

On Thu, 11 May 2000, Sven Wischnowsky wrote:

> 
> That's quite simple to add to the `menu' style. The patch makes
> `scroll=long' mean: use selection if list does not fit on screen. It
> also makes `scroll=long-list' mean: use selection if list is too long
> for screen, in all cases, even if the widget is d-c-o-l or something
> like that which would normally not start menu selection. (Well, it did 
> before this patch, but this was a bug.)
> 



Thank you, Sven! It even works here with not-so-fast connection ... really
nice.

Now, if just compinstall supported it :-)

Oh, yes, and you did not comment on per-completion widget styles. Is it
possible? Does it make sense (that is, are there any settings that may be
usefully set differently for different completion widgets)? The only
thing I had in mind was listing - but you did it with this patch.

-andrej

Re: PATCH: Re: "Cancel" menu selection & Co?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ...
> 
> Oh, yes, and you did not comment on per-completion widget styles. Is it
> possible? Does it make sense (that is, are there any settings that may be
> usefully set differently for different completion widgets)? The only
> thing I had in mind was listing - but you did it with this patch.

Sorry, forgot that. Currently we don't support it, which becomes
obvious by looking at the context names which don't include the widget 
name or class.


Aside: I've been playing with a little completer named `_guard' that
works a bit like _prefix and _ignored, i.e. it looks up completers
and calls them -- based on some condition. E.g. you could say:

  zstyle '...' guarded-completer \
    '[[ $WIDGET = *list* ]]' _complete:-list - \
    ... # other conditions/completers here

With this, listing widgets would use _complete, but under the name
`complete-list' and you could set the styles for them.

I then decided that I don't like this approach. Then I thought again
about adding conditionals to styles. For testing purposes, this could
be implemented by a new completion widget that calls _main_complete,
but defines a `zstyle' function before that. This functions could then 
do the real style-lookup and interpret the value, so that, for
example, one could use:

  zstyle ':completion:*' completer \
    if '[[ $WIDGET = *list* ]]' \
      _complete \
    else \
      _complete _approximate \

I.e. `if', `elif' and `else' are keywords. The first string after `if' 
and `elif' is eval'ed and if it return zero, the strings after it up
to the next `elif', `else' or end-of-value is the value returned for
the style (if there are no words, the style is unset under this
condition). The `if' as the first word also makes this distinguishable 
from unconditional values.

Something like this would allow us to finally get rid of the rather
ugly styles that contain conditions, like the ones used by
_expand. One could write:

  zstyle ':completion:*' substitute \
    if '[[ ${{NUMERIC:-1} -ne 1 ]]' yes else no

I haven't played with an implementation of this because it reminds me
too much of the `invent a little language'-trap. Using shell syntax
here could mean that the wrapper makes every style value be eval'ed as 
a whole and uses the `reply' array:

  zstyle ':completion:*' completer \
    'if [[ $WIDGET = *list* ]]; then
       reply=(_complete)
     else
       reply=(_complete _approximate)
     fi'
Although `value=(...)' would probably be better. And we should have a
way to tell the wrapper if the value is to be eval'ed or not, for
example with a special first value like `eval:' or some such.

Having to make the wrapper define a function for this is ugly. If
heavily used, this should be done in C. 


Note: I don't plan to implement this right now, or, more exactly, I
don't plan to try to convince anyone that we should do this or to get
a patch for it into the distribution. Maybe I'm just crazy.

Bye
 Sven


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