zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
@ 2000-05-31  9:53 Sven Wischnowsky
  0 siblings, 0 replies; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-31  9:53 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> ...
> 
> Hm, should we change the C-code to enforce showing the list when a
> `compadd -x' message was added (that *seems* sensible, but I think
> there may also be cases where one doesn't want that)? Alternatively,
> we could enhance $compstate[list]: if it contains `messages', only the 
> messages are shown (like the `explanations' we have now).

I've decided to do the latter. I.e. one can now put `messages' in
$compstate[list] to make it show only the messages. This can be
combined with `explanations' to show both types (but not the matches
themselves).

The former (force listing if messages were added) can then be
implemented in shell code, see _complete_debug for an example.

Bye
 Sven

Index: Completion/Commands/_complete_debug
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_complete_debug,v
retrieving revision 1.6
diff -u -r1.6 _complete_debug
--- Completion/Commands/_complete_debug	2000/05/30 03:57:39	1.6
+++ Completion/Commands/_complete_debug	2000/05/31 09:51:57
@@ -20,7 +20,8 @@
 [[ -t 3 ]] && {
     print -sR "${VISUAL:-${EDITOR:-${PAGER:-more}}} $tmp ;: $w"
     _message -r "Trace output left in $tmp (up-history to view)"
-    compstate[list]='list force'
+    [[ $compstate[nmatches] -le 1 && $compstate[list] != *force* ]] &&
+        compstate[list]='list force messages'
     exec 2>&3 3>&-
 }
 
Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.26
diff -u -r1.26 _main_complete
--- Completion/Core/_main_complete	2000/05/22 13:55:57	1.26
+++ Completion/Core/_main_complete	2000/05/31 09:51:58
@@ -220,9 +220,9 @@
       fi
     fi
   fi
-elif [[ nm -eq 0 && -n "$_comp_mesg" ]]; then
+elif [[ nm -le 1 && -n "$_comp_mesg" ]]; then
   compstate[insert]=''
-  compstate[list]='list force'
+  compstate[list]='list force messages'
 elif [[ nm -eq 0 &&
         $#_lastdescr -ne 0 && $compstate[old_list] != keep ]] &&
      zstyle -s ":completion:${curcontext}:warnings" format format; then
@@ -251,7 +251,7 @@
 
 [[ "$_comp_force_list" = always ||
    ( "$_comp_force_list" = ?*  && nm -ge _comp_force_list ) ]] &&
-    compstate[list]="$compstate[list] force"
+    compstate[list]="${compstate[list]//messages} force"
 
 [[ "$compstate[old_list]" = keep ]] && ZLS_COLORS="$_saved_colors"
 
Index: Completion/Core/_setup
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_setup,v
retrieving revision 1.3
diff -u -r1.3 _setup
--- Completion/Core/_setup	2000/05/08 08:16:32	1.3
+++ Completion/Core/_setup	2000/05/31 09:51:58
@@ -64,5 +64,5 @@
   zstyle -s ":completion:${curcontext}:$1" force-list val &&
     [[ "$val" = always ||
        ( "$val" = [0-9]## &&
-         ( -z "$_comp_force_list" || _comp_force_list -lt val ) ) ]] &&
+         ( -z "$_comp_force_list" || _comp_force_list -gt val ) ) ]] &&
     _comp_force_list="$val"
Index: Doc/Zsh/compwid.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compwid.yo,v
retrieving revision 1.16
diff -u -r1.16 compwid.yo
--- Doc/Zsh/compwid.yo	2000/05/23 14:23:27	1.16
+++ Doc/Zsh/compwid.yo	2000/05/31 09:52:00
@@ -259,9 +259,12 @@
 done for the tt(LIST_ROWS_FIRST) option with the substring tt(rows).
 
 Finally, if the value contains the string tt(explanations), only the
-explanation strings, if any, will be listed.  It will be set
-appropriately on entry to a completion widget and may be changed
-there.
+explanation strings, if any, will be listed and if it contains
+tt(messages), only the messages (added with the tt(-x) option of
+tt(compadd)) will be listed.  If it contains both tt(explanations) and 
+tt(messages) both kinds of explanation strings will be listed.  It
+will be set appropriately on entry to a completion widget and may be
+changed there.
 )
 vindex(list_max, compstate)
 item(tt(list_max))(
Index: Functions/Zle/incremental-complete-word
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/Zle/incremental-complete-word,v
retrieving revision 1.4
diff -u -r1.4 incremental-complete-word
--- Functions/Zle/incremental-complete-word	2000/04/05 11:07:26	1.4
+++ Functions/Zle/incremental-complete-word	2000/05/31 09:52:00
@@ -118,7 +118,7 @@
   # +1 for the status line we will add...
 
   if [[ compstate[list_lines]+BUFFERLINES+1 -gt LINES ]]; then
-    compstate[list]='list explanations'
+    compstate[list]='list explanations messages'
     [[ compstate[list_lines]+BUFFERLINES+1 -gt LINES ]] && compstate[list]=''
 
     toolong='...'
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.26
diff -u -r1.26 compcore.c
--- Src/Zle/compcore.c	2000/05/31 06:13:50	1.26
+++ Src/Zle/compcore.c	2000/05/31 09:52:01
@@ -440,7 +440,7 @@
     if (!showinglist && validlist && usemenu != 2 && 
 	(nmatches != 1 || diffmatches) &&
 	useline >= 0 && useline != 2 && (!oldlist || !listshown)) {
-	onlyexpl = 1;
+	onlyexpl = 3;
 	showinglist = -2;
     }
  compend:
@@ -802,7 +802,8 @@
 	else
 	    uselist = 0;
 	forcelist = (complist && strstr(complist, "force"));
-	onlyexpl = (complist && strstr(complist, "expl"));
+	onlyexpl = (complist ? ((strstr(complist, "expl") ? 1 : 0) |
+				(strstr(complist, "messages") ? 2 : 0)) : 0);
 
 	if (!compinsert)
 	    useline = 0;
@@ -2449,7 +2450,7 @@
 
     for (n = firstnode(expls); n; incnode(n)) {
 	e = (Cexpl) getdata(n);
-	if (!strcmp(curexpl->str, e->str)) {
+	if (e->count >= 0 && !strcmp(curexpl->str, e->str)) {
 	    e->count += curexpl->count;
 	    e->fcount += curexpl->fcount;
 
@@ -2471,11 +2472,11 @@
 
     for (n = firstnode(expls); n; incnode(n)) {
 	e = (Cexpl) getdata(n);
-	if (!strcmp(mesg, e->str))
+	if (e->count < 0 && !strcmp(mesg, e->str))
 	    return;
     }
     e = (Cexpl) zhalloc(sizeof(*e));
-    e->count = e->fcount = 1;
+    e->count = e->fcount = -1;
     e->str = dupstring(mesg);
     addlinknode(expls, e);
     newmatches = 1;
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.20
diff -u -r1.20 complist.c
--- Src/Zle/complist.c	2000/05/25 11:33:14	1.20
+++ Src/Zle/complist.c	2000/05/31 09:52:03
@@ -1026,7 +1026,9 @@
 		lastused = 1;
 	    }
 	    while (*e) {
-		if ((*e)->count) {
+		if ((*e)->count &&
+		    (!listdat.onlyexpl ||
+		     (listdat.onlyexpl & ((*e)->count > 0 ? 1 : 2)))) {
 		    if (pnl) {
 			if (dolistnl(ml) && compprintnl(ml))
 			    goto end;
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.17
diff -u -r1.17 compresult.c
--- Src/Zle/compresult.c	2000/05/31 06:31:22	1.17
+++ Src/Zle/compresult.c	2000/05/31 09:52:04
@@ -1170,7 +1170,8 @@
     zsfree(complist);
     complist = ztrdup(v);
 
-    onlyexpl = (v && strstr(v, "expl"));
+    onlyexpl = (v ? ((strstr(v, "expl") ? 1 : 0) |
+		     (strstr(v, "messages") ? 2 : 0)) : 0);
 }
 
 /* This skips over matches that are not to be listed. */
@@ -1300,7 +1301,9 @@
 	}
 	if ((e = g->expls)) {
 	    while (*e) {
-		if ((*e)->count)
+		if ((*e)->count &&
+		    (!onlyexpl ||
+		     (onlyexpl & ((*e)->count > 0 ? 1 : 2))))
 		    nlines += 1 + printfmt((*e)->str, (*e)->count, 0, 1);
 		e++;
 	    }
@@ -1690,7 +1693,9 @@
 	    int l;
 
 	    while (*e) {
-		if ((*e)->count) {
+		if ((*e)->count &&
+		    (!listdat.onlyexpl ||
+		     (listdat.onlyexpl & ((*e)->count > 0 ? 1 : 2)))) {
 		    if (pnl) {
 			putc('\n', shout);
 			pnl = 0;

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
  2000-05-25  7:57 Sven Wischnowsky
@ 2000-05-25 15:20 ` Bart Schaefer
  0 siblings, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2000-05-25 15:20 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

On May 25,  9:57am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
}
} Bart Schaefer wrote:
} 
} > The test case was to run `vared functions[_complete_debug]', scroll up
} > to the line `local w="${(qq)words}"', then type ^E ESC RET to open a
} > line, and begin completing on that line.
} 
} The fact that you used `functions[_complete_debug]' was an important
} information, because with that I found a buglet in _in_vared that made 
} _value complete alternatingly assoc keys and values, as if for a
} assingment to $functions.

Aha!

} I still can't see why it completed commands, but it might have
} something to do with this (I could understand it if you had tried it
} with commands[...]).

Actually, although I hadn't noticed it before, the number of completions
offered changes depending on which variable I'm editing, so that probably
is in fact the issue.  If it's still broken after the patch I'll let you
know.

} There is another thing I noticed: ^X? with only one match did not show 
} the _message, because with only one match it didn't show the list at
} all. The patch fixes this in _complete_debug.

Aha, again.  That explains another "bug" I was about to report.

} Hm, should we change the C-code to enforce showing the list when a
} `compadd -x' message was added (that *seems* sensible, but I think
} there may also be cases where one doesn't want that)? Alternatively,
} we could enhance $compstate[list]: if it contains `messages', only the 
} messages are shown (like the `explanations' we have now).

