From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: _approximate doesn't work
Date: Tue, 19 Feb 2008 00:29:35 -0800 [thread overview]
Message-ID: <080219002936.ZM16243@torch.brasslantern.com> (raw)
In-Reply-To: <080218013338.ZM15026@torch.brasslantern.com>
[Redirected to -workers]
On Feb 18, 1:33am, Bart Schaefer wrote:
} Subject: Re: _approximate doesn't work
}
} On Feb 17, 7:25pm, Peter Stephenson wrote:
} }
} } The problem is around this bit that's used if descriptions
} } for the commands are needed (the verbose style is set and at least some
} } commands have descriptions):
} }
} } for cmd in ${(@)commands[(I)$PREFIX*]}; do
} [...]
} } I can see that _path_commands is skipping this loop, indicating the
} } expansion was empty. However, I can't see why this is happening.
}
} Hmm, I get
}
} : _path_commands:15:then then for; line=whatis: -s: unknown option
I tweaked _path_commands to replace "whatis -s" with "apropos" and now
I can reproduce the original failure.
The problem is that at the line above in _path_commands, PREFIX is
always "xsane_g" (using PWS's test) and never "(#a1)xsane_g".
Looking through the output, PREFIX gets set by the replacement compadd
created via _approximate -- but that doesn't happen until *inside* the
call to _wanted, long after the test in _path_commands.
So the solution is to remove the attempt by _path_commands to pre-filter
on PREFIX, and instead simply pass the whole damned array through, as is
done with "compadd -k commands" in the no-descriptions branch.
However, I must say that I'm not all that thrilled with the whole idea
behind _path_commands, now that I look at it. Caching or not, I don't
really want the entire contents of the whatis database dumped into my
shell. Consequently I'm quite happy at the moment that "whatis -s"
does not work correctly on my system, and I'd respectfully ask that
someone else undertake to add a much more specific ztyle than just
(as currently used) "verbose", that must be set to enable this.
Meanwhile, here's the simple patch to fix the prefix matching.
Index: Completion/Unix/Type/_path_commands
--- zsh-forge/current/Completion/Unix/Type/_path_commands 2007-08-19 16:04:10.000000000 -0700
+++ zsh-4.3/Completion/Unix/Type/_path_commands 2008-02-18 20:55:51.000000000 -0800
@@ -52,7 +52,7 @@
if [[ -n $need_desc ]]; then
typeset -a dcmds descs cmds
local desc cmd sep
- for cmd in ${(@)commands[(I)$PREFIX*]}; do
+ for cmd in ${(k)commands}; do
desc=$_command_descriptions[$cmd]
if [[ -z $desc ]]; then
cmds+=$cmd
--
next parent reply other threads:[~2008-02-19 8:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200802171925.m1HJPbE8009696@pws-pc.ntlworld.com>
[not found] ` <080218013338.ZM15026@torch.brasslantern.com>
2008-02-19 8:29 ` Bart Schaefer [this message]
2008-02-19 10:19 ` Peter Stephenson
2008-02-19 22:22 ` 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=080219002936.ZM16243@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).