| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
Ensure we check the results from our own regex impl in all uses of
regexs in Kakoune.
|
|
|
|
|
|
|
|
Always remove threads with lower priority that end up on the same
instruction as a higher priority thread (as we know they will behave
the same from now on)
|
|
|
|
In addition to running boost regex, run our custom regex and compare
the results to ensure the two regex engine agree.
|
|
|
|
|
|
This is the most common syntax in various regex variants.
|
|
We do not support anything else than a plain literal string for
lookarounds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Display the place where parsing failed, refactor code to make
RegexParser a regular object.
|
|
|
|
Previous behaviour was treating {N} as {N,}
|
|
This is more extensible and should allow easier support for non ranges
classes.
|
|
That way we can see which features are missing.
|
|
|
|
|
|
Ensure threads are maintained in "priority" order, by having two
split instruction (prioritizing parent or child).
|
|
|
|
Always compile a `.*` as the first instructions in a regex bytecode,
depending on the match or search mode, the RegexVM will either execute
this or skip it and start directly at the matching bytecode.
|
|
Introduce the CompiledRegex class, rename ThreadedExecutor to
ThreadedRegexVM, remove the RegexProgram namespace.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Split now creates a new thread and keep the current one running, as
all of its uses are compatible with this behaviour, which enable a
more compact compiled code.
|
|
|
|
|
|
|
|
|
|
Just compose, to avoid coupling Highlighters with the Highlighter
interface. And yeah, that naming is a bit confusing.
|
|
|
|
Fixes #1653
|
|
|