Re: setopt globcomplete and () broken

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

There are two patch hunks in here, one all the way at the end.

On Mar 10,  1:51pm, Peter Stephenson wrote:
} Subject: Re: setopt globcomplete and () broken
}
} On Tue, 10 Mar 2009 14:25:16 +0100
} Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
} > % touch '()' '().'
} > % touch <tab>
} > % touch \(\)<tab>
} > \(\)   \(\).
} > % setopt globcomplete
} > % touch <tab>
} > % touch \(\)<tab>
} > # nothing appears
} 
} The following chunk of code in guess-where around line 201 is triggering:
} it's looking for glob qualifiers.  We need a test that the parentheses
} aren't quoted; we could have '()' or "()" or $'()' or \(\), or some
} mixture, possibly with text in between.
} 
} if [[ -n "$compstate[pattern_match]" &&

Note that this first test is true when globcomplete is set.  The only
other time it can be true is if we somehow come through here via one of 
_correct or _approximate (or someone's personal completer function that
attempts something similar).

}       ( ( -z "$SUFFIX" && "$PREFIX" = (|*[^\$])\([^\|\~]##\) ) ||
}         "$SUFFIX" =  (|*[^\$])\([^\|\~]##\) ) ]]; then

Except for the insanely complicated case where an (e:...:) qualifier
has an expression with backslashes, which I'll bet this has never
really handled anyway, I think the following may deal with it:

Index: Completion/Unix/Type/_path_files
===================================================================
diff -c -r1.20 _path_files
--- _path_files	28 Feb 2009 07:13:24 -0000	1.20
+++ _path_files	11 Mar 2009 03:34:33 -0000
@@ -199,8 +199,8 @@
 zstyle -s ":completion:${curcontext}:" ignore-parents ignpar
 
 if [[ -n "$compstate[pattern_match]" &&
-      ( ( -z "$SUFFIX" && "$PREFIX" = (|*[^\$])\([^\|\~]##\) ) ||
-        "$SUFFIX" =  (|*[^\$])\([^\|\~]##\) ) ]]; then
+      ( ( -z "$SUFFIX" && "$PREFIX" = (|*[^\$])\([^\|\~\\]##\) ) ||
+        "$SUFFIX" = (|*[^\$])\([^\|\~\\]##\) ) ]]; then
   # Copy all glob qualifiers from the line to
   # the patterns used when generating matches
   if [[ "$SUFFIX" = *\([^\|\~]##\) ]]; then


I think that will cover the majority of cases, but let's explore the
rathole PWS has gone down just a bit farther.


On Mar 10,  5:34pm, Peter Stephenson wrote:
} Subject: Re: setopt globcomplete and () broken
}
} On Tue, 10 Mar 2009 13:51:46 +0000
} Peter Stephenson <pws@xxxxxxx> wrote:
} >     elif [[ "$tmp1" = (#b)(*[^\$])(\(\([^\|~]##\)\)) ]]; then
} >       tmp2=( "$tmp2[@]" "${match[1]}((${tmp3}${match[2][3,-1]}" )
} 
} I thought I was on the way to understanding what was going on here, but
} this attempt to match some form of glob qualifiers has stumped me.  Why are
} we specially matching a pattern ending with glob qualifiers wrapped in
} double parentheses?

That seems to be from zsh-workers/9191, and Sven wrote it that way
right from the beginning.  Note it used to be inside a test for whether
the "sort" style was set; I haven't tracked down when that changed.

} Can I simply hold my breath until it goes away?

Or until Sven comes back, I suppose.


On Mar 10,  7:04pm, Mikael Magnusson wrote:
} Subject: Re: setopt globcomplete and () broken
}
} If I delete that whole paragraph of code, my completion works as I
} want

Not surprising, see my first remark about $compstate[pattern_match].


On Mar 10,  6:18pm, Peter Stephenson wrote:
} Subject: Re: setopt globcomplete and () broken
}
} Mikael Magnusson wrote:
} > And when completing actual files, why would globcomplete mean
} > _path_files has to do extra work instead of just expanding the
} > pattern?
} 
} The extra work in this particular case is merging together glob
} qualifiers passed down (e.g. "-/" becoming "*(-/)") with any that are
} there on the command line.

Right, but in this case there is no glob qualifier, just a real file
name with parens in it.  So what we really want to do is avoid that
mess entirely, isn't it?  Worrying about doubled parens is a tangent.


On Mar 10,  7:30pm, Mikael Magnusson wrote:
} Subject: Re: setopt globcomplete and () broken
}
} > Are you sure that's not going through _expand? If I remove _expand
} > from the list of completers, I don't get completions for things like
} > *zshe*(D) unless glob_complete is set.
} 
} Well, as i wrote further down my completer list is _oldlist _complete
} _correct, i don't know if that is a yes or a no :).

It completes for me without _expand as well.  The _complete_debug
trace is too long and call _path_files too many times to work out
exactly what the call sequence is, but it has something to do with
the _match completer.

} _path_files:25: command not found: _globflags
} printed 5 or 6 times, if I run autoload _globflags it works. This
} seems odd to me since _globquals seems to work without any special
} treatment.

The _globflags file in the source lacks a "#compdef" or "#autoload"
line at the top.

Index: Completion/Zsh/Type/_globflags
===================================================================
retrieving revision 1.1
diff -c -r1.1 _globflags
--- _globflags	23 Nov 2008 18:26:27 -0000	1.1
+++ _globflags	11 Mar 2009 04:21:01 -0000
@@ -1,3 +1,5 @@
+#autoload
+
 local ret=1
 local -a flags
 

--