On Fri, Feb 15, 2019, 11:13 Gary Johnson <[email protected] wrote: > 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? >
The problem is that less is "restoring" the wrong values. Vim will have already changed to Application Cursor/Keypad, so when less sets them to Normal, the terminal is now sending different sequences than when vim started. Cheers, James > -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
