BenjaminHoegh / ParsedownExtended

ParsedownExtended is an extention for Parsedown, offering additional features and functionalities.
https://benjaminhoegh.github.io/ParsedownExtended
MIT License
37 stars 7 forks source link

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

Closed brainexcerpts closed 7 months ago

brainexcerpts commented 7 months ago

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' => '\\]'],
            ],
        ],
    ]);