zsh 4.x bug in completion?

zsh 4.x bug in completion?

[Stefan `Sec` Zehl]

Hi,

I'm a long-time user of zsh, and like it very much. I noticed there was
a new release, and thought I should upgrade because some of the
minor shortcomings of the 3.0.x-series might have been fixed. So I
upgraded from zsh3.0.x to zsh4.0.2 and noticed that it behaves
completely different. While I detest changing so much of the integral
behaviour, most of this was configurable, so i could restore the old
behaviour, and regain my sanity.

One thing, though, looks like a bug to me, at least I found no way to
turn it off.

To verify it, I used plain setup except a different binding for tab:

| nuyen:~>zsh -f
| nuyen% echo $ZSH_VERSION 
| 4.0.2
| nuyen% bindkey ^i expand-or-complete-prefix

Now we enter a command. 

| nuyen% echo test
| test

Lets assume this fails due to lacking permissions. I want to prepend
"sudo " to this command (sudo runs its arguments as root)

So i go to the beginning of the line, and add "sud"-<TAB>. The line now
looks like this:

| nuyen% sudo echo test 

With the cursor beeing on the "e" of echo.
Now hit enter.

| nuyen% sudoecho test 
| zsh: command not found: sudoecho

zsh removes the space. I have no idea who had that brilliant idea.

I found no option to turn this off. The closest ones, auto_param_keys
and auto_remove_slash seem to have no effect on that.

Please help,
    Sec
