From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers <zsh-workers@sunsite.dk>
Subject: Re: setopt globcomplete and () broken
Date: Tue, 10 Mar 2009 21:22:18 -0700 [thread overview]
Message-ID: <090310212221.ZM29099@torch.brasslantern.com> (raw)
In-Reply-To: <20090310135146.30c0c794@news01>
In-Reply-To: <20090310173424.1af302c5@news01>
In-Reply-To: <237967ef0903101104y135e0ca6sdbd9fbe8272f2d99@mail.gmail.com>
In-Reply-To: <200903101818.n2AIIIFk010993@news01.csr.com>
In-Reply-To: <237967ef0903101130j64c71c88r9c8e234d000fc351@mail.gmail.com>
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@gmail.com> 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@csr.com> 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
--
next prev parent reply other threads:[~2009-03-11 4:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 13:25 Mikael Magnusson
2009-03-10 13:51 ` Peter Stephenson
2009-03-10 17:34 ` Peter Stephenson
2009-03-10 18:04 ` Mikael Magnusson
2009-03-10 18:18 ` Peter Stephenson
2009-03-10 18:30 ` Mikael Magnusson
2009-03-11 4:22 ` Bart Schaefer [this message]
2009-03-13 9:56 ` Peter Stephenson
2009-03-13 15:08 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=090310212221.ZM29099@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).