allow such matches to be cached, too, by guarding the cache
with the last used captures
makes VHDL highlighting instantanious for bug 418778
BUG: 418778
dhaumann | |
vkrause | |
nibags |
allow such matches to be cached, too, by guarding the cache
with the last used captures
makes VHDL highlighting instantanious for bug 418778
BUG: 418778
make && make test
example from bug 418778 is fast!
No Linters Available |
No Unit Test Coverage |
Buildable 23682 | |
Build 23700: arc lint + arc unit |
For the example from the bug this makes the difference between ~30 seconds on a 4 Ghz machine to << 1 second ;=)
I guess this is OK, but the concept of a "skip offset" is a bit fuzzy to me.
src/lib/rule_p.h | ||
---|---|---|
126 | I dislike this protected hack :-) |
Let me try to explain the skip offset idea (it's been years since I came up with this in GeSHi :) )
A code highlighter will repeatedly ask all highlight contexts and items therein to find the closest token to highlight next to the current cursor position.
The closest token will win and then the highlighter will repeat its question at the position after the token.
For regular expressions, it's often cheaper (as indicated by this patch once again), to match the line once starting from the current position and then remember where the first match - if any - is in the current line.
Then, the next time the highlighter asks for a token position, we can check the last matched position. This is essentially the skip offset - i.e. we know that we can skip querying the regexp again until the cursor position is beyond the next match.
Dominik, does this clear things up?
First let's have this, the current state is bad ;=)
src/lib/rule_p.h | ||
---|---|---|
126 | That is called inheritance ;=) |