Color the error: and warning: part of the CommandReturnObject output, similar to how an error is printed from the driver when colors are enabled.
Here's a screenshot of the output: https://jonasdevlieghere.com/static/colors.png
Differential D81058
[lldb/Interpreter] Color "error:" and "warning:" in the CommandReturnObject output. JDevlieghere on Jun 3 2020, 12:11 AM. Authored by Tokens
Details
Color the error: and warning: part of the CommandReturnObject output, similar to how an error is printed from the driver when colors are enabled. Here's a screenshot of the output: https://jonasdevlieghere.com/static/colors.png
Diff Detail Event TimelineComment Actions That was also on my list but it seems you beat me to it. I couldn't resist some smaller nit-picks but otherwise this LGTM beside that.
Comment Actions I'm wondering if it would be possible/acceptable to move the color-related code from llvm::raw_fd_ostream (where the RawOstreamForward code is copied from) into the raw_ostream base class (except that it would default to false, of course). Outputting the color escape codes to a non-terminal, is not a completely unreasonable thing to do. For example, one gather the codes into a string stream, and later output the string to a real terminal -- which, incidentally, is exactly what we are doing here. Then all we would need is to plumb the "color" flag into the appropriate stream object. One possible objection to that idea might be that this trick will work on windows only if we are using ansi emulation, which isn't always possible (I believe it's not available before windows 10). However, that objection applies regardless of where the feature is implemented -- the only difference is that we may be more willing to throw windows under the bus. Another thing that would be good to check is whether these color codes make their way through the SB API (SBCommandReturnObject). I don't think that's a bad thing -- the embedding application might actually want to print lldb command results in color. And also, it provides a nice way to test this feature. Comment Actions Let's talk about this more. I don't think we should cargo-cult code from llvm, especially when the cargo-culting won't actually work for the given use case. On windows, the llvm::sys::Process::*** functions will be messing with the terminal which does not sound like a good thing to do from a generic place like this.
Comment Actions I'm just responding to the questions @labath raised without really looking at the details of the code. I agree that there's nothing wrong with having the ability to output color codes to a file, but it's a surprising default and experience tells me it would break a lot of tests that are rightfully looking just at the content rather than the styling. But having the ability to turn on color for file output would make it possible to also test styling, an ability we don't currently have. Plumbing the option for color and other niceties down to a low level sounds like a great idea, as long as we get the defaults right. For Windows (for now) and for output redirected to a file, the default should be off. That said, I could see lowering of the color option being a separate effort outside the scope of this patch. For one thing, we'd have to get buy-in from the more general LLVM folks. And several of the llvm utilities currently use the WithColor approach, so there could be a lot of work updating those (or they would continue to use the old approach indefinitely).
Comment Actions I think this looks good now. All that's now left is a test case. I think it should be possible to test this in a number of ways:
|
I think a documentation line like "use_colors Use colors to highlight parts of the command output" would make this more obvious (also use_colors would bring this in line to what we call this setting in other parts of LLDB).