Re: nocorrect deduced from completion list?

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Adam Spiers wrote:

> This may be a totally unrealistic idea, but in principle it works
> nicely (I think):
> 
> How about an option which intercepts command-line processing just
> before spelling correction is invoked, and checks whether the word
> under suspicion of incorrect spelling belongs to the list of
> completions for that context?  E.g.
> 
> % perldoc -f pos
> zsh: correct 'pos' to 'os' [nyae]? n
> 
> would never happen, because `pos' is in the list of completions in the
> :complete::perldoc::-f-1 context.  It might slow things down too much
> for some people's tastes, but would it be worth implementing anyway?

I've been thinking about this too. A bit. I haven't really looked at
the code, but maybe something like this could be allowed via the
preexec function -- changing the command liine, which would then
require re-parsing.

Or maybe it's better to do something like this with a shell function
for accept-line (which should almost be possible already, the only
problem is that $BUFFERLINES is read-only).

But the main problem is to find out the right places where to call
completion (i.e. set $CURSOR, try completion, look at the result,
place the cursor at the next interesting position, etc.). A good
starting point may be try it at every white space after a word. But I
think we would really need a way to split a string into command line
words with full shell parsing to find the places where to set the
cursor. We currently only have this in the completion code. Hm. That
would mean to split the line at every command separator, call the
completion code only to get the $words (i.e. without any completers),
look at those words to find out which should be checked, call the
completion code for them and continue with the next command. Sounds
terribly expensive...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx