Wayland smooth scrolling?

[fuzzy7k]

I have been using the kgx, Kings Cross, terminal with smooth scrolling on mobile. It is quite nice, but I have found pagers to be a QoL setback.

For this reason, I have set PAGER=cat when using kgx. This is ok, but I lose the features of less, and for large outputs, my scrollback buffer gets obliterated.

Just wondering if any thought has been put into wayland support. For the most part, I believe terminal programs should be exempt from this. However, scrolling through text is the domain of a pager and on a touch screen, smooth is way more natural. Maybe this should be a new project, but having a full featured pager just work, regardless of whether I'm in ssh, using a keyboard, or on a touchscreen would be ideal.

Anyway, just throwing this idea out into the ether as a feature request.

[gwsw]

I'd never heard of wayland before, and after doing a little reading, I'm still not sure I understand what wayland is, what "smooth scrolling" is, or what this issue is requesting. Can you give a little more detail about what changes you envision would be necessary for "wayland support"?

[polluks]

I suppose https://en.wikipedia.org/wiki/Wayland_(protocol) and https://flak.tedunangst.com/post/terminal-smooth-scrolling. However smooth scrolling should only be part of the terminal...

[gwsw]

Ok, I still don't see how wayland affects anything that less does. The protocol used by the display server seems far behind the scenes from less's point of view. As far as smooth scrolling, is it just a question of sending a particular escape sequence like \e[4?h during initialization? You can do that today by editing your terminfo entry, or setting the LESS_TERMCAP_ti variable appropriately. The former seems better since it would enable smooth scrolling in all programs that use terminfo, not just less.

[fuzzy7k]

Thank you for that, but I don't think so? I looked up the ti code in man terminfo and found:

enter_ca_mode               smcup     ti     string to start programs using cup

That did not explain much to me so I searched for cup:

cursor_address              cup       cm     move to row #1 columns #2

Are these two related ‾\_(ツ)_/‾ Maybe it is short for CUsor Put?

Anyway, the kgx terminal has the value smcup=\E[?1049h\E[22;0;0t. With your use of the term smooth scrolling, do you mean line by line scrolling?

To try to be more relative with what I am after, given that less supports mouse scrolling, the desired outcome would be to replace the mouse wheel, which produces clicks, or button events, with touch input events, which are an order of magnitude more that those produced by a mouse wheel. If you have ever scrolled through a web page on a touch screen, that is smooth scrolling. It is perceived almost analog compared to the digital line by line scrolling that is achieved with a mouse. It is pixel by pixel vs line by line.

I see two theoretical possibilities. One, assuming that the terminal is the only one who can interpret touch events, it would trigger a line scroll event appropriate for the current finger position, how would be TBD. That option would be an improvement, but scrolling would not be smooth.

The other possibility that I see would be to subvert the terminal, and have less create it's own wayland client over the existing terminal. This way, less would own the touch input and be able to interpret it properly to do things like momentum scrolling. I realize that this would be a radical change. Given your unfamiliarity with wayland I would not ask you to take this on, but merely ask your willingness to allow such code into your project.

However smooth scrolling should only be part of the terminal...

From an architectural status quo point of view I see why you would say that. However, smooth scrolling is arguably more beneficial to a pager than a terminal so I debate the use of the word should.

[gwsw]

Based on https://flak.tedunangst.com/post/terminal-smooth-scrolling that polluks linked to, I got the impression that smooth scrolling is a terminal feature that can be enabled via an escape sequence (that page says it's \e[4?h. My point in mentioning the "ti" termcap entry is that you could add the smooth scroll enable sequence to your "ti" termcap entry ("smcup" terminfo), since less emits that sequence at startup.

However your mention of touch events seems to suggest that that's not what you're looking for. Perhaps some terminals have support for touch events, but I haven't found such a thing yet. The idea of sub-line scrolling seems problematic in less, since it doesn't scroll the whole screen. Would it be possible to have the body of the document scrolled so that, say, half of the last line is visible (the other bottom half vertically scrolled off screen) but the status line below that is still fully visible? I have a hard time envisioning how that would work.

I would be reluctant to add a lot of wayland-specific code into less. If it's a small piece of code, perhaps, but it sounds like it would be a completely different terminal handling architecture residing in parallel with the existing architecture. That would be difficult to maintain going forward as bugs are fixed and new features are added. It seems like a lot of ongoing difficulty to support a merely cosmetic feature.

[fuzzy7k]

I see, yes, not the same smooth scrolling that is implemented in kgx. I shall refer to it as touch scrolling now. Looking through some of the authors other posts, it appears that he implemented that ill supported terminal feature himself in his own terminal, vertigo.

However your mention of touch events seems to suggest that that's not what you're looking for.

Indeed, the touch data is needed to know how far & how fast to move the text.

Perhaps some terminals have support for touch events, but I haven't found such a thing yet.

As far as I know, kgx was the first terminal to support touch scrolling, being used primarily in Phosh. But kgx is being renamed to gnome-console and will be the default in gnome as well.

The idea of sub-line scrolling seems problematic in less, since it doesn't scroll the whole screen. Would it be possible to have the body of the document scrolled so that, say, half of the last line is visible (the other bottom half vertically scrolled off screen) but the status line below that is still fully visible? I have a hard time envisioning how that would work.

I don't doubt that it would be problematic. For the sake of discussion though, the idea in wayland is that everything is a buffer, and applications are responsible for updating their buffers. So, the status line could be one buffer, the body of text another. The real chore, I imagine, would be in doing some of the things that the terminal is usually responsible for. This sounds like a non-starter. Though, I was surprised to find that kgx weighs less than less.

172K /usr/bin/less 116K /usr/bin/kgx

I don't disagree with your reluctance. I was reluctant to ask in the first place. I did only because less seems to be the default everywhere that I see. So, I inquired here by default. Given it's name, I suppose it would be sacrilegious to implement such support.

It probably makes more sense to add pager functionality to a terminal that can speak wayland protocols and already do touch scrolling. But then, it would seem that the pager would need to be reinvented for each new terminal wishing to take advantage of that. Seems like fragmentation of such a basic thing, probably leading to reduced features.

The other option is to create a wayland speaking pager, and re-implement those terminal features required for things like keyboards and tmux to work. That almost sounds like more work, given the heavier size of less.

I would not call it merely cosmetic though. Maybe if a keyboard is all you have, yes. Though, swiping fast to move through large amounts of text is quite handy. Trying to live without that on a touch only device feels archaic and dis-functional.

[gwsw]

I would think the "normal" way to add touch support would be similar to the way that mouse support was added: an escape sequence would enable "touch reporting" and then the terminal would send escape sequences reporting the position of touches. In fact, touch reporting seems like it would be very similar if not identical to mouse reporting. I'd be surprised if there aren't already terminals which support touch events using the exact same format as mouse events.

[gwsw]

FYI I have added support for mouse dragging in 4c86653bb7fe5fd18781ce1c06c6938a33306bb7 in the post659 branch. If your terminal treats touch events as mouse events, this would allow you to scroll by dragging with your finger.

[avih]

For what it's worth, I don't know how much it's worth adding touch-drag (or mouse-drag) in "less". Even if this is maintainable in its current form, the next request would surely be to have (configurable) momentum after the touch is released like mobile scroll elsewhere (which is a real pandora's box, just look at the decade where android couldn't get it right despite it being its main UI), and then whatever else.

While I'm very greatful for the active maintenance and willingness to add features which users request, "less" is already very rich in features and behaviors, some would say bloated, and we already see how each new features can add complexity and bugs which are not always easy to notice immediately, and sometimes result in quite a few followup fixes (OSC 8 and headers come to mind).

The original issue of (pixel) smooth scroll is most probably out of scope for less. Less is a terminal application, and terminals work in lines, so (pixel) smooth scrolling, unless widely supported and easy to implement, doesn't belong in "less" IMHO.

Pixel-level scrolling should be handled in a GUI application and not a terminal app IMHO. The fact that one terminal allows smooth scrolling UI of the scrollback buffer is between the terminal and the user. It doesn't belong IMO between the terminal and applications running inside the terminal - even if the terminal adds such custom interface. It would be much better IMO if the terminal would allow the user to enable smooth scroll in cases where the terminal already does scroll anyway (even in applications like less) - and keep the application oblivious.

As the for line-based touch/mouse drag-scroll which was just added, unlike mouse-wheel-scroll which is likely expected and is supported by many terminal applications, I don't think I'm aware of mouse/touch drag-to-scroll in terminal applications, and users do expect momentum in touch-drag, so I think "less" should not add code, complexity and future maintenance burden to support it.

Apologies if this comes out as aggressive or out of place, but I do think it would be better to keep the focus on being the best terminal pager out there, while following proven paradigms in terminal applications, and without trying to reinvent GUI-like features in the terminal.

[gwsw]

I agree that pixel-level scrolling is out of scope.

I implemented drag scrolling after a conversation with a user who had a mouse with no scroll wheel, so got no benefit from the --mouse option (except clicking to set the # mark). Dragging seems like a natural extension of the --mouse feature.

[gwsw]

As far as I can tell, the addition of drag scrolling addresses the OP's request.