[FEATURE] Option to retain 'LESS_TERMCAP_xx' colors in non-interactive terminals

[LangLangBart]

Problem

When a user defines LESS_TERMCAP_xx, these colors are not applied when the output of less is going to a non-interactive terminal.

Consider this Docker command as an example:

docker run --tty --rm \
  -e LESS_TERMCAP_md=$(tput bold; tput setaf 4) \
  alpine sh -c 'apk add less; printf "F\bFO\bOO\bO\nBAR\n" | less -RF'

In an interactive terminal, FOO is displayed in bold blue. However, if you run the same Docker command without the --tty flag, FOO is not colored or bold.

Feature Request

Would it be possible to add a new option that forces LESS_TERMCAP_xx colors to be retained when the output of less goes to a non-interactive terminal?

---

More context

My use case involves fzf and its --preview window, which executes the command in non-interactive mode[^1].

The command downloads a html file using curl, and the html2text transforms into text but retains backspaces. Finally, less would make the output more readable by adding the user-defined LESS_TERMCAP_xx colors.

export LESS_TERMCAP_md=$(tput bold; tput setaf 4)
: | fzf \
  --preview-window 'left,80%' \
  --preview 'curl -fsSL https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/printf.html | html2text | less'

Currently, the result looks like this:

But I would like it to look like this inside fzf's preview window:

[^1]: less functionality is reduced in preview window · Issue #1118 · junegunn/fzf

[gwsw]

Perhaps I'm not fully understanding, but if you're not using less for paging but only for adding coloring, I'm not sure that it's the right tool for the job. It seems like you could do what you want with a simple sed script or something like that.

[LangLangBart]

Perhaps I'm not fully understanding

The request is to introduce an optional flag that retains the colors when the output is not a tty device.

For similar use cases, git offers the --color=always flag. However, less currently lacks such a feature.

I'm not sure that it's the right tool for the job.

That is the question: do you think less should be able to do this or not? Whatever you decide will be accepted.

It seems like you could do what you want with a simple sed script or something like that

For the use case outlined in the description of the issue, one can also use bat --color=always -pl man, but it would look better with less.

[gwsw]

Can you explain why it would look better using less rather than bat?

[LangLangBart]

Can you explain why it would look better using less rather than bat?

Having an option to retain the colors in less would improve the appearance because it ensures consistent highlighting, whether you're in an interactive or a non-interactive terminal. This consistency helps to spot visual cues more easily, making complex outputs easier to read.

The interactive command is shown below and creates the output you see in the image below. Run the command without the --interactive and --tty flags for the non-interactive version. By default, bat uses --pager "less -RF".

docker run --interactive --tty --rm  \
  -e LESS_TERMCAP_md=$(tput bold; tput setaf 4) \
  -e LESS_TERMCAP_us=$(tput smul; tput setaf 2) \
  -e LESS_TERMCAP_ue=$(tput sgr0) \
  alpine sh -c 'apk add bat curl less html2text; curl -fsSL https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/printf.html | html2text | bat -pl man --color=always'

[gwsw]

I'm going to say that this seems more trouble than it's worth. Currently when less detects a non-interactive terminal, it just outputs the raw input file, byte by byte, with no processing at all. Implementing this request would require a substantial implementation of a filter, similar to but different than the normal interactive processing, that detects ANSI sequences and applies color. But it would presumably not do any of the other processing normally done in interactive mode, like breaking lines at the terminal width, tab expansion, backspace processing, displaying a printable representation of control characters, etc. I don't think that this feature is worth the trouble and risk. If it were me, I would use a different tool to apply color to non-interactive output.

[LangLangBart]

Closing this, per the reasoning above.