Either or both.  I don't have a strong opinion, at least not yet.

} Well, another thing I noticed is that with a really large prompt and
} completion list scrolling it doesn't stop at the end of the list, so
} that the re-printed prompt scrolls most of the list out of the
} screen. So the patch makes it wait at the very end, allowing us to
} have a look at the whole list before printing the next prompt.

Yay!  Yet another thing I was about to report.  You're batting 300% on
this one.

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
@ 2000-05-25  7:57 Sven Wischnowsky
  2000-05-25 15:20 ` Bart Schaefer
  0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-25  7:57 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> ...
> 
> I've just tried comparing zsh with all patches up to but NOT including
> 11503, against zsh including 11503, and I see no differences between
> those (maybe 11493 had an effect?).  So then I compared zsh including
> 11503 against zsh patched up to 11471 (e.g. code-wise should be identical
> to -pre-4).  The newer zsh does NOT show the behavior above; the older
> one does.

Yes, 11493 should definitely had an effect on this.

> Since the newer version doesn't have the bad behavior, the following is
> mainly for information, in case a light bulb goes on above Sven when he
> sees it.
> 
> The test case was to run `vared functions[_complete_debug]', scroll up
> to the line `local w="${(qq)words}"', then type ^E ESC RET to open a
> line, and begin completing on that line.

The fact that you used `functions[_complete_debug]' was an important
information, because with that I found a buglet in _in_vared that made 
_value complete alternatingly assoc keys and values, as if for a
assingment to $functions.

