-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable a way to elide the message "header" #167
Comments
The change was made in #91 that didn't include the design decisions behind the API. I think they are in a hackmd document that @Muscraft has. With the old API, there wasn't clear reasoning for why choices were made and our primary audience atm is cargo and rustc, so we are making decisions in that direction, including wanting to make sure things are done "correctly". Note this doesn't preclude supporting other use cases. We make the header out of |
Yeah I'm still evaluating whether we want to own our own rendering code or not, but at least for now, yes, I think we could make it work if |
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
When combined with an empty `title`, this results in the header being omitted entirely. This isn't what @epage suggested in rust-lang#167 since changing our rendering to pass in a custom header is a bigger refactor than what I've been able to get to. The goal of this change was to be very small without requiring bigger code changes on our end. Unfortunately, this is a breaking change, so I'm not sure what the appetite is for this. Fixes rust-lang#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
This is a tiny change that, perhaps slightly shady, permits us to use the `annotate-snippets` renderer without its mandatory header (which wasn't there in `annotate-snippets 0.9`). Specifically, we can now do this: Level::None.title("") The combination of a "none" level and an empty label results in the `annotate-snippets` header being skipped entirely. (Not even an empty line is written.) This is maybe not the right API for upstream `annotate-snippets`, but it's very easy for us to do and unblocks the upgrade (albeit relying on a vendored copy). Ref rust-lang/annotate-snippets-rs#167
I'm somewhat new to this crate, so apologies for any category or vernacular errors that I make.
I'm looking at migrating ruff from
annotate-snippets 0.9
toannotate-snippets 0.11
. But I'm hitting an issue where we would like to use our own headers for snippets. This worked in0.9
, but I can't find a way to replicate it in0.11
. To make this concrete, consider this program using0.9
:It has this output:
In ruff, this gets transformed slightly to include a header:
Now consider this program, using
0.11
, which tries to mimic the above program:It has this output:
Which is... very close to what we had before. But it now has an
error: <TITLE>
line that I don't think can be removed. At least, it seems to correspond to a requirement to create a message by providing aLevel
with a title.Is this an intended change to the library that isn't meant to be configurable? If so, I think our options are to either go our own way or to explore changing the formatting of our own diagnostics (which we could do, but I definitely want to see if I can de-couple upgrading
annotate-snippets
from "let's reconsider our diagnostic formatting").I do see some other issues and PRs seemingly related to this issue, but I wasn't 100% sure if this was a strict duplicate or not. So I wanted to put my use case in writing and see where that takes us.
The text was updated successfully, but these errors were encountered: