Re: Command history scrolling after less

On 2019-02-15, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > 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.
>
> Well, I would think less is to blame to change the escape sequences and
> not restore it. Vim figures out what codes the cursor keys are sending,
> it's not really supposed to check every time an external command was
> executed, right?
>
> You can work around it by adding the Keypad code to t_ks, this will be
> output after an external command is finished.

If I understand the strace output correctly, less _is_ attempting to
restore the escape sequences. Don't the "Normal Cursor Keys" and
"Normal Keypad" sequences restore the effects of the "Application
Cursor Keys" and "Application Keypad" sequences? If less wasn't
properly restoring the escape sequences, wouldn't the cursor keys be
messed up every time less is run, not just when Vim pipes to it?

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.