Tracking: The Big Refactor

[zesterer]

I think it's clear that Ariadne has been successful in several domains, particularly the hobby langdev space. However, it has several limitations that a rewrite/refactor should address:

• No support for toggling colour on-and-off
• ANSI support is assumed, despite this assumption being unreasonable
• There are very few ways to customise the output (such as label ordering, for example)
• Terminal size can't be specified so label/note formatting is often broken

Additionally, there are some new features that a refactor could introduce:

• A generic DOM-like AST for reports (created using builder methods)
• More flexible structure with elements that can be arbitrarily nested
• Generic styling for elements
• Multiple backends (plaintext, ANSI, HTML, LSP JSON, etc.)

Comments welcome!

[CreatorSiSo]

I did a tiny test implementation to try out the user facing api:
https://github.com/CreatorSiSo/ariadne-next/blob/main/src/main.rs
and how a specific backend would be implemented:
https://github.com/CreatorSiSo/ariadne-next/blob/main/src/plaintext.rs

[CorvusPrudens]

At the very least, providing an AST would make it a lot easier to translate ariadne reports to HTML (if HTML isn't made a first-class backend target), which is a use case I'm very interested in! Any HTML implementation would likely be fairly opinionated, so an AST might even be preferable.

[calder]

One small thing that would be nice to fix: Cache::fetch returning references limits possible cache implementations (no RefCell for internally mutable caches for example).

[zesterer]

As a point of interest, I've made some initial headway into this on the ariadne2 branch. It's very early days, but it's already capable of showing some basic diagnostics.

[toadslop]

Keep up the good work! Looking forward to seeing the new release.

[ISSOtm]

I got interested in fixing some limitations of the current API in non backwards-compatible ways, and my understanding is that this big refactor is the way to do so. So please allow me a recap and “elaboration” reply to the OP, as I would like to help, the first step of which is figuring out how to help.

• No support for toggling colour on-and-off

This seems to now be supported via with_config().

• ANSI support is assumed, despite this assumption being unreasonable

Apparently the way to go is to use anstream, but if the diagnostics can be printed to arbitrary Write impls, then that assumption can be punted to the binary crate.

That said, I'm curious as to what terminals (that ariadne would be used with) nowadays don't support ANSI styling, now that Windows Terminal does?

• There are very few ways to customise the output (such as label ordering, for example)

What kind of customisation is there to expect? I believe ordering goes primarily by source code line number. Or am I missing something?

• A generic DOM-like AST for reports (created using builder methods)

What should that AST contain? The source code fragments, and the labels attached to them?

• More flexible structure with elements that can be arbitrarily nested

What kind of elements are expected here?

• Generic styling for elements

Do you mean that each label should be able to be given custom colours? Or is this covered by Label::with_color()?

• Multiple backends (plaintext, ANSI, HTML, LSP JSON, etc.)

I feel like this would be dealt with well by the AST export, especially as any HTML export would be really opinionated, as has been pointed out above.