search

wycats / language-reporting

13 stars 3 forks source link

Consider merging with annotate-snippets #6

Open zbraniecki opened 5 years ago

zbraniecki commented 5 years ago

This crate's purpose seems to heavily overlap with annotate-snippets which is currently being merged into rustc with an intention to replace the internal snippets formatter.

I believe that there's a very high value for the ecosystem in having a general purpose library of that kind as lowers the entry barrier to providing great UX for rust apps matching the experience of using rustc itself.

At the same time, the domain is esoteric enough that I'm concerned about spreading the investment across multiple similar libraries and ending up with multiple very similar, slightly undermaintained ones.

I started evaluating language-reporting to compare it to annotate-snippets and I think the latter provides a cleaner API, has smaller dependency chain and it would be easier to merge language-reporting into it than the reverse.

This is not a criticism of the language-reporting crate, and I am prone to bias due to being an author of the annotate-snippets - if you disagree and prefer to maintain your own crate, I will understand that. If you believe we should merge annotate-snippets into it, I'm open to discuss it as well!

To ease the evaluation, I ported emit.rs example to use annotate-snippets: https://gist.github.com/zbraniecki/1624937ef922a66884af8b2689d928ad

You can place it in ./examples and run with cargo run --example emit --features ansi_term.

It's not exactly 1-1 copy, and I think language-reporting brings features that can be merged into annotate-snippets and has some logic that annotate-snippets would benefit from (using writer!).

I hope this warrants a conversation starter about the role of those two crates and possibilities for unifying the effort.

zbraniecki commented 5 years ago

CC @brendanzab

wycats commented 5 years ago

@zbraniecki I'd be very open to merging the two projects.

There are two aspects of language-reporting that I spent a bunch of time on:

I care much more about the second than the first, which is really very experimental and not everyone's piece of cake.

zbraniecki commented 5 years ago

Great! Would you have time to formulate that as feature requests for annotate-snippets?

wycats commented 5 years ago

@zbraniecki I would love to chat about it before turning it into any formal feature request.

zbraniecki commented 5 years ago

Sounds good. Sent you a msg on twitter.

brendanzab commented 5 years ago

Thanks for CC-ing me in on this! I'll have to evaluate this with the codespan community - we have a number of people using it.

I'm pretty big on going ahead with decoupling the span/file db representation that language-reporting experimented with (brendanzab/codespan#79), but I like how annotate-snippets sidesteps the need to even have a file db by pushing that logic to the library user. I'm also a big fan of the annotation grouping that annotate-snippets does - that's something I've not yet got around to in codespan (brendanzab/codespan#100).

I do want to come up with a way of doing these diagnostics which guides people towards doing something that is reasonable close to what the LSP expects, but at the same time I'm curious about how we can explore things like integrating pretty printers, and domain-specific information, like LALRPOP's shift-reduce errors, and type diffs like in Dotty and Elm (brendanzab/codespan#1).

I'm also interested in ways we can allow for a nicer experience with box-drawing characters and text formatting, while allowing for people to use ASCII if their font/terminal does not support it. I do realise this diverges from the rustc error reporting style though - I'd like to provide a rustc-style for those who want to fit in with rustc however.

The other thing I'd prefer is using a writer that allows you to inject the color implementation in, like in termcolor. ansi_term looks really cool, and supports more formatting options (I'm a big fan of this) but it relies on global state, which makes testing harder, along with end-user customisation.

brendanzab commented 5 years ago

Hope this makes things a bit clearer! Ultimately I have a number of somewhat internally conflicting goals that I probably need to do a better job of expressing, and I'm open with chatting to you about this and figuring it out. Feel free to drop into the codespan chat if you like too! My DMs are also open on Twitter as well.