I still can't see why it completed commands, but it might have
something to do with this (I could understand it if you had tried it
with commands[...]).

> If I immediately type ^X?, both versions beep at me.  Comparing the xtrace
> output, the ONLY difference shown (other than line numbers) is the value
> assigned to the _saved_colors local, which is irrelevant.  Both versions
> output the string from _message.

There is another thing I noticed: ^X? with only one match did not show 
the _message, because with only one match it didn't show the list at
all. The patch fixes this in _complete_debug.

Hm, should we change the C-code to enforce showing the list when a
`compadd -x' message was added (that *seems* sensible, but I think
there may also be cases where one doesn't want that)? Alternatively,
we could enhance $compstate[list]: if it contains `messages', only the 
messages are shown (like the `explanations' we have now).

> If I start the test again from a fresh PS1, but type TAB and then ^X?,
> zsh-11502 produces the same xtrace as before, but zsh-11471 has this
> additional fragment:
> 
> +_main_complete:41:if: [[ tab automenu-unambiguous == tab* && _complete_debug != *list* ]]
> +_main_complete:42:then cursh: zstyle -T :completion::::: insert-tab
> +_main_complete:43:then cursh cmdand cursh: [[ ::: != :* || -z functions[_complete_debug] ]]
> +_main_complete:44:then cursh cmdand cursh cmdor: zstyle -t :completion:vared:::: insert-tab
> +_main_complete:46:then: compstate[insert]=automenu-unambiguous 

Yes, the corrected `tab'-in-$compstate[insert]-behaviour.

Well, another thing I noticed is that with a really large prompt and
completion list scrolling it doesn't stop at the end of the list, so
that the re-printed prompt scrolls most of the list out of the
screen. So the patch makes it wait at the very end, allowing us to
have a look at the whole list before printing the next prompt.

Bye
 Sven

Index: Completion/Base/_in_vared
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_in_vared,v
retrieving revision 1.1
diff -u -r1.1 _in_vared
--- Completion/Base/_in_vared	2000/05/15 13:19:26	1.1
+++ Completion/Base/_in_vared	2000/05/25 07:56:36
@@ -5,10 +5,17 @@
 # Completion inside vared.
 
 if [[ $compstate[vared] = *\[* ]]; then
-  # vared on an array-element
-  compstate[parameter]=${compstate[vared]%%\[*}
-  compstate[context]=-value-
-  also=value
+  if [[ $compstate[vared] = *\]* ]]; then
+    # vared on an array-element
+    compstate[parameter]=${${compstate[vared]%%\]*}//\[/-}
+    compstate[context]=value
+    also=-value-
+  else
+    # vared on an array-value
+    compstate[parameter]=${compstate[vared]%%\[*}
+    compstate[context]=value
+    also=-value-
+  fi
 else
   # vared on a parameter, let's see if it is an array
   compstate[parameter]=$compstate[vared]
Index: Completion/Commands/_complete_debug
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_complete_debug,v
retrieving revision 1.4
diff -u -r1.4 _complete_debug
--- Completion/Commands/_complete_debug	2000/05/19 16:04:16	1.4
+++ Completion/Commands/_complete_debug	2000/05/25 07:56:36
@@ -22,6 +22,7 @@
     # _message -r "Trace output left in $tmp (up-history to view)"
     # print -sR "${VISUAL:-${EDITOR:-${PAGER:-more}}} $tmp ;: $w"
     _message -r "Trace output left in $tmp"
+    compstate[list]='list force'
     print -zR "${VISUAL:-${EDITOR:-${PAGER:-more}}} $tmp ;: $w"
     exec 2>&3 3>&-
 }
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.18
diff -u -r1.18 complist.c
--- Src/Zle/complist.c	2000/05/22 08:47:31	1.18
+++ Src/Zle/complist.c	2000/05/25 07:56:37
@@ -1302,36 +1302,41 @@
     if (nlnct <= 1)
 	mscroll = 0;
     if (clearflag) {
+	int nl;
+
 	/* Move the cursor up to the prompt, if always_last_prompt *
 	 * is set and all that...                                  */
 	if (mlbeg >= 0) {
-	    if ((ml = listdat.nlines + nlnct) >= lines) {
+	    if ((nl = listdat.nlines + nlnct) >= lines) {
 		if (mhasstat) {
 		    putc('\n', shout);
 		    compprintfmt(NULL, 0, 1, 1, mline, NULL);
 		}
-		ml = lines - 1;
+		nl = lines - 1;
 	    } else
-		ml--;
-	    tcmultout(TCUP, TCMULTUP, ml);
+		nl--;
+	    tcmultout(TCUP, TCMULTUP, nl);
 	    showinglist = -1;
 
 	    lastlistlen = listdat.nlines;
-	} else if ((ml = listdat.nlines + nlnct - 1) < lines) {
+	} else if ((nl = listdat.nlines + nlnct - 1) < lines) {
 	    if (mlbeg >= 0 && tccan(TCCLEAREOL))
 		tcout(TCCLEAREOL);
-	    tcmultout(TCUP, TCMULTUP, ml);
+	    tcmultout(TCUP, TCMULTUP, nl);
 	    showinglist = -1;
 
 	    lastlistlen = listdat.nlines;
 	} else {
 	    clearflag = 0;
-	    if (!asked)
+	    if (!asked) {
+		mrestlines = (ml + nlnct > lines);
 		compprintnl(ml);
+	    }
 	}
-    } else if (!asked)
+    } else if (!asked) {
+	mrestlines = (ml + nlnct > lines);
 	compprintnl(ml);
-
+    }
     listshown = (clearflag ? 1 : -1);
     mnew = 0;
 

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
  2000-05-22 14:44 Sven Wischnowsky
@ 2000-05-22 16:52 ` Bart Schaefer
  0 siblings, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2000-05-22 16:52 UTC (permalink / raw)
  To: zsh-workers

On May 22,  4:44pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
}
} Bart Schaefer wrote:
} 
} > On May 22,  1:25pm, Sven Wischnowsky wrote:
} > } Subject: PATCH: Re: TAB and PS2 and multiline buffers and vared
} > }
} > } Bart Schaefer wrote:
} > } 
} > } > The situation is different in vared (again with a multiline buffer).
} > } > Sometimes it beeps and then asks me whether I want to see all 2200
} > } > possiblities, other times it just beeps and refuses to insert anything.
} > } > Whether it asks or just beeps seems to depend on whether I started out
} > } > on vared of a value containing newlines (e.g. vared functions[foo] vs.
} > } > vared foo).
} > } 
} > } Hm. Is that with the current CVS version?
} > 
} > Yes.  (Well, current at the time I sent the mail.)
} 
} I don't understand why it's completing commands then... Hm.

I've just tried comparing zsh with all patches up to but NOT including
11503, against zsh including 11503, and I see no differences between
those (maybe 11493 had an effect?).  So then I compared zsh including
11503 against zsh patched up to 11471 (e.g. code-wise should be identical
to -pre-4).  The newer zsh does NOT show the behavior above; the older
one does.

Since the newer version doesn't have the bad behavior, the following is
mainly for information, in case a light bulb goes on above Sven when he
sees it.

The test case was to run `vared functions[_complete_debug]', scroll up
to the line `local w="${(qq)words}"', then type ^E ESC RET to open a
line, and begin completing on that line.

If I immediately type ^X?, both versions beep at me.  Comparing the xtrace
output, the ONLY difference shown (other than line numbers) is the value
assigned to the _saved_colors local, which is irrelevant.  Both versions
output the string from _message.

If I start the test again from a fresh PS1, but type TAB and then ^X?,
zsh-11502 produces the same xtrace as before, but zsh-11471 has this
additional fragment:

+_main_complete:41:if: [[ tab automenu-unambiguous == tab* && _complete_debug != *list* ]]
+_main_complete:42:then cursh: zstyle -T :completion::::: insert-tab
+_main_complete:43:then cursh cmdand cursh: [[ ::: != :* || -z functions[_complete_debug] ]]
+_main_complete:44:then cursh cmdand cursh cmdor: zstyle -t :completion:vared:::: insert-tab
+_main_complete:46:then: compstate[insert]=automenu-unambiguous 

In this particular test they also both output the message, so I still
don't know exact steps to reproduce sending it into command completion.

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
@ 2000-05-22 14:44 Sven Wischnowsky
  2000-05-22 16:52 ` Bart Schaefer
  0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-22 14:44 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> On May 22,  1:25pm, Sven Wischnowsky wrote:
> } Subject: PATCH: Re: TAB and PS2 and multiline buffers and vared
> }
> } Bart Schaefer wrote:
> } 
> } > The situation is different in vared (again with a multiline buffer).
> } > Sometimes it beeps and then asks me whether I want to see all 2200
> } > possiblities, other times it just beeps and refuses to insert anything.
> } > Whether it asks or just beeps seems to depend on whether I started out
> } > on vared of a value containing newlines (e.g. vared functions[foo] vs.
> } > vared foo).
> } 
> } Hm. Is that with the current CVS version?
> 
> Yes.  (Well, current at the time I sent the mail.)

