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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11176 invoked from network); 24 Nov 2020 23:22:13 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 24 Nov 2020 23:22:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:cc:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=Fi5jOWXRw1krZM6P71t9JXafbO59m4mOKip2i3oHm/8=; b=yyeXYbcNGCjW4rU15Xe4KivYhR 4EJBO4Lu8iGnec/C4zFSyliesTSPv2SWSb9NoxaHKnW7YJVtfKK/nuhs+iUDusEpu/n0lXbZl8eaI Sk6lYVa6QeZyKalzrtjiE/B7P+2BI1/mVcvgN+H2kisDBeOOyVMlNF9IfCIByeSPQ6ImSPshxSmoH mThGM3XjutRwyf8pBxii2Eu2Jwe0WK9CkhAjcSN0x5ZNFpu5M+YraBzBgZnUHxp3Ug6VYOOMwM7Ar ghAYflbNpIo2nqjaIh9sn3HRx+ufF+OERKSYh9qIjM3MHh8Q4fs/wq8R043shF7fOKUAEIDUXWUNl 0eYszohg==; Received: from authenticated user by zero.zsh.org with local id 1khhdT-000Faq-W3; Tue, 24 Nov 2020 23:22:12 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1khhdF-000FQx-WC; Tue, 24 Nov 2020 23:21:58 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1khhdD-00066f-OF; Wed, 25 Nov 2020 00:21:56 +0100 cc: Felipe Contreras , Daniel Shahaf , Zsh hackers list In-reply-to: From: Oliver Kiddle References: <69b1ff42-3e60-4b40-8514-9bb0690eb250@www.fastmail.com> To: Bart Schaefer Subject: Re: Bug in completion with curly braces? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23475.1606260115.1@hydra> Date: Wed, 25 Nov 2020 00:21:55 +0100 Message-ID: <23476-1606260115.748247@tHME.aGU-.iDnX> X-Seq: 47616 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Bart Schaefer wrote: > Consequently if the calling function does not apply quoting, -Q is > only going to work well in cases where the matches either have no > common prefixes, or the common prefixes do not contain any of the > special characters, or menu completion is going to be forced (so the > user selects an entire match all at once rather than exit/re-enter > completion with the prefix). > > (I would be happy to have someone (Oliver?) argue the untruth of that > last statement.) I think it is essentially true except that your list of three special cases can perhaps be expanded. To say it doesn't "work well" perhaps misrepresents that it does do something well-defined, just not especially useful when misused. If you search for compadd.*-Q in completion functions, the cases are not normal. It is often combined with -U which disables matching altogether. You'll see cases where $PREFIX was used in building the actual values passed to compadd. Cases where compquote has been used first. And where QIPREFIX is checked. And anything that looks normal is probably wrong, e.g. in _gdb. I've been assuming that in Felipe's case, he is forced to use -Q because that is what bashcompinit does. bashcompinit uses it because of a patch he submitted in 30136 to make it do so. At the time, I wasn't motivated to review it but can remember being somewhat skeptical. Looking in more detail now, it is correct in essence but it doesn't surprise me that it should also cause some unexpected issues. Looking at the bash example in 30136, it would appear that quoting is left up to the completion function. Is that always true for bash completions? Matches are added with an unquoted trailing space but also some quoted spaces. To get it to pass through compgen, it seems two levels of quoting and removing space from IFS was necessary. Is this idiom common? We could do something like the following in bashcompinit to special case only space suffixes: - compadd -Q "${suf[@]}" -a matches && ret=0 + compadd "${suf[@]}" - "${(@)${(Q@)matches}:#*\ }" && ret=0 + compadd -S ' ' - ${${(M)${(Q)matches}:#*\ }% } && ret=0 For the more general case, we'd need to identify characters with one-level of quoting. Or do a limited number of special cases cover real-world usage? Ultimately there's always going to be a mismatch between what needs quoting in bash and in zsh. Note that in bash no quoting is needed for git stashes: bash$ echo stash{1} stash{1} So a bash completion for git didn't need to add quotes - hence this whole discussion. Perhaps we could add an option to allow that. Stuff like @\{1\}.. is also common in git. If completion that comes with git is really a lot faster, I think you'd be better served by finding out why and adding styles to zsh's completion to allow it to take a faster, more rudimentary approach in certain cases. It may even already be possible by disabling the right tags. Oliver