PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))

PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I'm sorry; I was trying zsh-3.1.7 -f ... it behaves as Sven says in 3.1.9,
> though I don't understand why they differ.

Dunno either, I can only remember the 3.1.9 behaviour...

> And this part still puzzles me:
> 
> } And if your tag-order were going to matter, shouldn't it need to be:
> } 
> }     zstyle ':completion:*:expand:*' tag-order - all-expansions
> } 
> } because
> }           If any string in the value consists of only a hyphen, then
> }           *only* the tags specified by the other strings in the value
> }           are generated.  Normally all tags not explicitly selected are
> }           tried last if the specified tags fail to generate any
> }           matches.
> 
> Is that doc excerpt wrong now?

No. It's tag-order: try sets of tags one after another until one
generates matches, then stop. Since in _expand all tags succeed (if
there are expansions at all), it will never come to try the second set 
(and, for that reason, _expand doesn't even have a tag loop).


Wayne Davison wrote:

> ...
> 
> My biggest gripe is that if I type "~/.z" or "$HOME/.z" and press tab,
> the prefix expands into my home directory path.  I *hate* this.  I'm
> typing an abbreviated directory path and I want to complete an
> abbreviated directory path.  When I remove the "_expand" portion of
> the zstyle, then that part of the completion works properly, but I can
> no longer expand "~/.z*" into a list of file names.  I would love to
> see a version of _expand that works like it did in 3.0.x.

You can also try the substs-globs-only style.

> On a related note, I've always disliked the fact that wildcard
> expansion expands variables and tilde references.

Maybe we should add a style for this...

> Finally, one of the just-committed cvs changes has introduced a bug
> where an extra space is getting added when it shouldn't be.  Now, if
> you type "~/.z<tab>" you get "/home/wayne/.z " even though that file
> does not exist.  You should be able to reproduce this as follows:

We are talking about *expansion* here. If you do `echo ~/.z', what do
you see? What does it *expand* to?

Bart's answer to this:

> It was 11777.  Confusion about a double-negative, or something like that.
> Sven changed a test to be:
> 
> 	if ! zstyle -T ":completion:${curcontext}:" add-space; then
> 
> Either it should go back to what it was before:
> 
> 	if zstyle -T ":completion:${curcontext}:" add-space; then
> 
> Or else it should use `-t':
> 
> 	if ! zstyle -t ":completion:${curcontext}:" add-space; then
> 
> The two are subtly different; the former means "no value for add-space is
> set to for the current context" and the latter means "it is not the case
> that add-space is set to one of `true', `yes', `on' or `1' for the current
> context."

I know all that. And I still insist, that the current behaviour is
correct; from the docs:

  item(tt(add-space))(
  This style is used by the tt(_expand) completer.  If it is `true' (the
  default), a space will be inserted after all words resulting from the 
  expansion (except for directory names which get a slash).

So, it appends a space to the generated expansion.

