xoofx / xoofx/markdig

Bold Text inside of a word with trailing punctuation character inside of bold is not rendered

Open
#683 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
C#
Stars
5.3k
Forks
510
Avg merge
8d 5h
Merged PRs (30d)
5

Description

There's a rendering issue with bold text when bold is selected without a trailing space after teh bold text (ie. inside of a word boundary) and the bold text ends in a puntuation or sign character.

GOOD: **bold text ending with slash/** followed by non-blank

BAD: **bold text ending with slash/**followed by non-blank

BAD: **bold text ending with slash=**followed by non-blank

<!-- workaround -->
GOOD: <b>bold text ending with slash/</b>followed by non-blank

Here's that rendered on GitHub which exhibts the same behavior actually:


GOOD: bold text ending with slash/ followed by non-blank

BAD: **bold text ending with slash/**followed by non-blank

BAD: **bold text ending with slash=**followed by non-blank

GOOD: bold text ending with slash/followed by non-blank


I've tried escaping the text with \ and none of that seems to help. The only workaround seems to be using raw HTML as long as the target parser supports that (and MarkDig and Github appear to both).

The following Babelmark demonstrates - although it behaves differently yet (even for MarkDig and GitHub which obviously behave slightly differently):

Babelmark for bold issue

(hmmm... babelmark seems to inject an extra space regardless, but GitHub here or MarkDig seem to do the right thing)

This is an edge case for sure, so probably low priority and apparently MarkDig isn't the only parser handling it this way. Not sure if this even should be fixed because it would give different behavior than GitHub which is the most common use case for Markdown to end up on.

Anybody know why the /**moreText would cause this behavior in the parser?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the GOOD and BAD Markdown examples from the issue, including punctuation immediately before the closing emphasis markers. Then trace the parser's handling of bold spans at a word boundary and compare its output with the expected HTML shown in the report. Done means the behavior is either corrected with regression coverage or clearly documented as intentional.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.