From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6552 invoked by alias); 10 Mar 2016 02:20:04 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38124 Received: (qmail 815 invoked from network); 10 Mar 2016 02:20:02 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=06Cg+UXTCD8cg8Gu8Vx6d/vzqqbOapKofJl5Feko5YY=; b=lTDR9OolZnfxQ4U3bEi7W0oPJ9bfVL9cY3Y+16j1T26MDdK0zPm/8QWj3ZrkMjP/Io MMuXPPXuXqpqXdCvjH9RBEy3h4LuITXez1x/DwXwDOrlraieuR/sqWc4kjk/WfAGUem+ NzkIUy0Um0INwkNsPN5+swvhSaAq2c1l4LHXBeiQUaUpXpwLwOpdxLuQW8b1BHlUSfOA THm4r/5n3gkbJF9wOPqXhZ+kTI1mcQ5pdkhLGTOloaQYrx9V83NQylDoUq9pfYuyTDOH eA0oPqqtfX5oKF7cj6qXuy8O1FYLW3yi/kb9rUBE/M8BhQ8V/dd7uWM4sGgHbxcPQlno yqCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=06Cg+UXTCD8cg8Gu8Vx6d/vzqqbOapKofJl5Feko5YY=; b=Lmu7025TAt0InIeoqaBA7jUehQ+LPlmMHcs25bADEpQRaXZV9LhlaMgzjr8o/XfNSM mXw8JxkRJFKnOqXHGTGkBAABOAZwegA3ySMr1B1ztKUVppP3dKCXD+futu8QNnq2ceYn Tq+NEhI91F9ViNCfzwkbPvblHX8nnY7do3HLSWENFFb3J+A9cE6Z5HLjWZ3/McY/FFYV q+I0LYq98NfoT5tFKQ3KcJ2TnTHZlnoyKyKSg7F93ejPQEEsZgIw9Lq10E242EZWAAYw qw0OmAGhk0rlta+z6NUT7MxMj/CmOOngXPz/ZLPPDusDfOh8SSkuzajKVGWwaiVYhq9T OqpQ== X-Gm-Message-State: AD7BkJKCTAjQt8Hx0VhE/CpYcq3ev0x9qMcUA8ab2jlFasAq89CIZf0OCP4bwKvOpcC50UXoTwUEF/ZcrD10Bg== MIME-Version: 1.0 X-Received: by 10.140.181.9 with SMTP id c9mr1170019qha.34.1457576396565; Wed, 09 Mar 2016 18:19:56 -0800 (PST) In-Reply-To: <160309144505.ZM11492@torch.brasslantern.com> References: <20160226175937.GA22547@lorien.comfychair.org> <160226114511.ZM17604@torch.brasslantern.com> <8456.1456706752@thecus.kiddle.eu> <160306094154.ZM20831@torch.brasslantern.com> <160309144505.ZM11492@torch.brasslantern.com> Date: Thu, 10 Mar 2016 03:19:56 +0100 Message-ID: Subject: Re: reverse-menu-complete re-starting completion on 5.2? From: Mikael Magnusson To: Bart Schaefer Cc: Zsh workers Content-Type: text/plain; charset=UTF-8 On Wed, Mar 9, 2016 at 11:45 PM, Bart Schaefer wrote: > On Mar 9, 12:41pm, Mikael Magnusson wrote: > } Subject: Re: reverse-menu-complete re-starting completion on 5.2? > } > } On Wed, Mar 9, 2016 at 12:12 PM, Mikael Magnusson wrote: > } > On Mon, Mar 7, 2016 at 3:05 AM, Mikael Magnusson wrote: > } >> On Sun, Mar 6, 2016 at 6:41 PM, Bart Schaefer wrote: > } >>> On Feb 29, 1:45am, Oliver Kiddle wrote: > } >>> } > } >>> } [...] I'm really not sure why we need to be so > } >>> } strict about the completion widget matching the last completion widget. > } >>> > } >>> The only reason I can think of is in case menu completion is invoked from > } >>> within a user-defined widget, or otherwise entered by a different widget > } >>> > } >>> Maybe we'd need another flag action for "zle -f" to continue/interrupt > > Turns out "zle auto-suffix-retain" already serves this purpose. > > This is tricky because widgets created with "zle -C" start directly in > completion context, which means that "zle" generates an error; i.e., if > we naively stick this into _generic: > > _generic:zle:1: widgets can only be called when ZLE is active > > (The error should probably be more specific, since a completion widget is > merely the wrong *kind* of widget.) > > The solution is to make a normal widget for auto-suffix-retain, then invoke > the completion widget with "zle the-widget -w". This seems a bit more work > than should be necessary, but see example below. > > } >> I can tell you I quite often complete a directory name using normal > } >> completion, and then press ctrl-n to complete files inside by latest > } >> modification date. > } > } zstyle ':completion:most-recent-file:*' match-original both > } zstyle ':completion:most-recent-file:*' file-sort modification > } zstyle ':completion:most-recent-file:*' file-patterns '*:all\ files' > } zstyle ':completion:most-recent-file:*' hidden all > } zstyle ':completion:most-recent-file:*' completer _files > } zle -C most-recent-file menu-complete _generic > } > } bindkey "^N" most-recent-file > > Just as-is, this works as you desire if the initial directory completion > is not ambiguous, but cycles if there are multiple possible matches in > the current menu. > > } I would like ^N after TAB to start completion over (even if this was > } originally a ^N completion), but TAB after ^N to continue the same > } completion. > > The following uses the normal-widget-calls-completion trick. There may > be a better name for it. > > -- 8< -- > # Replaces bindkey in the above, otherwise all the same > > complete-most-recent-file () { > [[ $LASTWIDGET != $WIDGET ]] && zle auto-suffix-retain > zle most-recent-file -w > } > zle -N complete-most-recent-file > > bindkey "^N" complete-most-recent-file > -- 8< -- > > If we're OK with this, Oliver's patch can remain, but it's possible that > there are other user-defined widgets that will start behaving unexpectedly. I did it like this, ## Helper function for most-*-file function _complete_separately() { [[ $LASTWIDGET != $WIDGET ]] && zle auto-suffix-retain zle ${WIDGET#complete-} -w } zle -N complete-most-recent-file _complete_separately zle -N complete-most-accessed-file _complete_separately Using accept-search instead of auto-suffix-retain also works, but it eats up the first press without doing anything for some reason (only if a menu is active). I don't think anyone else is likely to figure this out by themselves though :). -- Mikael Magnusson