feat(highlighting): implement syntax highlighting for unnamed source codes #425
Conversation
There was a problem hiding this comment.
I generally like this, but I'm gonna have to think more about moving those specific things around. I think there might be other things to be done about the struct to-be-formerly-known-as-NamedSource but I'll try and remember what else I thought might be nice.
I also don't know when I'll want to have a breaking release of miette. I try to keep them very very sparse, so if you 8000 can think of a way to do this without the breaking change, even if we eventually do the "nice" version, then that'll get unnamed source code highlighting working sooner for the community.
|
@zkat sure, I can do that. I'll simply create the |
| } | ||
| fn line_count(&self) -> usize { | ||
| self.line_count | ||
| } |
There was a problem hiding this comment.
I'm not sure this is optimal to move off of SpanContents for reasons I noted in #450.
Specifically, today, the interface could handle fun scenarios like markdown like this:
# An introduction to Rust
Here's a Rust program!
```rust
fn hello_world()
{
println!("hello world")
}
\```
(the \ is because I can't get GitHub to quite handle markdown inside its markdown with a code block inside it... unsurprisingly)
A markdown aware parser could go "right, this span is inside a code block, let's grab the bit after the backticks and use that as the language". The filename would remain whatever.md, but the language for that span would be whatever that is (in this case Rust).
Language being a property of SpanContents, IMO, thus makes sense. you can have multiple languages in one SourceCode
If you don't like the example of markdown, consider Razor/Blazor stuff, HTML, JavaScript, and CSS frequently living together, and so on and so on. Yes, the new interface could do this too, but it'd require representing those parts of the file as separate SourceCode.
I do see that there could be a more convenient interface; but I'm not (personally, for whatever little my opinion might be worth) sure this new interface is better.
There was a problem hiding this comment.
And SpanContents already can be used to provide language without name; both via your own struct implementing the trait and via MietteSpanContents::new; is there something I'm missing?
Currently, both
nameandlanguageare part of theSpanContentsabstraction, which comes from theNamedSourcestruct. It would make more semantic sense if those were part of theSourceCodeabstraction instead. This would allow us to use syntax highlighting in unnamed source codes, which is not currently possible. This PR proposes this.Changes
NamedSourcetoMietteSourceCode, addinglanguageto it.name()andlanguage()fromSpanContentstrait toSourceCodetrait.nameandlanguagefromMietteSpanContentsstruct toMietteSourceCodestruct.This is a breaking change because it refactors public APIs.
Before
After