PATCH: Re: expansion

PATCH: Re: expansion

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 7,  8:46am, Sven Wischnowsky wrote:
>
> ...
> 
> } 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.

The patch below makes the default `file' (I used that instead of the
longish `existing'). But that's easy to change.


> } 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* ...

I'm not sure what you mean. Completion (which, in my book, is
something completely different than expansion, but...) *always* adds a 
space, unless it's a directory and it completed filenames or there is
some other kind of suffix, most of which are only useful with
completion, I think.

Anyway, the patch also allows `add-space' to contain `subst', combined 
with either `true' or `file' to say that it shouldn't add the space if 
some kind of substitution was involved.


Peter Stephenson wrote:

> How about something like this?  The style keep-tilde defaults to on and
> makes _expand restore the ~/ or ~foo/ part of an expression after globbing.
> It doesn't need to default to on.  It could probably usefully take a third
> value indicating you would like the ~ expanded if there were no other
> changes --- that might be a good default.

Wonderful, I wrote something similar yesterday evening -- and called
it `keep-prefix'. I've now also added that third value you suggest
(I've called it `change') and made it the default. Again, that's easy
to change.

> I won't commit this because I'm sure someone will have suggestions for
> expansions, deletions, changes, or complete rewrites.  For example, you
> could restore initial parameter expressions such as ${HOME}/ in a similar
> way if the glob succeeded (or subst-globs-only is true).  But we could do
> with something or other along these lines.

It's called `keep-prefix' because it tries to do that. But the pattern 
matching is *very* simple currently, so that it will not catch all
complicated parameter expansions. That could be improved.

> It's a different question, but maybe we could set nonomatch for the
> duration of the function to handle failed matches more gracefully.  Or
> maybe people who don't set nonomatch (i.e. do set no nonomatch) like it the
> way it is.

Oops. Yes, good idea. Maybe we should also take the code we use
elsewhere when expanding ~unknown/foo to complain about an unknown
user/dir.


I'll commit this patch, in the hope that it will be easier to get the
behaviour that finally makes most people happy with it.

Bye
 Sven

Index: Completion/Core/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_expand,v
retrieving revision 1.14
diff -u -r1.14 _expand
--- Completion/Core/_expand	2000/06/06 13:04:10	1.14
+++ Completion/Core/_expand	2000/06/08 08:35:44
@@ -7,11 +7,11 @@
 # the expansions done produce no result or do not change the original
 # word from the line.
 
-setopt localoptions nullglob
+setopt localoptions nullglob nonomatch
 
 [[ _matcher_num -gt 1 ]] && return 1
 
-local exp word sort expr expl subd suf=" " force opt
+local exp word sort expr expl subd suf=" " force opt asp tmp opre pre epre
 
 (( $# )) &&
     while getopts gsco opt; do
@@ -46,8 +46,8 @@
    { { zstyle -s ":completion:${curcontext}:" substitute expr ||
        { [[ "$curcontext" = expand-word:* ]] && expr=1 } } &&
          [[ "${(e):-\$[$expr]}" -eq 1 ]] }; then
-  exp=( ${(f)"$(print -lR - ${(e)exp//\\[ 	
-]/ })"} ) 2>/dev/null
+  exp=( "${(e)exp//\\[ 	
+]/ }" )
 else
   exp=( "${exp:s/\\\$/\$}" )
 fi
@@ -81,18 +81,42 @@
       [[ "${(e):-\$[$expr]}" -eq 1 ]] } && 
         [[ "$subd" = "$exp"(|\(N\)) ]] && return 1
 
+zstyle -s ":completion:${curcontext}:" keep-prefix tmp || tmp=changed
+if [[ "$word" = [\~\$]*/* && "$tmp" = (yes|true|on|1|changed) ]]; then
+  epre=( ${(e)~${word%%/*}} )
+  if [[ -n "$epre" && $#epre -eq 1 ]]; then
+    opre="${word%%/*}"
+    pre="$epre[1]"
+    [[ "$tmp" != changed || $#exp -gt 1 ||
+       "${opre}${exp[1]#${pre}}" != "$word" ]] && exp=( ${opre}${^exp#${pre}} )
+  fi
+  [[ $#exp -eq 1 && "$exp[1]" = "$word" ]] && return 1
+fi
+
 # Now add as matches whatever the user requested.
 
 zstyle -s ":completion:${curcontext}:" sort sort
 
 [[ "$sort" = (yes|true|1|on) ]] && exp=( "${(@o)exp}" )
 
+if zstyle -s ":completion:${curcontext}:" add-space tmp; then
+  if [[ "$tmp" != *subst* || "$word" != *\$* || "$exp[1]" = *\$* ]]; then
+    [[ "$tmp" = *file* ]] && asp=file
+    [[ "$tmp" = *(yes|true|1|on|subst)* ]] && asp="yes$asp"
+  fi
+else
+  asp=file
+fi
+
 # If there is only one expansion, add a suitable suffix
 
 if (( $#exp == 1 )); then
-  if [[ -d $exp && "$exp[1]" != */ ]]; then
+  if [[ -d ${exp[1]/${opre}/${pre}} && "$exp[1]" != */ ]]; then
     suf=/
-  elif ! zstyle -T ":completion:${curcontext}:" add-space; then
+  elif [[ "$asp" = yes* ||
+          ( "$asp" = *file && -f "${exp[1]/${opre}/${pre}}" ) ]]; then
+    suf=' '
+  else
     suf=
   fi
 fi
