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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 725 invoked from network); 23 May 2020 19:22:23 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 23 May 2020 19:22:23 -0000 Received: (qmail 6766 invoked by alias); 23 May 2020 19:22:11 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24869 Received: (qmail 7621 invoked by uid 1010); 23 May 2020 19:22:11 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f41.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25814. spamassassin: 3.4.4. Clear:RC:0(209.85.210.41):SA:0(-1.9/5.0):. Processed in 1.922518 secs); 23 May 2020 19:22:11 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.210.41 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QcLVriMfXrU2C5084cw0gdvYSNeQd/duvr/KnFGz98M=; b=gtPoBvIjbksfGuA92YyQV8OCpHPdaTObUbsh3jSFJgmcEAmq3csjCZkTRj9HQZV9Vj /diNQk73lPyLM7aMeN/Kc9LZ6yRFSj6/83pHjfNRw7lymBeImbrS7VQEjpNiAZXCvdnB x1O2scP4X59z0Mr8EiDKaDlXI1/RLqTzbAIwfwmmZbu73pP2GyAtfjm6m7blnROtGKPK 2yHptVp+VDKeIWLBHawyTQzmuSHP43VHlWtzsZ0ZNgFU2Dh+N0m6DVjwceDmgMfpsnNz LOyARZ4qF6cBjNsXicLvqwuhU9KJMdFD3p0M18aD26iNjUE0x622VU6PBer3AR//C9lE y8vw== X-Gm-Message-State: AOAM533lRC+YeQXzTLiApT8g0KmvO3TbivL7Ga1+FyqZ1/b2kEGhjaU2 jmBeMasKCG67i8yL49TpxVlZpLkWP4vdd0k/jKQDvw== X-Google-Smtp-Source: ABdhPJzV7Xc9Ay+i5zpkqba0XqRMgc9GtReMIPkgoLbLxTDGzmBqHeZ54IC352unureqDcajz/oAFnlWi0F2C+Vxu7c= X-Received: by 2002:a9d:20e7:: with SMTP id x94mr16682587ota.260.1590261694945; Sat, 23 May 2020 12:21:34 -0700 (PDT) MIME-Version: 1.0 References: <587B9115-0CAB-4379-986C-F2C22BEA8460@kba.biglobe.ne.jp> <06E9B8F3-66E5-442F-9036-DB326A338E6F@kba.biglobe.ne.jp> <0382AECE-3FF4-45B3-A9EA-1B532849D80A@kba.biglobe.ne.jp> <6F7E7CFA-43CF-4D21-A9EA-E64CA84A9EAA@kba.biglobe.ne.jp> In-Reply-To: From: Bart Schaefer Date: Sat, 23 May 2020 12:21:23 -0700 Message-ID: Subject: Re: menu completion To: Pier Paolo Grassi Cc: "Jun. T" , Zsh-Users List Content-Type: text/plain; charset="UTF-8" On Sat, May 23, 2020 at 3:53 AM Pier Paolo Grassi wrote: > > Basically I wonder if it is up to the completer to choose whether to do > interactive menu completion, any thoughts on this? That's not precisely what's happening. The completer is deciding that you should see the message "pattern" because the guard says there are no valid options beginning with a single hyphen. (Literally it means anything not beginning with two hypens must be a pattern, and it doesn't know how to complete patterns, but the effect is the same.) It's the setup to display that message that turns off the menu, because you can't both have a menu and see the message. But the guard is wrong -- there actually ARE some options (non-patterns) that begin with a single hyphen. So the completer proceeds to add all the possible matching options, and when control returns to the top level (_main_complete), it sees the set of completions is not empty and therefore offers those instead of the message. It's possible this should be considered a problem with _message -- that is, that once _message has been called, completion should STOP and force the message to be seen, instead of continuing to try other possible variations. Then instead of zsh: do you wish to see all 156 possibilities (41 lines)? you would see (assuming you defined the "format" zstyle) e.g. completing pattern (and perhaps get a beep) which is actually what was intended by the guard. However, I suspect stopping after every _message might break other valid use cases.