-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix parsing issues #149
Fix parsing issues #149
Conversation
Codecov Report
@@ Coverage Diff @@
## main #149 +/- ##
==========================================
- Coverage 94.41% 94.39% -0.02%
==========================================
Files 42 42
Lines 1755 1749 -6
==========================================
- Hits 1657 1651 -6
Misses 98 98
Continue to review full report at Codecov.
|
Great job! I'm seeing some weirdness:
Are my expectations in line with what you are aiming for? Regardless, the last one seems unexpected 😉 |
Your work on this issue is much appreciated! 👍 |
Indeed, thank you. This case was not explicitly covered in a unit tests (added now) Actual behavior: Expected behavior: This should be fixed now: |
Here, the parser takes all between first opening and closing brace as |
Agreed. Yeah, i’ve written some parsers and it can get really messy. Your PR sure adds a lot of value as-is. Great job! |
Ooohh, how wonderful! Stay tuned 😁 In the end, the current parser must be re-written from scratch, as it's essentially unchanged since v1.6 or longer: |
* Reference to issues #148, #147, #143 * Updated README.md * Fix for #149 (comment) * Update CHANGES.md
This PR addresses issues referenced in #148, #147, #143.
Also fixed:
If the last item of a format string was an uncompleted
Placeholder
(e.g. ending"like {uncomplete"
), the parser now takes it as an erroneousPlaceholder
, not as aTextLiteral
(as it was the case until v2.6.2).@andersjonsson @nikita-starostin @hugoqribeiro: Your feedback on this PR would be appreciated.
@andersjonsson @nikita-starostin Since v2.6.2 the following issue is breaking backward-compatibility:
Parser.ErrorAction.MaintainTokens
: If one of serveralPlaceholder
s hasParsingErrors
, allPlaceholder
s are just displayed with their tokens. Expected: OnlyPlaceholder
s withParsingErrors
should show up with their tokens, others should be formatted.This has been fixed,
Other issues with the
Parser
have been fixed, too:Parser.ErrorAction.Ignore
: OnlyPlaceholder
s withParsingErrors
becomestring.Empty
, others are formatted.Parser
found aParsingError.TooManyClosingBraces
, this closing brace was simply "swallowed-up". Expected: The redundant closing brace should be treated as a literal. Otherwise the result withParser.ErrorAction.MaintainTokens
has differences to the original format string.@hugoqribeiro @nikita-starostin: You are using SmartFormat.NET for processing HTML strings with JavaScript or CSS.
SmartFormat/src/SmartFormat.Tests/Core/ParserTests.cs
Line 172 in ced05bb
SmartFormat/src/SmartFormat.Tests/Core/ParserTests.cs
Line 260 in ced05bb