@@ -120,30 +144,30 @@
     compadd "$disp[@]" "$expl[@]" -UQ -qS "$suf" - "$exp"
   fi
   if [[ $#exp -gt 1 ]] && _requested expansions; then
-    local i normal dir
+    local i j normal space dir
 
     if [[ "$sort" = menu ]]; then
       _description expansions expl expansions "o:$word"
     else
       _description -V expansions expl expansions "o:$word"
     fi
-    if zstyle -T ":completion:${curcontext}:" add-space; then
-      suf=' '
-    else
-      suf=
-    fi
     normal=()
+    space=()
     dir=()
 
     for i in "$exp[@]"; do
-      if [[ -d "$i" && "$i" != */ ]]; then
+      j="${i/${opre}/${pre}}"
+      if [[ -d "$j" && "$i" != */ ]]; then
         dir=( "$dir[@]" "$i" )
+      elif [[ "$asp" = yes* || ( "$asp" = *file && -f "$j" ) ]]; then
+        space=( "$space[@]" "$i" )
       else
 	normal=( "$normal[@]" "$i" )
       fi
     done
     (( $#dir ))    && compadd "$expl[@]" -UQ -qS/ -a dir
-    (( $#normal )) && compadd "$expl[@]" -UQ -qS "$suf" -a normal
+    (( $#space ))  && compadd "$expl[@]" -UQ -qS " " -a space
+    (( $#normal )) && compadd "$expl[@]" -UQ -qS "" -a normal
   fi
 
   _requested original expl original && compadd "$expl[@]" -UQ - "$word"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.59
diff -u -r1.59 compsys.yo
--- Doc/Zsh/compsys.yo	2000/05/29 14:48:38	1.59
+++ Doc/Zsh/compsys.yo	2000/06/08 08:35:46
@@ -784,10 +784,15 @@
 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).
+expansion (except for directory names which get a slash).  The value
+may also be the string `tt(file)' to make the completer add a space
+only to names of existing files.  Finally, the `true' values and
+`tt(file)' may be combined with `tt(subst)' to keep the completer from 
+adding a space when the resulting words were generated by expanding a
+substitution such as `tt($LPAR()...RPAR())' and `tt(${...})'.
 
-It is also used by the tt(_prefix) completer to decide if a space should
-be inserted before the suffix.
+It is also used by the tt(_prefix) completer as a simple boolean value
+to decide if a space should be inserted before the suffix.
 )
 kindex(ambiguous, completion style)
 item(tt(ambiguous))(
@@ -1282,6 +1287,22 @@
 in the context name to one of tt(correct-)var(num) or
 tt(approximate-)var(num), where var(num) is the number of errors that
 were accepted.
+)
+kindex(keep-prefix, completion style)
+item(tt(keep-prefix))(
+This style is used by the tt(_expand) completer.  If it is `true', the
+completer will try to keep a prefix containing a tilde or parameter
+expansion.  I.e., the string `tt(~/f*)' would be expanded to
+`tt(~/foo)' instead of `tt(/home/user/foo)'.  If the style is set to
+`tt(changed)' (the default), the prefix will only be left unchanged if
+there were other changes between the expanded words and the original
+word from the command line.  Any other value makes the prefix be
+expanded unconditionally.
+
+Note that with one of the `true' values, the tt(_expand) completer
+returns if there is only one expansion and that is, after restoring
+the original prefix, the same as the original word.  This means that
+other completers will be called immediately after tt(_expand).
 )
 kindex(last-prompt, completion style)
 item(tt(last-prompt))(

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

Re: PATCH: Re: expansion

[Peter Stephenson]

Sven wrote:
> What's going on here? With -f:
>   % a='a{b,c}d'
>   % setopt braceccl
>   % b=( ${${(q)a}:gs/\\{/{/:gs/\\}/}/} )
>   % echo $b
>   a,d abd acd
> 
> Oops. (Yes, works with just `echo ${${(q)a}...}', too.)

Yes, I'd use this:
  print ${${(q)a}:gs/\\\{/\{/:gs/\\\}/\}/}
to make sure all the relevant braces are quoted, or perhaps even better
(pattern matching is better about untokenising, because it only needs to do
it once while parsing):
  print ${${(q)a}//(#b)\\([{}])/$match[1]}

This is not very well handled at present; all sorts of things are a bit
more heavily tokenised than you might want at various places in
paramsubst(), because it's very hard to work out in the middle of all the
other streams of logic about substitution.

There's another glitch with braces I haven't looked at but I had to work
around in the parameter tests (possibly the most boring piece of zsh code
ever written):

%   array=(once bitten twice shy)              
%   print IF{${array},THEN}ELSE              
IF{once bitten twice shy,THEN}ELSE

Double-quoting ${array} fixes it, even more bizarrely.  This doesn't depend
on braceccl.  What's more, the full expansion works with RCEXPANDPARAM:

% print IF{${^array},THEN}ELSE 
IFonceELSE IFTHENELSE IFbittenELSE IFTHENELSE IFtwiceELSE IFTHENELSE IFshyELSE IFTHENELSE

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: Re: expansion

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 15,  5:15pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: Re: expansion
> }
> } > a(<tab> and you will get '_expand:78: bad pattern: a(' because of the
> } > lack of a closing bracket.
> } 
> } It doesn't anymore, (e) is silent nowadays. By using eval we could get 
> } that, though (that's why I said `careful').
> 
> Something like this:
> 
> 	eval exp\=\( ${${(q)exp}:gs/\\{/{/:gs/\\}/}/} \)
> 
> I haven't figured out where the right place to put that is, though.  I
> tried a couple of different spots in _expand and they both caused brace
> *completion* to stop working, even though the word on the line didn't
> change.

What's going on here? With -f:

  % a='a{b,c}d'
  % b=( ${${(q)a}:gs/\\{/{/:gs/\\}/}/} )
  % echo $b
  a{b,c}d                       # OK
  % setopt braceccl
  % b=( ${${(q)a}:gs/\\{/{/:gs/\\}/}/} )
  % echo $b
  a,d abd acd

Oops. (Yes, works with just `echo ${${(q)a}...}', too.)


Aha! It's the `{' and `}' in the replacements strings. They get
tokenized by the lexer, etc. etc.

Urgh. How... What... Where...

Bye
 Sven


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

Re: PATCH: Re: expansion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Bart wrote:
> > Sven wrote:
> > } They should be turned into boolean styles and the condition should come
> > } from somewhere else, e.g. the -e option to zstyle I suggested (see
> > } 11691).
> > 
> > I agree.
> 
> Yes, that would be preferable.  Does `evaluated' mean `treated as a string
> to be passed directly to eval' or `split into words and executed' or
> `parsed and executed as a command line'?  I think it could be clearer.
> `$reply' would be more standard, but it doesn't really mean much here; I
> wish there were something more obvious, but I bet we've discussed that.

Here's the patch, including:

- an improved version of the zstyle -e code, together with a hopefully 
  clear enough manual entry (do we need to mention this possibility in 
  the compsys manual? hm, maybe, together with examples of how to
  access the current word, the command name, etc, right? other ideas
  for things might want to do?)
- the changes to turn the styles into boolean ones (glob, substitute,
  subst-globs-only, condition (the last one is from _list))
- and the _expand styles have now default values that make expansion
  be done per default when _expand is in the completer list (I hope I
  got the defaults right to come as near to e-o-c as is currently
  possible)

No attempt for the brace expansion thing yet.

Bye
 Sven

Index: Completion/Core/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_expand,v
retrieving revision 1.17
diff -u -r1.17 _expand
--- Completion/Core/_expand	2000/06/14 16:12:14	1.17
+++ Completion/Core/_expand	2000/06/16 07:23:54
@@ -21,8 +21,7 @@
 # First, see if we should insert all *completions*.
 
 if [[ "$force" = *c* ]] ||
-   { zstyle -s ":completion:${curcontext}:" completions expr &&
-     [[ "${(e):-\$[$expr]}" -eq 1 ]] }; then
+   zstyle -t ":completion:${curcontext}:" completions; then
   compstate[insert]=all
   [[ "$curcontext" = expand-word:* ]] && _complete && return 0
   return 1
@@ -34,11 +33,12 @@
   word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
 fi
 
-zstyle -t ":completion:${curcontext}:" suffix &&
+zstyle -T ":completion:${curcontext}:" suffix &&
   [[ "$word" = (\~*/*|\$[a-zA-Z0-9_\[\]]##[^a-zA-Z0-9_\[\]]*|\$\{*\}?*) ]] &&
   return 1
 
 zstyle -t ":completion:${curcontext}:" accept-exact ||
+  [[ $? -eq 2 && ! -o recexact ]] ||
   { [[ "$word" = \~(|[-+]) ||
        ( "$word" = \~[-+][1-9]## && $word[3,-1] -le $#dirstack ) ||
        ( "$word" = \~* && ${#userdirs[(I)${word[2,-1]}*]}+${#nameddirs[(I)${word[2,-1]}*]} -ne 1 ) ||
@@ -54,9 +54,7 @@
 # this function from aborting on parse errors in the expansion.
 
 if [[ "$force" = *s* ]] ||
-   { { zstyle -s ":completion:${curcontext}:" substitute expr ||
-       { [[ "$curcontext" = expand-word:* ]] && expr=1 } } &&
-         [[ "${(e):-\$[$expr]}" -eq 1 ]] }; then
+   zstyle -T ":completion:${curcontext}:" substitute; then
   exp=( "${(e)exp//\\[ 	
 ]/ }" )
 else
@@ -71,10 +69,7 @@
 
 # Now try globbing.
 
-[[ "$force" = *g* ]] ||
-  { { zstyle -s ":completion:${curcontext}:" glob expr ||
-      { [[ "$curcontext" = expand-word:* ]] && expr=1 } } &&
-        [[ "${(e):-\$[$expr]}" -eq 1 ]] } &&
+[[ "$force" = *g* ]] || zstyle -T ":completion:${curcontext}:" glob &&
     exp=( ${~exp} )
 
 # If we don't have any expansions or only one and that is the same
@@ -87,10 +82,9 @@
 # With subst-globs-only we bail out if there were no glob expansions,
 # regardless of any substitutions
 
-[[ "$force" = *o* ]] ||
-  { zstyle -s ":completion:${curcontext}:" subst-globs-only expr &&
-      [[ "${(e):-\$[$expr]}" -eq 1 ]] } && 
-        [[ "$subd" = "$exp"(|\(N\)) ]] && return 1
+{ [[ "$force" = *o* ]] ||
+  zstyle -t ":completion:${curcontext}:" subst-globs-only } &&
+    [[ "$subd" = "$exp"(|\(N\)) ]] && return 1
 
 zstyle -s ":completion:${curcontext}:" keep-prefix tmp || tmp=changed
 if [[ "$word" = [\~\$]*/* && "$tmp" = (yes|true|on|1|changed) ]]; then
Index: Completion/Core/_list
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_list,v
retrieving revision 1.2
diff -u -r1.2 _list
--- Completion/Core/_list	2000/04/01 20:43:43	1.2
+++ Completion/Core/_list	2000/06/16 07:23:54
@@ -20,9 +20,8 @@
 
 # Should we only show a list now?
 
-zstyle -s ":completion:${curcontext}:" condition expr
-if [[ ( -z "$expr" || "${(e):-\$[$expr]}" -eq 1 ) &&
-      ( "$pre" != "$_list_prefix" || "$suf" != "$_list_suffix" ) ]]; then
+if zstyle -T ":completion:${curcontext}:" condition &&
+   [[ "$pre" != "$_list_prefix" || "$suf" != "$_list_suffix" ]]; then
 
   # Yes. Tell the completion code about it and save the new values
   # to compare the next time.
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.65
diff -u -r1.65 compsys.yo
--- Doc/Zsh/compsys.yo	2000/06/15 09:06:22	1.65
+++ Doc/Zsh/compsys.yo	2000/06/16 07:23:55
@@ -904,29 +904,16 @@
 )
 kindex(completions, completion style)
 item(tt(completions))(
-This style is used by the tt(_expand) completer function.
-
-If this is set to an non-empty string it should be an expression
-usable inside a `tt($((...)))' arithmetical expression. The completer
-function evaluates this expression and if the result is `tt(1)', no
-expansions will be generated, but instead the completions will be
-generated as normal and all of them will be inserted into the command
-line.
+This style is used by the tt(_expand) completer function. If it is set 
+to `true', the completer will not generate expansions, but instead the
+completions will be generated as normal and all of them will be
+inserted into the command line.
 )
 kindex(condition, completion style)
 item(tt(condition))(
-This style is used by the tt(_list) completer function.
-
-If it is not set or set to the empty string, the insertion of
-matches will be delayed unconditionally.  If it is set, the value
-should be an expression usable inside a `tt($((...)))'
-arithmetical expression.  In this case, delaying will be done if the
-expression evaluates to `tt(1)'. For example, with
-
-example(zstyle ':completion:*:list:::' condition '${NUMERIC:-1} != 1')
-
-delaying will be done only if given an explicit numeric argument
-other than `tt(1)'.
+This style is used by the tt(_list) completer function to decide if
+insertion of matches should be delayed unconditionally. The default is 
+`true'.
 )
 kindex(cursor, completion style)
 item(tt(cursor))(
@@ -1112,12 +1099,10 @@
 )
 kindex(glob, completion style)
 item(tt(glob))(
-Like tt(completions), this is used by the tt(_expand) completer.
-
-The value is used like the one for tt(completions) and if it evaluates to 
-`tt(1)', globbing will be attempted on the words resulting from
-substitution (see the tt(substitute) style) or the original string
-from the line.
+Like tt(completions), this is used by the tt(_expand) completer.  If
+it is set to `true' (the default), globbing will be attempted on the
+words resulting from substitution (see the tt(substitute) style) or
+the original string from the line.
 )
 kindex(group-name, completion style)
 item(tt(group-name))(
@@ -1785,26 +1770,21 @@
 )
 kindex(subst-globs-only, completion style)
 item(tt(subst-globs-only))(
-This is used by the tt(_expand) completer.  As for the tt(glob) style,
-the value should be a value usable in a `tt($((...)))' arithmetical
-expression.  If it evaluates to `tt(1)', the expansion will only be
-used if it resulted from globbing; hence, if expansions resulted
-from the use of the tt(substitute) style described below, but these
-were not further changed by globbing, the expansions will be rejected.
+This is used by the tt(_expand) completer.  If it is set to `true',
+the expansion will only be used if it resulted from globbing; hence,
+if expansions resulted from the use of the tt(substitute) style
+described below, but these were not further changed by globbing, the
+expansions will be rejected.
+
+The default for this style is `false'.
 )
 kindex(substitute, completion style)
 item(tt(substitute))(
-This style controls whether the tt(_expand) completer will first try to
-expand all substitutions in the string (such as `tt($LPAR()...RPAR())'
-and `tt(${...})').  It should be set to a number or an non-empty string
-which is an expression usable inside a `tt($((...)))' arithmetical
-expression.  Expansion of substitutions will be done if the expression
-evaluates to `tt(1)'. For example, with
+This boolean style controls whether the tt(_expand) completer will
+first try to expand all substitutions in the string (such as
+`tt($LPAR()...RPAR())' and `tt(${...})').
 
-example(zstyle ':completion:*:expand:::' substitute '${NUMERIC:-1} != 1')
-
-substitution will be performed only if given an explicit numeric
-argument other than `tt(1)', as by typing `tt(ESC 2 TAB)'.
+The default is `true'.
 )
 kindex(suffix, completion style)
 item(tt(suffix))(
@@ -1812,7 +1792,7 @@
 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'.
+`tt($foo/bar)'.  The default for this style is `true'.
 )
 kindex(tag-order, completion style)
 item(tt(tag-order))(
@@ -2263,9 +2243,7 @@
 string from the line.
 
 Which kind of expansion is tried is controlled by the tt(substitute),
-tt(glob) and tt(subts-globs-only) styles.  Note that none of these
-has a default value so that they have to be set to make tt(_expand)
-generate any expansions at all.
+tt(glob) and tt(subst-globs-only) styles.
 
 There is another style, tt(completions), which allows tt(_expand) to
 display or insert all em(completions) generated for the string.  The use of
@@ -2451,10 +2429,6 @@
 Performs expansion on the current word:  equivalent to the standard
 tt(expand-word) command, but using the tt(_expand) completer.  Before
 calling it, the var(function) field is set to `tt(expand-word)'.
-
-Unlike tt(_expand) this uses a `tt(1)' (one) as the default
-value for the tt(substitute) and tt(glob) styles, so both types of
-expansion will normally be performed.
 )
 findex(_generic)
 item(tt(_generic))(
Index: Doc/Zsh/mod_zutil.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_zutil.yo,v
retrieving revision 1.9
diff -u -r1.9 mod_zutil.yo
--- Doc/Zsh/mod_zutil.yo	2000/06/07 07:38:02	1.9
+++ Doc/Zsh/mod_zutil.yo	2000/06/16 07:23:56
@@ -8,7 +8,7 @@
 startitem()
 findex(zstyle)
 xitem(tt(zstyle) [ tt(-L) ])
-xitem(tt(zstyle) [ tt(-) | tt(-)tt(-) ] var(pattern) var(style) var(strings) ...)
+xitem(tt(zstyle) [ tt(-e) | tt(-) | tt(-)tt(-) ] var(pattern) var(style) var(strings) ...)
 xitem(tt(zstyle -d) [ var(pattern) [ var(styles) ... ] ])
 xitem(tt(zstyle -g) var(name) [ var(pattern) [ var(style) ] ])
 xitem(tt(zstyle -abs) var(context) var(style) var(name) [ var(sep) ])
@@ -33,9 +33,16 @@
 done in the form of calls to tt(zstyle).  Forms with arguments:
 
 startitem()
-item(tt(zstyle) [ tt(-) | tt(-)tt(-) ] var(pattern) var(style) var(strings) ...)(
+item(tt(zstyle) [ tt(-e) | tt(-) | tt(-)tt(-) ] var(pattern) var(style) var(strings) ...)(
 Defines the given var(style) for the var(pattern) with the var(strings) as
-the value.
+the value.  If the tt(-e) option is given, the var(strings) will be
+concatenated (separated by spaces) and the resulting string will be
+evaluated (in the same way as it is dome by the tt(eval) builtin
+command) when the style is looked up.  In this case the parameter
+tt(reply) will be used to get the strings to return after the
+evaluation.  Before evaluating the value, tt(reply) will be unset and
+if it is still unset after the evaluation, this will be handled as if
+the style were not set.
 )
 item(tt(zstyle -d) [ var(pattern) [ var(styles) ... ] ])(
 Delete style definitions. Without arguments all definitions are deleted,
Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.6
diff -u -r1.6 zutil.c
--- Src/Modules/zutil.c	2000/06/07 07:38:02	1.6
+++ Src/Modules/zutil.c	2000/06/16 07:23:56
@@ -48,6 +48,7 @@
     char *pat;			/* pattern string */
     Patprog prog;		/* compiled pattern */
     int weight;			/* how specific is the pattern? */
+    Eprog eval;			/* eval-on-retrieve? */
     char **vals;
 };
     
@@ -64,6 +65,8 @@
     freepatprog(p->prog);
     if (p->vals)
 	freearray(p->vals);
+    if (p->eval)
+	freeeprog(p->eval);
     zfree(p, sizeof(*p));
 }
 
@@ -101,13 +104,25 @@
 
 /* Store a value for a style. */
 
-static void
-setstypat(Style s, char *pat, Patprog prog, char **vals)
+static int
+setstypat(Style s, char *pat, Patprog prog, char **vals, int eval)
 {
     int weight, tmp, first;
     char *str;
     Stypat p, q, qq;
+    Eprog eprog = NULL;
+
+    if (eval) {
+	int ef = errflag;
+
+	eprog = parse_string(zjoin(vals, ' ', 1), 0);
+	errflag = ef;
+
+	if (!eprog)
+	    return 1;
 
+	eprog = dupeprog(eprog, 0);
+    }
     for (p = s->pats; p; p = p->next)
 	if (!strcmp(pat, p->pat)) {
 
@@ -115,9 +130,12 @@
 
 	    if (p->vals)
 		freearray(p->vals);
+	    if (p->eval)
+		freeeprog(p->eval);
 	    p->vals = zarrdup(vals);
+	    p->eval = eprog;
 
-	    return;
+	    return 0;
 	}
 
     /* New pattern. */
@@ -126,6 +144,7 @@
     p->pat = ztrdup(pat);
     p->prog = prog;
     p->vals = zarrdup(vals);
+    p->eval = eprog;
     p->next = NULL;
 
     /* Calculate the weight. */
@@ -161,6 +180,8 @@
 	qq->next = p;
     else
 	s->pats = p;
+
+    return 0;
 }
 
 /* Add a new style. */
@@ -184,9 +205,34 @@
     return s;
 }
 
+static char **
+evalstyle(Stypat p)
+{
+    int ef = errflag;
+    char **ret, *str;
+
+    unsetparam("reply");
+    execode(p->eval, 1, 0);
+    if (errflag) {
+	errflag = ef;
+	return NULL;
+    }
+    errflag = ef;
+
+    if ((ret = getaparam("reply")))
+	ret = arrdup(ret);
+    else if ((str = getsparam("reply"))) {
+	ret = (char **) hcalloc(2 * sizeof(char *));
+	ret[0] = dupstring(str);
+    }
+    unsetparam("reply");
+
+    return ret;
+}
+
 /* Look up a style for a context pattern. This does the matching. */
 
-static Stypat
+static char **
 lookupstyle(char *ctxt, char *style)
 {
     Style s;
@@ -196,7 +242,7 @@
 	if (!strcmp(s->name, style))
 	    for (p = s->pats; p; p = p->next)
 		if (pattry(p->prog, ctxt))
-		    return p;
+		    return (p->eval ? evalstyle(p) : p->vals);
 
     return NULL;
 }
@@ -204,7 +250,7 @@
 static int
 bin_zstyle(char *nam, char **args, char *ops, int func)
 {
-    int min, max, n, add = 0, list = 0;
+    int min, max, n, add = 0, list = 0, eval = 0;
 
     if (!args[0])
 	list = 1;
@@ -218,6 +264,10 @@
 	    }
 	    if (oc == 'L')
 		list = 2;
+	    else if (oc == 'e') {
+		eval = add = 1;
+		args++;
+	    }
 	} else {
 	    add = 1;
 	    args++;
@@ -243,9 +293,7 @@
 	}
 	if (!(s = getstyle(args[1])))
 	    s = addstyle(args[1]);
-	setstypat(s, args[0], prog, args + 2);
-
-	return 0;
+	return setstypat(s, args[0], prog, args + 2, eval);
     }
     if (list) {
 	Style s;
@@ -259,9 +307,9 @@
 	    }
 	    for (p = s->pats; p; p = p->next) {
 		if (list == 1)
-		    printf("    %s", p->pat);
+		    printf("%s  %s", (p->eval ? "(eval)" : "      "), p->pat);
 		else {
-		    printf("zstyle ");
+		    printf("zstyle %s", (p->eval ? "-e " : ""));
 		    quotedzputs(p->pat, stdout);
 		    printf(" %s", s->name);
 		}
@@ -343,12 +391,11 @@
 	break;
     case 's':
 	{
-	    Stypat s;
-	    char *ret;
+	    char **vals, *ret;
 	    int val;
 
-	    if ((s = lookupstyle(args[1], args[2])) && s->vals[0]) {
-		ret = sepjoin(s->vals, (args[4] ? args[4] : " "), 0);
+	    if ((vals = lookupstyle(args[1], args[2])) && vals[0]) {
+		ret = sepjoin(vals, (args[4] ? args[4] : " "), 0);
 		val = 0;
 	    } else {
 		ret = ztrdup("");
@@ -361,16 +408,15 @@
 	break;
     case 'b':
 	{
-	    Stypat s;
-	    char *ret;
+	    char **vals, *ret;
 	    int val;
 
-	    if ((s = lookupstyle(args[1], args[2])) &&
-		s->vals[0] && !s->vals[1] &&
-		(!strcmp(s->vals[0], "yes") ||
-		 !strcmp(s->vals[0], "true") ||
-		 !strcmp(s->vals[0], "on") ||
-		 !strcmp(s->vals[0], "1"))) {
+	    if ((vals = lookupstyle(args[1], args[2])) &&
+		vals[0] && !vals[1] &&
+		(!strcmp(vals[0], "yes") ||
+		 !strcmp(vals[0], "true") ||
+		 !strcmp(vals[0], "on") ||
+		 !strcmp(vals[0], "1"))) {
 		ret = "yes";
 		val = 0;
 	    } else {
@@ -384,12 +430,11 @@
 	break;
     case 'a':
 	{
-	    Stypat s;
-	    char **ret;
+	    char **vals, **ret;
 	    int val;
 
-	    if ((s = lookupstyle(args[1], args[2]))) {
-		ret = zarrdup(s->vals);
+	    if ((vals = lookupstyle(args[1], args[2]))) {
+		ret = zarrdup(vals);
 		val = 0;
 	    } else {
 		char *dummy = NULL;
@@ -405,14 +450,14 @@
     case 't':
     case 'T':
 	{
-	    Stypat s;
+	    char **vals;
 
-	    if ((s = lookupstyle(args[1], args[2])) && s->vals[0]) {
+	    if ((vals = lookupstyle(args[1], args[2])) && vals[0]) {
 		if (args[3]) {
 		    char **ap = args + 3, **p;
 
 		    while (*ap) {
-			p = s->vals;
+			p = vals;
 			while (*p)
 			    if (!strcmp(*ap, *p++))
 				return 0;
@@ -420,27 +465,25 @@
 		    }
 		    return 1;
 		} else
-		    return !(!strcmp(s->vals[0], "true") ||
-			     !strcmp(s->vals[0], "yes") ||
-			     !strcmp(s->vals[0], "on") ||
-			     !strcmp(s->vals[0], "1"));
+		    return !(!strcmp(vals[0], "true") ||
+			     !strcmp(vals[0], "yes") ||
+			     !strcmp(vals[0], "on") ||
+			     !strcmp(vals[0], "1"));
 	    }
-	    return (args[0][1] == 't' ? (s ? 1 : 2) : 0);
+	    return (args[0][1] == 't' ? (vals ? 1 : 2) : 0);
 	}
 	break;
     case 'm':
 	{
-	    Stypat s;
+	    char **vals;
 	    Patprog prog;
 
 	    tokenize(args[3]);
 
-	    if ((s = lookupstyle(args[1], args[2])) &&
+	    if ((vals = lookupstyle(args[1], args[2])) &&
 		(prog = patcompile(args[3], PAT_STATIC, NULL))) {
-		char **p = s->vals;
-
-		while (*p)
-		    if (pattry(prog, *p++))
+		while (*vals)
+		    if (pattry(prog, *vals++))
 			return 0;
 	    }
 	    return 1;

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

Re: PATCH: Re: expansion

[Bart Schaefer]

On Jun 15,  5:15pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: expansion
}
} > a(<tab> and you will get '_expand:78: bad pattern: a(' because of the
} > lack of a closing bracket.
} 
} It doesn't anymore, (e) is silent nowadays. By using eval we could get 
} that, though (that's why I said `careful').

Something like this:

	eval exp\=\( ${${(q)exp}:gs/\\{/{/:gs/\\}/}/} \)

I haven't figured out where the right place to put that is, though.  I
tried a couple of different spots in _expand and they both caused brace
*completion* to stop working, even though the word on the line didn't
change.

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

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > Yes, I think I said that the patterns could do with a little improvement.
> 
> Yes, and there is still scope for more improvements. Does anyone know
> which characters terminate a parameter reference which doesn't use
> braces?

Anything but [a-zA-Z0-9_], except for the special one-character
parameters and the `:...' modifiers if we want to deal with them.

> > 2) Not using `recexact' as the style name was, of course, intentional,
> >    because it really isn't about `recognising', is it? It's about
> >    accepting the exact match (it will always take an exact match as
> >    one of the possible matches[1]).
> >    And accept-exact has the same meaning as recexact, we don't need to
> >    reverse it.
> 
> Functionally, I can't see that there is a difference between recexact
> and accept-exact. Are you basically saying that acceptexact would have
> been a better name for the option as well?

No, that was taken from elsewhere, I think (csh? tcsh?). But we are
talking about `accepting' a match elsewhere, so...

> > [1] Has anyone else wished he had a style to say `complete anything
> >     *but* an exact match'?
> >     We already have ignore-line... we could extend that.
> 
> It took me a little while to work out what you mean by that but I can
> see that it might be useful because someone might feel that they are
> only going to press tab if they want to complete something.
> 
> It seems to me that the choices are that if the current line is an exact
> but ambiguous match, there are three choices: match only the current
> exact match, match all matches or match all but the current exact match
> so maybe a style with three possible values would be better.

I want to integrate it with (the already existing) ignore-line style,
three choices there: ignore all words from the line, ignore only the
current word, ignore all words except the current one.

> I actually got quite confused while trying to work out what happens in
> different situations because of the line in _expand which prevents
> substitutions expanding if they expand to an empty string and I was
> using an empty variable. Maybe _expand should display a message in this
> case.

Or make it configurable... (this is getting out of hand).

> > I didn't change that even now because I've regretted these
> > `mathematically conditional' styles for quite some time now. They
> > should be turned into boolean styles and the condition should come
> > from somewhere else, e.g. the -e option to zstyle I suggested (see
> > 11691).
> 
> I meant to reply to that at the time because it seems like a good idea.
> It would certainly be a lot cleaner if any sort of evaluations are built
> in to zstyle and don't have to be repeated in completion functions.
> 
> What exactly do you mean by the word evaluated when you say that 'the
> resulting string will be evaluated' in the documentation in the patch:
> is the idea that you would use a function.

The -e option makes the values given when defining the style be
concatenated with spaces between them and the resulting string eval'ed 
(i.e. exactly what the eval builtin does).

> How would this affect the
> functions which can be used for tag-order (which, if you remember I use
> to avoid completing commands with an empty word).

Not at all. Whatever the eval'ed code stores in $value/$reply is
returned as the value of the style when it is looked up. In a certain
sense it's just an extra level of indirection.

> For styles whose
> values are arrays, it would be useful to be able to return $value/$reply
> as an array.

Of course the patch already did that. Since I only used $value, not
$VALUE, you may have guessed that the eval'ed code can return *only*
arrays (well, ok, the contents of $value is only used as an array),
just like styles do. Before the stuff is eval'ed, $value is unset
(explicitly, by the zstyle-code). If it is left unset, this is as if
the style weren't set, if $value is set to some value, it is treated
as if that/those string/s were defined for the style without the -e
option.

> On the subject of the _expand not doing brace expansion, Sven wrote:
> 
> > Change (e)? Use `eval echo ...'? Urgh?
> 
> I think it would be a bad idea to change (e) and the eval is going to be
> slow. I think I said it before a while ago but it would be nice if there
> was clearly defined ways to do the various types of expansion,
> individually or together. A (b) to do brace expansion might solve the
> brace problem but we would maybe have fewer problems in _expand if there
> was syntax like (e:pab:) to do parameter, arithmetic and brace expansion
> with other letters for things like ~, =, history, command and whatever
> other expansions we have.

Well, history expansion at least has to be done before completion is
tried because it's done by the lexer.

The other thing: could get complicated to implement, I think (and
using e:...: might cause trouble with existing uses unless we allow
only a few special character as the separator; is E used?).

> This would have some problems though: expansions which expand to things
> which can be further expanded for example but I'd have thought these
> have all be addressed in the code before. The other trouble with
> expansion as a part of completion is that completion by definition deals
> with things which are incomplete so we have the problem of what to do
> with things which aren't syntactically correct yet. For example, try:
> a(<tab> and you will get '_expand:78: bad pattern: a(' because of the
> lack of a closing bracket.

It doesn't anymore, (e) is silent nowadays. By using eval we could get 
that, though (that's why I said `careful').

Bye
 Sven


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

Re: PATCH: Re: expansion

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Yes, I think I said that the patterns could do with a little improvement.

Yes, and there is still scope for more improvements. Does anyone know
which characters terminate a parameter reference which doesn't use
braces?

> 2) Not using `recexact' as the style name was, of course, intentional,
>    because it really isn't about `recognising', is it? It's about
>    accepting the exact match (it will always take an exact match as
>    one of the possible matches[1]).
>    And accept-exact has the same meaning as recexact, we don't need to
>    reverse it.

Functionally, I can't see that there is a difference between recexact
and accept-exact. Are you basically saying that acceptexact would have
been a better name for the option as well?

> [1] Has anyone else wished he had a style to say `complete anything
>     *but* an exact match'?
>     We already have ignore-line... we could extend that.

It took me a little while to work out what you mean by that but I can
see that it might be useful because someone might feel that they are
only going to press tab if they want to complete something.

It seems to me that the choices are that if the current line is an exact
but ambiguous match, there are three choices: match only the current
exact match, match all matches or match all but the current exact match
so maybe a style with three possible values would be better.

I actually got quite confused while trying to work out what happens in
different situations because of the line in _expand which prevents
substitutions expanding if they expand to an empty string and I was
using an empty variable. Maybe _expand should display a message in this
case.

> I didn't change that even now because I've regretted these
> `mathematically conditional' styles for quite some time now. They
> should be turned into boolean styles and the condition should come
> from somewhere else, e.g. the -e option to zstyle I suggested (see
> 11691).

I meant to reply to that at the time because it seems like a good idea.
It would certainly be a lot cleaner if any sort of evaluations are built
in to zstyle and don't have to be repeated in completion functions.

What exactly do you mean by the word evaluated when you say that 'the
resulting string will be evaluated' in the documentation in the patch:
is the idea that you would use a function. How would this affect the
functions which can be used for tag-order (which, if you remember I use
to avoid completing commands with an empty word). For styles whose
values are arrays, it would be useful to be able to return $value/$reply
as an array.

On the subject of the _expand not doing brace expansion, Sven wrote:

> Change (e)? Use `eval echo ...'? Urgh?

I think it would be a bad idea to change (e) and the eval is going to be
slow. I think I said it before a while ago but it would be nice if there
was clearly defined ways to do the various types of expansion,
individually or together. A (b) to do brace expansion might solve the
brace problem but we would maybe have fewer problems in _expand if there
was syntax like (e:pab:) to do parameter, arithmetic and brace expansion
with other letters for things like ~, =, history, command and whatever
other expansions we have.

This would have some problems though: expansions which expand to things
which can be further expanded for example but I'd have thought these
have all be addressed in the code before. The other trouble with
expansion as a part of completion is that completion by definition deals
with things which are incomplete so we have the problem of what to do
with things which aren't syntactically correct yet. For example, try:
a(<tab> and you will get '_expand:78: bad pattern: a(' because of the
lack of a closing bracket.

Oliver

Re: PATCH: Re: expansion

[Sven Wischnowsky]

Peter Stephenson wrote:

> Bart wrote:
> > Sven wrote:
> > } They should be turned into boolean styles and the condition should come
> > } from somewhere else, e.g. the -e option to zstyle I suggested (see
> > } 11691).
> > 
> > I agree.
> 
> Yes, that would be preferable.  Does `evaluated' mean `treated as a string
> to be passed directly to eval' or `split into words and executed' or
> `parsed and executed as a command line'? 

The last, which is what eval does, isn't it? At least it does the same
as bin_eval().

> I think it could be clearer.
> `$reply' would be more standard, but it doesn't really mean much here;

Ok.

> I wish there were something more obvious, but I bet we've discussed that.

Not much discussion. And yes, it would be nice if... but it was the
cleanest I could think of. Before that I suggested `special values'
which is even uglier.

If anyone has any ideas...

Bye
 Sven


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

Re: PATCH: Re: expansion

[Peter Stephenson]

Bart wrote:
> Sven wrote:
> } They should be turned into boolean styles and the condition should come
> } from somewhere else, e.g. the -e option to zstyle I suggested (see
> } 11691).
> 
> I agree.

Yes, that would be preferable.  Does `evaluated' mean `treated as a string
to be passed directly to eval' or `split into words and executed' or
`parsed and executed as a command line'?  I think it could be clearer.
`$reply' would be more standard, but it doesn't really mean much here; I
wish there were something more obvious, but I bet we've discussed that.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: Re: expansion

[Bart Schaefer]

On Jun 15, 10:26am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: expansion
}
} I didn't change that even now because I've regretted these
} `mathematically conditional' styles for quite some time now.

Yes, I find it extremely difficult to express any useful conditions
that way.  I usually want some prefix of the line to match, or some
such, and end up using ${#${some_complicated_parameter_substitution}}
to get a numeric result.

} They should be turned into boolean styles and the condition should come
} from somewhere else, e.g. the -e option to zstyle I suggested (see
} 11691).

I agree.

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

[Sven Wischnowsky]

I forgot:

> 2) Not using `recexact' as the style name was, of course, intentional,
>    because it really isn't about `recognising', is it? It's about
>    accepting the exact match (it will always take an exact match as
>    one of the possible matches[1]).

[1] Has anyone else wished he had a style to say `complete anything
    *but* an exact match'?
    We already have ignore-line... we could extend that.

Bye
 Sven


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

Re: PATCH: Re: expansion

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> There was one minor problem though.
> 
> > - 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'.
> 
> This doesn't work with arrays: they are never expanded. If I do
> cd $fpath[17]<tab> the directory from my fpath should be expanded. I
> have fixed this in the patch below.

Yes, I think I said that the patterns could do with a little improvement.

> With `suffix', variables mixed with globs (e.g $f/*<tab>) will not do
> glob expansion. This will not bother me a huge amount because I just
> have to remember to expand the variable before I put the glob part in
> but I'll maybe look at extending subst-globs-only to handle this
> situation as well.
> 
> Other people may want more control over when $( ... ) and math stuff is
> expanded (such as the suffix style functionality). I wouldn't for the
> $( ... ) stuff because we can't guarantee that the command produces the
> same output always so completion can't continue after one without
> expansion. I don't use $(( ... )) often enough to really care whether it
> expands though I'd probably prefer the suffix style behaviour.

Hmhm, I think I'll play with it some more, too.

> I'm now back to using _expand so I may come across other issues which I
> haven't thought of at the moment. I'll let you know if I think of
> anything.

Thanks.

> >   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?
> 
> Wouldn't it maybe be a good idea if the value of the recexact option
> was used to determine the default for accept-exact so by just setting
> the option, it would have an effect throughout the new completion
> system. There would then always be the option of setting it to a
> different value for a context with zstyle. I would also be inclined to
> rename the style to recexact and negate its meaning for consistency
> with the option.

1) Ah, for completion it already uses recexact as the default (without 
   doing something for it, actually). Only _expand has to handle it
   directly. I didn't think about using [[ -o recexact ]] or some
   such, I'll have a look.
2) Not using `recexact' as the style name was, of course, intentional,
   because it really isn't about `recognising', is it? It's about
   accepting the exact match (it will always take an exact match as
   one of the possible matches[1]).
   And accept-exact has the same meaning as recexact, we don't need to 
   reverse it.

> I've never been convinced that it is wise that without any styles set,
> _expand effectively does nothing: it will inevitably be the source of
> an FAQ. I would have thought that it would be best if by default it
> behaves in the way which most closely resembles expand-or-complete: so
> I would set suffix, glob and substitute by default.

And that from the guy who turned off _expand because it caused him
trouble? ;-)

I did that because before, _expand simply did too much harm to your
command line string. With all the new styles I would prefer to change
the default to be least aggressive but do expansion, but before...

I didn't change that even now because I've regretted these
`mathematically conditional' styles for quite some time now. They
should be turned into boolean styles and the condition should come
from somewhere else, e.g. the -e option to zstyle I suggested (see
11691).


Bye
 Sven


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

Re: PATCH: Re: expansion

[Peter Stephenson]

Oliver wrote:
> I also agree with Sven in not being too happy about having different
> defaults depending on whether _expand was used as a completer or called
> from _expand_word as suggested by Bart.

I think it was my suggestion, at least I suggested modifying the defaults
for _expand_word to work the way I expected (which was basically how ^x*
works), and it was simply to avoid having to impact on people who were
happily using _expand.  But if they prefer it to work by default the way
_expand_word was modified to, I'm all the happier.  (I can't parse the
first part of that last sentence any more, so it'll have to do how it is.)

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

PATCH: Re: expansion

[Oliver Kiddle]

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

> Ok. Is this good enough? Oliver?

This is a lot better. Thanks Sven.

There was one minor problem though.

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

This doesn't work with arrays: they are never expanded. If I do
cd $fpath[17]<tab> the directory from my fpath should be expanded. I
have fixed this in the patch below.

With `suffix', variables mixed with globs (e.g $f/*<tab>) will not do
glob expansion. This will not bother me a huge amount because I just
have to remember to expand the variable before I put the glob part in
but I'll maybe look at extending subst-globs-only to handle this
situation as well.

Other people may want more control over when $( ... ) and math stuff is
expanded (such as the suffix style functionality). I wouldn't for the
$( ... ) stuff because we can't guarantee that the command produces the
same output always so completion can't continue after one without
expansion. I don't use $(( ... )) often enough to really care whether it
expands though I'd probably prefer the suffix style behaviour.

I'm now back to using _expand so I may come across other issues which I
haven't thought of at the moment. I'll let you know if I think of
anything.

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

Wouldn't it maybe be a good idea if the value of the recexact option
was used to determine the default for accept-exact so by just setting
the option, it would have an effect throughout the new completion
system. There would then always be the option of setting it to a
different value for a context with zstyle. I would also be inclined to
rename the style to recexact and negate its meaning for consistency
with the option.

I've never been convinced that it is wise that without any styles set,
_expand effectively does nothing: it will inevitably be the source of
an FAQ. I would have thought that it would be best if by default it
behaves in the way which most closely resembles expand-or-complete: so
I would set suffix, glob and substitute by default.

I also agree with Sven in not being too happy about having different
defaults depending on whether _expand was used as a completer or called
from _expand_word as suggested by Bart.

Oliver

Index: Completion/Core/_expand
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_expand,v
retrieving revision 1.16
diff -u -r1.16 _expand
--- Completion/Core/_expand     2000/06/13 11:26:08     1.16
+++ Completion/Core/_expand     2000/06/14 16:03:07
@@ -35,7 +35,7 @@
 fi

 zstyle -t ":completion:${curcontext}:" suffix &&
-  [[ "$word" = (\~*/*|\$[a-zA-Z0-9_]##[^a-zA-Z0-9_]*|\$\{*\}?*) ]] &&
+  [[ "$word" = (\~*/*|\$[a-zA-Z0-9_\[\]]##[^a-zA-Z0-9_\[\]]*|\$\{*\}?*) ]] &&
   return 1

 zstyle -t ":completion:${curcontext}:" accept-exact ||