Accessors for private members of Message, Snippet, and friends

[SamWilsn]

Hey!

I currently use annotate-snippets 0.9.1 (I'm a little behind 😅) to render messages for a markdown linting tool. The tool has a few features that depend on inspecting the contents of structs. For example, it:

• Counts the number of each level of message (errors, warnings, etc.) to print at the end of the run;
• Serializes the structs to JSON so they're easier to work with in a GitHub Action;
• Adds additional contextual help (like links to documentation) based on the ID for each message.

Would you be open to a pull request making these fields public (possibly with a #[non_exhaustive] attribute on the struct for future extensions)?

[epage]

Our intention for annotate-snippets is that it isn't an application-level data type for diagnostics but a way to describe a printed message. That would imply that (1) and (2) would be out of scope unless something changes. As for (3), that depends on more context.

[SamWilsn]

Our intention for annotate-snippets is that it isn't an application-level data type for diagnostics but a way to describe a printed message.

So your suggestion would be to define my own message types (with the same information as annotate-snippets') and only convert them immediately before rendering? I can certainly do that, if that's how annotate-snippets is meant to be used.

As for (3), that depends on more context.

I have a middleware, I guess would be a good term, that adds a Help footer containing a URL to every message based on the message's ID.

[epage]

I would recommend creating your own diagnostic type that meets the needs of your application and convert that to annotate-snippet types when rendering. You may choose to provide higher level, programmatic access to the information that eventually gets rendered. Thats up to your code's needs.

[SamWilsn]

Gotcha, thanks!