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=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18641 invoked from network); 14 Jun 2020 04:29:36 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2020 04:29:36 -0000 Received: (qmail 28135 invoked by alias); 14 Jun 2020 04:29:26 -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: 24931 Received: (qmail 26070 invoked by uid 1010); 14 Jun 2020 04:29:25 -0000 X-Qmail-Scanner-Diagnostics: from mail-il1-f175.google.com by f.primenet.com.au (envelope-from <8fvebtoeq87@gmail.com>, uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25835. spamassassin: 3.4.4. Clear:RC:0(209.85.166.175):SA:0(-1.7/5.0):. Processed in 4.349062 secs); 14 Jun 2020 04:29:25 -0000 X-Envelope-From: 8fvebtoeq87@gmail.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.166.175 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=QYDVgi4KNWfEFTYihX9+VMqruwuqLC1F7GpeGhunwcQ=; b=HitvKEohHRxx6UeupZLtmbHkXya61yL/ObEMoFB8nuQ6wY5yyT3GqVoa6QsTiYnhy8 VztlzIA2PIekiFhk8lcNGg7iHUurRtOU5cSVM2EtQemKHrvOCy+bp8ua7t6GsmLSGfZU jBC1bnYLHUM0IXszWnxLassLxu8AuwihCvroATZml8mYkFKFpm1nHwGYNYQdJRNQcofq 0ESRSmgAT1G4K2rJPLJ76HN7vNgJ6NNlZ85UHpwiQBEE+QxDpOTO0KGHebj5qjXrvmEZ sC/1So8DNXmef7YEJqcwxDY3H7n5eHvB4TLeRtV/CDKBJPSMqg7qnBT1hM1ITOTf3hRZ voEg== X-Gm-Message-State: AOAM530k26sBPAJ5NmJiClxtyx8uGmgl5WrAhPNTPTgLLPwPP4mwNv9G wor3zTDFsK4ZkUSHLOo08V6J2avuPc8SwvSm9Bth2CGV X-Google-Smtp-Source: ABdhPJzxquCrMTuQw+j91hCRNCLsyj/2j+6ReXARtki+GY+Yifj954fqF3FZqq6N7Cj8zrvnD2MIVCaz2ziObHCqhu0= X-Received: by 2002:a92:5b99:: with SMTP id c25mr20967195ilg.42.1592108928180; Sat, 13 Jun 2020 21:28:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan <8fvebtoeq87@gmail.com> Date: Sun, 14 Jun 2020 00:28:37 -0400 Message-ID: Subject: Re: menu-select doesn't respect COMPLETE_IN_WORD option To: Bart Schaefer Cc: Zsh Users Content-Type: multipart/alternative; boundary="0000000000001ba99b05a803bf7c" --0000000000001ba99b05a803bf7c Content-Type: text/plain; charset="UTF-8" Thanks for your help with this Bart! When I leave completeinword unset, _prefix completion simply doesn't work, even if I have: zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix Or if I have: zstyle ':completion:*' completer _expand _prefix _complete _ignored (I also don't have alwaystoend set.) One additional thing I've found to be really strange about _prefix completion is if there is only one possible match. For example: % ls -a ./ ../ % mkdir -p dir1/dir2/dir3 % ls dir1/di_r2/dir3 (<-- where _ is the position of the cursor) % ls dir1_ (<-- the "/dir2/dir3" part of the line has been removed!) % ls dir1/dir2/di_r3 (<-- where _ is the position of the cursor) % ls dir1_ (<-- same thing happens) % ls di_r1/dir2/dir3 (<-- where _ is the position of the cursor) % ls dir1_r1 (<-- where _ is the position of the cursor. The suffix only until the first slash, "r1", has been kept after the cursor, but the "/dir2/dir3" part of the suffix has been removed!) When there are more than one possible completions, this doesn't happen and _prefix completion works normally by the previously stated behavior (i.e. keeps the entire suffix after the cursor, but completes/cycles only on the prefix). Seems like when there is only one possible match, the definition of prefix and suffix gets thrown out the window... possibly a bug? On Sat, Jun 13, 2020 at 11:07 PM Bart Schaefer wrote: > 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) > explanation 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, > _prefix forces completion not to complete inside a word. The point is that > without that option, completion is only ever tried at the end of the word, > so when 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 see 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 > would 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. > --0000000000001ba99b05a803bf7c--