From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5181 invoked by alias); 14 Sep 2016 05:20:23 -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: X-Seq: 39313 Received: (qmail 24482 invoked from network); 14 Sep 2016 05:20:23 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f43.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.43):SA:0(0.0/5.0):. Processed in 0.823603 secs); 14 Sep 2016 05:20:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=O5F4dTgp/SyPglAwTQ+L7cb+EiG4pQXFj9qgZIkwCWw=; b=u3/H0Ekd0wtN63cNy9ID/M7EuytgaDHOwQ9W3Gunhbi9li6D4hrQA0Bh6iF5FQd+or TG4Xi2NYSsLzijjKAVFilK1A6FYjmz5MSI5zCBosoQDL7KXmcfPDzch5EDIinK5etBoQ n5WSw3OdCXCnSBA7B2YXioyG1R+GGD1M5MQUJc4II6L36Rye2VRjP1jV7ELTyR3F6GxD bFD6ZB8wVkayjb/O7o8OT3uwaZQQD+pUmJryNbQr74dmPeDtx9UqQbfGSROWyGJTFWH/ ijLtq0G3AHlb/+wGKWZCAJ0jbENiI/jol2nhlJeNsVGWsmwp9Uepj05/sQ4P7zkHCeM8 yOPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=O5F4dTgp/SyPglAwTQ+L7cb+EiG4pQXFj9qgZIkwCWw=; b=K4KQiCgXimk2MAGjUh2h0HFyMUdGPwJiZuxbPBurM55XhoOS3fVN3mZe3D6LLpMeu5 GKjzJeaIc1thAzj0r9haucOw/s3yIgHxaQzTDdl1j0wcCd0BGGvDU/zS/QO55ffMn04v 3Z55PwH7+u4kgLs7e64BJWxWH0v63rcT50rFWTzStNvTPP0yNgqsNvACEjKwlWQ32c0R G/XUEWHQRSSsOm7HVg2mHrNyzsyhhEEI3ZXMxfnOBZ0qpAnH0RvW6mh5jn4o47uTrqZ0 LFeoTbPrF9HhjpdhIOSAv1GDj38fmBc/b1VH/x9rfYu9/6xxzh4etHPKZ30jAUfAkjVl 3Pcw== X-Gm-Message-State: AE9vXwODXR0NM48PSeFLI2g8kDa3QS8RzEqUwBJFdYQdbahTCqpHs92+i5DWrtpVDoFjzQ== X-Received: by 10.66.76.65 with SMTP id i1mr1155284paw.51.1473830419354; Tue, 13 Sep 2016 22:20:19 -0700 (PDT) From: Bart Schaefer Message-Id: <160913222029.ZM13117@torch.brasslantern.com> Date: Tue, 13 Sep 2016 22:20:29 -0700 In-Reply-To: <20160914032254.GA32528@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: compset -q oddities" (Sep 14, 3:22am) References: <20160911073031.GA19137@fujitsu.shahaf.local2> <160911191422.ZM21970@torch.brasslantern.com> <20160912230632.GA29577@fujitsu.shahaf.local2> <160912232853.ZM27002@torch.brasslantern.com> <20160914032254.GA32528@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: compset -q oddities MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 14, 3:22am, Daniel Shahaf wrote: } Subject: Re: compset -q oddities } } Bart Schaefer wrote on Mon, Sep 12, 2016 at 23:28:53 -0700: } > You didn't start from ~~~. You started from an empty word and typed } > TAB twice. ~~~ was never on the line. I concur that the result of } > the second attempt is weird, I would have expected it just to fail. } } I would have expected the second press to do nothing If the first tab had correctly produced one of ~~~ or \~\~\~ then I would have expected the second tab to do nothing, but given what the first tab incorrectly burped out, it should have failed. Also now that I think of it, there's only one match with that compadd, so it should have appended a trailing space and the second tab should have been in an entirely new (also empty) word. } > On the first tab (empty word), the prefix is empty but "compset -q" } > causes completion to believe there is quoting on the line (backslash } > by default). The compadd call makes ~~~ a valid completion, which } > when added is quoted to \~\~\~. The effect of compset is then undone, } > meaning the backslash-quoting that was presumed removed is restored, } > and you end up with \\\~\\\~\\\~. } } All this is fine. Well, no, not really. "compset -q" should make note that there were no quotes when it was called, and therefore not restore any quote on the way back out. There's a comment above compcore.c:307 /* * It looks like we may need to do stuff with backslashes even * if instring is QT_NONE. */ Peter, that was you in workers/22819, can you explain? } It would also have been correct for the first level of quoting not to } occur, since "~~~" doesn't need command-line escaping. As noted later, this is because of extendedglob. Examining each tilde in isolation, quotestring() has to assume the string may be interpreted as an X~Y pattern, so it quotes all tildes. } This makes sense as far as quotestring() is concerned, but when called } from completion, this causes the tilde to be quoted even though } ${_comp_caller_options[extendedglob]} is unset. Indeed. It might make sense for the internals to save the top-level option state on entry and implicitly re-assert it during compadd. } The backslash in \\~~~ is probably added by quotestring() [despite } unsetting extendedglob] because the 'u==s' part of the condition That's exactly what happens, and is also why a leading = gets quoted. } Perhaps making quotestring() not add that redundant first } backslash would workaround the issue The problem isn't really with the backslash being added there, it's somewhere later on when the prefix is being compared to the candidate match and one side of gets too much (? different?) quoting before the comparison is made. I haven't figured out where that is, yet (and am not going to try too hard, honestly).