Re: _approximate doesn't work

Re: _approximate doesn't work

[Bart Schaefer]

[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

-- 

Re: _approximate doesn't work

[Peter Stephenson]

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

Re: _approximate doesn't work

[Bart Schaefer]

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.