* Re: _approximate doesn't work [not found] ` <080218013338.ZM15026@torch.brasslantern.com> @ 2008-02-19 8:29 ` Bart Schaefer 2008-02-19 10:19 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Bart Schaefer @ 2008-02-19 8:29 UTC (permalink / raw) To: zsh-workers [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 -- ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: _approximate doesn't work 2008-02-19 8:29 ` _approximate doesn't work Bart Schaefer @ 2008-02-19 10:19 ` Peter Stephenson 2008-02-19 22:22 ` Bart Schaefer 0 siblings, 1 reply; 3+ messages in thread From: Peter Stephenson @ 2008-02-19 10:19 UTC (permalink / raw) To: zsh-workers On Tue, 19 Feb 2008 00:29:35 -0800 Bart Schaefer <schaefer@brasslantern.com> wrote: > 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. You're right this is happening quite late, and I think PREFIX is being restored automatically (by the compstate[restore]=auto mechanism), which is what I missed (a previously modified version of PREFIX wouldn't be picked up). However, this is an extremely general problem. Very many completion functions assume quite reasonably that testing PREFIX tests what the completer is trying to match. Perhaps we need to make approximation/correction more visible by introducing parameters that are local to the completion system and only contain text in the appropriate case (e.g. APPROX="(#a1)")? -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: _approximate doesn't work 2008-02-19 10:19 ` Peter Stephenson @ 2008-02-19 22:22 ` Bart Schaefer 0 siblings, 0 replies; 3+ messages in thread From: Bart Schaefer @ 2008-02-19 22:22 UTC (permalink / raw) To: zsh-workers On Feb 19, 10:19am, Peter Stephenson wrote: } Subject: Re: _approximate doesn't work } } On Tue, 19 Feb 2008 00:29:35 -0800 } Bart Schaefer <schaefer@brasslantern.com> wrote: } > 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. } } [...] this is an extremely general problem. Very many completion } functions assume quite reasonably that testing PREFIX tests what the } completer is trying to match. I just looked through "grep PREFIX Completion/**/*(.)" and I don't think there are very many functions that use PREFIX as a pattern in the way that _path_commands does. Most of them test another pattern against $PREFIX, to determine context based on what $PREFIX contains. The real, more general problem IMO is that we've allowed the lines of responsibility to become way too blurry. The original idea (ISTR) was that the completion functions (as opposed to "completers", or what the manual calls "control functions") would generate a large set of possible completions and then compadd would filter them down to the actual matches, because only compadd knows enough about the internal state of the shell to do so. This gets compromised for performance reasons (e.g., if we know an entire directory path, limit file names to those in that directory) but the early functions were careful to do this only with the parts of the command line that were already unambiguous. That is not, in general, true of $PREFIX. The job of a completer is to figure out the context and supply the corresponding tags. The job of a completion function is to enumerate all the possible strings for some subset of tags. The job of compadd is to reduce that set of strings to the actual completions. As soon as either of the functions starts crossing those boundaries, there's a potential problem, and it better be happening for a good reason. } Perhaps we need to make approximation/correction more visible by } introducing parameters that are local to the completion system and } only contain text in the appropriate case (e.g. APPROX="(#a1)")? It may be that approximation is worthy of addition to compset/compadd. The fact that _approximate has to create a dummy compadd function in order to be implemented, argues in that direction. However, I still think _path_commands was wrong to pre-filter on $PREFIX. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-02-19 22:30 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200802171925.m1HJPbE8009696@pws-pc.ntlworld.com> [not found] ` <080218013338.ZM15026@torch.brasslantern.com> 2008-02-19 8:29 ` _approximate doesn't work Bart Schaefer 2008-02-19 10:19 ` Peter Stephenson 2008-02-19 22:22 ` Bart Schaefer
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).