Make Ariadne understand colour & other text styling options

[nevakrien]

as discussed in #98 color should be optional and ANSI support should not be assumed.
this could be implemented independently of refactoring so I am noting it here as its own issue.

one way to go about this is adding a field to config named color-mode

enum ColorMode {
On,Off,Auto
}

with auto using known good practice ways like in the colored crate to check for whether ANSI is supported.

[zesterer]

The difficulty here is that Ariadne does not currently 'know' about colour: it just passes ANSI attributes through to the Writer without modification. However, this is a desirable feature (especially if the crate is to grow more backends).

[zesterer]

I added support for stripping the ANSI sequences in 696a058. I'm not entirely convinced that this should really be something that Ariadne is responsible for given its current design (not least because doing so drags in extra dependencies for very little in the way of functionality), but ah well.

[nevakrien]

I mostly put this here because you mentioned this was something you want from the refactor of write and so I was thinking I would add it if you gave the green light

the only real use case I am seeing is that tools like grep dont play nice with ANSI so if your using Ariadne to construct 100s of lines of errors it would be nice if it plays nice with grep.

and ya users can use a warped writer if they want but it would be nice if it worked well by default.
like the colorized crate has this https://docs.rs/colored/latest/src/colored/control.rs.html#104
which makes it so you basically dont have to think about ANSI codes ever and everything works smooth.

there is probably a nicer way to implement this so maybe we go back on 696a058 for now and we fix it later.
I would start working on a PR

[zesterer]

I think a better solution is much more than my small change.

In the future, multiple rendering backends might have different abilities to style content (ANSI CLI vs HTML vs SVG vs LSP JSON) so styling should be decoupled from the representation of the report

This decoupling could take the form of named styles with a way to provide definitions for those names on a per-backend basis. For example, a user-defined error style might show up as red + bold in the ANSI backend, but might also show up with additional effects for a hypothetical HTML backend. Think CSS!

Marrying this up with std's formatting machinery is... slightly annoying. One option is to continue with existing patterns and communicate styles in-band, perhaps using some special arrangement of unicode control characters to communicate style 'tags' in-band. So, you might be able to do

Label::new(span)
    .with_msg(format_args!("The type {} is invalid here", "Int".style("type")))

and then later specify how that style should appear:

let mut ansi = AnsiRenderer::new(std::io::stderr())
    .with_style("type", AnsiStyle { fg: Color::Red, bg: Color::Reset });

my_report.render(&mut ansi);

I might try sketching up a design like this in the next few days if you're interested?

[nevakrien]

are we using ANSI for things that are not color? because what i found when thinking about this is that my PR for changing styles had a bug where I had Some(Color) for custom instead of filter and i belive I just inherted that from the original code.

maybe this is actually a complete non issue where we just need to be using config correctly

[nevakrien]

@zesterer ya this does seem intresting.
although I am unsure that this cant be written as just ommiting HTML tags.

so for example doing

<p style="color red">
    text
</p>

is a perfectly valid way to translate to HTML.
I am not familiar enough with LSPs but i would imagine a similar thing applies right?

in other words it seems to me that color being per element the way it currently is kinda works. and then its just a matter of replacing the current yansi::Color with Backend::Color which we can require to implement Copy so it wont feel weird