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

Re: PATCH: expansion

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 13,  1:24pm, Sven Wischnowsky wrote:
> } Subject: PATCH: expansion
> }
> }   Note that I've used the same default value in _expand as it has
> }   elsewhere (`false'), which means that without further configuring,
> }   this now behaves differently. Should we make it default to `true' in 
> }   _expand?
> 
> If it now behaves by default more like the way the old expand-or-complete
> behaved, then I think we should leave it.

It is more like e-o-c. So this makes me wonder if the default for the
suffix style should be changed (currently its default is like the old
_expand, changing it would make it like e-o-c).

> Either that or the default
> should be different depending on whether _expand was used as a completer
> or called from _expand_word ... hrmm ...

I'm never too happy with adding differences between a completer and
the bindable command for it...

Bye
 Sven


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

Re: PATCH: expansion

[Bart Schaefer]

On Jun 13,  1:24pm, Sven Wischnowsky wrote:
} Subject: PATCH: expansion
}
}   Note that I've used the same default value in _expand as it has
}   elsewhere (`false'), which means that without further configuring,
}   this now behaves differently. Should we make it default to `true' in 
}   _expand?

If it now behaves by default more like the way the old expand-or-complete
behaved, then I think we should leave it.  Either that or the default
should be different depending on whether _expand was used as a completer
or called from _expand_word ... hrmm ...

-- 
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   

PATCH: expansion

[Sven Wischnowsky]

