expand style `suffix' option

expand style `suffix' option

[Peter Stephenson]

I've been meaning to try to get this to work for some time.  Have I
misunderstood?

     expand
          This style is used when completing  strings  consisting
          of  multiple  parts,  such as path names.  If its value
          contains the string `prefix', the partially typed  word
          from  the line will be expanded as far as possible even
          if trailing parts cannot be completed.  If it  contains
          the  string  `suffix' and normal (non-menu-) completion
          is used, matching names for components after the  first
          ambiguous  one will also be added.  This means that the
          resulting string is the longest unambiguous string pos-
          sible, but if menu completion is started on the list of
          matches generated this way  (e.g.  due  to  the  option
          AUTO_MENU  being set), this will also cycle through the
          names of the files in  pathname  components  after  the
          first ambiguous one.

First off, I assumed I could do
  zstyle ':completion:*' expand 'prefix suffix'
but a look at the code reveals this has to be
  zstyle ':completion:*' expand prefix suffix
so `contains the string' could be made a little clearer.

When it does seem to be on, I would expect
  ~/b/b<TAB>
to list or cycle through all files ~/b*/b* when menu completion is in use,
but it doesn't.  Is this assumption wrong?  The manual entry doesn't
actually say what happens when you have menu completion on from the start,
as opposed to started automatically, but I turned it off and still only get
the first subdirectory completed when automenu is activated.  If this isn't
what it does, what does it do?  Or does it conflict with some other style
or option?  But I get the same behaviour with zsh -f.

I was looking at adding the `expand' style to compinstall, but I'd like to
find out what it does first.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: expand style `suffix' option

[Bart Schaefer]

On Oct 2, 12:41pm, Peter Stephenson wrote:
}
}   zstyle ':completion:*' expand prefix suffix
} 
} When it does seem to be on, I would expect
}   ~/b/b<TAB>
} to list or cycle through all files ~/b*/b* when menu completion is in use,
} but it doesn't.  Is this assumption wrong?

I get the exact same behavior out of that no matter what `expand' is set
to.  E.g. I happen to have two files

	~/netmanage/record
	~/newmail/record

but no matter what the setting of the expand style, I always get:

schaefer<512> ls ~/n/r<TAB>
schaefer<512> ls ~/ne/r

