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 10141 invoked from network); 14 Jun 2020 03:08:25 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2020 03:08:25 -0000 Received: (qmail 9302 invoked by alias); 14 Jun 2020 03:08:08 -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: 24930 Received: (qmail 5781 invoked by uid 1010); 14 Jun 2020 03:08:08 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f174.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(209.85.167.174):SA:0(-1.9/5.0):. Processed in 2.063467 secs); 14 Jun 2020 03:08:08 -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.167.174 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:content-transfer-encoding; bh=y94VDEev3JYdsz5GETrBC8xl1u+qKDHiS0pqw9oQaEQ=; b=o6Ct/LKeHSY0pZcREcJJ61KGBk1XJniv7eqsnd5hwBuEo/sL1rpTPtDlRxRcP0hQ5E a39vFwSilcIXnCvVzoUeh/uJSHPT74ddbDK1oYmIDZb86OY9UW1d3Yn6vPDBcdGl8Y3T b1pvACoMhT2CVqG98+JqYGISSJQ7fzWl+VeGHpxytsLVB/3fnDzujl6tsu8XcfEfWUGx XZauPzdZqKWW6j384GwoIWWmOmmOqkiEjf91dfCqA8Bt2YZfAkerWOughdMD4SBheGmj jITeLPGN9z/u8ri0IGnuNZt7G2QOW8Dqhh9ZZVse4tkJVJ5m29rCqkrRq6E08cDK2p3j 4x+A== X-Gm-Message-State: AOAM5325X0xv3h9GsOXcoCwsDkSzLzDbBxw7HE6ltsgDGhyYvRtP4YVa 8JyYDp4CbOrJfxYTmPv+0n1+ZFbFu961IyVu/5E61A== X-Google-Smtp-Source: ABdhPJwS5tROGD716J+WknEYfWxd85IrbGWl67+sn38j3wEI/c0tGZqMEy1j4F8Aws2WnfTZ5fDjJYeZdwMdJGeGPrM= X-Received: by 2002:aca:57d7:: with SMTP id l206mr4438558oib.84.1592104052526; Sat, 13 Jun 2020 20:07:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bart Schaefer Date: Sat, 13 Jun 2020 20:07:20 -0700 Message-ID: Subject: Re: menu-select doesn't respect COMPLETE_IN_WORD option To: Alan <8fvebtoeq87@gmail.com> Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 10, 2020 at 8:26 PM Alan <8fvebtoeq87@gmail.com> wrote: > > Yes, I've tried *not* setting the complete_in_word option, but then the _= prefix completer doesn't work. See this (rather bizarre in my opinion) expl= anation from http://zsh.sourceforge.net/Guide/zshguide06.html: > > "One gotcha with the _prefix completer: you have to make sure the option = COMPLETE_IN_WORD is set. That may sound counter-intuitive: after all, _pref= ix forces completion not to complete inside a word. The point is that witho= ut that option, completion is only ever tried at the end of the word, so wh= en you type in the middle of , the cursor is moved to= after the end of the suffix before the completion system has a chance to s= ee what's there, and hence the whole thing is regarded as a prefix, with no= suffix." As you've noticed, I think this advice only applies when _prefix is attempted after _complete, or possibly when the ALWAYS_TO_END option is set (which by default it is not). I don't think COMPLETE_IN_WORD is relevant unless you want prefixes completed only when no other possibility is found (which is probably what it was thought most people would expect). If someone has a chance to test a few combinations and update that doc, please go ahead. I might but I don't know how soon. > (I'm not actually entirely clear how the completer ordering works, so not= sure if I need that second _prefix instance at the end, but whatever works= I guess. If someone would care to shed some light on the matter, that woul= d be good too.) The completion process happens in a nested loop: For each function in the completer list, try it with each of the patterns in the matcher-list. Ordinarily this loop stops as soon as one of the completers returns zero (true), which is why the order is important, but the _all_matches completer can change that. The only reason to put _prefix in the list twice would be to implement the example of doing so that appears in the documentation for _prefix.