Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Option to define custom flanking/canOpen/canClose rules for delimiters

Offen
  • Stimmt etwas nicht?
#428 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

@abhiramaab arbeitet bereits daran.

Seit 12.8.2026.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
tooling

Rechercherichtung

Beginne mit InlineParserImpl und verfolge, wie delimiter runs zu DelimiterData werden und wie processDelimiters DelimitedProcessor.process() aufruft. Überprüfe den Pfad von inlineParserFactory und ermittle, wo benutzerdefiniertes canOpen/canClose- oder flanking-Verhalten bereitgestellt werden könnte, ohne InlineParserImpl zu kopieren. Als erledigt gilt die Aufgabe, wenn ein Consumer benutzerdefinierte Delimiter-Regeln definieren kann und die angeforderte lockere Syntax für Fettdruck und Kursivschrift entsprechend geparst wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement

Is your feature request related to a problem? Please describe.
The markdown spec that I'm trying to parse has loose rules when it comes to bold and italic delimiters, i.e. *italic * is vaild syntax. These seem to be the rules:

  • _ - same behaviour as default
  • __ (as opener) - must have a space/punctuation on the left, but what's on the right doesn't matter
  • __ (as closer), *, ** - no rules (can be surrounded by anything, can have spaces on either side, and still work)

However, Commonmark-java follows the default markdown spec which is strict and has certain flanking rules. Currently these rules seem to be hardcoded in InlineParserImpl:

        boolean beforeIsPunctuation = before == Scanner.END || Characters.isPunctuationCodePoint(before);
        boolean beforeIsWhitespace = before == Scanner.END || Characters.isWhitespaceCodePoint(before);
        boolean afterIsPunctuation = after == Scanner.END || Characters.isPunctuationCodePoint(after);
        boolean afterIsWhitespace = after == Scanner.END || Characters.isWhitespaceCodePoint(after);

        boolean leftFlanking = !afterIsWhitespace &&
                (!afterIsPunctuation || beforeIsWhitespace || beforeIsPunctuation);
        boolean rightFlanking = !beforeIsWhitespace &&
                (!beforeIsPunctuation || afterIsWhitespace || afterIsPunctuation);
        boolean canOpen;
        boolean canClose;
        if (delimiterChar == '_') {
            canOpen = leftFlanking && (!rightFlanking || beforeIsPunctuation);
            canClose = rightFlanking && (!leftFlanking || afterIsPunctuation);
        } else {
            canOpen = leftFlanking && delimiterChar == delimiterProcessor.getOpeningCharacter();
            canClose = rightFlanking && delimiterChar == delimiterProcessor.getClosingCharacter();
        }

        return new DelimiterData(delimiters, canOpen, canClose);

As far as I understand this cannot be solved with custom DelimitedProcessors, for DelimitedProcessor.process() to be called, canOpen() (which is calculated in the code snippet above) must be true in processDelimiters(Delimiter):

...
if (opener.canOpen() && opener.delimiterChar == openingDelimiterChar) {
    potentialOpenerFound = true;
    usedDelims = delimiterProcessor.process(opener, closer);
    ...

So in other words I couldn't find an easy way to change this behaviour.

Describe the solution you'd like
I would like for it to be possible to somehow define custom flanking rules for certain delimiter runs. Maybe the part in InlineParserImpl responsible for calculating canOpen/canClose and constructing DelimiterData could be lifted into an interface of some kind, or a public method in InlineParserImpl so that it can be inherited from and the method overriden.

Describe alternatives you've considered
Copying InlineParserImpl over to my project and changing the relevant lines, then using it via inlineParserFactory when building a Parser

Vorherrschende Sprache
Java
Sterne
2.7k
Forks
336
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus commonmark/commonmark-java

Alle Issues in commonmark/commonmark-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.