Command history scrolling after less

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Command history scrolling after less

Paul-7
":<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.

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Gary Johnson-4
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.

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Gary Johnson-4
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Paul-7
On Thu, Feb 14, 2019 at 05:04:17PM -0800, Gary Johnson wrote:
>I found that the problem can be avoided by using the --no-keypad
>option to less, like this:
>
>    :w !less --no-keypad

Nice one :)

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Bram Moolenaar
In reply to this post by Gary Johnson-4

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.

--
DENNIS: You can't expect to wield supreme executive power just 'cause some
        watery tart threw a sword at you!
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Gary Johnson-4
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Command history scrolling after less

Gary Johnson-4
On 2019-02-15, James McCoy wrote:
> On Fri, Feb 15, 2019, 11:13 Gary Johnson wrote:
>
>     On 2019-02-15, Bram Moolenaar wrote:
>     > Gary Johnson wrote:

>     > > 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.

Thanks for the explanation.  I'll try to take a closer look and get
better understanding of just what's going on.

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 [hidden email].
For more options, visit https://groups.google.com/d/optout.