Well interesting.
But the compare is useless. SInce you are not comparing with what the highligther does in a normal scan.
(
And if you did, as I wrote before, the current hash, has an implementation flaw. If a hash is matched it should first compare with the potential word, and then call the sub. Yet it calls the sub and compares there. Thats wasted time.
So for a fair compare, you need to rewrite the hash in the HL first.
)
Also You compare words, that already know the len. But the HL does not have that luxury.
If the HL would know the wordlen upfront, it could use that.
But parsing the text into words is part of the time a HL needs to spent.
---------------
I am not going to see, if I can find a word that fails it (since that would be a brute force search... / and for the few pascal keywords it will likely not exist.)
But in a highlighter with user configured keywords, it will be possible to have a set of keywords, that allow a none keyword to be matched.
After all: Each of the individual checks is just a partial check.