4.0.1: menucomplete quirk leaving extra characters behind

4.0.1: menucomplete quirk leaving extra characters behind

[Jos Backus]

traitor:~% zsh -f
traitor% autoload -U compinit ; compinit
traitor% setopt menucomplete
traitor% _

Now when I hit <Tab>, I see:

traitor% \!
zsh: do you wish to see all 2188 possibilities (730 lines)? _

Answering ``n'' gives:

traitor% \!_

with the cursor sitting behind the !.

(Btw, on Solaris the characters are ``!='' instead.)

Any idea what causes this?

Thanks,
-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: 4.0.1: menucomplete quirk leaving extra characters behind

[Bart Schaefer]

On Jun 12,  3:37pm, Jos Backus wrote:
> 
> Now when I hit <Tab>, I see:
> 
> traitor% \!
> zsh: do you wish to see all 2188 possibilities (730 lines)? _
> 
> Answering ``n'' gives:
> 
> traitor% \!_

There's a reserved word `!' that's valid in command position.  It means
to negate the exit status of whatever command comes next.  You generally
use it like this:

	if ! othercommand; then ...; fi

So that happens to be the first item in the menu.  You asked zsh not to
list the rest of the menu, but you're still in menu completion, so if you
start pressing TAB repeatedly, you'll cycle through the rest of the words
that are valid in command position, most of which are external commands.

> (Btw, on Solaris the characters are ``!='' instead.)

That's what I see after pressing TAB twice; it's the next word in the menu
and it's the first part of a parameter assignment to the `!' parameter.  If
I keep on hitting TAB I see #= and $= and *=.  This is actually a bug, I
guess, because those parameters are read-only and so you shouldn't be able
to complete them on the left side of an assignment, but menucompletion is
not itself malfunctioning.

Are you sure you didn't hit TAB more than once on Solaris?
-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Jos Backus]

On Tue, Jun 12, 2001 at 05:16:41PM -0700, Bart Schaefer wrote:
[explanation about ! in command position elided]

I thought it was strange because 3.1.9 didn't behave the same way; it simply
tabs to the next tab position on the input line. So something seems to have
changed although that's not necessarily wrong. Your explanation makes perfect
sense, of course. Thanks.

> Are you sure you didn't hit TAB more than once on Solaris?

I guess I must have because I can't seem to reproduce this now :-/
The shell behaves as you describe; sorry for the false alarm.

-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: 4.0.1: menucomplete quirk leaving extra characters behind

[Bart Schaefer]

On Jun 12,  5:46pm, Jos Backus wrote:
} Subject: Re: 4.0.1: menucomplete quirk leaving extra characters behind
}
} On Tue, Jun 12, 2001 at 05:16:41PM -0700, Bart Schaefer wrote:
} [explanation about ! in command position elided]
} 
} I thought it was strange because 3.1.9 didn't behave the same way; it
} simply tabs to the next tab position on the input line.

Ah; you (may) want

	zstyle ':completion:*' insert-tab true


-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Jos Backus]

On Wed, Jun 13, 2001 at 02:23:07AM +0000, Bart Schaefer wrote:
> Ah; you (may) want
> 
> 	zstyle ':completion:*' insert-tab true

Great, thanks Bart.

-- 
Jos Backus                 _/  _/_/_/        "Modularity is not a hack."
                          _/  _/   _/                -- D. J. Bernstein
                         _/  _/_/_/             
                    _/  _/  _/    _/
josb@cncdsl.com     _/_/   _/_/_/            use Std::Disclaimer;

Re: 4.0.1: menucomplete quirk leaving extra characters behind

[Oliver Kiddle]

Bart Schaefer wrote:
> 
> > (Btw, on Solaris the characters are ``!='' instead.)
> 
> I keep on hitting TAB I see #= and $= and *=.  This is actually a bug, I
> guess, because those parameters are read-only and so you shouldn't be able
> to complete them on the left side of an assignment, but menucompletion is

