Bug when chopping long lines when using -r

[orenbenkiki]

For a long time less hasn't been working for me when there were long lines to be wrapped.
Specifically lines were disappearing - the display was flat out wrong.
I chalked it up to some weird xtrem issue.

This isn't about bad line wrapping though.
I have decided to just chop long lines and scroll to the right when the line is long.
To my surprise, -S/--chop-long-lines had no effect (long lines were still wrapped).
I downloaded the latest version. Still no chopping long lines.

Looked around in the code and came upon line 697 in line.c:

    if (ctldisp != OPT_ON && end_column - cshift + w + attr_ewidth(a) > sc_width)

Aha! I was using the -r flag by default and this seems to be disabling -S.
It seems unreasonable to me that the -r flag should have anything whatsoever to do with the -S behavior. So I changed this line to:

    if (end_column - cshift + w + attr_ewidth(a) > sc_width)

And haleluja, less started chopping lines when -S was specified as expected, even when using -r.
This seems to be a bug... or am I missing something? Without this fix I just can't force less to chop long lines no matter what I do.

Environment:

Latest less version v579, commit c763f86

Terminal program: MobaXterm Personal Edition v20.5 Build 4502

TERM: xterm-color

stty -a:

speed 38400 baud; rows 81; columns 144; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

[gwsw]

This is intentional, because when -r is enabled, escape sequences are sent directly to the terminal. In that case less has no way to know where to wrap lines. An escape sequence might move the cursor arbitrarily any number of spaces to the right or left, or even up/down. In general -r should only be used in extremely limited situations, when you know the contents of the file contain escape sequences that you are willing to send to the terminal and are willing to give up less keeping track of line lengths. Is there a specific reason you are using -r?

This is noted in the man page:

Warning: when the -r option is used,  less  cannot
keep track of the actual appearance of the screen (since this depends on how
the screen responds to each type of control character).  Thus, various display
problems may result, such as long lines being split in the wrong place.

[orenbenkiki]

I use -r to deal with colored output.

It would have been awesome if less recognized at least some standard ANSI escape sequences (color, bold, etc.). In this day and age, "almost everyone" uses a terminal emulator and therefore "almost everyone" uses ANSI escape codes (that is, some variant of xterm). But that's a large task.

Still, less wraps longs lines even when -r is used, so it does have some prediction of what's going on, even if inaccurate. Doesn't it make sense that, similarly to still wrapping long lines, it would also still allow chopping them?

[gwsw]

If you just want to support color, you should use -R rather than -r.

[orenbenkiki]

Ugh, I should have seen -R. Seems like -R is a "new" flag, only 20 years old or so ;-) I have been using less since the 80s when it didn't have such fancy features. Goes to show that one should re-read the man pages for the utilities once every decade or so and update one's aliases accordingly. Sorry to have bothered you. My bad.