Starting replace-string minibuffer in Vi command-mode

Starting replace-string minibuffer in Vi command-mode

[Nikolai Weibull]

Hi!

I like having the replace-string function, but as I invoke it from Vi
command-mode (through a binding to ":s") the minibuffer will also be
in Vi command-mode when I'm expecting Vi insert-mode.  Is there a way
to get around this?  Is there even a way to do it with the current
implementation of read-from-minibuffer/"zle recursive-edit"?

Thanks.

  nikolai

Re: Starting replace-string minibuffer in Vi command-mode

[Peter Stephenson]

"Nikolai Weibull" wrote:
> I like having the replace-string function, but as I invoke it from Vi
> command-mode (through a binding to ":s") the minibuffer will also be
> in Vi command-mode when I'm expecting Vi insert-mode.  Is there a way
> to get around this?  Is there even a way to do it with the current
> implementation of read-from-minibuffer/"zle recursive-edit"?

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?

There's no way to do this at the moment, but it's very easy to add an
option to zle that temporarily sets the keymap for the duration of the
widget.  It would be possible to set and restore the keymap inside
read-from-minibuffer, but setting and restoring is one of the things
that's easier in the C code: no exception handling is required, so
there's less chance of the user getting stuck with the wrong keymap.
(Compare the -M and -m options to vared to set the main and alternative
keymaps for the call:  that could usefully be added to recursive-edit,
too.)

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?  However, this patch is more consistent with the existing "zle
-K", and, given that KEYMAP can change under your feet (because it's
usually set in other ways), saving and restoring it using parameter
scope is fraught with difficulty.  So I think I prefer this patch.
(The discussion probably ought to go on zsh-workers.)

Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.49
diff -u -r1.49 zle.yo
--- Doc/Zsh/zle.yo	28 Jan 2006 15:02:26 -0000	1.49
+++ Doc/Zsh/zle.yo	19 Mar 2006 22:34:38 -0000
@@ -332,7 +332,7 @@
 xitem(tt(zle) tt(-K) var(keymap))
 xitem(tt(zle) tt(-F) [ tt(-L) ] [ var(fd) [ var(handler) ] ])
 xitem(tt(zle) tt(-I))
-item(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
+item(tt(zle) var(widget) tt([ -n) var(num) tt(]) tt([ -N ] [ -K) var(keymap) tt(]) var(args) ...)(
 The tt(zle) builtin performs a number of different actions concerning
 ZLE.
 
@@ -529,7 +529,7 @@
 notification.  To test if a zle widget may be called at this point, execute
 tt(zle) with no arguments and examine the return status.
 )
-item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ]) var(args) ...)(
+item(var(widget) tt([ -n) var(num) tt(]) tt([ -N ] [ -K) var(keymap) tt(]) var(args) ...)(
 Invoke the specified widget.  This can only be done when ZLE is
 active; normally this will be within a user-defined widget.
 
@@ -538,6 +538,10 @@
 sets the numerical argument temporarily to var(num), while `tt(-N)' sets it
 to the default, i.e. as if there were none.
 
+With the option tt(-K), var(keymap) will be used as the current keymap
+during the execution of the widget.  The previous keymap will be
+restored when the widget exits.
+
 Any further arguments will be passed to the widget.  If it is a shell
 function, these are passed down as positional parameters; for builtin
 widgets it is up to the widget in question what it does with them.
Index: Src/Zle/zle_thingy.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_thingy.c,v
retrieving revision 1.24
diff -u -r1.24 zle_thingy.c
--- Src/Zle/zle_thingy.c	9 Mar 2006 09:44:28 -0000	1.24
+++ Src/Zle/zle_thingy.c	19 Mar 2006 22:34:38 -0000
@@ -642,7 +642,7 @@
     Thingy t;
     struct modifier modsave = zmod;
     int ret, saveflag = 0;
-    char *wname = *args++;
+    char *wname = *args++, *keymap_restore = NULL, *keymap_tmp;
 
     if (!wname)
 	return !zle_usable();
@@ -680,6 +680,18 @@
 		zmod.mult = 1;
 		zmod.flags &= ~MOD_MULT;
 		break;
+	    case 'K':
+		keymap_tmp = args[0][1] ? args[0]+1 : args[1];
+		if (!keymap_tmp) {
+		    zwarnname(name, "keymap expected after -%c", NULL, **args);
+		    return 1;
+		}
+		if (!args[0][1])
+		    *++args = "" - 1;
+		keymap_restore = dupstring(curkeymapname);
+		if (selectkeymap(keymap_tmp, 0))
+		    return 1;
+		break;
 	    default:
 		zwarnnam(name, "unknown option: %s", *args, 0);
 		return 1;
@@ -693,6 +705,8 @@
     unrefthingy(t);
     if (saveflag)
 	zmod = modsave;
+    if (keymap_restore)
+	selectkeymap(keymap_restore, 0);
     return ret;
 }
 
Index: Functions/Zle/read-from-minibuffer
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/Zle/read-from-minibuffer,v
retrieving revision 1.4
diff -u -r1.4 read-from-minibuffer
--- Functions/Zle/read-from-minibuffer	30 Jul 2004 11:09:20 -0000	1.4
+++ Functions/Zle/read-from-minibuffer	19 Mar 2006 22:34:38 -0000
@@ -33,7 +33,7 @@
   read -k $keys
   stat=$?
 else
-  zle recursive-edit
+  zle recursive-edit -K main
   stat=$?
   (( stat )) || REPLY=$BUFFER
 fi

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/

Re: Starting replace-string minibuffer in Vi command-mode

[Bart Schaefer]

On Mar 19, 12:39am, Nikolai Weibull wrote:
}
} I like having the replace-string function, but as I invoke it from Vi
} command-mode (through a binding to ":s") the minibuffer will also be
} in Vi command-mode when I'm expecting Vi insert-mode.

My first thought when I saw this was "if what you really want is vi,
why is replace-string good enough?"

E.g.,

    autoload -U edit-command-line
    ex-mode() { VISUAL=ex edit-command-line }
    zle -N ex-mode
    bindkey -M vicmd : ex-mode

Unfortunately I find that vim is seriously brain-damaged in ex mode.
It switches to the alternate screen in an xterm (which seems silly),
and even if given TERM=dumb it comes up in no-echo mode so you can't
see what you're typing (which must have something to do with calling
it from inside zle, but I haven't yet figured out what).

} Is there even a way to do it with the current implementation of
} read-from-minibuffer/"zle recursive-edit"?

In the absence of Peter's patch, I think this will do it:

    autoload -U replace-string
    vi-replace-string() {
      zle -K viins
      replace-string
    }
    zle -N vi-replace-string
    bindkey -M vicmd :s vi-replace-string