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 6033 invoked from network); 17 Sep 2020 19:36:51 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 17 Sep 2020 19:36:51 -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=d0b6Vdq7h6hUz7q89hih0NGgZLxnKGOc5c6Ls+xdxJk=; b=CW2QWSsjzRZ8gwByPC2MMIhRzG UH1Fi26+OuuTUjBR8PNFDAra0YOURHp0TaoQ9U695y7wyWpF6hlbcg5eqWTUvGxdTnDqwvOI8MOH7 4Rbkmon+TyWXPgaZJlarSHmZD/G5mGvXadWZ3sPr1/So0yYyVCmL2Isahm7f6t2T5ckezZHBwvntN jNAZci6rFCIQDvEM4DwDmMhCvtVSHcDL3FHUta2RXXmRnnJVByZXhBl0HIB5/jukDO9nl2vrobk17 DLvL7BNNNzMoZiaF7yiydu9sS3sqO2C/Dl9UYBlzsPxw8NGBm7EykP7AeHhyd9Ia6FXkZdfdBihWR NGWR3QNg==; Received: from authenticated user by zero.zsh.org with local id 1kIzi4-000INw-Vh; Thu, 17 Sep 2020 19:36:49 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1kIzhd-000I15-Qt; Thu, 17 Sep 2020 19:36:22 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1kIzhb-000Ocf-RM; Thu, 17 Sep 2020 21:36:20 +0200 cc: zsh-users@zsh.org In-reply-to: <20200918.022213.2164194227802931452.yasu@utahime.org> From: Oliver Kiddle References: <20200918.022213.2164194227802931452.yasu@utahime.org> To: Yasuhiro KIMURA Subject: Re: Strange behavior about option completion of `git push` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94651.1600371379.1@hydra> Date: Thu, 17 Sep 2020 21:36:19 +0200 Message-ID: <94652-1600371379.844993@tOXe.J2fU.pIBE> X-Seq: 26071 Archived-At: X-Loop: zsh-users@zsh.org Errors-To: zsh-users-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-users-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Yasuhiro KIMURA wrote: > Next let's type `git push --f' and hit TAB. In this case options that > start with `--f' are `--follow-tags`, `--force` and > `--force-with-lease` and all of them start with `--fo`. So expected > behavior is that it will be completed as `git push --fo`. But what > really happens is that there is no change after TAB is hit. This appears to be a bug in the zsh completion internals. The difference between --f and --r is that for --f, the options are added with more than one call to compadd because there's a mix of suffix characters required on those options. Any further discussion on this line should probably go to -workers but a minimal function to reproduce the issue is as follows: compadd -M 'r:|.=*' one compadd -M 'r:|-=*' - --follow-tags --force compadd -M 'r:|-=*' - --force-with-lease return 0 With _git_push the first of these compadd calls is from _ssh_hosts. The matching control options are needed. The latter two with - as a pivot but the first can use any character. The case with --r is equivalent to combining the latter two compadd calls into a single call. Matching control is known to have some gnarly issues. Oliver