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

Fix trailing space breaking blocks if placed after the start delimiter or end delimiter. #55

Conversation

brainexcerpts
Copy link
Contributor

Issue:

So you might not agree with this "fix" but at least a PR has the merit to document this particular way of doing things.
I'm trying to fix the following issue: having trailing spaces or characters after the block delimiters breaks parsing, for instance:

    \[ trailing space or characters here
        f_a(x) = x +a 
    ]/ or here breaks parsing

Discussion

You may object: but this is not a valid block syntax anyway and people should do a proper line return.
This is my argument: at the very least we should be agnostic to trailing spaces which happen quite often and is hard to spot.
Breaking parsing on trailing spaces would be quite confusing for the user.

Now why admit characters? Sure, why not taking into account characters after the starting delimiter... but who would ever want to put characters after the end delimiter right? (Markdown should be human readable anyway).
My argument: I have real-time rendering of my markdown code, and while typing I may for a moment forget to insert a line return. As is, it temporally breaks rendering of unrelated lines, which is confusing. I would also argue that, even without real-time rendering, if someone mistakenly leaves characters the way it breaks remains confusing.

Solution

For now my solution was to simply modify the regexpr that detect the start and end delimiters.
I allowed for any trailing characters and refeed them to the parser.

One caveat is that while I could refeed the line after the start delimiter to be inserted in the final math block.
I could not figure out how to refeed the line after the end symbol to be interpreted as markdown.
I think that's ok because as discussed, one should not actually do that anyway,
and having the markdown syntax not working for that particular line,
is probably the most graceful way to fail and hint the user that this is not the proper way.
(as oppose to break unrelated stuff around.)

    \[ will be captured as math
        f_a(x) = x +a 
    ]/ everything here will be displayed but **markdown** syntax ignored.

Settings used

    $Parsedown = new ParsedownExtended();
    $Parsedown->setSetting('math', true);

    $Parsedown->setSetting('math', [
        'inline' => [
            'delimiters' => [
                ['left' => '\\(', 'right' => '\\)'],
                ['left' => '$', 'right' => '$'],
            ],
        ],
        'block' => [
            'delimiters' => [
                ['left' => '$$', 'right' => '$$'],
                ['left' => '\\[', 'right' => '\\]'],
            ],
        ],
    ]);

…k. Captures the characters and feed it back to parsedown parser
@BenjaminHoegh BenjaminHoegh merged commit 8a65035 into BenjaminHoegh:main Feb 18, 2024
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants