I have a tool to produce multiline colored attributes for VT100 and the like, including Xterm, rxvt, libvte (gnome-terminal, mate-terminal, terminator, etc...).
When piping to less(1) (pager), the color attribute is lost at end of line, is that expected?
Here is a script to reproduce.
#!/bin/bash
shopt -s expand_aliases
alias e='echo -e'
e "line 1, start \e[35mmagenta, don't close it..."
e "line 2, magenta should still be there, and now \e[mback to normal attr."
e "line 3."
Running that as ./attr.sh then as ./attr.sh | less shows that less(1) loose the color on line 2.
I guess I must miss an option but can't figure,
thanx @Thomas, I didn't find the hit in SE, thanx for that. Still I find it strange that less(1) has no 'options' to let me choose to loose some perf for a better result, for instance gcc has some options that will make a source file longer to compile, for possible a better result.
I discovered yesterday that less -N would print out the line number with a given color, then scrolling horizontally a long line with various color change on it, less is able to clear whatever color is at the end of line, set color for the line number, then restore end of line color and print out the rest of the line with the correct color, meaning color at end of line has been saved, line number with its own attribute has been printed, and end of line color restored. So all the 'slow' circuitry is already there. Here is the snippet to show how less is able to handle attribute save/restore.
Run it as ./attr2.sh | less -N and use --> <-- to scroll horizontally (or other keys like { or }
So to me it looks more like a bug than a perf advantage, because now I got to write a filter to save/restore char attribute on a text stream with line length exceeding the current window size, well in short rewrite less :)