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 16153 invoked from network); 15 Jun 2020 00:38:28 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 15 Jun 2020 00:38:28 -0000 Received: (qmail 29941 invoked by alias); 15 Jun 2020 00:38:18 -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: 24932 Received: (qmail 13244 invoked by uid 1010); 15 Jun 2020 00:38:18 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f173.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25842. spamassassin: 3.4.4. Clear:RC:0(209.85.167.173):SA:0(-1.9/5.0):. Processed in 2.633616 secs); 15 Jun 2020 00:38:18 -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.173 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=wqUQ2xr9tAYMFPZgos4E6hbRH9TmzlPQjDYd3NoDQRI=; b=SRaKOtP6D3zDMqoEzH1h7PTxoMgsbQQrTeKxYrH1nkIRR2Td46Ug/rCN5rvN7tUKEk spwgR77I75FuteKmjdvE07G0fD3qv0GzjhIRzi4NDANT4Rmx0NyZNQIRcjKhGY4EhJoA IU6v5hBnIPvxEPip/mHa7c9jYLZh/n30Ct4yhwKI1msLzzpL9XmtnUNRL0vB7AVGRZhs w4Jw88xCNotL7zAg8Qjzrgnvlmgf++GEMY6YOaf02kczqwm96JbUzYn2klGGFP6m36I5 gTgulKAYagxIN9nJdOPDcdhjdrx7Upj1A5XYWOYtm0pDiREJrs904KdG9zc65eL0IkQf dAjA== X-Gm-Message-State: AOAM531amTdVUoNitYjuyT5l/wbLjaVd6cPhs7OBOZ4CB4ykU4PQ9DNh shRajZTEcxU7crvLVcT6YooiTYHs7dhiqtkLFx/NNQ== X-Google-Smtp-Source: ABdhPJzMBSG7blkB41HngBWLiCv605hR2kel0Rne3P5ZbjPBBF5NfHCEftjkLwCzbWM1o2TD5xWz+WoBPkmrVXXLrFY= X-Received: by 2002:aca:cf15:: with SMTP id f21mr7095092oig.173.1592181462050; Sun, 14 Jun 2020 17:37:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bart Schaefer Date: Sun, 14 Jun 2020 17:37:30 -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" On Sat, Jun 13, 2020 at 9:28 PM Alan <8fvebtoeq87@gmail.com> wrote: > > When I leave completeinword unset, _prefix completion simply doesn't work, even if I have: > > zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix > > 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!) Starting from "zsh -f" and like you using "_" for cursor position: % compinit -D % zstyle \* format %d % zstyle ':completion:*' menu 'select=1' % zstyle ':completion:*' completer _expand _prefix _complete _ignored % mkdir -p dir1/dir2/dir3 % ls dir1/di_r2/dir3 % ls dir1/dir2/dir3/_ The above happens with any of complete-word, expand-or-complete, or menu-complete. If I run expand-or-complete-prefix instead: % ls dir1/di_r2/dir3 % ls dir1/dir2/_r2/dir3 Which looks exactly like I would expect. % set -o | grep complete completealiases off completeinword off globcomplete off menucomplete off If I turn on "globcomplete" then nothing works except expand-or-complete-prefix, but I still don't get anything removed from the line. I just get a beep and the cursor stays in the middle of "dir2" and the description "files" appears (from the format zstyle). If I turn on "completeinword" then I can reproduce your described behavior with menu-complete, although expand-or-complete-prefix still works as expected. Looking at the output of ^x? (complete-debug), what's happening is that _prefix says "if there is only one possible completion, then insert only the unambiguous prefix" which (because of the way completing across a directory boundary works) is only "dir1". This does not occur if you are completing a file name in the current directory: % touch part1.part2.part3 % ls part1.pa_rt2.part3 % ls part1.part2.part3_rt2.part3 So I still think you want to leave complete-in-word turned off and find out what other part of your startup is breaking things when you do. Incidentally the _prefix behavior with the unambiguous prefix is itself a compromise; before workers/18841 (2003-07-09) it would alarmingly delete the entire word from the line.