zsh-workers
 help / color / mirror / code / Atom feed
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


  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).