0

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,

Peter O.
  • 32,158
  • 14
  • 82
  • 96
Phi
  • 735
  • 7
  • 22
  • 1
    The developer did this intentionally, for performance. (see [this](https://unix.stackexchange.com/questions/446532/why-do-i-not-need-to-reset-text-attributes-with-less/446541#446541)) – Thomas Dickey Apr 20 '21 at 19:04
  • Regarding the performance reason, I don't really get it :), to me it sound the operator is spending time reading the display, striking [space] at snail pace, even for the one doing auto-repeat on [space], barely making less a cat(1), I still don't really buy the perf reason, the cpu cycles needed to scan a line for clever attr reset, attr set based on where to truncate line seems slim compared to the code path needed to flush each line to the terminal (scroll) i.e write(2) occurs at each line... Say otherwise, I doubt less(1) is on any perf/critical path :) – Phi Apr 22 '21 at 11:25

1 Answers1

0

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.

#!/bin/bash
shopt -s expand_aliases
alias e='echo -e'
e "line 1, start \e[35mmagenta, ona very long line so we can scroll it horizontally, and now \e[mback to normal attr."
e "line 2."

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 :)

Phi
  • 735
  • 7
  • 22