What you folks really want is a more sophisticated add-space
behaviour, namely (I'm guessing ;-): if add-space if false, never add
a space; if it is true, add a space if the generated word is the name
of an existing file. But then I would insist, that we change add-space 
to:

  - true: always add a space (after all, one might want to use it to
           generate names of non-existing files)
  - false: never add a space
  - exisiting: add a space only if the word is the name of an
           exisiting file

Ok? Can anyone think of even more possible wishes?


Wayne Davison wrote:

> On Wed, 7 Jun 2000, Bart Schaefer wrote:
> > I think you want to NOT rebind '\t' to complete-word -- that is,
> > leave it bound to expand-or-complete -- AND leave out the _expand
> > completer.  This will give you the old behavior of expansion
> > followed by the new behavior of completion.
> 
> That would be cool if I could get it to work.  However, no matter
> what I try, tab does not expand wildcards with expand-or-complete
> set.  It just expands $VARIABLES.

[Scratching head...] Hm. It works for me.

> > You can still get the new behavior of _expand from <C-x e> in this case.
> 
> The only thing I get when I do that is this error:
> 
>     _expand_word:5: curcontext: parameter not set
> 
> This is caused by my predilection to having the "no_unset" option set
> for my interactive-shell use.

Oh, that one again. The patch below fixes this.

Bye
 Sven

Index: Completion/Commands/_correct_word
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_correct_word,v
retrieving revision 1.1.1.6
diff -u -r1.1.1.6 _correct_word
--- Completion/Commands/_correct_word	2000/02/03 17:22:42	1.1.1.6
+++ Completion/Commands/_correct_word	2000/06/07 06:45:38
@@ -7,6 +7,9 @@
 # If configurations keys with the prefix `correctword_' are
 # given they override those starting with `correct_'.
 
+setopt localoptions nullglob rcexpandparam extendedglob
+unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
 local curcontext="$curcontext"
 
 if [[ -z "$curcontext" ]]; then
Index: Completion/Commands/_expand_word
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_expand_word,v
retrieving revision 1.2
diff -u -r1.2 _expand_word
--- Completion/Commands/_expand_word	2000/04/20 08:04:56	1.2
+++ Completion/Commands/_expand_word	2000/06/07 06:45:38
@@ -2,6 +2,9 @@
 
 # Simple completion front-end implementing expansion.
 
+setopt localoptions nullglob rcexpandparam extendedglob
+unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
 local curcontext="$curcontext"
 
 if [[ -z "$curcontext" ]]; then
Index: Completion/Commands/_next_tags
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Commands/_next_tags,v
retrieving revision 1.6
diff -u -r1.6 _next_tags
--- Completion/Commands/_next_tags	2000/05/23 08:54:30	1.6
+++ Completion/Commands/_next_tags	2000/06/07 06:45:38
@@ -3,6 +3,9 @@
 # Main widget.
 
 _next_tags() {
+  setopt localoptions nullglob rcexpandparam extendedglob
+  unsetopt markdirs globsubst shwordsplit nounset ksharrays
+
   local ins ops="$PREFIX$SUFFIX"
 
   unfunction _all_labels _next_label

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

Re: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))

[Sven Wischnowsky]

I wrote:

> [ add-space in _expand ]
> 
>   - true: always add a space (after all, one might want to use it to
>            generate names of non-existing files)
>   - false: never add a space
>   - exisiting: add a space only if the word is the name of an
>            exisiting file
> 
> Ok? Can anyone think of even more possible wishes?

Maybe we should add to this: add a space if the thing comes from a
parameter expansion even if it isn't the name of an existing file.

Bye
 Sven


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

Re: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))

[Bart Schaefer]

On Jun 7,  8:46am, Sven Wischnowsky wrote:
} Subject: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference betw
}
} 
} Bart Schaefer wrote:
} 
} > It was 11777.  Confusion about a double-negative, or something like that.

I'm going to stop responding to articles with numbers ending in three 7s.

} > Sven changed a test to be:
} > 
} > 	if ! zstyle -T ":completion:${curcontext}:" add-space; then
} 
} I know all that.

