Another keep-prefix problem

Another keep-prefix problem

[Wayne Davison]

I noticed one other problem with the current zsh (in CVS) and how it
handles keeping the prefix.  After Bart's last set of tweaks, this
works:

   % ls $var1/foo/$var2/bar<TAB>

But leaving off the leading variable results in a useless expansion:

   % ls /full/path/foo/$var/bar<TAB>

When the filename only has an embedded variable, it is expanded.
Here's a (completely usless) failure case:

   zsh -f
   % autoload -U compinit
   % compinit
   % zstyle ':completion:*' completer _expand _complete
   % zstyle ':completion:*:expand:*' keep-prefix true
   % bindkey '\t' complete-word
   % www=/var/www/html
   % mkdir $www/subdir
   % echo ~
   /home/wayne
   % ls -l ~/../..$www/sub<TAB>

... properly expands to 'subdir' ...

   % ls -l /home/wayne/../..$www/sub<TAB>

... does not.

..wayne..

Re: Another keep-prefix problem

[Bart Schaefer]

On Apr 23,  5:46pm, Wayne Davison wrote:
} Subject: Another keep-prefix problem
}
} I noticed one other problem with the current zsh (in CVS) and how it
} handles keeping the prefix.  After Bart's last set of tweaks, this
} works:
} 
}    % ls $var1/foo/$var2/bar<TAB>
} 
} But leaving off the leading variable results in a useless expansion:
} 
}    % ls /full/path/foo/$var/bar<TAB>
} 
} When the filename only has an embedded variable, it is expanded.

I suspect this is because of the `suffix' style:

suffix
     This is used by the _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 `~foo' or `$foo', but not if it is `~foo/' or
     `$foo/bar', unless that suffix itself contains characters eligible
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     for expansion.  The default for this style is `true'.

In your example, $var2 is in the suffix and eligible for expansion, so
expansion is tried, and keep-prefix only preserves the leading $var1 in
that case.

} Here's a (completely usless) failure case:
} 
}    zsh -f
}    % autoload -U compinit
}    % compinit
}    % zstyle ':completion:*' completer _expand _complete
}    % zstyle ':completion:*:expand:*' keep-prefix true
}    % bindkey '\t' complete-word
}    % www=/var/www/html
}    % mkdir $www/subdir
}    % echo ~
}    /home/wayne
}    % ls -l ~/../..$www/sub<TAB>
} 
} ... properly expands to 'subdir' ...

You don't mean "expands", you mean "completes", right?

}    % ls -l /home/wayne/../..$www/sub<TAB>
} 
} ... does not.

Exactly how does it not work?  For me, it expands (not completes) to
`/home/wayne/../../var/www/html/sub' and completion can continue from
there.  keep-prefix only applies to words that begin with `~' or `$',
not to words that have a `$' anywhere in the prefix; the `suffix' style
is for the words with a `$' somewhere else (which is a slight misnomer,
as it means the file-path-suffix of the completion-prefix, and not the
completion-suffix (which is the stuff to the right of the cursor)).

Maybe you want to look at the `subst-globs-only' and/or `substitute'
styles, if you haven't already done so.

-- 
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: Another keep-prefix problem

[Wayne Davison]

In reading through the man page some more, it looks like in this case
I should be complaining about the "suffix" style:  that it requires
the word to start with a $ or a ~ for this rule to kick in.

The old expander does not require this.  I.e. it treats this as a
completion request (use expand-or-complete without _expand in your
completer setting):

  % ls -l /net/machine$path/foo<TAB>

This does not expand anything.  I think that it will cause less
confusion if the new expander would work like the old one does in
this regard.

However, I have the same complaint about keep-prefix when using
wildcards:

  % ls -l /net/machine$path/foo*<TAB>

I'd like to see $path left unexpanded.  In other words, I want keep-
prefix to preserve the prefix no matter where the $ expression is in
the prefix.

> Maybe you want to look at the `subst-globs-only' and/or `substitute'
> styles, if you haven't already done so.

I suppose using subst-globs-only might be a fairly good way to go
(along with changing ^Xe to something that would actually expand
variables -- using "expand-word" seems to work fine).  However, using
this setting does still "fail" my glob-expansion test above (i.e. it
does not leave the $path unexpanded when expanding wildcards).

Using "substitute false" appears to break wildcards with variables
completely, so that doesn't appear to be useful to me.

..wayne..

Re: Another keep-prefix problem

[Sven Wischnowsky]