[ sunsite.auc.dk seems to be down, at least I don't get my mails
  back... I'll just keep on sending patches ;-]

We were discussing these... This adds the style `suffix' and makes
`accept-exact' be used by _expand:

- With `suffix', expansion is not done if there is anything after a
  `~foo' or `$foo'. I.e. it will not expand `~foo/<TAB>', but it will
  expand `~foo'.
- With `accept-exact' set it will expand `$MAIL', with it unset, it
  will not expand it (if there are other parameters starting with
  `MAIL').
  We were using rexexact in the old expansion code, so I thought we
  should just use `accept-exact' which is the style equivalent of
  recexact.
  Note that I've used the same default value in _expand as it has
  elsewhere (`false'), which means that without further configuring,
  this now behaves differently. Should we make it default to `true' in 
  _expand?

Ok. Is this good enough? Oliver?

Bye
 Sven

Index: Completion/Core/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_expand,v
retrieving revision 1.15
diff -u -r1.15 _expand
--- Completion/Core/_expand	2000/06/08 08:39:51	1.15
+++ Completion/Core/_expand	2000/06/13 11:22:46
@@ -18,12 +18,6 @@
       force="$force$opt"
     done
 
-if [[ "$funcstack[2]" = _prefix ]]; then
-  word="$IPREFIX$PREFIX$SUFFIX"
-else
-  word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
-fi
-
 # First, see if we should insert all *completions*.
 
 if [[ "$force" = *c* ]] ||
@@ -33,8 +27,25 @@
   [[ "$curcontext" = expand-word:* ]] && _complete && return 0
   return 1
 fi
+
+if [[ "$funcstack[2]" = _prefix ]]; then
+  word="$IPREFIX$PREFIX$SUFFIX"
+else
+  word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
+fi
+
+zstyle -t ":completion:${curcontext}:" suffix &&
+  [[ "$word" = (\~*/*|\$[a-zA-Z0-9_]##[^a-zA-Z0-9_]*|\$\{*\}?*) ]] &&
+  return 1
+
+zstyle -t ":completion:${curcontext}:" accept-exact ||
+  { [[ "$word" = \~(|[-+]) ||
+       ( "$word" = \~[-+][1-9]## && $word[3,-1] -le $#dirstack ) ||
+       ( "$word" = \~* && ${#userdirs[(I)${word[2,-1]}*]}+${#nameddirs[(I)${word[2,-1]}*]} -ne 1 ) ||
+       ( "$word" = \$[a-zA-Z0-9_]## && 
+         ${#parameters[(I)${word[2,-1]}*]} -ne 1 ) ]] && return 1 }
 
-# In exp we will collect the expansion.
+# In exp we will collect the expansions.
 
 exp=("$word")
 
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.60
diff -u -r1.60 compsys.yo
--- Doc/Zsh/compsys.yo	2000/06/08 08:39:51	1.60
+++ Doc/Zsh/compsys.yo	2000/06/13 11:22:48
@@ -779,6 +779,12 @@
 matches.  If it is set to `true' for at least one match which is the
 same as the string on the line, this match will immediately be
 accepted.
+
+Note that this is also used by the tt(_expand) completer to decide if
+words beginning with a tilde or parameter expansion should be
+expanded. This means that if, for example, there are parameters
+tt(foo) and tt(foobar), the string `tt($foo)' will only be expanded if 
+tt(accept-exact) is set to `true'.
 )
 kindex(add-space, completion style)
 item(tt(add-space))(
@@ -1785,6 +1791,14 @@
 
 substitution will be performed only if given an explicit numeric
 argument other than `tt(1)', as by typing `tt(ESC 2 TAB)'.
+)
+kindex(suffix, completion style)
+item(tt(suffix))(
+This is used by the tt(_expand) completer if the word starts with a
+tilde or parameter expansion. If it is set to `true', the word will
+only be expanded if it doesn't have a suffix, i.e. if it is something
+like `tt(~foo)' or `tt($foo)', but not if it is `tt(~foo/)' or
+`tt($foo/bar)'. The default for this style is `false'.
 )
 kindex(tag-order, completion style)
 item(tt(tag-order))(

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

Re: PATCH: expansion

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Hm, do you want it to ever expand tildes at all? 

Not particularly. I wouldn't mind if it only did straight after the
tilde reference like expand-or-complete does for parameters but it would
have to be intelligent enough to see if it could be a partial reference
to a longer named directory. Whatever the completion does, it would also
be useful to be able to bind ^X~ to expand tildes.

> We could add more fine-grained control over the kinds of substitutions tried.

I think we should add fine-grained control though I fear it isn't easy
to do. It's a pity that the nearest I can get the the behaviour I want
is not by using _expand.

> Does anyone have other ideas for conditions when to expand or not?
> Let's collect them.

The only thing I can think of at the moment is the same thing I was
saying about tilde expansions with parameter substitutions: if I had a
$MAIL and $MAILPATH parameter, $MAIL<tab> should do completion and not
expansion. To a certain extent, this is what you might get if you had
the _expand completer after _complete if it wasn't for the fact that
completion would generally not give expansion a chance.

Oliver

Re: PATCH: expansion

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Peter Stephenson wrote:
> > 
> > > Glob expansion including tilde expansion was the final annoyance that
> > > made me stop using _expand altogether.
> > 
> > You might want to try again with the latest keep-prefix style (which has a
> > sensible default) to see if it's any better, and what if anything remains
> > to do.
> 
> That's certainly better but it has reminded me why I stopped using
> _expand:
> 
> cd ~+<tab> expands, even with keep-prefix. I use the autopushd option
> and really like being able to do cd ~+<tab and using the list of
> directories to return to a previous directory.
> 
> Similar to this is the following:
> hash -d abc=whatever
> hash -d abcd=whatever
> 
> I'm always used to completion not doing anything where there is more
> than one match so I don't like it when ~abc<tab> expands ~abc.

Hm, do you want it to ever expand tildes at all? We could add more
fine-grained control over the kinds of substitutions tried.

> One thing which I like about the way expand-or-complete works is that
> for example, $HOME<tab> will expand but $HOME/<tab> doesn't. In general,
> I prefer variables and tildes not to be expanded but in some cases I
> specifically want them expanded and if I press tab immediately after
> something, I've probably conciously thought to do the expansion.

Yes, that was always the problem with expansion -- guessing if the
user wants it or not. Hm, maybe some kind of expand-ambiguous style.

Does anyone have other ideas for conditions when to expand or not?
Let's collect them.

Bye
 Sven


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

Re: PATCH: expansion

[Oliver Kiddle]

Peter Stephenson wrote:
> 
> > Glob expansion including tilde expansion was the final annoyance that
> > made me stop using _expand altogether.
> 
> You might want to try again with the latest keep-prefix style (which has a
> sensible default) to see if it's any better, and what if anything remains
> to do.

That's certainly better but it has reminded me why I stopped using
_expand:

cd ~+<tab> expands, even with keep-prefix. I use the autopushd option
and really like being able to do cd ~+<tab and using the list of
directories to return to a previous directory.

Similar to this is the following:
hash -d abc=whatever
hash -d abcd=whatever

I'm always used to completion not doing anything where there is more
than one match so I don't like it when ~abc<tab> expands ~abc.

One thing which I like about the way expand-or-complete works is that
for example, $HOME<tab> will expand but $HOME/<tab> doesn't. In general,
I prefer variables and tildes not to be expanded but in some cases I
specifically want them expanded and if I press tab immediately after
something, I've probably conciously thought to do the expansion. Tab is
always much handier than ^X$ so this is something I like. Globs aren't
mixed with completion as often so I generally do want globs expanded
which is why I wanted subst-only-globs.

Oliver