I don't understand why it's completing commands then... Hm.

> } > Sometimes after this happens the completion system gets into a state
> } > where _complete_debug ceases to function properly.  I type ^X? and the
> } > debug output goes to the file as expected, but _message doesn't work.
> } > Also, `?' gets inserted because of compstate[insert]=tab, which is a bit
> } > strange though not exactly wrong.
> } 
> } The patch also changes it to insert a tab only when TAB was pressed.
> 
> Thanks, but as I mentioned in my followup message, compstate[insert]
> seems to have gotten `stuck' somehow, that is, once I'm in this state
> it *always* begins with "tab " so nothing will complete anywhere.  Not
> just inside vared, but after I exit vared and go on to the next PS1.

After having a look at zle_tricky.c again... the patch below should
help when the widget wasn't invoked by TAB, but with TAB, it shouldn't 
have happened before. Did it contain the `tab' on entry to
_main_complete or only on exit?

> } About the missing _message: you have _oldlist in your completer style, 
> } right? Did you try ^X? directly after the TAB?
> 
> Yes, I do have _oldlist, and probably I did try right after the tab.

Then ^X? showed you the list from the TAB, of course, the one without
the _message-string. Maybe we should change _oldlist to not do its job 
when called from _complete_debug. But then again, maybe we shouldn't.


Brute force patch below, but it'll hopefully make sure that we don't
enter docomplete() with an old value in wouldinstab again.

Bye
 Sven

Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v
retrieving revision 1.10
diff -u -r1.10 zle_tricky.c
--- Src/Zle/zle_tricky.c	2000/05/22 11:28:29	1.10
+++ Src/Zle/zle_tricky.c	2000/05/22 14:42:22
@@ -158,7 +158,6 @@
 {
     unsigned char *s = line + cs - 1;
 
-    wouldinstab = 0;
     if (keybuf[0] != '\t' || keybuf[1])
 	return 0;
     for (; s >= line && *s != '\n'; s--)
@@ -192,6 +191,7 @@
 {
     usemenu = !!isset(MENUCOMPLETE);
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     if (c == '\t' && usetab())
 	return selfinsert(args);
     else {
@@ -213,6 +213,7 @@
 {
     usemenu = 1;
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     if (c == '\t' && usetab())
 	return selfinsert(args);
     else
@@ -225,6 +226,7 @@
 {
     usemenu = !!isset(MENUCOMPLETE);
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     return docomplete(COMP_LIST_COMPLETE);
 }
 
@@ -233,6 +235,7 @@
 spellword(char **args)
 {
     usemenu = useglob = 0;
+    wouldinstab = 0;
     return docomplete(COMP_SPELL);
 }
 
@@ -242,6 +245,7 @@
 {
     usemenu = !!isset(MENUCOMPLETE);
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
 
     if (cs != ll) {
 	fixsuffix();
@@ -256,6 +260,7 @@
 expandword(char **args)
 {
     usemenu = useglob = 0;
+    wouldinstab = 0;
     if (c == '\t' && usetab())
 	return selfinsert(args);
     else
@@ -268,6 +273,7 @@
 {
     usemenu = !!isset(MENUCOMPLETE);
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     if (c == '\t' && usetab())
 	return selfinsert(args);
     else {
@@ -289,6 +295,7 @@
 {
     usemenu = 1;
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     if (c == '\t' && usetab())
 	return selfinsert(args);
     else
@@ -301,6 +308,7 @@
 {
     usemenu = !!isset(MENUCOMPLETE);
     useglob = isset(GLOBCOMPLETE);
+    wouldinstab = 0;
     return docomplete(COMP_LIST_EXPAND);
 }
 
@@ -308,6 +316,7 @@
 mod_export int
 reversemenucomplete(char **args)
 {
+    wouldinstab = 0;
     if (!menucmp)
 	return menucomplete(args);
 
@@ -319,6 +328,7 @@
 int
 acceptandmenucomplete(char **args)
 {
+    wouldinstab = 0;
     if (!menucmp)
 	return 1;
     runhookdef(ACCEPTCOMPHOOK, NULL);

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: PATCH: Re: TAB and PS2 and multiline buffers and vared
  2000-05-22 11:25 Sven Wischnowsky
@ 2000-05-22 14:27 ` Bart Schaefer
  0 siblings, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2000-05-22 14:27 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

