Re: Command history scrolling after less

On 2019-02-14, Gary Johnson wrote:
> On 2019-02-14, Paul wrote:
> > ":<up>" normally scrolls through command history. However, after
> > I pipe the buffer to less, that no longer happens. With or without
> > any LESS* environment variables set:
> >
> > 1. vim -Nu NONE
> > 2. :<up> " Fine
> > 3. <esc> " To cancel the scrolling from step 2
> > 4. :w !less
> > 5. Press "q", "enter", or whatever to get back to Vim
> > 5. :<up> " Not fine, back to normal mode
> >
> > This doesn't appear to be an issue in gvim, nor does it happen
> > when piped to more or cat instead of less, so I'm wondering if
> > this is a less issue rather than a vim one.
>
> I can reproduce this using:
>
> Vim 8.1.865
> less 481
> GNOME Terminal 2.32.0
>
> Also, when I exit vim with :q, the screen is not cleared.
>
> Less seems to redefine the escape sequences coming from the arrow
> keys. Before executing ":w !less" in the above demonstration,
> I entered insert mode and typed ^V before typing each of the arrow
> keys, in the order <Up>, <Down>, <Right>, <Left>. The result was
>
> ^[OA^[OB^[OC^[OD
>
> where ^[ is Vim's representation of <Esc>. After executing ":w
> !less" and quitting less, the result of inserting the same key
> sequence was
>
> ^[[A^[[B^[[C^[[D
>
> I also reproduced the problem with a few combinations of Vim
> 7.3.315, less 436, xterm 261 and xterm 322 as well as the versions
> above.

I did some investigation using strace and discovered that less
writes the following escape sequences to stdout. Note that I have
expanded them, inserting spaces and newlines for clarity. I decoded
them with the aid of /usr/share/doc/xterm/ctlseqs.txt.gz.

\33[ ?1049h Save cursor and use Alternate Screen Buffer,
clearing it first.
\33[ 22;0;0t Save xterm icon and window title on stack.
\33[ ?1h Application Cursor Keys
\33= Application Keypad
\r

\r
\33[ K Erase to the right.
\33[ 7m Character Attributes: Inverse
(END)
\33[ 27m Character Attributes: Not Inverse
\33[ K Erase to the right.

\r
\33[ K Erase to the right.
\33[ ?1l Normal Cursor Keys
\33> Normal Keypad
\33[ ?1049l Use Normal Screen Buffer and restore cursor.
\33[ 23;0;0t Restore xterm icon and window title from stack.

I found that the problem can be avoided by using the --no-keypad
option to less, like this:

:w !less --no-keypad

The less(1) man page says that --no-keypad:

Disables sending the keypad initialization and deinitialization
strings to the terminal. This is sometimes useful if the
keypad strings make the numeric keypad behave in an undesirable
manner.

I verified by running strace again that with that option, less does
not write these:

\33[ ?1h Application Cursor Keys
\33= Application Keypad

\33[ ?1l Normal Cursor Keys
\33> Normal Keypad

My guess is that Vim is swallowing the Normal Cursor Keys command.

I'm cc'ing the vim_dev list because I think that this may be a bug
in Vim and that further discussion belongs there.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.