From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27717 invoked by alias); 18 Aug 2016 05:32:02 -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: 39058 Received: (qmail 2943 invoked from network); 18 Aug 2016 05:32:02 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f48.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.48):SA:0(1.3/5.0):. Processed in 0.198952 secs); 18 Aug 2016 05:32:02 -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=1.3 required=5.0 tests=T_DKIM_INVALID,URI_HEX autolearn=no 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:in-reply-to :comments:to:subject:mime-version; bh=j16KsVAb2rCgbuHSWjY8RNVyquQMdBuMZ5kkdiFuAvs=; b=CyoL8c/tVdlGcbVNM+FKmocj5Wa5w1cGjntczKVbM4Y3MKfyR9Nw2gZEHUMPnIhauZ PBJLjGtxBVluch8EggAxOxIvLFEmcA+twarZe6jL/jt9Tkgetc4O9yV/aUyzvzZWYzK2 MvJE+WdN5J8KO5ZTfVtOF/u5U+NFydAu3kMJd0M9zChkBzhsZ8+svjCYpt6snVlv/Uy/ Do4wF4hrcGWSq95F4A2S6teoz+L5jioYeY4CLMVQPsIcKBCCgODyjCPjonZXKKn0x/P5 01JAuzQarq+UvYxICvpJAm/kLrUGKTaariehetyWOyZ6O3K7fbJ30sJaafkbPl50cu98 CAtw== 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:in-reply-to:comments:to:subject:mime-version; bh=j16KsVAb2rCgbuHSWjY8RNVyquQMdBuMZ5kkdiFuAvs=; b=cEJ8ZjefTpOOni6aMjJocKCIA32ImHDw33cU2PldwSNGYucnEqLjXzbQfTy4bckdxB ZaVnW+Iy0dJ3vi88ppGGowhfIwbybR/k6XyFtMXEwBw/HOOQPsUTSo+dkxwbzu14y9bP VddBUTbi+YEQgBY2VnCdH6nIcsek+u9GznDgXu0TPaVzajPIvf+s922l6PIJNc/wMGom oQTr/RkHTcO3FFnYG+PE3vHgx9u8qdBFkpGPCL54S/4+PM3dC+9koEFkhIyFd/k0U7Rh fVxdS2teQlqv3z+/wEJtp71On9EVfBqF6qFZDabIksRMCLIn9T9dlSGt6aDiNtHA3pTP +pyw== X-Gm-Message-State: AEkoouueY44O3hQvOH9LfwCact2xFLvW7SHEvz91/z8ZiZvhiHwUjXN7kQ9qHvSCXUnB5Q== X-Received: by 10.66.221.229 with SMTP id qh5mr824881pac.66.1471498315476; Wed, 17 Aug 2016 22:31:55 -0700 (PDT) From: Bart Schaefer Message-Id: <160817223204.ZM23377@torch.brasslantern.com> Date: Wed, 17 Aug 2016 22:32:04 -0700 In-Reply-To: Comments: In reply to Daniel Hahler "Re: SSH hostname completion with common suffix and globcomplete inserts characters" (Aug 17, 9:38pm) References: <705fb246-abcf-176b-d4fa-eb0e01cded05@thequod.de> <174db3fa-2af2-d43b-3978-5cb789af4ed9@thequod.de> In-Reply-To: <174db3fa-2af2-d43b-3978-5cb789af4ed9@thequod.de> Comments: In reply to Daniel Hahler "Re: SSH hostname completion with common suffix and globcomplete inserts characters" (Aug 18, 12:52am) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: SSH hostname completion with common suffix and globcomplete inserts characters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 17, 9:38pm, Daniel Hahler wrote: } } Given ssh_config2: } } Host foo-test-05827d88.foo.bar bar-test-6cae9ce0.foo.bar } } % ssh -F ssh_config2 test } } completes to } } % ssh -F ssh_config2 -test-|.foo.bar I can't reproduce this from "zsh -f" -- I had needed your matcher-list style from your second message. } and a second invocation of the completion will then use the "-t" at the } beginning (for "escape character (or `none')"). } } Should this get quoted on expansion to prevent this? It might be possible to fix this in this specific case, but in general I don't think it can/should be handled. This goes along with the usual completion dilemma of whether to assume the user intends quoting to be interpreted by completion to change the result, or to be kept in place in order to affect the parse when the line is accepted. A more ideal approach would be similar to using _oldlist, wherein the internals would remember the previous semantic of the current word (in this case, that it's an argument rather than an option) and use that semantic again if another completion is attempted in the same word position, rather than recalculating the context every time. } When quoting it manually, I see a similar issue as described before (see } below), where } } ssh -F ssh_config2 '-test-.foo.bar' } } gets expanded to } } ssh -F ssh_config2 '-test-BR.foo.bar' } } (without the globcomplete option though!) I'm not able to reproduce that, either, when quoted. Instead I get a listing of the two possible results, and then cycling through them on repeated tabs. On Aug 18, 12:52am, Daniel Hahler wrote: } } The insertion of "BR" does not happen with "zsh -f" though. It is } caused by matcher-list zstyle setting in my config: 'r:|[._-]=*' There must be another zstyle in play somehow, because with this -- } zstyle ':completion:*' matcher-list '' 'm:{[:lower:]}={[:upper:]}' \ } 'm:{[:upper:]}={[:lower:]}' 'r:|[._-]=* r:|=*' 'l:|=* r:|=*' -- as my only zstyle, I can't reproduce the result above. I *can* reproduce the original report by adding globcomplete. } While looking at it, it seems like 'r:|[._-]=* r:|=*' is redundant The thing on the right side of the equal matches the trial completion, whereas the thing on the left of the equal matches the command line. So r:|=* means anything can match an empty word (nothing on the command line) whereas r:|[._-]=* means anything can match after dot, underscore, or hyphen. The 'l:|=* r:|=*' may be redundant but I don't think the other bits are. } For some other reason I cannot reproduce the issue of "BR" being } inserted when using ssh_config2 with "zsh -f" just by using the same } matcher-list zstyle config. As noted above, I get the "BR" thing only with globcomplete, and only when the string on the line is not quoted.