Skip to content
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

Merged
merged 1 commit into from
Oct 27, 2024
Merged

Add support for nix #244

merged 1 commit into from
Oct 27, 2024

Conversation

jfly
Copy link
Contributor

@jfly jfly commented Oct 26, 2024

No description provided.

@elijah-potter
Copy link
Collaborator

elijah-potter commented Oct 27, 2024

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?

Copy link
Contributor Author

@jfly jfly left a 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's Unit 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?
  • 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.

@elijah-potter
Copy link
Collaborator

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!

@elijah-potter elijah-potter merged commit df0ab61 into Automattic:master Oct 27, 2024
12 checks passed
@jfly jfly deleted the add-nix branch October 27, 2024 16:42
jfly added a commit to jfly/nvim-lspconfig that referenced this pull request Oct 27, 2024
jfly added a commit to jfly/nvim-lspconfig that referenced this pull request Oct 27, 2024
justinmk pushed a commit to neovim/nvim-lspconfig that referenced this pull request Oct 28, 2024
Support for nix just landed in harper: Automattic/harper#244
@mcecode mcecode mentioned this pull request Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants