From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8129 invoked from network); 24 May 2020 18:40:51 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 24 May 2020 18:40:51 -0000 Received: (qmail 21099 invoked by alias); 24 May 2020 18:40:39 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45908 Received: (qmail 14423 invoked by uid 1010); 24 May 2020 18:40:39 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f47.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25821. spamassassin: 3.4.4. Clear:RC:0(209.85.210.47):SA:0(-1.9/5.0):. Processed in 1.959067 secs); 24 May 2020 18:40:39 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.210.47 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pK6fnq4sbQe4n2Ir1OyLlt1tTRkkT/BZdbppS/OP91c=; b=f97iU8k3Tun0+v3sGyiXR80GvTQ5xNudxYXHR02TNgLgC+OjvajmAiciZpGga5dcqv F9sLIMpCYQRKBK5n2eEH4r9Fy4wW+aBZ/kVtCMbnK3F8cC+iISq9FKMHORmXIpHs02hi gukttxIRYvR//SuGwBHUcgqz9GnbsJrP39PfKAXtm35w/8+1tbGLILhoap0QJNOtc6Uj yBtkkwmjzyuxfO7J8tML/rMkk4K7cFZJ+O7yPKGBuqARXH6t9cKuNILqdgAtqX79Zhf1 HzyCU0sbRrKqQVba9xsUxqINI1Em315+/Tf2Oi2gjQ/OMgvzbJfftjZq+GBQcoUqTFpi 5uCQ== X-Gm-Message-State: AOAM532qzszfWDg8T0RtRO6VnjcTSadHlMe0AyTKGniMVW0gKmiheXlO +/uXBJMxLUHKhT78Eq14IDpqqs1wWe87umMvrqQBOsbJrEnXCw== X-Google-Smtp-Source: ABdhPJxyJXT6R4dMGci7vS7ogZdouyhHq2NgwDwikR6rjfgUDhydiuTPy6Z44qsMi5GXtwelKSxkhcHegwrvIcxbOQg= X-Received: by 2002:a05:6830:16c4:: with SMTP id l4mr19504095otr.161.1590345603753; Sun, 24 May 2020 11:40:03 -0700 (PDT) MIME-Version: 1.0 References: <22f19bb4707e388629092d2e8673d8294fa8e375.camel@ntlworld.com> <2d5fcc3630beeec538b7b4dc334991da7420968e.camel@ntlworld.com> In-Reply-To: <2d5fcc3630beeec538b7b4dc334991da7420968e.camel@ntlworld.com> From: Bart Schaefer Date: Sun, 24 May 2020 11:39:52 -0700 Message-ID: Subject: Re: [PATCH?] Re: Autocorrect for commands with a hyphen (dash) in the name To: Peter Stephenson Cc: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" On Sun, May 24, 2020 at 10:12 AM Peter Stephenson wrote: > > > You mean you think we can unify lex.c > > and zle_tricky.c inside spckword()? > > Yes, at the moment spckword() is expecting a sort of slightly tokenised > here and there string, which isn't a particular great interface. There's a problem with this to which I don't see an immediate solution: spckword() modifies the original input string in place, to return the best guess. In both lex.c and zle_tricky.c, that result string is then used in later code, which means if it goes in tokenized it ought to come back out that way as well. In zle_tricky.c it is actually strcmp()'d against the input string, even though zle_tricky.c then immediately untokenizes it again to actually insert it on the command line. You said: > If the spell check worked, > the result is just a normal word. We'll at least have to change spckword() from a void function to one that returns a status of whether it found a guess, because otherwise "check worked" is a matter of that strcmp(). lex.c seems to want it tokenized, because it then does something similar to untokenize() except it also converts Nularg (which untokenize() skips over). Maybe there are guaranteed not to be any Nularg at that point. This is all very messy. Also, confirm that hash tables are stored untokenized?