From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25126 invoked by alias); 17 Sep 2014 01:14:16 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33191 Received: (qmail 25018 invoked from network); 17 Sep 2014 01:14:13 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 From: Frank Terbeck To: Mica Chimera Cc: zsh-workers@zsh.org Subject: Re: bug report In-Reply-To: (Mica Chimera's message of "Tue, 16 Sep 2014 19:26:01 -0500") References: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.93 (gnu/linux) Date: Wed, 17 Sep 2014 03:08:27 +0200 Message-ID: <874mw72gvo.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Df-Sender: NDMwNDQ0 Hello Mica, Mica Chimera wrote: > Strange behavior when using vi editor mode. > It goes something like this, with "|" being cursor: > > %: bindkey -v > %: mv /some/file /some/other/file > commands: Bi > %: mv /some/file |/some/other/file > > At this point I can type in new stuff just fine, and up to the point > where I reentered insert mode, but anything earlier than that beeps and > doesn't delete. This is the behaviour of the original vi, which vi-mode is loosely based on. You can always rebind to =E2=80=98backward-delete-char=E2=80=99 if you = prefer. > Stranger still is when I > > %: mv /some/file /SOME/OTH|er/file > > Changes it to caps. This on the other hand is just a lack of understanding of how terminals work. I'll try to give a brief explanation of what's going on: Special keys, like DELETE or INSERT or the PageUp key, are encoded by terminals as so called escape sequences. (All of this stems from the fact that "terminals" are actually programs that emulate ancient hardware that exchanged characters with a host via serial links. Colours, for example, are encoded by escape sequences as well.) In my terminal, pressing the DELETE key sends four bytes, namely: ESC [ 3 ~ If that sequence is not bound to a widget (which it is not by default), ZLE (zsh's line editor) executes the actions associated with the individual characters. ESC would change back to normal mode; [ would do nothing by default; and "3 ~" would toggle the capitalisation of the next three characters. That would be the case with you, as well. Only that there appears to be a larger integer in front of the tilde. Like I said "If that sequence is not bound to a widget". You can bind it to a widget, like this: bindkey '^[[3~' delete-char But the problem with that is, that different terminals use different sequences for this kind of stuff. Debian's new zsh packages include a few lines of configuration code that bind a few common special keys to widgets automatically by looking at the terminal's terminfo database entry=C2=B9. If you're interested, the code resides in: http://anonscm.debian.org/cgit/collab-maint/zsh.git/tree/debian/zshrc And the lines you would be looking for are the ones from line 18 up to and including line 91. You could fix your issue with the BackSpace key in one go by changing line 54 of that file from bind2maps viins -- BackSpace vi-backward-delete-char to: bind2maps viins -- BackSpace backward-delete-char (=E2=80=98bind2maps=E2=80=99 is a simple function defined in that file, tha= t wraps around =E2=80=98bindkey=E2=80=99.) > I'm using version 5.0.6 and have reproduced the error on multiple x86_64 > machines with default configuration. > > Since no one else seems to be reporting this bug and it's so severe I > figure it's likely there's something I just don't get. If that's the case > I'm sorry for all the trouble, but can you let me know what's happening? No worries. This is quite the common source of confusion. Regards, Frank =C2=B9 There are other attempts of handling special keys, like zkbd, but I'm pretty convinced, that the approach used in that setup is quite robust for most terminals and the most common of keys. Anything beyond is usually very much more terminal-specific. --=20 In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925