Autocorrect for commands with a hyphen (dash) in the name

Autocorrect for commands with a hyphen (dash) in the name

[Seth Tisue]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

...doesn't work, in either zsh 5.7 or 5.8:

    % which aspell-import
    /usr/local/bin/aspell-import
    % apsell-import
    zsh: command not found: apsell-import

but the same isn't true for underscores:

    % which apfs_hfs_convert
    /sbin/apfs_hfs_convert
    % apsf_hfs_convert
    zsh: correct 'apsf_hfs_convert' to 'apfs_hfs_convert' [nyae]?

seems like a bug?

Re: Autocorrect for commands with a hyphen (dash) in the name

[Bart Schaefer]

On Mon, May 18, 2020 at 5:16 PM Seth Tisue <seth@tisue.net> wrote:
>
> ...doesn't work, in either zsh 5.7 or 5.8:
> [...]
> but the same isn't true for underscores:
> [...]
> seems like a bug?

On a quick glance at the code, it appears hyphen is considered to be
"close to" a number, whereas underscore is considered to be "close to"
a letter.  This may have something to do with a long-ago transcription
of a then-common keyboard layout.

Autocorrect isn't really a spelling checker, despite everything that's
said about it.  It's a typographical error checker comparing the
command word to something it can look up in the command hash table.
So it'll fail if the hash table isn't filled yet, or if it decides
your input is too "far away" to be a typo.

Re: Autocorrect for commands with a hyphen (dash) in the name

[Daniel Shahaf]

Bart Schaefer wrote on Tue, 19 May 2020 00:38 +00:00:
> On Mon, May 18, 2020 at 5:16 PM Seth Tisue <seth@tisue.net> wrote:
> >
> > ...doesn't work, in either zsh 5.7 or 5.8:
> > [...]
> > but the same isn't true for underscores:
> > [...]
> > seems like a bug?
> 
> On a quick glance at the code, it appears hyphen is considered to be
> "close to" a number, whereas underscore is considered to be "close to"
> a letter.  This may have something to do with a long-ago transcription
> of a then-common keyboard layout.
> 
> Autocorrect isn't really a spelling checker, despite everything that's
> said about it.  It's a typographical error checker comparing the
> command word to something it can look up in the command hash table.
> So it'll fail if the hash table isn't filled yet, or if it decides
> your input is too "far away" to be a typo.

I think there may be more to it than that.  spckword() expects its first
argument, *s, to be unmetafied; however, when that function is called
from the «isset(CORRECT)» codepath, *s is metafied.

The zle callsite passes an unmetafied string, and invoking the spell-word
widget correctly corrects a word that isset(CORRECT) does not correct.

Seth, as a workaround you can use the spell-word widget.

Re: Autocorrect for commands with a hyphen (dash) in the name

[Bart Schaefer]

On Mon, May 18, 2020 at 5:53 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Tue, 19 May 2020 00:38 +00:00:
> > Autocorrect isn't really a spelling checker
>
> I think there may be more to it than that.  spckword() expects its first
> argument, *s, to be unmetafied; however, when that function is called
> from the «isset(CORRECT)» codepath, *s is metafied.

Ahh, another side-effect of the decision to metafy hyphens.

So, the following?  Or should this also have the equivalent of

            if (*w == Tilde || *w == Equals || *w == String)
                *x = *w;

like zle_tricky.c?

diff --git a/Src/lex.c b/Src/lex.c
index a541def..615da5a 100644
--- a/Src/lex.c
+++ b/Src/lex.c
@@ -1868,8 +1868,12 @@ exalias(void)
     hwend();
     if (interact && isset(SHINSTDIN) && !strin && incasepat <= 0 &&
        tok == STRING && !nocorrect && !(inbufflags & INP_ALIAS) &&
-       (isset(CORRECTALL) || (isset(CORRECT) && incmdpos)))
-       spckword(&tokstr, 1, incmdpos, 1);
+       (isset(CORRECTALL) || (isset(CORRECT) && incmdpos))) {
+       char *x = dupstring(tokstr);
+       untokenize(x);
+       spckword(&x, 1, incmdpos, 1);
+       tokenize(tokstr = x);
+    }

     if (!tokstr) {
        zshlextext = tokstrings[tok];