-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add support for nix #244
Add support for nix #244
Conversation
Looks ready to merge. Before I do, does Nix need any additional support beyond this? For example, is there anything like JsDoc @tags for Nix? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ready to merge. Before I do, does Nix need any additional support beyond this? For example, is there anything like JsDoc https://github.com/tags for Nix?
Yes, there's RFC 0145, which defines which comments are "doc-comments" and says that doc-comments are CommonMark. There's also nixdoc
, which understands the RFC and documents the comment format.
It looks like Unit
comment parser in harper
already supports codefences.
I jut tried it out on some nixpkgs
library code, and it doesn't seem to understand this :::{.example}
... :::
syntax. These are pandoc "fenced div", and nixpkgs
documents its usage of these here.
So, tl;dr:
- RFC 0145 tells us that doc-comments start with
/**
and contain CommonMark. - The largest nix project (
nixpkgs
) allows these doc-comments to contain pandoc fenced divs.- It might be fair to call this one of those "established conventions in the nix ecosystem" mentioned by RFC 0145.
So, how does this PR do?
- We're not detecting the difference between regular comments and doc-comments.
- IMO, this is OK. Treating every comment as a doc-comment is fine for a spelling/grammar checking tool. This would be unacceptable behavior for a tool that generates documentation, but that's not Harper's job.
- We interpret all comments with
harper
'sUnit
parser when they really should be interpreted as CommonMark.- This might be nice to fix. Would we need a new
comment_parser
for this? Could we somehow leverage the existing Markdown parser?
- This might be nice to fix. Would we need a new
- We don't understand pandoc "fenced divs".
- I don't know what would be involved in this. I haven't been able to find a discussion about this over in our Markdown parser library.
IMO, the above imperfections are good enough for now.
I completely agree. I just want to be aware of the limitations and have a written record of what needs to happen for "full" support. Thank you so much! |
Support for nix just landed in harper: Automattic/harper#244
Support for nix just landed in harper: Automattic/harper#244
Support for nix just landed in harper: Automattic/harper#244
No description provided.