From: Peter Stephenson <pws@csr.com>
To: zsh-workers@sunsite.dk
Subject: Re: Starting replace-string minibuffer in Vi command-mode
Date: Mon, 20 Mar 2006 10:37:30 +0000 [thread overview]
Message-ID: <EXCHANGE03kP1zJ2amn000012ac@exchange03.csr.com> (raw)
In-Reply-To: <060319202425.ZM5142@torch.brasslantern.com>
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
next prev parent reply other threads:[~2006-03-20 10:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <dbfc82860603181539u10dd337dl10e21e352b6bcf4d@mail.gmail.com>
[not found] ` <200603192243.k2JMhcqd027578@pwslaptop.csr.com>
2006-03-20 4:24 ` Bart Schaefer
2006-03-20 10:37 ` Peter Stephenson [this message]
2006-03-20 20:16 ` Bart Schaefer
2006-03-25 19:16 ` Wayne Davison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EXCHANGE03kP1zJ2amn000012ac@exchange03.csr.com \
--to=pws@csr.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).