You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we're handling log messages outside of parsec's own state mechanism, we now get log messages even for parsers that fail. This leads to repeated, and in some cases misleading messages.
Example:
% pandoc -f rst
`click here`__
.. _link1: link2_
.. _link2: link1_
__ link1_
^D
WARNING Circular reference 'link1' at line 1 column 15
WARNING Circular reference 'link1' at line 1 column 15
WARNING Circular reference 'link1' at line 1 column 15
<p><a href="">click here</a></p>
Why do we get three messages? Well, first we're parsing the first line looking for a field list, then we're parsing for something else, then a paragraph.
Previously we used updateState from parsec to add messages to state. This worked well, because an update in a parser that fails is rolled back, so we'd only get one message.
A band-aid would be to go through the list and remove duplicates. But better to design so these duplicates don't occur. Especially because in some cases they may be misleading.
The text was updated successfully, but these errors were encountered:
jgm
changed the title
log messages even on failing parsers
Log messages generated even by failing parsers
Feb 15, 2017
See #3447. To complete fixes on this issue, we need to
do the same for the other readers. Note that the changes
required are minimal -- add reportLogMessages to the end
of the main parser, and replace report with logMessage.
(except for trace)
Since we're handling log messages outside of parsec's own state mechanism, we now get log messages even for parsers that fail. This leads to repeated, and in some cases misleading messages.
Example:
Why do we get three messages? Well, first we're parsing the first line looking for a field list, then we're parsing for something else, then a paragraph.
Previously we used updateState from parsec to add messages to state. This worked well, because an update in a parser that fails is rolled back, so we'd only get one message.
A band-aid would be to go through the list and remove duplicates. But better to design so these duplicates don't occur. Especially because in some cases they may be misleading.
The text was updated successfully, but these errors were encountered: