From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16190 invoked from network); 3 Apr 2003 13:21:12 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 3 Apr 2003 13:21:12 -0000 Received: (qmail 19614 invoked by alias); 3 Apr 2003 13:20:46 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6005 Received: (qmail 19602 invoked from network); 3 Apr 2003 13:20:46 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 3 Apr 2003 13:20:46 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [62.189.183.235] by sunsite.dk (MessageWall 1.0.8) with SMTP; 3 Apr 2003 13:20:45 -0000 Received: from exchange01.csr.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 3 Apr 2003 14:29:08 +0100 Received: from csr.com (tinky-winky.csr.com [192.168.144.127]) by exchange01.csr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H5TX1A7Q; Thu, 3 Apr 2003 14:19:49 +0100 To: zsh-users@sunsite.dk Subject: Re: is there way to use vicmd (not viins) layout initially? In-reply-to: "Ilya Kuznecov"'s message of "Thu, 03 Apr 2003 17:00:59 +0500." <20030403120059.GA5325@r3_kuznecov.lan.blok-caf.ru> Date: Thu, 03 Apr 2003 14:20:42 +0100 Message-ID: <4898.1049376042@csr.com> From: Peter Stephenson Ilya Kuznecov wrote: > As far as I know, this is only viins mode by default. Do I fail? You probably *should* be able to do this: zle -A vicmd main Unfortunately, if you do that, although the shell starts in vicmd mode, you can't get into viins mode, because the code which implements `vi-insert' switches to the main keymap, i.e. in this case straight back to vicmd. This is actually documented, but I'm not sure if it's necessary. You can get round it with: vi-insert() { zle -K viins; } zle -N vi-insert but unfortunately you need to rewrite every widget that switches to insert mode (those bound to I, a, A, c, etc. etc.) in a similar fashion. What does everyone think about tying vi-insert to switching to viins, rather than `main' (and other logically related changes)? This would need changes in the documentation, too. Note there's nothing to stop you copying another keymap onto viins, so I don't think this stops you doing anything you might want to. I think the problem comes with the vi-cmd-mode binding in Emacs mode. In this case, `i' or whatever will put you into vi insert mode, not back to Emacs mode. But that seems to me to be exactly what is documented: vi-insert (unbound) (i) (unbound) Enter insert mode. --- nothing about returning to the main keymap. You can write a widget to switch the keymap. main-map() { zle -K main; } zle -N main-map bindkey -M vicmd 'M' main-map then i etc. still do what are documented, but 'M' returns you to the main keymap. This seems to me more useful and predictable than the current arrangement. If there's deathly silence I won't dare change this. Index: Src/Zle/zle_vi.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_vi.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 zle_vi.c --- Src/Zle/zle_vi.c 3 Jul 1999 13:18:04 -0000 1.1.1.9 +++ Src/Zle/zle_vi.c 3 Apr 2003 12:57:32 -0000 @@ -89,7 +89,7 @@ startvitext(int im) { startvichange(im); - selectkeymap("main", 1); + selectkeymap("viins", 1); undoing = 0; viinsbegin = cs; } @@ -98,7 +98,7 @@ int vigetkey(void) { - Keymap mn = openkeymap("main"); + Keymap mn = openkeymap("viins"); char m[3], *str; Thingy cmd; @@ -351,7 +351,7 @@ if ((c2 = getvirange(1)) != -1) { ret = 0; forekill(c2 - cs, 0); - selectkeymap("main", 1); + selectkeymap("viins", 1); viinsbegin = cs; undoing = 0; } ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************