[markbt]

This change rewrites the screen rendering algorithm to allow wrapping of lines. Lines can be wrapped at grapheme or word boundaries. The wrapping mode is controlled with the \ key.

[markbt]

I started using this today and it seems to work fine. Once I'm happy I haven't regressed anything, I'll merge it.

Any additional testing help appreciated.

[quark-zju]

The direct mode currently truncates lines unconditionally since that's easier to implement. Perhaps it can respond to the line wrapping too, or just enter the full screen mode if the user wants the wrapper behavior.

[markbt]

I was thinking that direct mode should default to showing things wrapped. It doesn't make much sense to show things unwrapped there as the user can't scroll to the right. Probably it needs a config option, and probably we need to start thinking about a proper config file for streampager.

[quark-zju]

Related to this. I wonder if we should make the text in the stderr panel wrapped by default. Internally, hintutil prints to there and some hints are quite long.

[wez]

Some thoughts:

• direct mode should always use wrapping otherwise it nets out a worse UX than just using cat for files that have long lines.
• wrapping should be the default as the UX feels better in my opinion and experience; I've never reached for man page to figure out how to disable wrapping in less
• Subjectively, I feel that word wrapping looks better and would be happy if that were the default.
• having --wrap=none|line|word as a command line option would make sense as a way to override the default.

I'd be hesitant to add a configuration file because the complexity increases disproportionately, but it depends on just many options you think you'll need to grow over time. If you think it will be super simple declarative stuff forever then serde/TOML are pretty easy.

However, I just started to move away from those in wezterm because I was feeling constrained when it came to eg: key assignments. I've switched to using lua and wrote some serde glue to keep it almost as simple as TOML to embed and map data to/from lua. This is likely overkill for a pager!

[markbt]

I actually prefer non-wrapping by default, with the ability to wrap if needed. When viewing logs with timestamps at the left they don't get broken up by the wrapped lines, and the graph view in hg/git log also doesn't get chopped up. But I can see I might be unusual there, which is why I think it'll need to be config.

The less option for defaulting to this is -S, but afaik there's no easy way to toggle it from within less, which is a shame.

I actually wanted to add config files precisely for keymapping, which is what I planned to work on after wrapping is wrapped up. What problems did you hit that required using lua? I was thinking a simple "key combo" -> "action" mapping would be sufficient.

[wez]

What problems did you hit that required using lua? I was thinking a simple "key combo" -> "action" mapping would be sufficient.

I kept wanting to use loops to emit bindings for numbers and function keys for jumping directly to tabs because it was a bit of a chore and repeaty to duplicate the lines.

I also wanted to allow defining a callback to allow more complex actions; eg: press a single key and have it spawn a set of windows/tabs to re-establish a preferred workspace layout.

sp doesn't seem likely to need either of these anytime soon so you're probably safe to skip lua :)

[quark-zju]

It's also not too difficult to implement some lisp-like language (with true lambda support, but no control flow call/cc) in pure Rust and integrate with pure Rust functions well. I have done that. I can make things more reusable if it's interesting.