Repository navigation
fix: ignore marker delimiters that come from ordinary code - #244
Merged
Merged
Conversation
Benchmark ResultsComparison of Open to see the benchmark results
Generated by phpbench against commit 8297742 |
There was a problem hiding this comment.
🟡 Changes recommended
The filter rejects valid block-transition markers, and repeated rejected candidates cause quadratic scanning.
2 open issues
What changed in this PR
This PR addresses #240 by filtering accidental emphasis, strong, and blur marker pairs in ordinary code through their shared injection trait.
Changes:
- Adds brace-balance checks to reject accidental marker matches.
- Continues searching after rejected candidates to find later real markers.
- Adds tests for ordinary-code collisions, marker recovery, and unbalanced braces.
| File | Description |
|---|---|
| tests/Languages/Base/HighlightMarkersTest.php | Adds collision and marker-preservation regression cases. |
| src/Languages/Base/IsHighlightInjection.php | Filters marker candidates using brace balance and retries after rejected matches. |
Review effort: Balanced
Member
|
Thanks! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #240
{_,{*and{~were read as highlight markers even when they came from ordinary code, for exampleconst {_id} = a; const {name_} = b;in JavaScript ora = {_: 1}/b = {1: _}in Python. The delimiters were hidden and everything in between was wrapped inhl-em.Cause
IsHighlightInjectionmatched any{_…_}pair. In code like the examples above, the brace of{_is closed by the code itself, so the "marker" content leaves one pair of braces and ends inside another:id} = a; const {name.Fix
A match is now skipped when its content has a
}that closes a brace opened before it, followed by a{that stays open. Real markers never do that. The search then continues right after the skipped{_, so a real marker later in the same snippet is still found (const {_id} = a; {_b_};highlightsb).This applies to emphasis, strong and blur, since they share the same trait. Custom classes (
{:class: :}) and additions/deletions aren't affected.Markers around unbalanced braces keep working:
{_function foo() {_}: an opening brace only{_ return 1;\n}_}: a closing brace only{~}): Foo {}~}: the existing case fromPhpLanguageTestTests
Added cases to
HighlightMarkersTest:_,*and~Known limitation
A marker that wraps braces in the reverse order inside a string, like
{_echo "}{";_}, is no longer treated as a marker. That seemed rare enough compared to destructuring or dict literals, but I'm happy to handle it differently if you'd prefer.