Yes, it is arguably a bug, though not hard to fix. This will still offer
@= and *= because they are not readonly but you can't assign to them
this way. I'll commit this to the stable branch later unless anyone
objects.

> Ah; you (may) want
>       zstyle ':completion:*' insert-tab true

I use this:
zstyle -e ':completion:*:*:-command-:*' tag-order '
    [[ -n $PREFIX$SUFFIX || $1 = messages ]] || 
        { reply=( - ); _message "not with an empty word" }'

which has the advantage of working in other places where commands are
completed such as after noglob. It depends on why you don't want
completion at that position - I don't because it tends to be slow with
several thousand commands.

Oliver

Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.1
diff -u -r1.1 _command_names
--- Completion/Zsh/Type/_command_names  2001/04/02 11:17:31     1.1
+++ Completion/Zsh/Type/_command_names  2001/06/13 10:28:19
@@ -22,7 +22,7 @@
     'aliases:alias:compadd -k aliases'
     'reserved-words:reserved word:compadd -k reswords'
     'jobs:: _jobs -t'
-    'parameters:: _parameters -qS= -r "\n\t\- =["'
+    'parameters:: _parameters -g "^*readonly*" -qS= -r "\n\t\- =["'
   )
 fi

Re: 4.0.1: menucomplete quirk leaving extra characters behind

[Bart Schaefer]

On Jun 13, 11:32am, Oliver Kiddle wrote:
} Subject: Re: 4.0.1: menucomplete quirk leaving extra characters behind
}
} This will still offer @= and *= because they are not readonly but you
} can't assign to them

Hmm, maybe they _should_ be readonly?  Does `unset @' really make sense?


-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Peter Stephenson]

"Bart Schaefer" wrote:
> Does `unset @' really make sense?

Arguably, but it's a little tricky.

  % set these are arguments
  % unset @
  % print $*
  
  % print $@
  
  % set these are more arguments
  % print $@
  
  % print $*
  these are more arguments

And I've completely failed to convince it that $@ is active again.  You
can't assign to it normally.  Making it readonly makes sense, but remember
it's actually possible to turn that off.  Should we make readonly special
variables unreadwriteable?

-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Bart Schaefer]

On Jun 13,  5:58pm, Peter Stephenson wrote:
}
} Should we make readonly special variables unreadwriteable?

That would probably be a very good idea.  I think it falls under the existing
"can't change type of a special parameter" rule.

-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Jun 13,  5:58pm, Peter Stephenson wrote:
> }
> } Should we make readonly special variables unreadwriteable?
> 
> That would probably be a very good idea.  I think it falls under the existing
> "can't change type of a special parameter" rule.

That makes it easy.  I'm in two minds about one thing, though:  should it
still be possible to turn on the readonly flag for a special?  The problem
is that once on, you can't turn it off.  That may be still be useful,
though.  Or we can introduce a flag PM_SPECIALREADONLY which has the same
effect as PM_READONLY but can't be reset (and we complain if the user tries
to change PM_READONLY if that's set).

-- 
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: 4.0.1: menucomplete quirk leaving extra characters behind

[Bart Schaefer]

On Jun 13,  7:48pm, Peter Stephenson wrote:
> Subject: Re: 4.0.1: menucomplete quirk leaving extra characters behind
> 
> Or we can introduce a flag PM_SPECIALREADONLY which has the same
> effect as PM_READONLY but can't be reset (and we complain if the user tries
> to change PM_READONLY if that's set).

Or we could add to struct param a mask word of those flag bits that are
allowed to be changed ... but maybe that's overkill and one new flag is
sufficient to cover the cases.

I'd say first let's just try it with readonly being a one-way trip, and
see where we end up.

Re: 4.0.1: menucomplete quirk leaving extra characters behind

[Peter Stephenson]

"Bart Schaefer" wrote:
> I'd say first let's just try it with readonly being a one-way trip, and
> see where we end up.

This also does the same for autoloadable but not yet loaded parameters; the
problem in that case is usually that turning attributes on or off is
meaningless rather than dangerous, and the typeset code is complicated
enough that anything that allows us to keep different cases together is
good news.

