Moar reset colors when it shouldn't

[nkh]

example below with ANSI codes between <> (can't upload an example on github)

text no color <38;5;25> text <38;5;28> text here should be <38;5;28> but color has been reset same as above

[walles]

Can you upload this?

• An example text file as an attachment
• A screenshot of the correct rendering of this text file

[nkh]

Can't upload my file in github but this is how it looks like when I "cat" it

and this is how it looks like in moar

The code below shows the problem: echo -e '\e[32mline_1\nline_2'

echo -e '\e[32mline_1\nline_2' | moar

[walles]

moar resets colors at the end of each line.

What colorizing tools (like git) tends to do is to add a color marker at the start of each line they want colored, maybe PBS (?) should do that as well? And a reset marker at the end of each line.

Maybe PBS does that already for the blue lines at the top? Is that why they work well?

Having each line being independent like that simplifies interoperability with other tools.

Try head -12 yourfile.txt && echo hello for example. I assume hello is now printed in green, which is not intentional I assume.

On moar's side, let's say it's showing the end of a 50MB file. At half the file there's one escape code turning the text green. To get this right, moar would have to scan the whole file, which would be a performance issue.

So I think that in this case, updating PBS to color each line individually would probably be the best way forward.

[nkh]

I'll use a different pager to show ANSI streams since moar can't handle them.

[walles]

If you do find a pager that handles this case like you want, it would be super if you could add that info to this ticket!

less -R worked like moar when I tried it with your example and I don't really know which other options there are...

Which pager will you switch to?

[nkh]

I know that less -R worked in similar fashion but new tools should handle things better IMO.

I also understand the performance implication of course.

Let me give you a metaphor, you drive a car (moar) on a road (an input stream), you meet a 90 Km/h sign, you don't expect to see a 90 Km/h sign every 10 meters do you?

Of course you could also start driving in the middle of a long road and the sign is behind you, you wouldn't know what speed to drive and you'd be conservative about it.

So there's a difference between getting a stream of data from the beginning or the middle, people who generate ANSI streams don't expect parts of of a stream to be handled as if the whole stream was available, on the other hand when the whole stream is displayed from the beginning I expect it to be displayed properly.

Shall we push "interoperability" a bit further and color each character individually?

Interoperability is of course of great interest but commands further down the pipeline should not filter the input if not asked to do sol; IMO there's a difference between a pager and a filter and that's why less implements (poorly) the -R option. This is not specific to moar and has been a problem since terminals learned to handle colors, an old problem we still have to deal with.

In the case of Pbs, I'm the author, I could make the change but that could be generated by a tool I have no control over.

We, of course, always have to massage input data in pipelines and may be the solution would be something like this:

some_input_data_with_ansi | massage_the data_so_each_line_has_a_color | the_command_that_expects_line_colors

That the command that expects colors doesn't handle them is a bit weird to me, and it seems to me that the best place to add those "extra" color codes (extra because a terminal doesn't need them) would be in the application that handles color ... by adding colors to a stream.

As I wrote above I'll use another application, vim+AnsiEsc handle it properly.