[ We only just found out that my machine still had the address of that
server that died yesterday in it's resolv.conf... that was the reason
why I didn't get my mails back -- they weren't sent.  Apologies to the
folks at sunsite.  Ahem. ]


Wayne Davison wrote:

> ...
> 
>   % ls -l /net/machine$path/foo<TAB>
> 
> This does not expand anything.  I think that it will cause less
> confusion if the new expander would work like the old one does in
> this regard.
> 
> However, I have the same complaint about keep-prefix when using
> wildcards:
> 
>   % ls -l /net/machine$path/foo*<TAB>
> 
> I'd like to see $path left unexpanded.  In other words, I want keep-
> prefix to preserve the prefix no matter where the $ expression is in
> the prefix.

Please try the patch below and tell me what you think (and everyone else
interested in this subject, too, please).  It gives me what you want for
both cases.

I won't commit this before I get positive replies and answers to the
question if we then should add another possible value for the
keep-prefix style for this new behaviour or if that's not needed (I
can't really think of a reason for keeping the old behaviour -- put some
people probably like it?).

Bye
  Sven

Index: Completion/Base/Completer/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_expand,v
retrieving revision 1.1
diff -u -r1.1 _expand
--- Completion/Base/Completer/_expand	2001/04/02 11:06:35	1.1
+++ Completion/Base/Completer/_expand	2001/04/25 13:20:37
@@ -89,10 +89,16 @@
   [[ "$subd" = "$exp"(|\(N\)) ]] &&  return 1
 
 zstyle -s ":completion:${curcontext}:" keep-prefix tmp || tmp=changed
-if [[ "$word" = [\~\$]*/* && "$tmp" = (yes|true|on|1|changed) ]]; then
-  eval 'epre=( ${(e)~${word%%/*}} )' 2>/dev/null
-  if [[ -n "$epre" && $#epre -eq 1 ]]; then
+
+if [[ "$word" = (\~*/*|*\$*/*) && "$tmp" = (yes|true|on|1|changed) ]]; then
+  if [[ "$word" = *\$* ]]; then
+    opre="${(M)word##*\$[^/]##/}"
+  else
     opre="${word%%/*}"
+  fi
+  eval 'epre=( ${(e)~opre} )' 2> /dev/null
+
+  if [[ -n "$epre" && $#epre -eq 1 ]]; then
     pre="${(q)epre[1]}"
     [[ "$tmp" != changed || $#exp -gt 1 ||
        "${opre}${exp[1]#${pre}}" != "$word" ]] && exp=( ${opre}${^exp#${pre}} )

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

Re: Another keep-prefix problem

[Bart Schaefer]

On Apr 25,  3:25pm, Sven Wischnowsky wrote:
}
} I won't commit this before I get positive replies and answers to the
} question if we then should add another possible value for the
} keep-prefix style for this new behaviour or if that's not needed (I
} can't really think of a reason for keeping the old behaviour -- put some
} people probably like it?).

I think the behavior of expanding only some of the parameter references
in a word was a bit odd to begin with, and that we should just do it the
way this patch changed it and leave it at that.  I.e., no new style.

-- 
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: Another keep-prefix problem

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> To test I did:
> c1=/home
> c3=cvs
> Now,
> cd $c1/kiddleo/$c3/<tab> expands both $c1 and $c3 which I don't want.
> Having typed the / after $c3, I expect it to complete subdirectories
> in my ~/cvs and not do expansion.

As has already been said, this has to do with the suffix style (or
should have to do with it).  The patch below changes the test for that. 
Like Bart, I'm not exactly sure how the test should look like (for a
really good test we would need more complicated code than can be
expressed by a simple pattern).  So there may be no better way than to
commit the thing below and to invite everyone interested to play with
the code and commit improvements (if we find more than one interesting
setting, we can always add special values to select them to the suffix
style).

> Okay, so I tried setting keep-prefix to 1 and things start working nicely.
> Except what is going on here (where I mix globs with variables):
>    cd /home/kiddle?/$c3/<tab> results in:
>    cd /home/kiddle?/$c3//home/kiddleo/cvs/
> this definitely isn't right.

That was caused by _path_files which found the $-expression, remembered
everything up to and including it and later was unable to properly
replace the prefixes of the generated pathnames with the original
prefix.  I don't see how we can solve that, so I've at least changed
_path_files so that it doesn't complete anything in such cases.

> So in what situations is the changed value of keep-prefix useful for?
> It sounds something like subst-globs-only from the docs. I can't
> remember why I used it and not a value of 1.

It is slightly comparable to what s-g-o does and it also has to do (a
bit) with what suffix does.  And it's probably most useful for people
who know what it does (although I think I hoped that it gives a quite
natural behaviour, actually reducing the number of surprises for users).

When thinking only aboyt expansion, I though that people would probably
want the parameter substitution in `$foo/pat*<TAB>' to be left alone. 
But if a user does that on `$foo/<TAB>' or `~foo/<TAB>', with other
styles set up so that the keep-prefix style is tested for it at all, he
probably wants the thing expanded.

> Actually, talking of the docs for styles, the section on tag-order is
> messed up and seems to have the same example twice.

I've removed one of the places where that example was given.


Bye
  Sven

Index: Completion/Base/Completer/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Completer/_expand,v
retrieving revision 1.2
diff -u -r1.2 _expand
--- Completion/Base/Completer/_expand	2001/04/26 07:02:49	1.2
+++ Completion/Base/Completer/_expand	2001/04/27 09:03:14
@@ -28,8 +28,13 @@
    ( "$word" = *\$[a-zA-Z0-9_]## && $+parameters[${word##*\$}] -eq 0 ) ]] &&
     return 1
 
+### I'm not sure about the pattern to use in the following test.
+# It once was:
+#  [[ "$word" = (\~*/|\$(|[=~#^+])[a-zA-Z0-9_\[\]]##[^a-zA-Z0-9_\[\]]|\$\{*\}?)[^\$\{\}\(\)\<\>?^*#~]# ]] &&
+
 zstyle -T ":completion:${curcontext}:" suffix &&
-  [[ "$word" = (\~*/|\$(|[=~#^+])[a-zA-Z0-9_\[\]]##[^a-zA-Z0-9_\[\]]|\$\{*\}?)[^\$\{\}\(\)\<\>?^*#~]# ]] &&
+  [[ "$word" = (\~*/|*\$(|[=~#^+])[a-zA-Z0-9_\[\]]##[^a-zA-Z0-9_\[\]]|*\$\{*\}?) &&
+     "${(e)word}" != *[][^~*?\<\>\{\}\|]* ]] &&
   return 1
 
 zstyle -t ":completion:${curcontext}:" accept-exact ||
Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.3
diff -u -r1.3 _path_files
--- Completion/Unix/Type/_path_files	2001/04/18 16:02:52	1.3
+++ Completion/Unix/Type/_path_files	2001/04/27 09:03:14
@@ -190,7 +190,7 @@
 
 # Now let's have a closer look at the string to complete.
 
-if [[ "$pre" = *(\`[^\`]#\`|\$)*/* && "$compstate[quote]" != \' ]]; then
+if [[ "$pre" = [^][*?#^\|\<\>]#(\`[^\`]#\`|\$)*/* && "$compstate[quote]" != \' ]]; then
 
   # If there is a parameter expansion in the word from the line, we try
   # to complete the beast by expanding the prefix and completing anything
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.120
diff -u -r1.120 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/26 14:40:11	1.120
+++ Doc/Zsh/compsys.yo	2001/04/27 09:03:17
@@ -1949,7 +1949,7 @@
 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
+tilde or contains a 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)', unless that suffix itself contains characters eligible
@@ -2001,18 +2001,8 @@
 var(label) starts with a hyphen, the var(tag) is prepended to the
 var(label) to form the name used for lookup.  This can be
 used to make the completion system try a certain tag more than once,
-supplying different style settings for each attempt.  For example,
-
-example(zstyle ':completion:*:*:-command-:*' \ 
-    tag-order 'functions:-non-comp'
-zstyle ':completion:*:functions-non-comp' \ 
-    ignored-patterns '_*')
-
-This makes completion in command position first try only names of shell
-functions that don't match the pattern `tt(_*)'. If that generates no
-matches, the default of trying all the other things that can be
-completed in command position is used, including the names of all
-shell functions.
+supplying different style settings for each attempt, see below for an
+example.
 
 The var(label) may optionally be followed by a second colon and a
 description.  This description will then be used for the `tt(%d)' in

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

Re: Another keep-prefix problem

[Wayne Davison]

On Thu, 26 Apr 2001, Bart Schaefer wrote:
>      something like `~foo' or `$foo', but not if it is `~foo/' or
>      `$foo/bar', unless that suffix itself contains characters eligible
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      for expansion.  The default for this style is `true'.

Which is what I'm advocating changing.  Don't require the variable to
be at the start of the word, just look if there are suffix char(s)
between the variable and the cursor, and only expand the variable if
the cursor is right next to the variable.  This is how the old
expander works.

> Which means, I think, that you would like the default setting of suffix
> to be false rather than true, and the default setting of keep-prefix to
> be true rather than "changed".

No, setting suffix to false would make it expand variables even when
suffix chars are present, and that's different than the default with
the old expander, so I'd leave suffix set to true by default.  I
wouldn't mind having keep-prefix set to true by default, but I think
that's a separate issue from making "suffix true" work the same as the
old expansion code.

..wayne..

Re: Another keep-prefix problem

[Bart Schaefer]

} On Thu, 26 Apr 2001, Oliver Kiddle wrote:
} > For _expand I use the glob 1, substitute 1, suffix 1, accept-exact
} > false and tag-order all-expansions styles. keep-prefix changed is
} > the default so that too.
} >
} > To test I did:
} > c1=/home
} > c3=cvs
} > Now,
} > cd $c1/kiddleo/$c3/<tab> expands both $c1 and $c3 which I don't want.

Then as I understand it you don't want `suffix 1' but rather `suffix 0'
and `keep-prefix 1'.

The confusion may be that "suffix" here does not mean "everything after
the rightmost slash".  It means "everything after the LEFTMOST slash."

suffix
     This is used by the _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 `~foo' or `$foo', but not if it is `~foo/' or
     `$foo/bar', unless that suffix itself contains characters eligible
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     for expansion.  The default for this style is `true'.


Hmm.  Looking more closely at the code, this is messed up.  It matches
up to the rightmost slash if the string begins with `~', but only up to
the leftmost slash when it begins with a `$', unless all the parameter
references are in `${...}' form, in which case it matches everything
from the lefmost `${' to the rightmost `}' (even if the rightmost `}' is
part of a brace-expansion rather than a parameter-expansion, I think),
as long as there is something after the rightmost `}'.

I spent a while (too long) thinking about how possibly to rewrite this,
but didn't come up with anything helpful.

On Apr 26,  8:43am, Wayne Davison wrote:
}
} Your example would also fail if you just had the $c3 variable (i.e.
} any variable not at the start of the word).  I would like the default
} setting of "suffix 1" to work like the "expand-or-complete" code's
} expander in this regard.

Which means, I think, that you would like the default setting of suffix
to be false rather than true, and the default setting of keep-prefix to
be true rather than "changed".  But I'm not entirely sure of that ...

-- 
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: Another keep-prefix problem

[Wayne Davison]

On Thu, 26 Apr 2001, Oliver Kiddle wrote:
> For _expand I use the glob 1, substitute 1, suffix 1, accept-exact
> false and tag-order all-expansions styles. keep-prefix changed is
> the default so that too.
>
> To test I did:
> c1=/home
> c3=cvs
> Now,
> cd $c1/kiddleo/$c3/<tab> expands both $c1 and $c3 which I don't want.
> Having typed the / after $c3, I expect it to complete subdirectories
> in my ~/cvs and not do expansion.

Yeah, I've been meaning to mention this too.  Sven's recent change
only affected the keep-prefix code, but not the "suffix" setting.
Your example would also fail if you just had the $c3 variable (i.e.
any variable not at the start of the word).  I would like the default
setting of "suffix 1" to work like the "expand-or-complete" code's
expander in this regard.

..wayne..

Re: Another keep-prefix problem

[Oliver Kiddle]

Sven Wischnowsky wrote:

> I won't commit this before I get positive replies and answers to the
> question if we then should add another possible value for the
> keep-prefix style for this new behaviour or if that's not needed (I

As seems to be the consensus, I don't think we need another value for
keep-prefix for this.

This is more than likely nothing to do with the latest patch but when
I tried testing all this, things didn't work as I'd like or expect.

For _expand I use the glob 1, substitute 1, suffix 1, accept-exact
false and tag-order all-expansions styles. keep-prefix changed is
the default so that too.

To test I did:
c1=/home
c3=cvs
Now,
cd $c1/kiddleo/$c3/<tab> expands both $c1 and $c3 which I don't want.
Having typed the / after $c3, I expect it to complete subdirectories
in my ~/cvs and not do expansion.

Okay, so I tried setting keep-prefix to 1 and things start working nicely.
Except what is going on here (where I mix globs with variables):
   cd /home/kiddle?/$c3/<tab> results in:
   cd /home/kiddle?/$c3//home/kiddleo/cvs/
this definitely isn't right.

So in what situations is the changed value of keep-prefix useful for?
It sounds something like subst-globs-only from the docs. I can't
remember why I used it and not a value of 1.

Actually, talking of the docs for styles, the section on tag-order is
messed up and seems to have the same example twice.

Oliver