Improves the logic of AnsiLoggerWithFooter. #1340
Conversation
| plainLogger.accept(footerBuilder.toString()); | ||
| for (String newFooterLine : newFooterLines) { | ||
| plainPrinter.accept(newFooterPrefix + BOLD + newFooterLine + UNBOLD); | ||
| newFooterPrefix = ""; |
There was a problem hiding this comment.
Hmm... how unfortunate. What do you think of
plainPrinter.accept(TWO_TIMES_CURSOR_UP_SEQUENCE);
for (...) {
plainPrinter.accept(BOLD + newFooterLine + UNBOLD);
}? (Note "TWO_TIMES_".)
There was a problem hiding this comment.
Yea that would be ideal, though somehow on Gradle, this sometimes causes a prior-logged line to disappear. Not too sure why that happens though...
There was a problem hiding this comment.
Ah, OK. Moving one line seems safer.
|
|
||
| // If a previous footer was erased, the message needs to go up a line. | ||
| String messagePrefix = didErase ? CURSOR_UP_SEQUENCE : ""; | ||
| messageLogger.accept(messagePrefix + message); |
There was a problem hiding this comment.
Will this work when messageLogger itself is prepending, e.g., "[INFO] "? For example, I wonder if the end string might be "[INFO] + <cursor up> + message", in which case you leave "[INFO] " at the bottom and the actual message line loses "[INFO]".
There was a problem hiding this comment.
Yep, it works since cursor up goes up in the same column. However, it does replace other message lines' prepended text like [DEBUG] with [INFO].
There was a problem hiding this comment.
I see. I think we can tolerate that.
Part of #1297
To be more compatible with logging methods with newline at end.