[BUG] Cannot select whole long/multi line, after a search, using double click

[xidiot]

Steps to reproduce:

1. Download this file. longlines.txt (copied from Incorrect horizontal scroll using --incsearch with -S #428) and make sure that lines are wrapped.

2. Search for 2046 (just an example)

3. Double click on any line after the match - whole line will be selected.

4. Double click on any line before the match - only one line of the multi-line will be selected.

I've tested on:

1. Linux (Fedora) with version 668, terminator as a terminal client
2. Linux (Fedora XFCE) with version 643 with both terminator and qTerminal as terminal clients
3. macOS (15.3.1 (24D70)) with version 581.2 with both iTerm2 and Terminal as terminal clients

I'm a bit worried if this is an less issue, because the workarounds I found are:

1. Either change terminal to "Make Text Bigger" or "Make Text Smaller" (iTerm2 actions)
2. Change the size of the terminal which will cause it to wrap or unwrap some lines

[gwsw]

I cannot reproduce this, using Terminator with TERM set to xterm-256color. What is your TERM variable set to?

[xidiot]

xterm-256color for 2 and 3, which unfortunately are not with the latest version, I'll check for 1 later or tomorrow, but I suspect the same.

[gwsw]

When you say "Double click on any line before the match", are you using -j to position the search match lower on the screen so that you can see lines before the match? Or did you not mention a step between steps 3 and 4 where you manually scroll the file down to see lines before the match?

In the latter case, the issue is that when you scroll backwards, each line is individually printed at the top of the screen. If you scroll the terminal backwards one line and print a full line of text in the now-empty first line, then do the same again, most terminals will not treat the two lines as one single line when you try to select one of them. You can work around it by pressing r before selecting text.

[xidiot]

Yep, I'm scrolling up (without using -j) and yes r seems to be a the "proper" workaround for this. I'm however wondering why you cannot reproduce this? So like I've mentioned this is not really less issue, but more like a terminal one?

[avih]

3. Double click on any line after the match - whole line will be selected.

Assuming you're not using --mouse, then double clicking would result in the terminal doing the selection - not "less" itself.

I wonder if this comes down to some "smart" terminal behavior of selecting multiple lines on screen when the terminal wraps one very long line which the application printed into few lines on screen?

[gwsw]

I can reproduce it if I scroll up. At first I was just using -j because the scrolling step wasn't mentioned in your initial report.

As to whether it's a less issue or a terminal issue, I think that's somewhat a matter of opinion. One might argue that the terminal should combine lines when they are printed backwards at the top of the screen, but there's also a reasonable argument that the existing terminal behavior is correct. In any case, I don't know that there is anything less can do about this other than perhaps repainting the entire screen on any backwards movement. You could simulate this by using the -h0 option, but I don't think that should be the default because it is quite inefficient.