Copying single-line text from scrollback buffer introduces newlines

[Neob91]

Describe the bug Copying a single-line output that was wrapped because of its length using the scrollback buffer, results in newlines being added at the wrap positions.

To Reproduce Steps to reproduce the behavior:

1. Output a long line of text (without newlines) to the terminal (one that is sure to not fully fit in one line)
2. Open scrollback buffer (I'm using less for the scrollback buffer, but I'm not sure it matters).
3. Select the entire line, and copy it using a system shortcut (cmd+C on MacOS)
4. When you paste it, it will be split by a newline at the wrap position.

Expected behavior The line is copied without newlines (as it would be using standalone less)

Screenshots Pasted when copied from terminal directly (first) and pasted when copied from scrollback buffer (second):

Copied from:

Environment details OS: MacOS Catalina 10.15.7

[339 09:49:53.894839] Failed to set locale with LANG: en_PL.UTF-8
kitty 0.16.0 created by Kovid Goyal
Darwin MATRIX-x07.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
ProductName:    Mac OS X ProductVersion:    10.15.7 BuildVersion:   19H2
Loaded config files: /Users/neob91/.config/kitty/kitty.conf

Config options different from defaults:
active_border_color       Color(red=96, green=192, blue=224)
color0                    Color(red=31, green=31, blue=31)
color1                    Color(red=247, green=17, blue=24)
color10                   Color(red=29, green=210, blue=96)
color11                   Color(red=242, green=189, blue=9)
color12                   Color(red=15, green=128, blue=213)
color13                   Color(red=82, green=79, blue=185)
color14                   Color(red=15, green=124, blue=218)
color2                    Color(red=44, green=197, blue=93)
color3                    Color(red=236, green=185, blue=15)
color4                    Color(red=42, green=132, blue=210)
color5                    Color(red=78, green=89, blue=183)
color6                    Color(red=15, green=128, blue=213)
color7                    Color(red=214, green=218, blue=228)
color8                    Color(red=214, green=218, blue=228)
color9                    Color(red=222, green=52, blue=46)
cursor                    Color(red=185, green=185, blue=185)
foreground                Color(red=239, green=239, blue=239)
input_delay               5
kitty_mod                 9
macos_option_as_alt       2
repaint_delay             15
resize_debounce_time      0.2
scrollback_lines          12000
select_by_word_characters @-./_~?&=%+#
selection_background      Color(red=96, green=192, blue=224)
selection_foreground      Color(red=51, green=51, blue=51)
shell                     bash --login
tab_bar_style             powerline
update_check_interval     8.0
Added shortcuts:
    super+right KeyAction(func='next_tab', args=())
    super+left KeyAction(func='previous_tab', args=())

Additional context Managed to reproduce with kitty --config NONE (the shortcut for the scrollback buffer is then ctrl+shift+h)

[kovidgoyal]

yes, this is un-avoidable as otherwise it is not possible to sync the current scroll position with less. To fix it would require implementing a better pager than less. Which is on my TODO list for someday, but not soon.

[neg-serg]

The same behavior is true for neovim as pager. It seems there is no workaround for it except using tmux. But using it introduce too much latency/performance penalty.