Consider exporting `prettyDiagnostic` about diagnose HOT 8 CLOSED

This was included in the version 1.9.0!

from diagnose.

Thanks for looking into it!
All the above issues should be fixed now. Some of them were details I completely missed when changing the pretty-printing library used internally (I used to use ansi-wl-pprint but switch to prettyprinter as the former got deprecated).

I'm already enjoying reading errors (sad, but true).

That is quite funny to read actually! This may be one of the downsides of this library. 😂

from diagnose.

Ideally, there would be no such function.
However, as the Pretty instance cannot convey colors, this cannot be done that way.
Also, since we require some parameters (e.g. for unicode characters), this is not possible.

There are 3 options:

1. Create a Pretty instance, which gets rid of the colors and adds default parameters (basically pretty = unAnnotate . prettyDiagnostic True True).
   This is not a great solution in my opinion;
2. Expose the function prettyDiagnostic and let the user remove colors if needed (using unAnnotate).
   This just needs a small pass on documentation, which is not actually up to date;
3. Expose the function and add a parameter to remove colors conditionnaly (similarly to printDiagnostic).
   This needs a little bit of refactoring but should be fine.

Among all those options, I prefer the 2nd one, as it is the simpler one.

from diagnose.

I'd also like to suggest that instead of annotating the PP.Doc directly with AnsiStyle, you could defined your own annotation type that identified the significant portions of the doc (e.g. data DiagnoseAnn = ErrorAnn | WarningAnn | ThisAnn | WhereAnn | HintAnn | ...). Then in the printDiagnostic it could reAnnotate to convert the DiagnoseAnn into the AnsiStyle annotations you provide, but this would allow the prettyDiagnostic results to be easily reAnnotated into whatever styling is desired by the client code. The DiagnoseAnn is more easily matched than AnsiStyle, and is also more informative (e.g. currently Color Red is used for both the header "error" text and for the This portion) for reannotation.

from diagnose.

That is a great idea I actually did not think about.
This allows for more customization (the basic style will still be an option in a specific package) on how stuff is rendered.

This will take a bit of work to introduce into the library, but I think it is completely worth it.
Thanks for the suggestion!

from diagnose.

I have added in da0ccd5 a way of handling style simply via a maping Annotation -> AnsiStyle, similar to this

That way, people can create their own styles (or themes, whatever you want to call it) and can feed them to printDiagnostic.
prettyDiagnostic, on the other hand, must have the style applied to it (e.g. myCustomStyle $ prettyDiagnostic ...).

This seems to implement your suggestion, which I quite like.
I will be closing this issue for the next release.

from diagnose.

Excellent! I'm glad I was able to help improve this library: I'm already enjoying reading errors (sad, but true).

Looking over the changes, I noticed a couple of spots where you might want to update the documentation:

• https://github.com/Mesabloo/diagnose/blob/master/README.md?plain=1#L81-L82
• https://github.com/Mesabloo/diagnose/blob/master/src/Error/Diagnose.hs#L14 (only describes file output)
• https://github.com/Mesabloo/diagnose/blob/master/src/Error/Diagnose.hs#L121 (references the wrong prettyprinter package)

And all the module copyright dates.

from diagnose.

Sorry for the delay.
All these new changes have been incorporated in the new version 2.0.0. 🎉 (see the module Error.Diagnose.Style)

from diagnose.