From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5484 invoked by alias); 5 Nov 2013 15:57:25 -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: X-Seq: 18094 Received: (qmail 7707 invoked from network); 5 Nov 2013 15:57:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 From: Bart Schaefer Message-id: <131105075700.ZM18043@torch.brasslantern.com> Date: Tue, 05 Nov 2013 07:57:00 -0800 In-reply-to: Comments: In reply to Thiago Padilha "Re: Fish-like autosuggestions" (Nov 4, 5:30pm) References: <131030092555.ZM8077@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh-Users List Subject: Re: Fish-like autosuggestions MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 4, 5:30pm, Thiago Padilha wrote: } } I would also use the following arguments to } defend the security of the model: Thanks for the summary; as I said I handn't looked closely. I was thinking of the doc for tcp_proxy: caution should be taken as there is no security whatsoever and this can leave your computer open to the world. Ideally, it should only be used behind a firewall. } I've been playing with keymap+widget but I'm still deciding whether it is } the best solution for the following reasons: } } - I'm only using recusive-edit because I couldn't do asynchronous updates } to the zle RBUFFER using 'zle -F'(I started from the 'predict-on' code) Hmm; so the trick here is that if you start recursive-edit, then when the zle -F handler executes the special parameters from the surrounding (original) ZLE context are still defined in the handler? I'm pretty sure this is an unintentional side-effect of recursive-edit, and now that you've pointed it out we need to decide whether there is (a) any reason this shouldn't continue to work, or (b) whether it ought to be necessary, i.e., why the handlers can't always have ZLE context. } - Sometimes I have to deactivate the autosuggestions feature and } consequently some of the widget hooks(eg: editing the middle of the line or } in vi normal mode) If deactivation is accomplished by changing a key binding, then this will "just happen" for e.g. vi mode when the vicmd keymap replaces the one used by recursive-edit. If it's deactivated another way, keymap+widget won't help, but won't hurt either. } With the current issues in mind I have a few more questions: } } - Is it possible to update the zle RBUFFER from outside a widget? Only with "print -z" which still requires "zle get-line" at some point later. } ... is there a way to enter zle's context from a hook set with 'zle -F' ? I don't think so, but PWS may know better. } - Can the keymap+widget feature be used outside recursive-edit? Yes, as long as you created the keymap with "bindkey -N newkeymap main" after initializing keymap+widget, switching to that keymap will invoke the widgets whose names are prefixed with the keymap name. (It won't work for other keymaps like vicmd without extra effort, nor for any of the "special" keymaps like menuselect.) recursive-edit is just a convenient way to semi-automaticall push/pop keymaps. } ... if thats the case I can simply switch } keymaps with 'zle -K [keymap]' whenever I need a set of widget hooks to be } active right? Yes. } - Whats the best way to modify RBUFFER before a completion widget is } executed? I've tried the comppostfuncs but the RBUFFER variable is } read-only in that context. (comppostfuncs would modify the buffer after the completion widget was executed.) It might depend on what you're doing to RBUFFER but the only general way I can think of is to start off with a normal widget and then call the desired widget from inside it with "zle completion-widget-name". If you start out in a widget defined with "zle -C" all of the normal widget variables are already read-only and you can only affect RBUFFER by changing what gets passed to compadd.