From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: PATCH: Re: use of `expand suffix' style in _multi_parts
Date: Wed, 19 Feb 2003 09:05:57 +0100 [thread overview]
Message-ID: <6216.1045641957@finches.logica.co.uk> (raw)
In-Reply-To: <2098.1045227503@csr.com>
On 14 Feb, Peter wrote:
> Completing directories after
>
> tar xvzf file.tar.gz HERE/
>
> with the `expand' style set to include `suffix' is inconvenient as it
> appends a space after the slash when completing the directory HERE.
> This is obviously wrong --- there is no reason to do anything other than
> normal file completion at this point, irrespective of styles.
>
> I can fix this by setting `expand' specially for the tar command, of course.
> However, it needs fixing more generally. Unfortunately I can't work out
> what's actually wrong. The culprit is _multi_parts where the style is
> tested. Is this wrong, is the compadd on the next line (which uses the
> options passed rather than the separator passed) warong, is _tar wrong,
> in any case what needs changing?
using:
compdef '_multi_parts / "(HERE/ HERE/one HERE/two)"' foo
is enough to show the problem so it certainly isn't _tar.
If you rearrange the three matches, it is always the first one that is
completed.
This line in the trace output then looks suspicious:
+_multi_parts:94> compadd -O tmp1 -M 'r:|/=* r:|=* ' - HERE HERE HERE
It is followed by assertions being made based upon $#tmp1. So for the
part it is looking at there are three matches but they are all the
same.
This patch fixes the problem by adding all those matches.
Oliver
Index: Completion/Base/Utility/_multi_parts
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_multi_parts,v
retrieving revision 1.4
diff -u -r1.4 _multi_parts
--- Completion/Base/Utility/_multi_parts 31 May 2001 07:17:04 -0000 1.4
+++ Completion/Base/Utility/_multi_parts 19 Feb 2003 07:55:41 -0000
@@ -114,7 +114,7 @@
if [[ $#imm -ne 0 && $#matches -eq 1 ]] ||
zstyle -t ":completion:${curcontext}:" expand suffix; then
compadd "$group[@]" "$expl[@]" "$sopts[@]" \
- -M "r:|${sep}=* r:|=* $matcher" - "$pref$matches[1]"
+ -M "r:|${sep}=* r:|=* $matcher" - $pref$matches
else
if (( $matches[(I)${tmp1[1]}${sep}*] )); then
compadd "$group[@]" "$expl[@]" -p "$pref" -r "$sep" -S "$sep" "$opts[@]" \
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
prev parent reply other threads:[~2003-02-19 8:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-14 12:58 Peter Stephenson
2003-02-19 8:05 ` Oliver Kiddle [this message]
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=6216.1045641957@finches.logica.co.uk \
--to=okiddle@yahoo.co.uk \
--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).