[Toybox] Fwd: hexedit uses VT-420 scroll ctrl sequences which dont work on tty1

[Rob Landley]

On 9/25/19 1:59 PM, Jarno Mäkipää wrote:
> On Wed, Sep 25, 2019 at 8:23 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 9/24/19 1:18 AM, Jarno Mäkipää wrote:
>>> Hi
>>>
>>> I now tested to run hexedit in tmux: downscroll works but upscroll does not...
>>> Well we might say its tmux fault, but lots of people use tmux nowadays.
>>> And this behavior seemed to be same in framebuffer console and xterms...
>>
>> I have a todo item to write a screen for toybox. I'll make sure this works
>> there. If you want to submit a bug report to the old one, have at.
>>
>> No, I am not redrawing the screen every time you scroll up. If hexedit isn't
>> usable in some broken environments, I'm ok with that.
>>
>> Rob
> 
> Well my original intention was to ask is it ok to use S and T escapes in vi

If hexedit is doing it, there's precedent. It won't be _more_ broken than hexedit.

(This is all software parsing these escape sequences, and software can be fixed.)

> Running hexedit inside gnu screen seems to fix scrolling everywhere I
> tested, and ironically tmux sets up $TERM=screen and breaks
> functionality even inside xterm.

We're not reading $TERM, we're just emitting the same ANSI-ish escape sequences
each time. Our behavior should be consistent, the question is what the behavior
of the term program parsing us is. (It's always a program these days, it hasn't
been a mechanical "terminal" since there were actual VT100 (introduced august
1978 discontinued october 1985) and TN3270 (1983-1987) devices connected to a
real computer via serial port.)

> Perhaps I try to figure is there any other way to scroll up without
> drawing whole page every line moved...

If you find one, let me know. That's the one that was documented in the Linux
man page.

> -Jarno

Rob