* Re: Starting replace-string minibuffer in Vi command-mode [not found] ` <200603192243.k2JMhcqd027578@pwslaptop.csr.com> @ 2006-03-20 4:24 ` Bart Schaefer 2006-03-20 10:37 ` Peter Stephenson 2006-03-25 19:16 ` Wayne Davison 1 sibling, 1 reply; 4+ messages in thread From: Bart Schaefer @ 2006-03-20 4:24 UTC (permalink / raw) To: zsh-workers On Mar 19, 10:43pm, Peter Stephenson wrote: } } (The discussion probably ought to go on zsh-workers.) Redirected there. } I tried this and it's very annoying... It seems to me } read-from-minibuffer looks to the user like a new command line and } therefore should always start in the "main" keymap, right? I'd think so, yes. I'm not sure that's exactly the right thing in this specific case, but it's closer. } There's no way to do this at the moment Really? What's wrong with the following? vi-read-from-minibuffer() { zle -K viins zle read-from-minibuffer } zle -N vi-read-from-minibuffer } However, this patch is more consistent with the existing "zle -K" Why add a -K option after the widget name rather than allow the widget name to follow the existing -K option and its argument? That is, why do zle read-from-minibuffer -K viins rather than zle -K viins read-from-minibuffer ?? Just curious. It looks like it would be just as easy to call on through to bin_zle_call() from bin_zle_keymap() as to embed a call to selectkeymap() in the former. } Hmmm... making the KEYMAP variable read/write and then making it local } in read-from-minibuffer would do the same thing. Maybe that's more } natural? No, I think your patch is on the right track. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Starting replace-string minibuffer in Vi command-mode 2006-03-20 4:24 ` Starting replace-string minibuffer in Vi command-mode Bart Schaefer @ 2006-03-20 10:37 ` Peter Stephenson 2006-03-20 20:16 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Peter Stephenson @ 2006-03-20 10:37 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > } I tried this and it's very annoying... It seems to me > } read-from-minibuffer looks to the user like a new command line and > } therefore should always start in the "main" keymap, right? > > I'd think so, yes. I'm not sure that's exactly the right thing in this > specific case, but it's closer. As I said, there's room for an extension to select your own main and alternate keymaps similar to vared, but this is the first step. > } There's no way to do this at the moment > > Really? What's wrong with the following? > > vi-read-from-minibuffer() { > zle -K viins > zle read-from-minibuffer > } > zle -N vi-read-from-minibuffer I meant "without rewriting the function", but yes, if you want to alter replace-string that would be fine. > } However, this patch is more consistent with the existing "zle -K" > > Why add a -K option after the widget name rather than allow the widget > name to follow the existing -K option and its argument? That is, why do > > zle read-from-minibuffer -K viins > > rather than > > zle -K viins read-from-minibuffer > > ?? Just curious. It looks like it would be just as easy to call on > through to bin_zle_call() from bin_zle_keymap() as to embed a call to > selectkeymap() in the former. Only because of existing practice... options restricted to the widget (like -n and -N) have tended to come after it. The latter is another possibility. I think I marginally prefer the former anyway, unless you have a strong preference, since the latter looks to me like an additional argument to the keymap-setting function, rather than a widget called in a particular context. Also it's not *so* much easier to do it via bin_zle_keymap(), since you need to restore the keymap afterwards, and you probably want the return status of the widget rather than what zle -K would normally return... but this is all fairly minor. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Starting replace-string minibuffer in Vi command-mode 2006-03-20 10:37 ` Peter Stephenson @ 2006-03-20 20:16 ` Bart Schaefer 0 siblings, 0 replies; 4+ messages in thread From: Bart Schaefer @ 2006-03-20 20:16 UTC (permalink / raw) To: zsh-workers On Mar 20, 10:37am, Peter Stephenson wrote: } } > Why add a -K option after the widget name rather than allow the widget } > name to follow the existing -K option and its argument? } } Only because of existing practice... options restricted to the widget } (like -n and -N) have tended to come after it. Yeah, but -n and -N emulate things the user can pass to the widget with other ZLE controls, whereas there's no keymap-selection equivalent of universal-argument. (I suppose there could be, though. Hmm.) } I think I marginally prefer the former anyway, unless you have a } strong preference I don't. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Starting replace-string minibuffer in Vi command-mode [not found] ` <200603192243.k2JMhcqd027578@pwslaptop.csr.com> 2006-03-20 4:24 ` Starting replace-string minibuffer in Vi command-mode Bart Schaefer @ 2006-03-25 19:16 ` Wayne Davison 1 sibling, 0 replies; 4+ messages in thread From: Wayne Davison @ 2006-03-25 19:16 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers On Sun, Mar 19, 2006 at 10:43:38PM +0000, Peter Stephenson wrote: > + zwarnname(name, "keymap expected after -%c", NULL, **args); This should have been a call to zwarnnam(). I've checked in a fix. ..wayne.. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-03-25 19:17 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <dbfc82860603181539u10dd337dl10e21e352b6bcf4d@mail.gmail.com> [not found] ` <200603192243.k2JMhcqd027578@pwslaptop.csr.com> 2006-03-20 4:24 ` Starting replace-string minibuffer in Vi command-mode Bart Schaefer 2006-03-20 10:37 ` Peter Stephenson 2006-03-20 20:16 ` Bart Schaefer 2006-03-25 19:16 ` Wayne Davison
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).