zsh-users
 help / color / mirror / code / Atom feed
* Autocorrect for commands with a hyphen (dash) in the name
@ 2020-05-19  0:15 Seth Tisue
  2020-05-19  0:38 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Seth Tisue @ 2020-05-19  0:15 UTC (permalink / raw)
  To: zsh-users

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Autocorrect for commands with a hyphen (dash) in the name
  2020-05-19  0:15 Autocorrect for commands with a hyphen (dash) in the name Seth Tisue
@ 2020-05-19  0:38 ` Bart Schaefer
  2020-05-19  0:52   ` Daniel Shahaf
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2020-05-19  0:38 UTC (permalink / raw)
  To: Seth Tisue; +Cc: Zsh Users

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Autocorrect for commands with a hyphen (dash) in the name
  2020-05-19  0:38 ` Bart Schaefer
@ 2020-05-19  0:52   ` Daniel Shahaf
  2020-05-19 21:25     ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Shahaf @ 2020-05-19  0:52 UTC (permalink / raw)
  To: zsh-users

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Autocorrect for commands with a hyphen (dash) in the name
  2020-05-19  0:52   ` Daniel Shahaf
@ 2020-05-19 21:25     ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2020-05-19 21:25 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh Users

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];

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-19 21:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-19  0:15 Autocorrect for commands with a hyphen (dash) in the name Seth Tisue
2020-05-19  0:38 ` Bart Schaefer
2020-05-19  0:52   ` Daniel Shahaf
2020-05-19 21:25     ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).