Bold/emphasis fails when closing delimiter is preceded by a closing bracket and followed by a non-punctuation character
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- markdown
- Área
- documentation
Línea de trabajo
Start with CommonMark spec §6.2 and reproduce the examples using the GitHub Markdown API command in the issue. Compare the delimiter rules for closing punctuation against the listed expected and actual results. Done means reaching agreement on the proposed Unicode Pe rule and updating the relevant specification behavior and coverage.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
Strong emphasis (bold) is not rendered when a ** closing delimiter is
immediately preceded by a closing bracket (e.g. ), ], ") and followed
by a non-punctuation, non-whitespace character such as a letter or digit.
Reproduction
Verified on GitHub.com via the Markdown API:
curl -s -X POST \
-H "Content-Type: application/json" \
-d '{"text": "**)**a\n", "mode": "gfm"}' \
https://api.github.com/markdown
# => <p>**)**a</p> ← not bold
| Input | Expected | Actual |
|---|---|---|
**)**a |
**)**a (bold) | **)**a (literal) |
**)**1 |
**)**1 (bold) | **)**1 (literal) |
**]**a |
**]**a (bold) | **]**a (literal) |
**"**a |
**"**a (bold) | **"**a (literal) |
**)**! |
)! (bold) | ✅ correct |
**)** a |
)·a (bold) |
✅ correct (with space) |
Root Cause
The CommonMark spec §6.2 defines a right-flanking delimiter run as:
(1) not preceded by Unicode whitespace, and
(2a) not preceded by a Unicode punctuation character, OR
(2b) preceded by a Unicode punctuation character AND followed by
Unicode whitespace or a Unicode punctuation character.
For **)**a, the closing ** has:
before=)→unicode.IsPunct= trueafter=a→ neither whitespace nor punctuation
Applying the rule:
!false && (!true || false || false) = false
→ The closing ** is not right-flanking → bold is not rendered.
Why this is a spec issue
Closing brackets (Unicode category Pe: ), ], }, ", », etc.)
are punctuation by Unicode definition, yet they are semantically
word-terminating — the character following them is logically separate
from the bracketed content. The current rule treats them the same as
opening punctuation like ( or ", which causes the asymmetry:
**(note)** is bold ✅ (after = space)
**(note)**. is bold ✅ (after = punctuation)
**(note)**a is NOT ❌ (after = letter)
This is counterintuitive: a user writing see **(RFC 9110)**section 5
would reasonably expect bold to apply.
Suggested fix
Amend condition (2b) to exclude closing punctuation (Unicode category Pe)
from the "preceded by punctuation" restriction:
(2b) preceded by a Unicode punctuation character other than a closing
bracket (category Pe), AND followed by Unicode whitespace or
a Unicode punctuation character.
Or equivalently: treat Unicode Pe characters as non-punctuation for the
purpose of the right-flanking delimiter rule only.
References
- CommonMark spec §6.2: https://spec.commonmark.org/0.31.2/#left-flanking-delimiter-run
- Unicode Pe (Close Punctuation): https://www.unicode.org/versions/Unicode15.0.0/ch04.pdf
- Lenguaje dominante
- Python
- Estrellas
- 5.2k
- Forks
- 360
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de commonmark/commonmark-spec
-
NBSP written two different waysAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
commonmark/commonmark-spec#843 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
commonmark/commonmark-spec#838 · 2 comentarios ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
commonmark/commonmark-spec#728 · 2 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
commonmark/commonmark-spec#844 · 5 comentarios · 1 reacción ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
commonmark/commonmark-spec#842 ·
Todos los issues de commonmark/commonmark-spec
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
-
[Bug]: Queen's own Ollama model loses num_ctx when a running session switches to itPosiblemente ocupada @anasamin26 la tomó hoy. Abiertobug enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
aden-hive/hive#7508 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
llm translation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
BerriAI/litellm#47884 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug 🐛
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
netalertx/NetAlertX#1856 · 1 reacción ·
Los mantenedores suelen responder en 1 día