less -R resets colours over multilines

[rowlap]

The behaviour of less -R is surprising when outputting formatted text over multiples lines.

Steps to repro (the colour output is lost in this Github bug report)

$ export TERM=xterm
$ echo -e '\033[1;32mgreen\nalso green\033[m\nnot green'
green
also green
not green
$ echo -e '\033[1;32mgreen\nalso green\033[m\nnot green' | less -X -r
green
also green
not green
$ echo -e '\033[1;32mgreen\nalso green\033[m\nnot green' | less -X -R
green
also green
not green

-R is expected to allow through colour codes, but instead it inserts a \33[m reset at the end of the first line, resulting in also green not being coloured green.

$ cat less.strace
write(1, "\33[?1h\33=\r", 8)            = 8
write(1, "\33[1;32mgreen\33[m\nalso green\33[m\33[m\nnot green\33[m\n", 46) = 46
write(1, "\33[7m(END)\33[27m\33[K", 17) = 17
write(1, "\r\33[K\33[?1l\33>", 11)      = 11
+++ exited with 0 +++

Tested with less 530 and less 643.

[avih]

-R is expected to allow through colour codes,

Not if you read the documentation of -R, especially from the middle to the end:

-R or --RAW-CONTROL-CHARS
      Like -r, but only ANSI "color" escape sequences and OSC 8 hyper‐
      link sequences are output in "raw" form.  Unlike -r, the  screen
      appearance  is  maintained correctly, provided that there are no
      escape sequences in the file other than these  types  of  escape
      sequences.   Color  escape sequences are only supported when the
      color is changed within one line, not across  lines.   In  other
      words,  the beginning of each line is assumed to be normal (non-
      colored), regardless of any escape sequences in previous  lines.
      For the purpose of keeping track of screen appearance, these es‐
      cape sequences are assumed to not move the cursor.

[rowlap]

Ah, I see the docs for -R were tightened up recently in 9e01fe6.

Thanks for the pointer.

[avih]

That doesn't mean that it would be a bad behavior to let colors continue on th next line, however, most (all?) syntax highlighters do reset the color at the end of the line and/or set-it-again at the next line even if the same color continues at the next line.

[gwsw]

The issue with maintaining colors across lines is it would be impossible to seek to different parts of the file. All file movement would need to be done by reading, to ensure that we know what color to use at the start of each line. So, for example, issuing the G command in a gigabyte file would be much slower.