Emoji in Headers Triggers MD051 as invalid link fragment

[craglin]

When creating a markdown document that includes emojis in the headings, the linter flags the generated anchor tags as incomplete links. This is possibly due to incomplete regex not recognizing the unicode emojis included.

• What did you do? When adding emoji to headings, functional links are flagged as invalid link fragments.

• What did you expect to happen? No warning should be triggered, as the link is functional when using a unicode character

• What actually happened? A warning showed up

• What messages or errors were there? MD051/link-fragments: Link fragments should be validmarkdownlint[MD051](https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md051.md)

• How can the issue be reproduced? See code snippet below:

# My Header

## Table of Contents

1. [Non-Emoji Link](#non-emoji-heading)
2. [Shortcode Heading, Shortcode Link](#:smile:-shortcode-heading)
3. [Shortcode Heading, Truncated Link](#smile-shortcode-heading)
4. [Shortcode Heading, Unicode Link](#😄-shortcode-heading)
5. [Unicode Heading, Shortcode Link](#:smile:-unicode-heading)
6. [Unicode Heading, Unicode Link](#😄-unicode-heading)

## Non-Emoji Heading

There are no issues with this link. It is both functional and does not throw an error.

## :smile: Shortcode Heading

:smile: in shortcode, spelled out like `:smile:`.
The shortcode link (2) does not work.
The unicode (3) version of the link is functional, but throws an error.

## 😄 Unicode Heading

Unicode link is functional and does not throw error.

## Summary

| Link | Functional | Errors Thrown |
| ---- | ---------- | ------------- |
| 1    | True       | False         |
| 2    | False      | True          |
| 3    | False      | False         |
| 4    | True       | True          |
| 5    | False      | True          |
| 6    | True       | True          |

• What version were you using? markdownlint v0.60.0

• What operating system were you using? Windows 11 Pro

• Additional information Relevant markdown extensions being used include:

• GitHub Markdown Preview (bierner.github-markdown-preview)
  • Markdown Preview Github Styling
  • Markdown Emoji
  • Markdown Checkboxes
  • Markdown yaml Preamble
  • Markdown Footnotes
  • Markdown Preview Mermaid Support
• markdownlint

[DavidAnson]

Please show the Markdown to reproduce your issue. I tried based on part of your rendered output above and that produces no violations:

https://dlaa.me/markdownlint/#%25m%23%20%3Asmile%3A%20Spelled%20Heading%0A

[DavidAnson]

Or maybe you are complaining about the "generated anchor tags"? If so, please show what those are. A simple example in the demo playground I use above would be the most helpful.

[craglin]

Or maybe you are complaining about the "generated anchor tags"? If so, please show what those are. A simple example in the demo playground I use above would be the most helpful.

Hi David. Sorry, I meant to show my markdown as code instead of formatted. I've adjusted my code for clarity, and my post to show the revised code. I also copied it to the demo playground you linked. Here is my markdown example.

You can see the link fragment warnings for lines 6, 8, 9, and 10. There are two ways that I'm importing emojis; one is direct unicode copy-paste and the other is using the shortcode. Shortcode breaks the links when included as :smile:, whereas in line 7 there is no warning given, but the code is still nonfunctional.

[DavidAnson]

Thank you, this is very helpful! I'll have a look soon. In the meantime, if you are curious please see the bottom of the documentation for this rule which explains that it specifically enforces the GitHub algorithm for representing heading links. Every link has just one representation and this rule expects the document to use that. So there can be cases where a link works yet is still reported as invalid by this rule. Those are by design.

[DavidAnson]

I've had a look:

1. Correct (per your table)
2. Correct
3. Why do you say this is not functional. The GitHub version of the target is #smile-shortcode-heading which is what's used here.
4. As I wrote above, this may work on GitHub (for me, it doesn't render as a link at all), but it does not use the canonical form (see 3 above), so is deliberately reported.
5. Correct
6. The GitHub version of the target is #-unicode-heading, so this is deliberate reported as with 4 above.

I don't see anything improper here unless you can help me understand why 3 is not functional.

[craglin]

I understand that your implementation is based off GitHub's algorithm. My primary use case is in VSCode and I'm looking for a way to provide the linter with a supplemental rule set to allow for custom whitelisting of link formats that are functional, but do not use the canonical form.

[DavidAnson]

Defining those additional formats would seem to require code and that's not an extension point for this rule. I would recommend disabling the rule for your scenario.

If this is important for your scenario, you could implement a custom rule that allows the variety of formats you desire.

[craglin]

Sounds like that's the way to go. Thank you for looking into this for me.