Repository navigation
Combined emphasis and strong emphasis wrong output #979
Description
Not sure ***word*** is actually supported, although it does seem to work in general. But with 3.2.2:
>>> markdown.markdown("""traced ***along*** bla **blocked** if other ***or***""")
'<p>traced <strong><em>along</em></strong> bla <strong>blocked*<em> if other </em></strong>or***</p>'
I.e. the strong emphasis on "blocked" is not ended, but emphasis started instead.
Activity
paulmelis commentedon Jun 13, 2020
Similar case but here the combined emphasis later in the string causes the earlier strong emphasis to get output incorrectly:
paulmelis commentedon Jun 13, 2020
Workaround by combining
**and_works, I guess I'll use that:waylan commentedon Jun 13, 2020
@facelessuser I expect this was introduced in your refactor of inline parsing. Could you take a look at this?
facelessuser commentedon Jun 13, 2020
@waylan, I think it is triggered by the case
**text*text***. I think we added logic for this case and allowed it to have the same "dumb" logic that the other patterns have. Even my variant in the BetterEm extension suffers from this unless "smart" logic is enabled:Basic logic:`
Smart logic:
In short, the current recognition for
**text*text***doesn't pay attention so much to the word boundaries and white space, but maybe this particular case should be more intelligent and selective on what it recognizes. It may make sense to reduce the chance of this particular cases chance of matching with a little intelligence in regards to word boundaries and whitespace.I'll have to take a deeper look at exactly what causes this failure, but I suspect my initial gut feeling is most likely, and by tweaking this case to be more strict will prevent these problems.
facelessuser commentedon Jun 14, 2020
I'll look into this case when I get a chance. This matching case is clearly too greedy and should be limited.
facelessuser commentedon Jun 14, 2020
Doing some simple tests, I think the best approach is maybe to handle both
**text*text***and**text**at the same time. I'll probably adjust the pattern**text*text***pattern to handle**text**in the same step, favoring**text**first. I think that'll basically fix things.In short, we don't want to run
**text**by itself first, because then it'll make**text*text***impossible to catch. But if we handle**text**and**text*text***in the same step, we can detect both. I think we just had test cases that were too simple to catch issues as exposed in this issue.facelessuser commentedon Jun 14, 2020
It's possible moving the pattern order is all that's required as I believe we now cycle through the patterns on each
*detection with the new approach. Which is different than the legacy approach which would run one pattern on the whole paragraph before the next pattern. So, it's likely this will require no pattern changes, and simply an order change favoring**text**over**text*text***.facelessuser commentedon Jun 14, 2020
In the end, I think I'll probably just go with this:
This limits the
**text*text***case to not not allow any*to appear between the first section (**text*). This will prevent**text**text***from matching, which is basically what is happening above. This simple restriction should make the above pattern more reliable, and prevent it from being too greedy. I'll run more tests and such this week to make sure there are no adverse side effects, but this seems like the best choice with the limited tests I've just run.facelessuser commentedon Jun 20, 2020
I believe we have a fix in Pull #984.
Fix issues with complex emphasis