Of course YOU know all that.  Wayne might not.

} And I still insist, that the current behaviour is
} correct; from the docs:
} 
}   This style is used by the tt(_expand) completer.  If it is `true' (the
}   default), a space will be inserted after all words resulting from the 
}   expansion (except for directory names which get a slash).
} 
} So, it appends a space to the generated expansion.
} 
} What you folks really want is a more sophisticated add-space

Actually what I want is some way to know without looking at the docs
whether a style defaults to `true' when not set or to `false' when not
set.  Back in the mists of time we used to have options whose names
started with `no' so that you'd know that setting it turned something
off, rather than on, and there was no non-`no' (I sound like a backup
singer for a '50s rock group) option to unset instead, so looking at
the output of `setopt' was enough to tell you what the heck was going
on:  The default behavior changed only when something became true, and
"not set" always meant false.

Pardon me, I just go off on that from time to time.  I'm not really
suggesting that we redo it all again at this point.

Anyway, I assumed without looking that add-space was supposed to default
to false when not set, since that had been the previous behavior.

} namely (I'm guessing ;-): if add-space if false, never add
} a space; if it is true, add a space if the generated word is the name
} of an existing file.

I just speculated exactly this in my reply to the expand-or-complete
thread, but I don't think it makes as much sense as does appending a
space only when multiple words result.

} But then I would insist, that we change add-space to:
} 
}   - true: always add a space (after all, one might want to use it to
}            generate names of non-existing files)
}   - false: never add a space
}   - exisiting: add a space only if the word is the name of an
}            exisiting file
} 
} Ok?

Whether that is "ok" depends more on what the behavior is when it is not
set at all than on what the possible settings are.

-- 
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: PATCH: expansion (was: Re: PATCH: Re: blah*[TAB] (difference between 3.1.6 and 3.1.9))

[Bart Schaefer]

Sorry, I meant to catch this in my other message:

On Jun 7,  9:07am, Sven Wischnowsky wrote:
}
} Maybe we should add to this: add a space if the thing comes from a
} parameter expansion even if it isn't the name of an existing file.

How about a simplified rule of "add a space whenever completion would."

Of course that's probably a much more complicated *implementation* ...

-- 
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: PATCH: expansion

[Wayne Davison]

On Wed, 7 Jun 2000, Sven Wischnowsky wrote:
> I wrote:
> > Finally, one of the just-committed cvs changes has introduced a bug
> > where an extra space is getting added when it shouldn't be.  Now, if
> > you type "~/.z<tab>" you get "/home/wayne/.z " even though that file
> > does not exist.
> 
> We are talking about *expansion* here.

Yes, I was switching topics a bit and talking about a bug in the
_expand module.  When I type the string "ls ~/.z<tab>" hoping to
complete the filename, instead the _expand module expands the ~ into
my home directory, and it now adds a space to the end of the string.
That means I have to backspace over the space to continue completing
the filename.

> Wayne Davison wrote:
> > However, no matter what I try, tab does not expand wildcards with
> > expand-or-complete set.
> 
> [Scratching head...] Hm. It works for me.

...And it would have worked for me too if glob_complete hadn't been
turned on in the /etc/zshrc file.  I apparently didn't notice that
Mandrake Linux does this (because I have been attempting to use the
new expansion/completion system on my Linux box).

> [Going back to the glob discussion...]
> You can also try the substs-globs-only style.

I assume that should be spelled "subst-globs-only".  I can't get this
style to work for me.  If I only set subst-globs-only (without anything
like "glob" set), it does nothing.  If I also set "glob", it expands
tildes.  I.e.:

% zsh -f
% bindkey '\t' complete-word
% autoload -U compinit
% compinit -D
% zstyle ':completion:*' completer _expand _complete
% zstyle ':completion:*:expand:::' subst-globs-only 1
% zstyle ':completion:*:expand:*' tag-order all-expansions
% touch tmp{1..3}
% ls tmp*<tab>

This fails to do anything (but beep).  If I add this line:

% zstyle ':completion:*:expand:::' glob 1

then "ls tmp*<tab>" expands correctly, but "~/.z<tab>" expands the
tilde instead of doing nothing.

..wayne..

Re: PATCH: expansion

[Oliver Kiddle]

Wayne Davison wrote:
> 
> I assume that should be spelled "subst-globs-only".  I can't get this
> style to work for me.  If I only set subst-globs-only (without anything
> like "glob" set), it does nothing.  If I also set "glob", it expands
> tildes.

For subst-globs-only to be useful, you will want to set both substitute
and glob as well. What it does is allow substitutions only when globbing
is going to do something so if you type cd $HOME/<tab>, $HOME will not
be expanded but if you type echo $HOME/*<tab> it will be because the
expansion is necessary for the globbing to work.

Whether this is something that you want I don't know. For me, it made
the behaviour better but still a long way from the way I'd like it to
be.

Glob expansion including tilde expansion was the final annoyance that
made me stop using _expand altogether.

Oliver Kiddle