Then $* and $@ are made readonly.  As I reported, you can't set them
directly anyway; as Bart reported, you can only cause mischief by unsetting
them.

Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/builtins.yo,v
retrieving revision 1.29
diff -u -r1.29 builtins.yo
--- Doc/Zsh/builtins.yo	2001/06/08 03:04:41	1.29
+++ Doc/Zsh/builtins.yo	2001/06/14 09:32:23
@@ -1192,7 +1192,9 @@
 The value is em(not) converted when assigned.
 )
 item(tt(-r))(
-The given var(name)s are marked readonly.
+The given var(name)s are marked readonly.  Note that if var(name) is a
+special parameter, the readonly attribute can be turned on, but cannot then
+be turned off.
 )
 item(tt(-t))(
 Tags the named parameters.  Tags have no special meaning to the shell.
Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.9
diff -u -r1.9 params.yo
--- Doc/Zsh/params.yo	2001/05/29 17:54:39	1.9
+++ Doc/Zsh/params.yo	2001/06/14 09:32:23
@@ -31,9 +31,11 @@
 
 In the parameter lists that follow, the mark `<S>' indicates that the
 parameter is special.
-Special parameters cannot have their type changed, and they stay special even
-if unset.  `<Z>' indicates that the parameter does not exist when the shell
-initializes in tt(sh) or tt(ksh) emulation mode.
+Special parameters cannot have their type changed or their
+readonly attribute turned off, and if a special parameter is unset, then
+later recreated, the special properties will be retained.  `<Z>' indicates
+that the parameter does not exist when the shell initializes in tt(sh) or
+tt(ksh) emulation mode.
 startmenu()
 menu(Array Parameters)
 menu(Positional Parameters)
Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.46
diff -u -r1.46 builtin.c
--- Src/builtin.c	2001/05/15 10:02:35	1.46
+++ Src/builtin.c	2001/06/14 09:32:23
@@ -1628,7 +1628,14 @@
 	if ((tc = chflags && chflags != (PM_EFLOAT|PM_FFLOAT)))
 	    usepm = 0;
     }
-    if (tc){
+
+    /*
+     * Extra checks if converting the type of a parameter, or if
+     * trying to remove readonlyness.  It's dangerous doing either
+     * with a special or a parameter which isn't loaded yet (which
+     * may be special when it is loaded; we can't tell yet).
+     */
+    if (tc || ((usepm || newspecial) && (off & pm->flags & PM_READONLY))) {
 	if (pm->flags & PM_SPECIAL) {
 	    zerrnam(cname, "%s: can't change type of a special parameter",
 		    pname, 0);
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.48
diff -u -r1.48 params.c
--- Src/params.c	2001/05/31 09:44:00	1.48
+++ Src/params.c	2001/06/14 09:32:23
@@ -216,8 +216,8 @@
 
 #define IPDEF9F(A,B,C,D) {NULL,A,D|PM_ARRAY|PM_SPECIAL|PM_DONTIMPORT,BR((void *)B),SFN(arrvarsetfn),GFN(arrvargetfn),stdunsetfn,0,NULL,C,NULL,0}
 #define IPDEF9(A,B,C) IPDEF9F(A,B,C,0)
-IPDEF9("*", &pparams, NULL),
-IPDEF9("@", &pparams, NULL),
+IPDEF9F("*", &pparams, NULL, PM_ARRAY|PM_SPECIAL|PM_DONTIMPORT|PM_READONLY),
+IPDEF9F("@", &pparams, NULL, PM_ARRAY|PM_SPECIAL|PM_DONTIMPORT|PM_READONLY),
 {NULL, NULL},
 #define IPDEF10(A,B,C) {NULL,A,PM_ARRAY|PM_SPECIAL,BR(NULL),SFN(C),GFN(B),stdunsetfn,10,NULL,NULL,NULL,0}
 
-- 
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.
**********************************************************************