very minimalistic support for colors (warnings and errors) #207
Conversation
|
You should really use Format.tag for this. It would simplify the enabling/disabling and solve the weird indentation. Respecting |
|
My personal opinion is that while I don't personally care about colors (Emacs and Merlin do that for me), I have heard enough demand from enough people to believe that integrating it in the compiler is worthwhile. I find it rather silly to say that a compiler is "massively more usable" when it adds colors (not saying that's what @c-cube claims, but I have heard this argument around the Clang debates), but if enough people hold that irrational belief it becomes an important aspect of usability to please them -- and also they might be right, who knows? Cc: @ppedrot which asked me privately about doing such things in the toplevel (but I think there |
|
@gasche I think many people use OCaml without emacs, those days, including me. Colors do not have a "massive" effects, but they do help spot where important messages lie. |
|
One of the problem with tags is that they are not compositional (though it may not be a problem in that case, it is if you try to provide styling as a library). You can also simply use |
|
I like this idea, personally. Colored warnings and errors are definitely helpful, especially for beginners. |
|
The code is better now (using Format tags). It prints warnings in magenta, locations in bold, errors in red. |
|
I should probably add some support into ocamlbuild (with a tag?) |
|
Yes, I was thinking of that yesterday. If you don't mind, an ocamlbuild tag would be nice -- it's rather easy to add by imitating what is already present, eg |
|
Three questions:
Also, you definitely need to add this option to the |
|
for 2. there is always the possibility to check terminfo ... which should be done anyway. Emacs users can enable ansicolor. |
|
There seems to be some |
|
"Massively more usable" is a silly claim, but "massively more readable" isn't one. For that matter, even OCaml agrees and uses some formatting for the toplevel. |
| (* color output *) | ||
| | "color" -> | ||
| begin try | ||
| let b = bool_of_string v in |
There was a problem hiding this comment.
There already is a standardized interface for boolean parameters, which is to use 0/1 (see Compenv.setter) rather than bool_of_string. You should feel free to generalize Compenv.setter to support calling an arbitrary function (as an auxiliary function).
|
I think the current codebase is reasonable and could be mergeable after having been made a bit less Re. default setting: I would enable it by default on On the other hand, checking how other projects handle this question (eg. clang?) may suffice to have a good/consensual answer. |
|
@gasche Usually, you check the |
|
I'm working on @gasche 's recommendations. I moved |
| let mk_no_color f = | ||
| "-no-color", Arg.Unit f, | ||
| " <bool> Disable ANSI color codes for warning/error messages" | ||
|
|
There was a problem hiding this comment.
It would be nice if there was a way to explicitly ask on the command line the "auto" mode -- you had a good idea in separating these three options. You could have -color-auto as a third flag, or maybe accept -color {on,off,auto} (or {always,never,auto}, these are the option names in git and grep). This would mean that the OCAMLPARAM handling code would have to be changed again...
|
Indeed, forgot about the ocamlbuild tag (which should become several tags: |
|
I'm not sure why the testsuite fails, but it may be the case that some tests in the testsuite do not run with |
|
The errors were because the output was slightly changed by this branch; the last commit should fix this. |
|
yay! |
| print ppf loc; | ||
| fprintf ppf "Warning %a@." Warnings.print w | ||
| pp_open_tag ppf "warning"; |
There was a problem hiding this comment.
is there a particular reason for not using a format string here?
|
For what it's worth, keep in mind that the Windows terminal does not support ANSI escapes, despite MSDOS's famous ANSI.SYS extension that made them ubiquitous: |
|
|
||
| let print_error_prefix ppf () = | ||
| setup_colors (); | ||
| pp_open_tag ppf "error"; |
There was a problem hiding this comment.
Is there a particular reason for not using a format here? (I don't mind either the format or plain-pp styles, but mixing both is a bit surprising)
|
@gasche I'm moving to format strings, right. |
|
Sorry to nitpick, but the current patch series isn't really usable as is -- for example, this commit is not at all what it says. Would it be possible to have another rebase? I will do it myself otherwise, but probably not today. Other points I noticed when trying to rebase myself this morning:
|
|
Also, I noticed during my testing that, when printing a location, the characters are not highlighted with the rest of the location (this corresponds to a small bug in |
|
I will do the rebase and change the bad commit/commit messages. What do you mean by non-highlighted 'characters'? |
|
Only the line numbers are highlighted, not the character range. |
|
Right, fixed. About the bootstrap, I admit it's funny to have yellow colors (it illustrates the idea of the compiler hidden backdoor perfectly imho); I can change the bootstrap again if you want, either using the latest version or the one just after |
|
I think it's nice to bootstrap with the color-enabled compiler, as it ensures that other maintainers will see the effect of the change -- early adopters! But then you should use the right colors. (Bootstrapping before is fine as well.) You should also merge "add option handling" and "add color handling in OCAMLPARAM and ocamlbuild". Thanks for the changelog message. Would it be possible to also have a test in the testsuite that checks that the behavior is as expected for (I'm thinking of adding two changes on top of this PR in the future: change the option handling to use |
|
Ok, will do. About the bold locations, I followed what clang and gcc do, and I don't find it too invasive. It will be easy to change later anyway. Is there something that would help me write tests that set specific options to the compiler before compiling the sample? |
use bold magenta for warnings (works on white background)
use -color, -no-color, -color-auto in the compiler use "0", "1" or "a" for the "color" option in OCAMLPARAM add tags 'color', 'color_auto', 'no_color' to ocamlbuild
|
Now that I think of it, testsuite would be a pain because you'd have to disable them under Windows and other unsupported environment. I think it's not worth it, so feel free to skip these. (If color get broken, people will complain anyway, hopefully...). An example of test controlling the command-line parameters of the compiler is lib-dynlink-bytecode. |
|
Ok. Then I think the current set of commits is ready (I re-bootstraped and fixed the location bug, please check!). |
|
Merged in trunk. Thanks for the patch! |
|
apologies for the bad rebasing (I did rebase a lot tbh, it must have gone wrong at some iteration). |
|
Based on this caml-list discussion, it seems that the current patch breaks the ability to define a custom margin for toplevel messages. We should fix that, and add a regression test to the testsuite. |
|
I don't think it breaks this feature, I think it was already broken. Formatting was done using |
|
Indeed, it seems you were right and the change happened between 4.01 and 4.02. Sorry for jumping to the wrong conclusions. |
The point of this PR is to poll maintainers and users, do NOT merge (yet) :-)
The idea is simple: print warnings in yellow and errors in red, as other compilers (gcc, clang for instance) do. I didn't spend a lot of time on this (no tests, a problem with
Formatwhich indents weirdly because of escape codes). I could useANSITerminalbut I'm not sure about adding dependencies to the compiler.