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 645 invoked from network); 28 Mar 2021 21:42:36 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 28 Mar 2021 21:42:36 -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=37F90UnZxmHcMoR8W2FkgblhFHGunthMwDJz1k9xe9A=; b=ASOSqK9hCrVi+uoWbdbxORCUNa bg1IwBSlZTrVf0S3j0/w4sJ8cDoATLBjPN9pNU3N89lcFU370E0md7iAX5sEPyz3qR3gvubxkCtXx /t7SlfDQNmJT56aY1gVRj2Oegyhwz1QiS7xTXY9yCJSuNmg0Xls0GC+Q+8Rcq7BQIvF5T+lvIJneF aviAmsWB27+JK5o4pfhBgMK/kEut888Rda0EKWnSokCaSdijFsb7Z/VrDBmEktLbn2+B4Eg6nnTBk RrA1IS+iQ3NYOfpsw8Kbd1RHmEnhxqTZj7qe95w0K86HQaikxxGdbeR/SY0QHfyWXVYL15iqsTCK2 k96UPLzQ==; Received: from authenticated user by zero.zsh.org with local id 1lQdB5-000OH0-4H; Sun, 28 Mar 2021 21:42:35 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1lQdAr-000O7E-BO; Sun, 28 Mar 2021 21:42:21 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.93.0.4) (envelope-from ) id 1lQdAo-000JK2-BT; Sun, 28 Mar 2021 23:42:20 +0200 cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: To: Marlon Richert Subject: Re: Why does _main_complete not try the next completer when $_comp_mesg is non-zero? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74276.1616967738.1@hydra> Date: Sun, 28 Mar 2021 23:42:18 +0200 Message-ID: <74277-1616967738.353098@Tsys.Nn18.rMz7> X-Seq: 48295 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: Marlon Richert wrote: > The following line in _main_complete > > [[ -n "$_comp_mesg" ]] && break > > has the effect that, whenever _message has been called (with only few > exceptions), the next completer won't be tried, _even when > $compstate[nmatches] is zero._ > > Why? What is the reason for this? This allows you to see a hint of the command argument expected at the cursor position. When you use commands that you're not especially familiar with, getting prompts telling you what sort of value is expected along with units and defaults can be very useful. _messages -e/compadd -x was a later addition that allowed it to prompt as-if there were matches which is useful for things like patterns and numbers that can't be usefully completed. This also tied in with the fake styles for adding fake matches. I've always had a separate key bound for history completion. > And is there a convenient way to work around this behavior? I want > _history to be tried when _complete fails, but this behavior often > prevents it. For example, if I try `grep \t`, then I get only the > message `pattern`, whereas I would like to get history words. You could create a wrapper for _complete that unsets it, something like: _complete_nomesg() { _complete local ret=$? _comp_mesg= return ret } It might be better to experiment with something like that first. You'll find that _message changing compstate[insert] is also affecting it. > And if there is not an easy workaround, would you accept a patch from > me that changes this? That would break things that I've got too accustomed to over many years so I'd not be enthusiastic about a patch that "changes this". Many completion functions rely on the fact that they don't need to care so much about return status if _message is called. It could be possible to add some style or perhaps change the completer style to allow for different criteria as to whether it continues. A problem with trying to change this at the level of _main_complete is that that is very generic and has no detailed information about the context so any style lookup would be a basic on/off rather than being context-sensitive. If you want to experiment with it, guarding the first _comp_mesg assignment in _message with [[ -n "$3" ]] && allows the format style to be set to the empty string to disable the setting. Oliver