Inflloop in font-lock due to mismatched cache #110
Merged
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.
I have got an infloop report from multiple users (polymode/polymode#87) in poly markdown modes. It's hard to reproduce. I have tracked it down to markdown proper and it's due to the fact that cached matched data at POS ends at (1- POS). This is strange. I don't have a reproducible example outside polymode but I am pretty sure it must be happening in simple markdown files as well. You might have a better idea of why and where this dismatch in position happens.
This pull is a generic fix of such anomalies directly in
markdown-match-propertized-text
. It simply ensures that matcher moves the point at least one char beyond current point. This is what internal font lock code expects and implements itself (font-lock-fontify-keywords-region
). Info for function matcher suggests the same:I am attaching the relevant part of the tracing that clearly pins it on infloop of
markdown-match-heading-1-atx
which returns matched data (1331 1345) while the current point and the position where this data was cached is 1346.