(with cursor on the second `/').  Using menucomplete instead of automenu,
I get the menu:

schaefer<514> ls ~/n/r<TAB>
schaefer<515> ls ~/netmanage/r
Completing files
netmanage/  newmail/  

but once again the `expand' style has no effect on this.

It looks like _path_files applies the `expand prefix' style only if the
number of matches generated is the same as the number that existed at
the time _path_files was called (line 655, nm -eq compstate[nmatches]).
But that never seems to be true.

Also, _path_files only checks that `expand suffix' is NOT set, and then
as part of a larger test to decide whether to clear compstate[to_end]
(lines 508-515), and I can't figure out what circumstances cause all the
other ||'d conditions to be false so that `expand suffix' will matter.

-- 
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: expand style `suffix' option

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> First off, I assumed I could do
>   zstyle ':completion:*' expand 'prefix suffix'
> but a look at the code reveals this has to be
>   zstyle ':completion:*' expand prefix suffix
> so `contains the string' could be made a little clearer.

Yes.

> When it does seem to be on, I would expect
>   ~/b/b<TAB>
> to list or cycle through all files ~/b*/b* when menu completion is in use,
> but it doesn't. 

Well, it says (or tries to say) that this suff-behaviour is only done
when not using menu-completion. I think we either had a discussion or
I thought that people using menu-completion wouldn't want to be
bothered with looong lists.

But anyway, that style appears to be broken (both prefix and
suffix). I seem to have a fix for the suffix thing now (it was broken
when list-suffixes was added, I think) and I know what's the problem
for the prefix part (compfiles building the pattern, so that
_path_files doesn't have the original anymore and doesn't add it to
$exppaths). I'll look into this tomorrow or next week.


Restoring those things would still not make it work with menu
completion, though (the suffix thing), but that could be added. Should 
we?


Bye
  Sven

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

Re: expand style `suffix' option

[Peter Stephenson]

Sven Wischnowsky wrote:
> > When it does seem to be on, I would expect
> >   ~/b/b<TAB>
> > to list or cycle through all files ~/b*/b* when menu completion is in use,
> > but it doesn't. 
> 
> Well, it says (or tries to say) that this suff-behaviour is only done
> when not using menu-completion. I think we either had a discussion or
> I thought that people using menu-completion wouldn't want to be
> bothered with looong lists.
>...
> Restoring those things would still not make it work with menu
> completion, though (the suffix thing), but that could be added. Should 
> we?

OK, I suppose the manual is saying it works if menu completion is started
afterwards, but not if it's already in effect.

Since the `suffix' behaviour is selectable completely separately from
anything else, I can't think of a good reason why the setting shouldn't
simply be respected.  If you don't want it with menu completion you can
simply not turn it on.

Tying settings together is really another problem entirely.  If we want
some more general way of grouping --- set a whole load of styles all
together - we can probably write a function suite that does it, e.g.
  % zselect -v my_menu_styles
  Turning on option `menuselect'
  Changing style `expand' from `prefix suffix' to `prefix'
However, it's not that trivial when you take contexts into account
(compinstall has basically side-stepped this issue and while it handles
contexts, you have to select them by hand).

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: expand style `suffix' option

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> OK, I suppose the manual is saying it works if menu completion is started
> afterwards, but not if it's already in effect.
> 
> Since the `suffix' behaviour is selectable completely separately from
> anything else, I can't think of a good reason why the setting shouldn't
> simply be respected.  If you don't want it with menu completion you can
> simply not turn it on.

Right.  The patch below tries to make this style work again and it
also removes the dependency on not using menu completion (that part of 
the code is pretty hairy, so there might be things which now work
differently with menu-completion -- I'd like to hear about them so
that we can fix them).

> Tying settings together is really another problem entirely.  If we want
> some more general way of grouping --- set a whole load of styles all
> together - we can probably write a function suite that does it, e.g.
>   % zselect -v my_menu_styles
>   Turning on option `menuselect'
>   Changing style `expand' from `prefix suffix' to `prefix'
> However, it's not that trivial when you take contexts into account
> (compinstall has basically side-stepped this issue and while it handles
> contexts, you have to select them by hand).

Yes, I've been thinking about things like this, too, and haven't come
to a conclusion either.


The patch also tries to make the docs clearer on how the style has to
be set, because I haven't changed the code to look for sub-strings.


Bye
  Sven

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.11
diff -u -r1.11 _path_files
--- Completion/Unix/Type/_path_files	2001/08/17 09:25:22	1.11
+++ Completion/Unix/Type/_path_files	2001/10/05 11:11:15
@@ -332,6 +332,8 @@
 
     # Get the matching files by globbing.
 
+    tmp2=( "$tmp1[@]" )
+
     if [[ "$tpre$tsuf" = */* ]]; then
       compfiles -P$cfopt tmp1 accex "$skipped" "$_matcher" "$sdirs" fake
     elif [[ "$sopt" = *[/f]* ]]; then
@@ -344,7 +346,9 @@
     if [[ -n "$PREFIX$SUFFIX" ]]; then
       # See which of them match what's on the line.
 
-      if [[ "$tmp1[1]" = */* ]]; then
+      if (( ! $#tmp1 )); then
+        tmp2=( ${^tmp2}/$PREFIX$SUFFIX )
+      elif [[ "$tmp1[1]" = */* ]]; then
         if [[ -n "$_comp_correct" ]]; then
           tmp2=( "$tmp1[@]" )
           builtin compadd -D tmp1 -F _comp_ignore "$matcher[@]" - "${(@)tmp1:t}"
@@ -504,13 +508,16 @@
         PREFIX="$opre"
         SUFFIX="$osuf"
       fi
+
+      # This once tested `-n $menu ||' but our menu-completion expert says
+      # that's not what we want.
 
-      if [[ -n $menu || -z "$compstate[insert]" ]] ||
-         ! zstyle -t ":completion:${curcontext}:paths" expand suffix ||
+      if [[ -z "$compstate[insert]" ]] ||
+         { ! zstyle -t ":completion:${curcontext}:paths" expand suffix &&
            [[ -z "$listsfx" &&
               ( -n "$_comp_correct" ||
                 -z "$compstate[pattern_match]" || "$SUFFIX" != */* ||
-                "${SUFFIX#*/}" = (|*[^\\])[][*?#~^\|\<\>]* ) ]]; then
+                "${SUFFIX#*/}" = (|*[^\\])[][*?#~^\|\<\>]* ) ]] }; then
         (( tmp4 )) && zstyle -t ":completion:${curcontext}:paths" ambiguous &&
             compstate[to_end]=
         if [[ "$tmp3" = */* ]]; then
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.134
diff -u -r1.134 compsys.yo
--- Doc/Zsh/compsys.yo	2001/08/15 13:50:03	1.134
+++ Doc/Zsh/compsys.yo	2001/10/05 11:11:16
@@ -1070,15 +1070,15 @@
 kindex(expand, completion style)
 item(tt(expand))(
 This style is used when completing strings consisting of multiple
-parts, such as path names.  If its
-value contains the string `tt(prefix)', the partially typed word from
+parts, such as path names.  If one of its values is
+the string `tt(prefix)', the partially typed word from
 the line will be expanded as far as possible even if trailing parts
-cannot be completed.  If it contains the string `tt(suffix)'
-and normal (non-menu-) completion is used, matching names for
+cannot be completed.  If one of its values is the string `tt(suffix)',
+matching names for
 components after the first ambiguous one will also be added.  This
 means that the resulting string is the longest unambiguous string
 possible, but if menu completion is started on the list of matches
-generated this way (e.g. due to the option tt(AUTO_MENU) being set),
+generated this way,
 this will also cycle through the names of the files in pathname
 components after the first ambiguous one.
 )

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

PATCH: Re: expand style `suffix' option

[Peter Stephenson]

Sven Wischnowsky wrote:
> Right.  The patch below tries to make this style work again and it
> also removes the dependency on not using menu completion (that part of 
> the code is pretty hairy, so there might be things which now work
> differently with menu-completion -- I'd like to hear about them so
> that we can fix them).

Working fine so far.

The only glitch I've come across is that you only get the top level
directory in the list even you are completing to multiple levels,
e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing.  One can,
of course, argue that this is perfectly reasonable:  menu completion will
show the full set.  One could wish for an extra directory level to be shown
to resolve conflicts, but then one could wish for free chocolate.

Here's the compinstall stuff for the expand style.

There's a glaring hole in the `styles for particular completions' in the
top menu.  The only entry is for file completions.  I was hoping for people
to add configuration for their own favourite types of completion.  I
haven't thought of anything that useful.

Index: Completion/compinstall
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compinstall,v
retrieving revision 1.4
diff -u -r1.4 compinstall
--- Completion/compinstall	2001/06/13 09:26:15	1.4
+++ Completion/compinstall	2001/10/05 15:57:42
@@ -1529,11 +1529,13 @@
 #       squeeze-slashes,
 __ci_do_file_styles() {
   local key files cursor expand speciald ignorep squeezes select
+  local prefon suffon
 
   __ci_get_this_style file-sort files
   __ci_get_this_style ignore-parents ignorep
   __ci_get_this_style special-dirs speciald
   __ci_get_this_style squeeze-slashes squeezes
+  __ci_get_this_style expand expand
 
   while true; do
     clear
@@ -1548,6 +1550,8 @@
 
 4.  When expanding paths, \`foo//bar' is treated as \`foo/bar'.
 
+5.  Configure how multiple paths are expanded, e.g. /f/b -> /foo/bar
+
 q.  Return without saving.
 0.  Done setting options for filename completion.
 "
@@ -1655,6 +1659,52 @@
 	    ([nN]) squeezes=;;
 	  esac
           ;;
+      (5) if [[ $expand = *prefix* ]]; then
+             prefon=prefix
+	  else
+	     prefon=
+	  fi
+	  if [[ $expand = *suffix* ]]; then
+	     suffon=suffix
+	  else
+	     suffon=
+	  fi
+          print "
+When expanding /f/b, the shell will attempt to match /f*/b* (e.g. /foo/bar), 
+and so on to any depth.  If the first part of the expansion fails, by default
+the shell will not expand the remainder.  However, you can force it always
+to expand the first part.  Currently this feature is ${${prefon:+on}:-off}.
+Do you want it on ([y]es, [n]o, [k]eep current setting)?
+"
+	  while true; do
+	    read -k key'?--- Hit selection --- '
+	    [[ $key = [yYnNkK] ]] && break
+	    print "Type one of y, n or k."
+	  done
+	  case $key in
+	    ([yY]) prefon=prefix;;
+	    ([nN]) prefon=prefix;;
+	  esac
+	  print "
+Further, if /f*/b* is ambiguous, the shell will usually only expand
+as far as the part that is unambiguous; for example, if /foo/bar and
+/food/basket exist, it will wait for you to choose either /foo or /food,
+and not attempt to expand the rest of the match.  However, you can force
+it to add all possible completions for you to resolve conflicts in the
+normal way.  Currently this feature is ${${suffon:+on}:-off}.
+Do you want it on ([y]es, [n]o, [k]eep current settign)?
+"
+	  while true; do
+	    read -k key'?--- Hit selection --- '
+	    [[ $key = [yYnNkK] ]] && break
+	    print "Type one of y, n or k."
+	  done
+	  case $key in
+	    ([yY]) suffon=suffix;;
+	    ([nN]) suffon=suffix;;
+	  esac
+	  expand=${prefon:+$prefon${suffon:+ }}${suffon}
+	  ;;
       (q) return 1
 	 ;;
     esac
@@ -1665,6 +1715,7 @@
   __ci_set_this_style ignore-parents ignorep
   __ci_set_this_style special-dirs speciald
   __ci_set_this_style squeeze-slashes squeezes
+  __ci_set_this_style expand expand
 
   return 0
 }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: PATCH: Re: expand style `suffix' option

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> The only glitch I've come across is that you only get the top level
> directory in the list even you are completing to multiple levels,
> e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing.  One can,
> of course, argue that this is perfectly reasonable:  menu completion will
> show the full set.  One could wish for an extra directory level to be shown
> to resolve conflicts, but then one could wish for free chocolate.

Ah, with the file-sort style set, right?  I'll have a look when I find 
the time.

> There's a glaring hole in the `styles for particular completions' in the
> top menu.  The only entry is for file completions.  I was hoping for people
> to add configuration for their own favourite types of completion.  I
> haven't thought of anything that useful.

Uh, oh.  (Most of the time, I just forget to remember compinstall. So
to say.)


Bye
  Sven

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

Re: PATCH: Re: expand style `suffix' option

[Sven Wischnowsky]

Peter Stephenson wrote:

> ...
> 
> The only glitch I've come across is that you only get the top level
> directory in the list even you are completing to multiple levels,
> e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing.  One can,
> of course, argue that this is perfectly reasonable:  menu completion will
> show the full set.

That bug was in a different place than I first suspected. With
unsorted groups (and neither -1 nor -2) duplicate matches were removed 
but it didn't make sure to hide matches showing the same string in the 
list. I'm pretty sure this wasn't done on purpose.

>  One could wish for an extra directory level to be shown
> to resolve conflicts, but then one could wish for free chocolate.

No change here, one can always set the list-sufffixes style to get
that behaviour (although it would probably be sensible to do that
automatically with menu-completion).


Bye
  Sven

Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.50
diff -u -r1.50 compcore.c
--- Src/Zle/compcore.c	2001/08/20 13:13:50	1.50
+++ Src/Zle/compcore.c	2001/10/09 09:43:15
@@ -2654,6 +2654,8 @@
 	    }
 	} else {
 	    if (!(flags & CGF_UNIQALL) && !(flags & CGF_UNIQCON)) {
+                int dup;
+
 		for (ap = rp; *ap; ap++) {
 		    for (bp = cp = ap + 1; *bp; bp++) {
 			if (!matcheq(*ap, *bp))
@@ -2662,6 +2664,17 @@
 			    n--;
 		    }
 		    *cp = NULL;
+                    if (!(*ap)->disp) {
+                        for (dup = 0, bp = ap + 1; *bp; bp++)
+                            if (!(*bp)->disp &&
+                                !((*bp)->flags & CMF_MULT) &&
+                                !strcmp((*ap)->str, (*bp)->str)) {
+                                (*bp)->flags |= CMF_MULT;
+                                dup = 1;
+                            }
+                        if (dup)
+                            (*ap)->flags |= CMF_FMULT;
+                    }
 		}
 	    } else if (!(flags & CGF_UNIQCON)) {
 		int dup;

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

Re: PATCH: Re: expand style `suffix' option

[Peter Stephenson]

Sven Wischnowsky wrote:
> > The only glitch I've come across is that you only get the top level
> > directory in the list even you are completing to multiple levels,
> > e.g. ~/b/b<TAB> shows up a whole load of `bin/'s in the listing.  One can,
> > of course, argue that this is perfectly reasonable:  menu completion will
> > show the full set.
> 
> That bug was in a different place than I first suspected. With
> unsorted groups (and neither -1 nor -2) duplicate matches were removed 
> but it didn't make sure to hide matches showing the same string in the 
> list. I'm pretty sure this wasn't done on purpose.

I'm still getting the behaviour, but I don't believe it's really a bug:
with menu completion and menu selection, you need different entries in the
displayed menu to cycle through.

> >  One could wish for an extra directory level to be shown
> > to resolve conflicts, but then one could wish for free chocolate.
> 
> No change here, one can always set the list-sufffixes style to get
> that behaviour (although it would probably be sensible to do that
> automatically with menu-completion).

Yes, this does what I want.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************