On May 22,  1:25pm, Sven Wischnowsky wrote:
} Subject: PATCH: Re: TAB and PS2 and multiline buffers and vared
}
} Bart Schaefer wrote:
} 
} > The situation is different in vared (again with a multiline buffer).
} > Sometimes it beeps and then asks me whether I want to see all 2200
} > possiblities, other times it just beeps and refuses to insert anything.
} > Whether it asks or just beeps seems to depend on whether I started out
} > on vared of a value containing newlines (e.g. vared functions[foo] vs.
} > vared foo).
} 
} Hm. Is that with the current CVS version?

Yes.  (Well, current at the time I sent the mail.)

} > Sometimes after this happens the completion system gets into a state
} > where _complete_debug ceases to function properly.  I type ^X? and the
} > debug output goes to the file as expected, but _message doesn't work.
} > Also, `?' gets inserted because of compstate[insert]=tab, which is a bit
} > strange though not exactly wrong.
} 
} The patch also changes it to insert a tab only when TAB was pressed.

Thanks, but as I mentioned in my followup message, compstate[insert]
seems to have gotten `stuck' somehow, that is, once I'm in this state
it *always* begins with "tab " so nothing will complete anywhere.  Not
just inside vared, but after I exit vared and go on to the next PS1.

} About the missing _message: you have _oldlist in your completer style, 
} right? Did you try ^X? directly after the TAB?

