Colors mismatch when scrolling

[sbellus]

See attached pictures.

After scrolling, lines above colored lines have same color. This color is also remembered and when new build is started, text color is red.

First build:

After scrolling:

[mihnita]

Thank you for reporting it...

• Can you please "reveal the codes" and take another screen-shoot here? Or select the output and copy / paste it here? (the keeps the escape sequences even if they are not visible on screen)
• Is this installed from my site, or you built it from the sources here?

Thank you very much.

[sbellus]

**** Build of configuration test for project ----- ****

/home/---/----/ --- test runTest 
***************** uses >Makefile.host< as Makefile.
We were called using******.
HelloWorld without ansi sequence at begin
[31mHelloWorld with RED_COLOR ansi sequence at begin
HelloWorld without ansi sequence at begin
[0mHelloWorld with NORMAL ansi sequence at begin

**** Build Finished ****

After scrolling up first line that has ansi sequence:

**** Build of configuration test for project ------ ****

/home/---/----/ --- test runTest 
***************** uses >Makefile.host< as Makefile.
We were called using******.
HelloWorld without ansi sequence at begin
[31mHelloWorld with RED_COLOR ansi sequence at begin
HelloWorld without ansi sequence at begin
[0mHelloWorld with NORMAL ansi sequence at begin

**** Build Finished ****

What I noticed is: color of lines are changed when I scroll up (outside the window) first line that has RED_COLOR Ansi sequence.

It is installed from your site.

[mihnita]

I can reproduce it, but I did not have time to see what is going on "inside." Thanks for reporting it.

[mihnita]

Hmmm, Eclipse remembers the text, but it is still calling me to ask about attributes for each line. And when you go up it can call me with the lines in revert order (for lines that were outside the visible range). So multiple lines get messed-up.

Example: 18: Normal 18 19: Normal 19 20: {esc-red}This text is red 21: This is also red 23: Red {esc-reset} Normal

When going up and Eclipse calls to format 20, then 19, 18, the {esc-red} from 20 gets "inherited" by 19, 18. My assumption was that Eclipse will cache the formatting (as it does with the text) and I will only be called when going forward. The only way to solve this (probably) is to do my own caching for the attributes. Kind of error prone, as other things do their own coloring in the same console (i.e. the C++ builder).

[mihnita]

Can't cleanly fix with the current hooking mechanism.

[VsevolodGolovanov]

I worked around this by making a custom formatter, that outputs color codes on each line of multiline log entries.

[mihnita]

Thank you for sharing. That is a bug that annoys me a lot, but I can't find any good workaround for that Eclipse limitation...

[calvertdw]

@VsevolodGolovanov Were you able to accomplish this using a logging framework? I am trying to figure out how to do that with log4j2.

[VsevolodGolovanov]

@calvertdw, yes, here is my custom formatter for JBoss Logging.

import org.jboss.logmanager.ExtLogRecord;
import org.jboss.logmanager.formatters.PatternFormatter;

public class ConsoleColorFormatter extends PatternFormatter {

    private volatile boolean appDebugMode;

    public boolean isAppDebugMode() {
        return appDebugMode;
    }

    public void setAppDebugMode(boolean appDebugMode) {
        this.appDebugMode = appDebugMode;
    }

    @Override
    public String format(ExtLogRecord record) {
        if (isAppDebugMode()) {
            String formatted = super.format(record);
            // if the message starts with "ESC[" and is multiline, then repeat the color code after each '\n'
            if (formatted.startsWith("\u001b[") && formatted.indexOf('\n') != formatted.lastIndexOf('\n')) {
                // color code ends with "m"
                String colorCode = formatted.substring(0, formatted.indexOf('m') + 1);
                StringBuilder builder = new StringBuilder(formatted.length() + formatted.length() / 100
                        * colorCode.length());
                int firstNewline = formatted.indexOf('\n');
                builder.append(formatted.substring(0, firstNewline + 1));
                for (int cur = firstNewline, next = -1; cur != -1; cur = next) {
                    next = formatted.indexOf('\n', cur + 1);
                    builder.append(colorCode);
                    if (cur + 1 < formatted.length()) {
                        builder.append(formatted.substring(cur + 1, next != -1 ? next + 1 : formatted.length()));
                    }
                }
                formatted = builder.toString();
            }
            return formatted;
        } else {
            return super.format(record);
        }
    }

}

[calvertdw]

Black text is no longer readable in a console with a black background. I think you must use "uncolored" text for black/white.

[VsevolodGolovanov]

@calvertdw, the formatter doesn't hardcode any colors, just repeats what's configured on every line. It's up to you to configure the proper colors. E.g. our config is

<property name="colors" value="severe:brightred,fatal:brightred,error:brightred,warn:red,warning:red,info:cyan,config:cyan,debug:blue,fine:blue" />

trace isn't configured, so yeah it's uncolored and shows black or white depending on the console background color.

[kutschkem]

Maybe you are just not using the best extension point for what you are trying to achieve.

I used consolePatternMatchListeners once to look for stack traces (so multiline pattern!) in console output. I don't remember exactly what I did with it, but I think you could hook into this to look for the ranges between color escapes and the reset codes, and color the text in between. This gets you access to the whole console output, not just one line at a time. The scrolling issue basically solves itself because of that as well.

[mihnita]

Fixed by version 1.4.0.202001252332