From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18124 invoked by alias); 31 Dec 2010 08:28:39 -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: 28560 Received: (qmail 23887 invoked from network); 31 Dec 2010 08:28:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <101231002820.ZM7583@torch.brasslantern.com> Date: Fri, 31 Dec 2010 00:28:20 -0800 In-reply-to: Comments: In reply to Wayne Davison "Overriding a yank* widget in zle" (Dec 30, 1:59pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Overriding a yank* widget in zle MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 30, 1:59pm, Wayne Davison wrote: } } I've coded up a patch that adds the -y option to zle so that I can define a } "zle -Ny yank" widget (as well as yank-pop), which marks it as being a } ZLE_YANK equivalent. This sort of follows from "zle -C". For completion widgets, it was recognized that there are a set of behaviors which are the model for any newly-added widget, and the builtin completion widgets provide names for those behaviors. Perhaps a general solution would be that for *any* widget, not just a completion one, it should be possible to name a "prototype" widget whose behavior the new widget is intended to simulate or replace. "zle -P WIDGET PROTOTYPE-WIDGET [FUNCTION]" where "zle -N ..." becomes a special case equivalent to "zle -P WIDGET self-insert FUNCTION", or something to that effect (or maybe undefined-key instead). Then one could write, e.g., zle -P history-search-sideways history-incremental-search-forward and zle would "know" to invoke the minibuffer and re-call the function as each new keystroke is typed, without that needing to be coded as a loop in the widget itself. Then the question would be whether we still need "zle -C ..." other than for backward compatibility. The only other solution to this that I've thought of would be to follow the example of the auto-suffix-remove and auto-suffix-retain widgets, that is, have a special widget whose only effect is to have the side- effect of enabling yank-pop on the next interaction: yank-pop-enable perhaps (is yank-pop-disable ever needed?).