Yes, I do have _oldlist, and probably I did try right after the tab.

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* PATCH: Re: TAB and PS2 and multiline buffers and vared
@ 2000-05-22 11:25 Sven Wischnowsky
  2000-05-22 14:27 ` Bart Schaefer
  0 siblings, 1 reply; 7+ messages in thread
From: Sven Wischnowsky @ 2000-05-22 11:25 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> At either the PS2 prompt or in a multiline buffer, with the new completion
> system enabled, typing TAB beeps and then inserts the tab.
> 
> Why does it beep?

Ahem. Because _main_complete returned one there, I didn't think of the 
beep-effect. That's because I always turn off all beeps.

The return value is probably also the reason for users/3074.

> The situation is different in vared (again with a multiline buffer).
> Sometimes it beeps and then asks me whether I want to see all 2200
> possiblities, other times it just beeps and refuses to insert anything.
> Whether it asks or just beeps seems to depend on whether I started out
> on vared of a value containing newlines (e.g. vared functions[foo] vs.
> vared foo).

Hm. Is that with the current CVS version? We now have the _in_vared
function for completing there and that does assignment-completion
which doesn't complete commands. And it also does its own
tab-insertion handling. And it works for me.

> Sometimes after this happens the completion system gets into a state
> where _complete_debug ceases to function properly.  I type ^X? and the
> debug output goes to the file as expected, but _message doesn't work.
> Also, `?' gets inserted because of compstate[insert]=tab, which is a bit
> strange though not exactly wrong.