-- 
(Learn Lisp.  (Really.  (I'm serious.  (Trust me. (It rocks all over.)))))
-- Matt Curtin <cmcurtin@interhack.net> on freebsd-chat

Re: zsh 4.x bug in completion?

[Andrej Borsenkow]

Stefan `Sec` Zehl wrote:

> 
> So i go to the beginning of the line, and add "sud"-<TAB>. The line now
> looks like this:
> 
> | nuyen% sudo echo test 
> 


Use new completion (you are better off to remap TAB to complete-word 
instead of expand-or-coplete)

{pts/1}% zsh -f
localhost% autoload -U compinit; compinit
localhost% zstyle ':completion:*' completer _oldlist _complete _match 
_prefix
localhost%  zstyle ':completion:*' add-space true
localhost% setopt completeinword
localhost% echo test
test
localhost% sudTABecho  test
localhost% sudo echo test
test


-andrej

Re: zsh 4.x bug in completion?

[Peter Stephenson]

Stefan `Sec` Zehl wrote:
> Hi,
> 
> I'm a long-time user of zsh, and like it very much. I noticed there was
> a new release, and thought I should upgrade because some of the
> minor shortcomings of the 3.0.x-series might have been fixed. So I
> upgraded from zsh3.0.x to zsh4.0.2 and noticed that it behaves
> completely different. While I detest changing so much of the integral
> behaviour, most of this was configurable, so i could restore the old
> behaviour, and regain my sanity.

There's a list of `possible incompatibilities' in the README.  It would be
good if you could list any others you found.  I'm sure there must be more
I've forgotten about.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh 4.x bug in completion?

[Oliver Kiddle]

Peter Stephenson wrote:
> 
> There's a list of `possible incompatibilities' in the README.  It would be
> good if you could list any others you found.  I'm sure there must be more
> I've forgotten about.

Before we start listing this as a known incompatibility, I should just
point out that I can't reproduce this "bug". This may be something to do
with vi/emacs keybindings and how you move the cursor to the `e' of
echo. I can't think of much else seeing as the example starts from zsh
-f. Can anyone else reproduce it?

Oliver

Re: zsh 4.x bug in completion?

[Andrej Borsenkow]

On Mon, 9 Jul 2001, Oliver Kiddle wrote:

> Peter Stephenson wrote:
> >
> > There's a list of `possible incompatibilities' in the README.  It would be
> > good if you could list any others you found.  I'm sure there must be more
> > I've forgotten about.
>
> Before we start listing this as a known incompatibility, I should just
> point out that I can't reproduce this "bug". This may be something to do
> with vi/emacs keybindings and how you move the cursor to the `e' of
> echo. I can't think of much else seeing as the example starts from zsh
> -f. Can anyone else reproduce it?
>

Yes, I can with slightly outdated CVS. Using new completion and _prefix
completer I do not even get autoremoved space added (unless add-space is
set).

I won't claim it is neccessarily a bug. But I never used prefix completion
myself so I'm not sure what is correct (=logical?) behaviour.

-andrej

Re: zsh 4.x bug in completion?

[Bart Schaefer]

I get very strange behavior from 4.0.2.

With

zstyle ':completion:*' completer _complete _prefix  

I get:

schaefer<503> <Ctrl-P>
schaefer<503> echo foo<Ctrl-A>
schaefer<503> sud<TAB>echo foo
schaefer<503> sudoecho  foo
                       ^
		       cursor here

That is, it inserts `sudo' with no trailing space, but then moves to
the end of the word `echo' and adds a space *there*.  That is almost
certainly wrong?

I get exactly the same thing from 4.1.0-dev-2.

If I then add

zstyle ':completion:*' add-space yes

I get `sudo echo  foo', that is, it has added a space both after `sudo'
and after `echo'.

And, by the way, with TAB bound to expand-or-complete-prefix, I can in
fact reproduce the original complaint.  Auto-removing the space may make
sense when completing in the middle of a file path, but it doesn't when
completing in command position.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: zsh 4.x bug in completion?

[Sven Wischnowsky]

Bart Schaefer wrote:

> I get very strange behavior from 4.0.2.
> 
> With
> 
> zstyle ':completion:*' completer _complete _prefix  
> 
> I get:
> 
> schaefer<503> <Ctrl-P>
> schaefer<503> echo foo<Ctrl-A>
> schaefer<503> sud<TAB>echo foo
> schaefer<503> sudoecho  foo
>                        ^
> 		       cursor here
> 
> That is, it inserts `sudo' with no trailing space, but then moves to
> the end of the word `echo' and adds a space *there*.  That is almost
> certainly wrong?
> 
> I get exactly the same thing from 4.1.0-dev-2.
> 
> If I then add
> 
> zstyle ':completion:*' add-space yes
> 
> I get `sudo echo  foo', that is, it has added a space both after `sudo'
> and after `echo'.

Hm, yes.  These were both caused by _prefix being actually a hack.  But
we can hack some more when there is a single match, to trick it into
leaving the cursor where it should be left.

And then we need that hunk in the C-code because if the user requests
that no list is shown, we should do that and not print the explanation
strings.

> And, by the way, with TAB bound to expand-or-complete-prefix, I can in
> fact reproduce the original complaint.  Auto-removing the space may make
> sense when completing in the middle of a file path, but it doesn't when
> completing in command position.

That's the hunk in zle_tricky.c.  It turns off the auto-suffix behaviour
if completion left us after a space, leaving the space if a non-space
character is typed next.  I hope this is the most sensible thing to do.


Should this and/or the _man thing go into the stable branch? (I.e., is
that to be updated until the next stable release?)


Bye
  Sven

Index: Completion/Base/Completer/_prefix
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_prefix,v
retrieving revision 1.1
diff -u -r1.1 _prefix
--- Completion/Base/Completer/_prefix	2001/04/02 11:08:54	1.1
+++ Completion/Base/Completer/_prefix	2001/07/10 09:16:04
@@ -4,7 +4,7 @@
 
 [[ _matcher_num -gt 1 || -z "$SUFFIX" ]] && return 1
 
-local comp curcontext="$curcontext" tmp \
+local comp curcontext="$curcontext" tmp suf="$SUFFIX" \
       _completer _completer_num \
       _matcher _c_matcher _matchers _matcher_num
 
@@ -44,7 +44,13 @@
       _matcher="$_c_matcher"
     fi
 
-    [[ "$tmp" != _prefix ]] && "$tmp" && return 0
+    if [[ "$tmp" != _prefix ]] && "$tmp"; then
+      [[ compstate[nmatches] -gt 1 ]] && return 0
+      compadd -U -i "$IPREFIX" -I "$ISUFFIX" - "${compstate[unambiguous]%$suf}x"
+      compstate[list]=
+      compstate[insert]=unambiguous
+      return 0
+    fi
     (( _matcher_num++ ))
   done
   (( _completer_num++ ))
Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.45
diff -u -r1.45 compcore.c
--- Src/Zle/compcore.c	2001/02/28 09:12:57	1.45
+++ Src/Zle/compcore.c	2001/07/10 09:16:05
@@ -420,7 +420,7 @@
 	cs = origcs;
     }
     /* Print the explanation strings if needed. */
-    if (!showinglist && validlist && usemenu != 2 && 
+    if (!showinglist && validlist && usemenu != 2 && uselist &&
 	(nmatches != 1 || diffmatches) &&
 	useline >= 0 && useline != 2 && (!oldlist || !listshown)) {
 	onlyexpl = 3;
Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v
retrieving revision 1.30
diff -u -r1.30 zle_tricky.c
--- Src/Zle/zle_tricky.c	2001/06/25 09:32:21	1.30
+++ Src/Zle/zle_tricky.c	2001/07/10 09:16:06
@@ -2363,6 +2363,8 @@
 
     comppref = 1;
     ret = expandorcomplete(args);
+    if (cs && line[cs - 1] == ' ')
+        makesuffixstr(NULL, "\\-", 0);
     comppref = 0;
     return ret;
 }

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

Re: zsh 4.x bug in completion?

[Peter Stephenson]

Sven Wischnowsky wrote:
> Should this and/or the _man thing go into the stable branch? (I.e., is
> that to be updated until the next stable release?)

The next stable release probably isn't for a while, since none of the
problems in 4.0.2 seems to be critical.  You could wait till nearer the
time if you prefer.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh 4.x bug in completion?

[Bart Schaefer]

On Jul 10, 10:32am, Peter Stephenson wrote:
} Subject: Re: zsh 4.x bug in completion?
}
} Sven Wischnowsky wrote:
} > Should this and/or the _man thing go into the stable branch? (I.e., is
} > that to be updated until the next stable release?)
} 
} You could wait till nearer the time if you prefer.

On the other hand, the longer you wait, the more likely there is to be a
conflict with some other change.  It's easier to merge when code differs
less.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: zsh 4.x bug in completion?

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jul 10, 10:32am, Peter Stephenson wrote:
> } Subject: Re: zsh 4.x bug in completion?
> }
> } Sven Wischnowsky wrote:
> } > Should this and/or the _man thing go into the stable branch? (I.e., is
> } > that to be updated until the next stable release?)
> } 
> } You could wait till nearer the time if you prefer.
> 
> On the other hand, the longer you wait, the more likely there is to be a
> conflict with some other change.  It's easier to merge when code differs
> less.

Yes, I came to the same conclusion yesterday evening.  So I've committed
them now.


Bye
  Sven


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

Re: zsh 4.x bug in completion?

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Mon, Jul 09, 2001 at 08:31:39PM +0100,
Oliver Kiddle <opk@u.genie.co.uk> wrote:
> 
> Peter Stephenson wrote:
> > 
> > There's a list of `possible incompatibilities' in the README.  It would be
> > good if you could list any others you found.  I'm sure there must be more
> > I've forgotten about.
> 
> Before we start listing this as a known incompatibility, I should just
> point out that I can't reproduce this "bug". This may be something to do
> with vi/emacs keybindings and how you move the cursor to the `e' of
> echo. I can't think of much else seeing as the example starts from zsh
> -f. Can anyone else reproduce it?

I can.
~> zsh -f
picard% bindkey -e
picard% bindkey ^i expand-or-complete-prefix
picard% echo test
test
picard% su-echo test          <- cursor on e, hit TAB
picard% su-to-root echo test  (cursor on e, hit enter)
zsh: command not found: su-to-rootecho

Then again, I still have zsh-4.0.1 ;-)

> Oliver

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]