Re: correction hook

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, 11 Feb 2002, Clint Adams wrote:

> Someone complained to me that when he mistyped "make" as "mak", zsh
> would spell-correct it to "mawk" instead of "make".  I had asked him for
> a proposed algorithm to solve this, but he had none.

Incidentally, I think this happens because of the order in which the hash
table is traversed when looking for a likely correction.

On Mon, 11 Feb 2002, Peter Stephenson wrote:

> Peter Stephenson wrote:
> > You can add stuff to the hash table with the `hash' command; it's probably
> > a gap that, as far as I can see, you can delete commands you never want to
> > use or see completions or corrections for.
>
> That should say `can't', or this doesn't make sense.

But you *can* delete commands you never want to use.  You can't prevent
them from coming back again if you rehash or if you actually do use them,
but `hash -f ; unhash mawk' will produce the desired effect for the
example above.

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.

> 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.

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?)

> > 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 imagine that would be slow, though quite useful to some.

It's not all that slow.  You can try something like it now with the
predictive typing bindings that are included in the distribution.