The patch also changes it to insert a tab only when TAB was pressed.

About the missing _message: you have _oldlist in your completer style, 
right? Did you try ^X? directly after the TAB?


Bye
 Sven

Index: Completion/Core/_main_complete
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_main_complete,v
retrieving revision 1.22
diff -u -r1.22 _main_complete
--- Completion/Core/_main_complete	2000/05/19 16:04:16	1.22
+++ Completion/Core/_main_complete	2000/05/22 11:25:49
@@ -41,7 +41,7 @@
 if [[ "$compstate[insert]" = tab* && "$WIDGET" != *list* ]]; then
   { zstyle -T ":completion:${curcontext}:" insert-tab &&
     { [[ "$curcontext" != :* || -z "$compstate[vared]" ]] ||
-        zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 1
+        zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 0
 
   compstate[insert]="${compstate[insert]//tab /}"
 fi
Index: Doc/Zsh/compwid.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compwid.yo,v
retrieving revision 1.14
diff -u -r1.14 compwid.yo
--- Doc/Zsh/compwid.yo	2000/05/17 11:59:32	1.14
+++ Doc/Zsh/compwid.yo	2000/05/22 11:25:50
@@ -314,8 +314,7 @@
 to start menucompletion, beginning with the second match.
 
 Note that a value containing the substring `tt(tab)' makes the
-matches generated be ignored and only the character that was used to
-call the completion widget be inserted.
+matches generated be ignored and only the TAB be inserted.
 
 Finally, it may also be set to tt(all), which makes all matches
 generated be inserted into the line.
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.22
diff -u -r1.22 compcore.c
--- Src/Zle/compcore.c	2000/05/17 11:59:33	1.22
+++ Src/Zle/compcore.c	2000/05/22 11:25:51
@@ -335,7 +335,7 @@
 	ret = 1;
 	minfo.cur = NULL;
 	if (useline < 0)
-	    selfinsert(zlenoargs);
+	    ret = selfinsert(zlenoargs);
 	goto compend;
     }
     zsfree(lastprebr);
@@ -345,7 +345,7 @@
     if (comppatmatch && *comppatmatch && comppatmatch != opm)
 	haspattern = 1;
     if (useline < 0)
-	selfinsert(zlenoargs);
+	ret = selfinsert(zlenoargs);
     else if (!useline && uselist) {
 	/* All this and the guy only wants to see the list, sigh. */
 	cs = 0;
Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v
retrieving revision 1.9
diff -u -r1.9 zle_tricky.c
--- Src/Zle/zle_tricky.c	2000/05/15 09:54:46	1.9
+++ Src/Zle/zle_tricky.c	2000/05/22 11:25:51
@@ -159,6 +159,8 @@
     unsigned char *s = line + cs - 1;
 
     wouldinstab = 0;
+    if (keybuf[0] != '\t' || keybuf[1])
+	return 0;
     for (; s >= line && *s != '\n'; s--)
 	if (*s != '\t' && *s != ' ')
 	    return 0;

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2000-05-31  9:54 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-31  9:53 PATCH: Re: TAB and PS2 and multiline buffers and vared Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
2000-05-25  7:57 Sven Wischnowsky
2000-05-25 15:20 ` Bart Schaefer
2000-05-22 14:44 Sven Wischnowsky
2000-05-22 16:52 ` Bart Schaefer
2000-05-22 11:25 Sven Wischnowsky
2000-05-22 14:27 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).