Re: correction hook

[Felix Rosencrantz <f_rosencrantz@xxxxxxxxx>]

This is a response to an old thread from February.  A draft I wrote in March. 
The topic hasn't come up in a while, so it seems like there wasn't much
interest.
-FR

On Mon, 11 Feb 2002 Bart Schaefer wrote:
>On Mon, 11 Feb 2002, Clint Adams wrote:
>> Sorry, I described a specific case and forgot to mention the more
>> general problems.  They are as follows.
>> 1) In the case of mak/mawk/make, the user has no instances of 'mawk'
>> in his history, but he has recently typed 'make'.  The correction
>> algorithm is unaware of these details.
>
>"Past performance is no guarantee of future results."  Just because a
>software developer tends to type "make" repeatedly, doesn't mean that's a
>good indication of the behavior of some other shell user.

Correction is never going to be 100% right.  The idea is to improve
the odds.  Different scoring strategies (e.g. commands previously
used score higher) will give different results that will depend on
the user&tasks at hand.  I think it would be useful, if just like
completion, correction could use different scoring strategies for
performing correction.

So many times I find I'm upset with correction for offering up commands
I have never used.  So this would be one strategy for finding a good
correction.  But a different user may find that this is not for them.
Maybe that user is very prone to having one of their hands offset on
the keyboard (more becomes nire), so that user might prefer to use a
keyboard hand offset strategy.


>> 2) When one has CORRECT_ALL set, correction isn't nearly as intelligent
>> as completion. [...]
>> Rather than adding a slew of additional aliases, it would be nice if
>> correction were smart enough [...]
>
>We've discussed before that the correction system could be tied to
>completion.  It'd have to be something equivalent to that in order for it
>to "know" the legitimate arguments to every possible command, and there's
>no point in inventing all of that twice.

Sounds like time to plug the XML completion stuff... :) 
It would be easy to take the XML description of a command and convert
that into a getopt like description, which could be used to parse the
command line.  And the XML description could still be used to generate
a completion function.  If there is no checker for a command, it just
scores lower than other commands, assumption that this command is not
interesting to the user.

>Correction could actually go one step further -- when it finds a command
>name it wants to correct, it could, for each possible correction, attempt
>to check the argument list against the possible completions, and pick the
>correction for which the existing arguments give the best match.  (That
>would be some impressive code.  Anybody looking for a Master's thesis
>project?)

Seems like you have described a good algorithm.  Not sure why it would
have to be as complicated as a Master's thesis.  With some sort of
getopt-parsing, and argument count checks, it might be a useful strategy
for correcting a command.  (Though with a good hook mechanism in place,
it would make it easier for someone to tackle this as a Master's thesis
project.)

I've always been pretty impressed with the results of predictive-type
widget you've written.  It works really well in certain circumstances.
All just by calling completion. Though shell typing prediction has been
the subject of a few graduate students research. (I mention the ones I
know in zsh-workers/12289.)  So it might be possible to use some less
complicated algorithms and still get good results.

Also, it might be useful if there were a few more options at the
correction prompt.  What if zsh offered more that one possible
correction (rather than the "I'm feeling lucky" way).  The user could
select the best choice via a number menu, or completion menu. Maybe
we should allow the user to jump directly into completion from the
correction message.


On Mon, 11 Feb 2002 Oliver Kiddle wrote:
>I'm not entirely convinced by the correction mechanism because it has
>to interrupt you with its prompt. With the new completion system I get
>any typo in a word I completed corrected by _approximate anyway. I'd be
>more inclined to think about a totally different way of spotting and
>communicating typos such as using the completion system continually and
>underlining possible typos.

I like that idea.  That would be very useful.  Though, if the user
didn't fix the command name, the shell should still prompt about the
problem.  So there would still be the issue of post-enter command line
correction.

Also, there is a difference between correction and approximation.
Command correction uses a scoring system that not only counts errors,
it also looks at which errors are more likely based on a model of the
keyboard. (At least that what I remember...)  Which is different than
the _correct completer...

I would like to see some improvements on the correction front.  I think
a hook would be useful.  And potentially could provide even better
correction choices.  Also, if we had some way of highlighting problems
as the user typed, that would be useful.

My experience with tcsh and zsh, is that zsh does a much better job
at correction than tcsh did. (It's been a while since I used tcsh.)
I believe the reason was related to the fact that zsh used a scoring
system that modeled the keyboard, while tcsh just did a score based on
typing error counts.

Throw in past command usage, some flag&argument checking, multiple
choices, and some completion correction could be even better.

-FR.



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/