forked from jgm/pandoc
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
RST reader: remove support for nested inlines, closes jgm#4581
- Loading branch information
Showing
2 changed files
with
22 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5c45bba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect that moving the
str
andwhitespace
parsers down in the list will have a significant performance impact: have you measured this?If it is significant enough, it might be a good idea not to reuse
inlineContent
ininline
, as you do above.5c45bba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot spot any performance loss due to this change. The following
mean times are for the RST writer on the current master branch
(a2816cc):
The following times are for branch
italia/4581
which i just rebasedon
master
:Anyway you make a good point, it would be better to run shorter parsers before the longer ones. Would it work if, in the expression for
inline
, we movedinlineContent
up to the second position afternote
?5c45bba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5c45bba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well maybe we lose some performance points but i find that the code is less error-prone and more readable this way. It makes sense to first try to parse potential wrappers, and then parse for plain content. So is there anything we still want to change in this pull request?