Newlines added to text copied from Windows full-screen applications

[proski]

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

wezterm 20230226-223328-0ac1cbc4

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When text is selected by mouse in certain Windows programs (Far Manager, Midnight Commander for Windows, vi from OpenWatcom 1.9), sometimes it is copied to the clipboard with extra newlines at the end. The way to trigger the issue is to select multi-line text with mouse. After that, even single words selected by mouse have newlines at the end.

I know that the newlines are in the clipboard by pasting text in another program such as Notepad.

I've seen up to 30 newlines appended, but sometimes it's just one or two. After selecting several short single-line snippets, the issue goes away.

Some full-screen Windows programs are not affected. For instance, vim from msys2 doesn't appear to be affected. Programs run remotely over SSH are not affected either.

To Reproduce

Install OpenWatcom 1.9
Start wezterm
Run OpenWatcom vi: C:\WATCOM\binnt\vi.exe
Select several lines by mouse
Select one word e.g. no_name by mouse
Open notepad
Paste
Most of the time, at least one newline would appear after the no_name

Configuration

No config

Expected Behavior

no_name is pasted without any newlines at the end

Logs

Debug Overlay
wezterm version: 20230226-223328-0ac1cbc4 x86_64-pc-windows-msvc
Window Environment: Windows
OpenGL version: Intel(R) UHD Graphics 4.5.0 - Build 31.0.101.3358
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
>

Anything else?

My guess is that there is some Windows-specific code for adding newlines to the text added to the clipboard (perhaps for certain kind of Windows programs), and the data used by that code is not cleared when a new text is selected.

[wez]

Take a look at https://wezfurlong.org/wezterm/config/lua/config/canonicalize_pasted_newlines.html in particular, the last couple of paragraphs

[proski]

That's a separate issue. I tried different settings for canonicalize_pasted_newlines but they don't make any difference for this issue, it can still be reproduced.

This issue is about copying to clipboard, not about pasting from it. That's why I'm using notepad to demonstrate the issue. Also, I don't care much about copying and pasting multi-line text. I want to copy a single word or part of a single string and paste it. I get several newlines after that, which is unexpected. That's especially bad when copying a command that I want to edit, but it runs as is.

[wangvisual]

#2057 (comment)

[proski]

@wangvisual: yes, it looks like the same issue. It's not clear from that ticket is the issue is with copying or pasting. In my case, the issue is with copying, I can see newlines when pasting in Notepad. The vi bracketed mode should be irrelevant, as it affects pasting only, not copying.

[proski]

The issue is "fixed" by commenting out this code in wezterm-gui/src/termwindow/selection.rs, function selection_text():

                if !s.is_empty() && !last_was_wrapped {
                    s.push('\n');
                }

Unfortunately, it breaks copying of multi-line selections as they are copied without newlines. But it's very rare that I need that functionality. I copy text that fits one line most of the time.

At least we know where the newlines are coming from, so it could be a good starting point for the correct fix.

[proski]

Here's my progress so far.
selection_text() (wezterm-gui/src/termwindow/selection.rs) can get 1 or 2 logical lines for a selection within one line. If it gets 2 logical lines, the first line is the correct selection, and then a newline is appended to the selection for the second logical line.
The logical lines come from get_logical_lines() (mux/src/localpane.rs) which in turn gets then from impl_get_logical_lines_via_get_lines() (mux/src/pane.rs)
The latter function gets one line but returns one or two lines. If I add debug statements, I see that many lines are considered "wrapped" (if under Some), but eventually a line is added under else, which makes it the second line in the lines vector.
I suspect that the spaces produces by some Windows programs are considered "printable" and the lines filled by them to the end of the visible area are treated as "wrapped". It still seems wrong to me to look beyond the selection, it should not matter. Besides, the inconsistent behavior is just wrong.

[wez]

is there more that needs to be done here?

[proski]

No, it's good now.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.