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 13246 invoked from network); 23 May 2020 21:19:33 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 23 May 2020 21:19:32 -0000 Received: (qmail 7096 invoked by alias); 23 May 2020 21:19:27 -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: 45905 Received: (qmail 21881 invoked by uid 1010); 23 May 2020 21:19:27 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f175.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25814. spamassassin: 3.4.4. Clear:RC:0(209.85.167.175):SA:0(-1.9/5.0):. Processed in 27.866573 secs); 23 May 2020 21:19:27 -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.167.175 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=sxFX0skX0S6OEP5RwvzduDbzl/m1MNZC3MdM/N3Dq6U=; b=mDP7lgIQcmu6/MvrREscIjfLTa7AtLW+iSXlVezb1xwZuCgnG51rT1VN1U4xdLWou5 vLrMn/HV+lMVblJCwsLWtuLQHgrShORomy2TbXcXeueMNp5M+KzzTQEBwterPISXpRDb JiO+xovVa++oZ0fXL1lxBaeqUl4sWL5fjkmLSKX+6FmupOgUXPaaQdzXOHHQPylGwQgI QwzF/X6v+xTSJBsmurJJNLqrwXjx51KLZjoSRCo8UqqPIX2SaTlKgDDvdLLrWSXEYTMx mI9yflfvzrW8xR9Pl+lOvHSmf99c+h6LPshSyHlPSdKAYRuuRUX0kVQM9SG7eDrUop5p DlRw== X-Gm-Message-State: AOAM531JhO7r6tlmxZ2sYX/08AuUwMwt0tWNMBlsMZnxNKslAUZZaoR+ 0QuPzaG38EcLM57M2EWIKniAN4VnVBxdg9cYb/twdGpoWbE= X-Google-Smtp-Source: ABdhPJwspO2QLqGD4hGzifpCyuF1wI6Q4ABfSYIunJQqvyOMrtGhNn1odgzRUlbe8GpvDuR8CR083mdVedS7MfRPj0k= X-Received: by 2002:aca:ed10:: with SMTP id l16mr6691524oih.84.1590268705829; Sat, 23 May 2020 14:18:25 -0700 (PDT) MIME-Version: 1.0 References: <22f19bb4707e388629092d2e8673d8294fa8e375.camel@ntlworld.com> In-Reply-To: From: Bart Schaefer Date: Sat, 23 May 2020 14:18:14 -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 Sat, May 23, 2020 at 1:31 PM Peter Stephenson wrote: > > On Sat, 2020-05-23 at 12:54 -0700, Bart Schaefer wrote: > > > > > > > > > > if (*w == Tilde || *w == Equals || *w == String) > > > > > *x = *w; > > Yes, I guess you need to skip over those before untokenizing. zle_tricky is actually re-tokenizing them again after untokenizing but before calling spckword(). > That matches this line in spckword(): > > if (*t == Tilde || *t == Equals || *t == String) > t++; Right, and then it uses those tokens to decide which hash table to search. OK, I think that answers the question. > But still not sure we > actually need two separate token-based interventions. Which two are we talking about? You mean you think we can unify lex.c and zle_tricky.c inside spckword()? Yes, we could move the whole thing to utils.c, and then spckword() would be expecting to take a tokenized string rather than an untokenized one.