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

Feature Request: Recognize markdownlint-* configuration comments in "non-HTML comments" (unused link reference definitions) #1263

Open
DianaNites opened this issue Jun 19, 2024 · 1 comment

Comments

@DianaNites
Copy link

HTML comments as used to configure markdownlint within a file often have the unfortunate side-effect of appearing in the final HTML source, even though unrendered.

It would be nice-to-have(TM) for the various markdownlint configuration comments to also recognize the conventional "non-HTML" comment syntax, as commonly used and supported by default in MD053.

[//]: # (markdownlint-disable MD053)
[unused]: https://example.com
[//]: # (markdownlint-enable MD053)

This would purely be a "Nice To Have(TM)" convenience feature, as it is currently possible to do this by inserting a HTML comment inside the non-HTML comment, which also does not appear in the final HTML source of most renderers, per BabelMark

[//]: # (<!-- markdownlint-disable MD053 -->)
[unused]: https://example.com
[//]: # (<!-- markdownlint-enable MD053 -->)

Another possible use-case besides convenience for this feature could be a new lint against HTML comments entirely, to make sure undesired comments don't end up user-visible without giving up on the ability to configure markdownlint inline.

It is perfectly understandable if this is not deemed worth it.

@DavidAnson DavidAnson changed the title Feature Request: Recognize markdownlint-* configuration comments in "non-HTML comments" Feature Request: Recognize markdownlint-* configuration comments in "non-HTML comments" (unused link reference definitions) Jun 19, 2024
@DavidAnson
Copy link
Owner

I'm not sure how I feel about this approach, but you make a good case for it. :) That said, you also show how it's possible to accomplish the desired result today with only a few extra characters and so I am less inclined to add explicit support.

I will leave this issue open as a possible enhancement, but anyone reading this should please treat the "mixed" approach above as the current recommendation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants