Re: compstate[old_list]

Re: compstate[old_list]

[Sven Wischnowsky]

Peter Stephenson wrote:

> I tried to add these lines to the top of _main_complete so that listing
> widgets could be made to use an existing list of completions.
> 
> if [[ $WIDGET = *list* && -n $compconfig[old_list] &&
>   -n $compstate[old_list] &&
>   ( $compconfig[old_list] = always || $compstate[old_list] != shown ) ]]; then
>   compstate[old_list]=keep
>   return
> fi
> 
> But when I start a non-contextual completion, and the list is displayed by
> autolist, and I then type ^D, this doesn't work --- it seems
> $compstate[old_list] is not set.  Is this just me?

This was caused in zle_main.c, which I obviously forgot to change.

Bye
 Sven

diff -u os/Zle/zle_main.c Src/Zle/zle_main.c
--- os/Zle/zle_main.c	Tue Apr 13 09:41:27 1999
+++ Src/Zle/zle_main.c	Mon Apr 19 11:59:59 1999
@@ -579,12 +579,7 @@
 
 	if(!(wflags & ZLE_KEEPSUFFIX))
 	    removesuffix();
-	if(!(wflags & ZLE_MENUCMP) ||
-	   ((wflags & WIDGET_NCOMP) && compwidget != w)) {
-	    /* If we are doing a special completion, and the widget
-	     * is not the one currently in use for special completion,
-	     * we are starting a new completion.
-	     */
+	if(!(wflags & ZLE_MENUCMP)) {
 	    fixsuffix();
 	    invalidatelist();
 	}

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

Re: compstate[old_list]

[Peter Stephenson]

Sven Wischnowsky wrote:
> Peter Stephenson wrote:
> 
> > But when I start a non-contextual completion, and the list is displayed by
> > autolist, and I then type ^D, this doesn't work --- it seems
> > $compstate[old_list] is not set.  Is this just me?
> 
> This was caused in zle_main.c, which I obviously forgot to change.

I didn't notice to begin with, but this seems to have the opposite effect.
If I do a non-contextual completion, every completion-based command
following it always acts as if it were using the old list, and
_main_complete never gets called at all (I checked that the widget I first
used wasn't being called again, either).  This even happens to the extent
that calling a different ad-hoc completion when menucompletion is active
still simply cycles through the existing list.  The default should
presumably be to call the appropriate widget and allow the shell code to
decide whether to re-use the old list (though it's quite convenient that
TAB will now cycle through the ad-hoc completion list, which might be
harder to do in the shell code where it belongs).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: compstate[old_list]

[Sven Wischnowsky]

Peter Stephenson wrote:

> I'll put it in and see what happens.  Maybe I'll make a $compconfig
> patch for some of these things, once I work out what they are.  Or is that
> causing the danger of code bloat?

I'd prefer to have a new completer function for things like this
(`compconf completer=_old:...'). Or, probably more precisely, I'd
prefer to not alter `_main_complete' any more unless we find some
interesting ways to change or configure the overall control flow,
which should then be put into it.

Bye
 Sven


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

Re: compstate[old_list]

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > Peter Stephenson wrote:
> > 
> > > But when I start a non-contextual completion, and the list is displayed by
> > > autolist, and I then type ^D, this doesn't work --- it seems
> > > $compstate[old_list] is not set.  Is this just me?
> > 
> > This was caused in zle_main.c, which I obviously forgot to change.
> 
> I didn't notice to begin with, but this seems to have the opposite effect.
> If I do a non-contextual completion, every completion-based command
> following it always acts as if it were using the old list, and
> _main_complete never gets called at all (I checked that the widget I first
> used wasn't being called again, either).  This even happens to the extent
> that calling a different ad-hoc completion when menucompletion is active
> still simply cycles through the existing list.  The default should
> presumably be to call the appropriate widget and allow the shell code to
> decide whether to re-use the old list (though it's quite convenient that
> TAB will now cycle through the ad-hoc completion list, which might be
> harder to do in the shell code where it belongs).

Uh, err... hm.

For now I don't know how to change it. This is an effect of
menucompletion being set. Without menucompletion, the other completion 
widgets get called all right. But with menucompletion and the ad-hoc
completion widget not behaving like `list-choices' or `delete-char-or-list',
the test in zle_tricky:759 keeps the next completion widget from being
called.

Hm. maybe if we move the test I removed zle_main.c to this place...

Could you play with it and tell me if this is better?

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Apr 13 10:32:15 1999
+++ Src/Zle/zle_tricky.c	Tue Apr 20 16:15:12 1999
@@ -72,6 +72,10 @@
 
 static int offs;
 
+/* the last completion widget called */
+
+static Widget lastcompwidget;
+
 /* These control the type of completion that will be done.  They are      *
  * affected by the choice of ZLE command and by relevant shell options.   *
  * usemenu is set to 2 if we have to start automenu and 3 if we have to   *
@@ -756,10 +760,12 @@
 
     /* If we are doing a menu-completion... */
 
-    if (menucmp && lst != COMP_LIST_EXPAND) {
+    if (menucmp && lst != COMP_LIST_EXPAND && compwidget &&
+	compwidget == lastcompwidget) {
 	do_menucmp(lst);
 	return;
     }
+    lastcompwidget = compwidget;
 
     /* We may have to reset the cursor to its position after the   *
      * string inserted by the last completion. */

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

Re: compstate[old_list]

[Peter Stephenson]

Sven Wischnowsky wrote:
> Hm. maybe if we move the test I removed zle_main.c to this place...
> 
> Could you play with it and tell me if this is better?

So far, it's fine.  Normal menu-completion behaviour is OK, _main_complete
gets called when I expect it to, and I can engineer the `TAB continues
ad-hoc menu-completion'-type behaviour by adding

if [[ -n $compstate[old_insert] && $WIDGET = *complete(|-prefix) &&
  -n $compconfig[old_menu] ]]; then
  compstate[old_list]=keep
  if [[ $WIDGET = *reverse* ]]; then
    compstate[insert]=$(( compstate[old_insert] - 1 ))
  else
    compstate[insert]=$(( compstate[old_insert] + 1 ))
  fi
  return
fi

to _main_complete.

I'll put it in and see what happens.  Maybe I'll make a $compconfig
patch for some of these things, once I work out what they are.  Or is that
causing the danger of code bloat?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

compstate[old_list]

[Peter Stephenson]

I tried to add these lines to the top of _main_complete so that listing
widgets could be made to use an existing list of completions.

if [[ $WIDGET = *list* && -n $compconfig[old_list] &&
  -n $compstate[old_list] &&
  ( $compconfig[old_list] = always || $compstate[old_list] != shown ) ]]; then
  compstate[old_list]=keep
  return
fi

But when I start a non-contextual completion, and the list is displayed by
autolist, and I then type ^D, this doesn't work --- it seems
$compstate[old_list] is not set.  Is this just me?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy