feat: distinguish actual scrollback newlines vs vim.o.columns hardwrapped newlines

[neg-serg]

Steps to reproduce:

Generate extremely long newline, for example:

for t in {1..100}; do echo -ne eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeemmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm;

There is only one long string here, but it's impossible to select with pager as the single line. In the same time with the mouse it remains be possible via kitty scroll-back.
Is there any way to get around this problem?

This can often be seen in practice when parsing absurdly large log lines. After this, they are very inconvenient to copy using the keyboard, which adds manual work. The problem can be worked around using tmux, but it increase overall latency.

[mikesmithgh]

Reproduced:

#!/bin/bash

for ((i = 0; i < 90; i++)); do
	echo -n "123456789|"
done

echo

reproduced-300-wrap.mov

Setting vim.o.columns to 300 here https://github.com/mikesmithgh/kitty-scrollback.nvim/blob/main/lua/kitty-scrollback/launch.lua#L375

[mikesmithgh]

Hey @neg-serg thanks for the issue, so the problem is around the number of columns I have set for Neovim (currently 300). When kitty-scrollback.nvim reads the scrollback buffer into neovim's terminal it hard wraps at 300. When I increase vim.o.columns during processing it starts to reduce the performance. I'll have to think if there is a decent way to work around this.

When you say workaround with tmux, what exactly do you mean?

[neg-serg]

If you copy this string with tmux you get one string only, without additional newlines.

Using tmux selection with clipboard integration get you the same result as with kitty-scrollback via mouse.

You have 10000 columns limit in modern vim/neovim, after that strings going to be wrapped.
The problem here that you cannot distinguish newlines from wrapping and newlines from output via pager.