@Brendan Zabarauskas , @Christopher Durham let's move the codespan, text_unit conversation here :-)
I have been wanting to make a breaking change to
text_unit for some time (to get rid of inconsistent by-ref/by-value methods on
TextRange, and of
of_str ocamlism). I'll be totally up to replacing it with a new crate, if that crate has more than one designer (and I am totally willing to help out).
As I've written in discord:
StrRangeterminology: it's short, it's about "how do you use it" and not "how do you implement it", and it's more orthogonal.
StrOffsetmakes sense. I would just trust @Brendan Zabarauskas opinion here
Also, @Brendan Zabarauskas what are your thoughts in general about splitting
codespan into a indexin bit, and printing & filemap bit?
The indexing part seems to be a micro crate, which is bad. However, at the same time it's also a "vocabulary type" and sits at the interface, and this seems like a good reason to keep it separate
The purpose of the
Offset split IIUC is that
Offset is a signed type (
i64) suitable for arbitrary offsets
I guess the TL;DR of it @Brendan Zabarauskas is that I'd love to help with the move to merge annotate-snippets / codespan-reporting / langauge-reporting / text_unit
Especially if the end result manages to nicely be bring-your-own DB and pluggable formatting engine
(and, to clarify, my interest here is to extract a non-generic super-stupid crate with two types for better-than-usize indexing of strings)
Which is definitely part of doing said merging
@Christopher Durham could you push that to a repo? I'd like to add a couple of comments :D
OK, a decent baseline to review: https://github.com/CAD97/str-index/pull/1
Sorry about the billion
force-with-lease pushes, I'm trying (maybe too hard) to keep the commit history clean, and having branches PRing to a branch being adjusted is a recipe for a lot of rebasing.
@Christopher Durham yeah, I've been curious about annotate-snippets too. I like how they completely remove the need for a file DB+indexing type
That was the direction I was actually hoping to move in with codespan.
The thing that has been preventing me from going all-in with
- their use of
ansi_term - which doesn't allow for injecting a custom coloured writer and relies on global state
- how they try to stick close to rustc's error reporting style - I think we can make better use of box drawing characters, while also gracefully derading to ascii for those who need it
We _have_ been in discussions to see if we can get agreement for simplifying the ecosystem around
annotate-snippets. So at least that's something!
rustc is moving towards using
annotate-snippets IIRC (reminder: merge intension issue)
Yeah Zibi, Yehuda, and I had a DM discussion on twitter about it a few months ago
So now's definitely the best time to consolidate efforts
Yeah, tbh I would rather not have to maintain codespan if I don't need to
From the outside looking in it seems like building a new one by taking the good ideas from all three might be the best way forward (but I have I bias towards building things I'll admit)
Do you like anything about
The name :P
language-reporting was a nice name for the reporting side of things
The other thing I'd like some help on is how to integrate domain-specific diagnostics, like those in LALRPOP
And also allowing stuff like coloured type diffs and pretty printing, eg. https://github.com/Marwes/pretty.rs/
I think there's lots of cool scope to push beyond what rustc does. But perhaps if we joined forces we could improve rustc too.
I had some ideas showing example output from different languages/tools: https://github.com/brendanzab/codespan/issues/1
usize for indexing, and I think that's the right approach there. This is purely an sink layer, so optimizing storage with u32 does not makes sense, and because the user only feeds these types in, newtype wrapper benefits are also not that important.
This is in contrast to rowan, which both stores text unites, and is a source of text unites.
@matklad Yes, I agree. In hindsight I think the sink approach is a better design.
@Christopher Durham what are your goals here? I feel that, if the lodestar is "unifying error reporting" crates, then
StrIndex might not be on the right path then
@matklad I think that my end goal is in fact "unifying error reporting", that said error reporting framework "seamlessly" translates from the "major" libraries for managing code span references, and that it can "render" to LSP (and no functionality of LSP is lost).
Still, I think the experimentation done with
StrIndex here can definitely serve to improve
Having played with annotate-snippets'
cleanup branch a little, I think the "best" way forward seems to be building from there and bridging
The exact point of concretizing spans for snippet annotation though is an interesting question
In a "fork" of annotate-snippets I've delayed
Span resolution all the way to printing with a
FnMut(Span, &mut dyn WriteColor) -> io::Result<()> such that printing could include syntax highlighting
I'm actually drafting an issue to propose the API surface I discovered with experimentation in said fork to