Josh Goebel

It seems auto-detect by error isn't workable: ```js > "p{ID_Start}".match(/\p{ID_Start}/) // yes, non-UTF8 [ 'p{ID_Start}', index: 0, input: 'p{ID_Start}', groups: undefined ] ``` Since this \p stuff seems to be...

Problems with per-regex: - Often they are strings (so there is a HUGE legacy cost to upgrading). Though maybe this could be done by machine? - I suppose you could...

Update: This can now be taken up one language at a time - now that we allow turning on UTF8 regex per languages - (so we can test for performance...

You'll likely need to edit `keywords/$pattern` also. (See docs). The default pattern only matches ASCII keywords.

See `aliases` and `registerAliases`.

> languageDetectRe Yep, I'd say that would fix your issue.

In the recent past the parser assumed any expression like `.keyword` or `keyword.` could not be a keyword... recent parser changes broke this behavior (see #2428) but I'm not sure...

Here is my issue with the prior behavior `.` keyword behavior: You write: ```js contains: [ {beginKeywords: "mud dirt gook"} ] ``` But what you really get [behavior] is essentially:...

I'm not suggesting `METHOD_GUARD` is how we should solve this. Both solutions are kludgy. Honestly you'd want this to 'just work'. But for the prefix case we really need negative...

@egor-rogov @allejo Any thoughts? CC @marcoscaceres I'm surprised we have no tests for this behavior (when we sort it out we should add some)... but it wouldn't just be Java...