Delimiter point is escaped in numbers

[dennis-hh]

I experienced some unexpected behavior while using this library.
If a text begins with, let's say "120.000", the delimiter point is escaped, resulting in "120\.000".
If the same string appears somewhere else in a string ("We like 120.000"), it is not escaped.
The reason seems to be this code in src/Converter/ParagraphConverter.php:

private function escapeOtherCharactersRegex($line) { $regExs = array( // Match numbers ending on ')' or '.' that are at the beginning of the line. '/^[0-9]+(?=\)|\.)/' ); foreach ($regExs as $i) { if (preg_match($i, $line, $match)) { // Matched an escapable character, adding a backslash on the string before the offending character $line = substr_replace($line, '\\', strlen($match[0]), 0); } } return $line; }

The regex ignores the fact that this is not a numbered list, but a regular number with a delimiter character.

[andreskrey]

I'm assuming you mean 120\.000 because is both examples you showed the same characters.

I think this is the correct behavior, if your text starts with a numbered list-like text, it should be escaped. If it is not, then don't escape it.

Can you provide an example of what's your expected behavior?

[dennis-hh]

Hey! Yes, i meant 120\.000.
I would expect that the converter correctly interprets 120. as a list item and 120.000 not as a list item.

[andreskrey]

Well, after playing with the Commonmark dingus I realized two things:

1. Behavior is correct. 120\.000 is correct as it doesn't renders as a list item. In order to trigger the list behavior you have to add a space between the dot and the following characters
2. Escaping is not necessary. 120.000 is as valid as 120\.000.

Which parser are you using to consider 120\.000 as incorrect? According to Commonmark, we are doing the right thing.

[colinodell]

According to the CommonMark spec:

Note that at least one space is needed between the list marker and any following content

While I do think that converting <p>120.000</p> to 120\.000 is technically valid, it's not what you'd expect. 120.000 would also be valid per the spec, and I do prefer that, so I've gone ahead and implemented c7f9f37 to change that.

[colinodell]

Just released 4.6.0 with this fix :)

[dennis-hh]

Awesome! Thanks for the quick solution! :)