From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26865 invoked by alias); 14 Sep 2016 16:12:54 -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: 39322 Received: (qmail 18926 invoked from network); 14 Sep 2016 16:12:54 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f172.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.192.172):SA:0(0.0/5.0):. Processed in 0.588571 secs); 14 Sep 2016 16:12:54 -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=KSLKn0kLtZW2Vcyomx1Igf6reF/Av8lCrfpicLLKlzc=; b=uMboX4d6T7T3zFSbTXYIADdYl4od0tNSlz528FtoI96IF5Jp7M+Y5eX/MZwbpymZC+ qlwkW49eFvqHrzr3AuuSkFcfeYnN2tF4zktPK7m0kfCxo7kVM30LfPdwOC/FnqEQlqQG 9TT6mqnXSWGStsunkTB016ulY073a4N6JhHB137z2ErhdKjpIUqEZJgnCEObxWAsncSd A/ZJZazHgNnbh8TrkHfA2c335iENr4Hl7+u4yxywFbN5+Yr6nS9o+6eHVntfjgU6SLrf LWx0dLWpQnUt8gIUNbiQeI2M3QDSc6jRAY8vL/OfXVmMY/Q0GbO7NQexbuIu3RLPsc4x GMfA== 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=KSLKn0kLtZW2Vcyomx1Igf6reF/Av8lCrfpicLLKlzc=; b=hqjK7TUpTCcW6qCn/PW5GcLxLxAagB/HQRPCH/gBvD66jyUIJzMKmoT0s9rXrtUUi1 /4wkIkNQklp+HeYGS7ddtm0p9wQKiA3QX/5z4eS/vv8F9/jhXwb4E7N05h7cB3MnVuWk tEHJJC7VmoDsaGm33xRa2AJLlzMN7mPg2618h+6lBhopgCezUY9XJl7JqfSlOgcIOEWQ BM4HPqYqxaq0r4QCjoZWPQeLzDD3SWmltQ53P8Uaj1+DGb6T6uSo8kRqF7tssFm/jIrE sdYK2wQ9Lk2W8QA2t0Aiz6MgInwDwqhDityTW9xZCfUN8SQGH+pA5oULMdezU337duzh n5CQ== X-Gm-Message-State: AE9vXwMjXNcY1I1UVtoA0RjBWh+7pl/HiTDFXI8EjjwDxtlPCFYXqR+n2GVBf5R+uNAHBA== X-Received: by 10.98.198.85 with SMTP id m82mr5846545pfg.3.1473869086290; Wed, 14 Sep 2016 09:04:46 -0700 (PDT) From: Bart Schaefer Message-Id: <160914090457.ZM29602@torch.brasslantern.com> Date: Wed, 14 Sep 2016 09:04:57 -0700 In-Reply-To: <20160914093146.08a2c090@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: compset -q oddities" (Sep 14, 9:31am) 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> <160913222029.ZM13117@torch.brasslantern.com> <20160914093146.08a2c090@pwslap01u.europe.root.pri> 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, 9:31am, Peter Stephenson wrote: } Subject: Re: compset -q oddities } } On Tue, 13 Sep 2016 22:20:29 -0700 } Bart Schaefer wrote: } > 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. } > */ } } I think the point is related to the fact that in the case of backslashes } we never know there are no quotes. Aha. So if we see a word that starts with backslash, instring will be QT_BACKSLASH, but when instring is QT_NONE, we do not know whether any other backslashes appear in the middle of the word. However, as I said in a previous reply: >> 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. That later stage [wherever it is, I suspect comp_match()] also expects that quoting has been manipulated in this way, and so if it has *not* (I played with compcore.c:307) then strings that should match, do not. The problem is that we have [at least] three sources of data: The literal command line, the (possibly quoting-manipulated) subset of the command line against which completion is being attempted, and the candidate matches passed to compadd. Canonicalizing in a way that makes it possible to compare any two of the three is very difficult.