From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10862 invoked from network); 3 Nov 2008 17:35:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 3 Nov 2008 17:35:21 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 29369 invoked from network); 3 Nov 2008 17:35:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 3 Nov 2008 17:35:13 -0000 Received: (qmail 13926 invoked by alias); 3 Nov 2008 17:35:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25996 Received: (qmail 13916 invoked from network); 3 Nov 2008 17:35:08 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 3 Nov 2008 17:35:08 -0000 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1AFBA80524C0 for ; Mon, 3 Nov 2008 18:35:04 +0100 (CET) Received: by ug-out-1314.google.com with SMTP id 36so1833088ugg.18 for ; Mon, 03 Nov 2008 09:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2wWNtUpGM6Kqdwe15FYnXiThtPV7dbavT7YowcxqjBU=; b=mxbtG2yVSfi4u1sRJj28SJp3AKIRdLk+7lMeeIJhDLyFJN/LvHj753VnDqbrrt9gob +P4zyF3IxMuup9gHlfiQ3b2r8wDajSogG9BjNi2f897IQGjL96xxkU4u3tRtjqu7/CbZ LGerNlfZAUr+r6Xm3P5fH4G0E/1+/lIa/JJ3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=gz7SQNJYfMDsZD86wtERVK8gJPQ9GbSeCN0akbHVuEXAWps+AbCPH1/X+TeIWT6PwQ 8Hf0agbU72n0CfeZJ6678ZvhE5J8eSaNC0pS4i8rlYWbuXkrk5ER7J9x1GfS1YxcuCxy twZ+GwX2IU4KgK+aisrwLlUdwcb/nVW/+kKnY= Received: by 10.86.80.5 with SMTP id d5mr349214fgb.47.1225733704332; Mon, 03 Nov 2008 09:35:04 -0800 (PST) Received: from ?192.168.1.11? (AMontsouris-159-1-10-231.w83-202.abo.wanadoo.fr [83.202.165.231]) by mx.google.com with ESMTPS id e20sm8872827fga.1.2008.11.03.09.35.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 09:35:03 -0800 (PST) Message-ID: <490F3638.4000706@gmail.com> Date: Mon, 03 Nov 2008 18:34:48 +0100 From: Matthieu Louvel de Monceaux User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Peter Stephenson , Stephane Chazelas , zsh-workers@sunsite.dk Subject: Re: Weird Vi-mode behavior References: <490EED78.8010802@gmail.com> <200811031237.mA3Cb2VS013961@news01.csr.com> <20081103125609.GA4855@sc.homeunix.net> In-Reply-To: <20081103125609.GA4855@sc.homeunix.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8559/Mon Nov 3 17:41:26 2008 on bifrost X-Virus-Status: Clean Stephane Chazelas wrote: > On Mon, Nov 03, 2008 at 12:37:02PM +0000, Peter Stephenson wrote: > >> Matthieu Louvel de Monceaux wrote: >> >>> When we return from command mode to insert mode, we can't modify >>> the text from the beginning to the spot where we got insert ... >>> Definitely a weird behavior ... >>> >>> To get it too, just type 'foo folk x' for example. >>> Then Esc, type 'b' to go to the previous word, then press 'i' to go >>> insert mode. >>> Now you can't edit the 'foo ' part anymore. >>> >> I'm sorry, I don't understand. >> > [...] > > I suspect he is refering to the traditional vi behavior of > vi-backward-delete-char documented in "info zsh 'Modifying > Text'" > > vi-backward-delete-char (unbound) (X) (^H) > Delete the character behind the cursor, without changing lines. > If in insert mode, this won't delete past the point where insert > mode was last entered. > > So I suspects he wants instead: > > if (($+terminfo[kbs])); then > bindkey -M viins $terminfo[kbs] backward-delete-char > else > bindkey -M viins '^?' backward-delete-char > bindkey -M viins '^H' backward-delete-char > fi > (($+terminfo[kdch1])) && > bindkey -M viins $terminfo[kdch1] delete-char > > > The above trys to map the emacs-style (as opposed to vi style) > backward-delete-char to the character sent by the backspace key > (using the terminfo database if it's there, or hardcoding both > ^? and ^H). It also maps delete-char to the character sent by > the delete key if the terminfo database has that information. > Note that on a number of terminals, backspace sends ^H and > delete ^? while in a number of others backspace sends ^? and > delete something else like the sequence \e[3~ > > Thank you for your nice piece of information. You want me to put those bindings in my zshrc file ? But i don't understand that : (($+terminfo[kdch1])) && You said that it maps delete-char to the char sent by the delete key. Is it the role of the '&&' ? M. Louvel de Monceaux