I have a MatchDecorator that matches image base64 strings which are often pretty big, I noticed it’ll start failing to match when the text exceeds about 5000 characters (the strings themselves still fit the regexp), is this behavior expected? If yes is there any way to get around?
What is happening is that the editor avoids rendering parts of very long lines, and doesn’t include those in visibleRanges, which is what MatchDecorator matches over. This patch makes it match into such hidden ranges, and adds an option that allows you to control how much.
1 Like
Thanks for the fast patch! This works amazingly.
Does it make sense to allow it match the entire line instead of a range (by like maxLength: -1)? Setting maxLength: REALLY_BIG_NUMBER works, but wondering if supporting this natively would be reasonable
Right, setting it to a large number makes it obvious that any performance issues introduced are your own fault, and doesn’t require any additional code paths, so I think I prefer that.
That makes sense 
I have read this commit, but I have a problem. The number of visibleRanges I get by printing the update method is all 1, which will hit the first if, resulting in maxLength not going forward. Did I miss anything?
MaxLength is a number added to the matched regions when parts of long lines are not rendered by the editor (and thus missing from visibleRanges), to avoid missing matches that are only partially rendered. When no such hiding is happening (when visibleRanges precisely matches viewport), there is no reason to apply this kludge.
Height is set in my case, beyond which scrolling will occur. I understand that the content of viewport is only part of the content, not all of the content, so when there is a scroll bar, these two values are always equivalent. Is it related to this?