Josh Goebel

What if we just allow it to take a string or array? ```js var UNDERSCORE_KEYWORDS_RE = [/_[A-Z][a-z\d_]+/, /__[a-z\d_]+/] var CPP_KEYWORDS = { keyword: ['int float while private char catch import...

I'm worried we may be overthinking this. Let me think and dig into this a bit more. :) Think there may be a few things about how we do keywords...

So seems keywords don't really seem to support regex anyways, so that one grammar is mistaken unless I'm reading something wrong. So I think right now the only way to...

Now that we have some precedent what about: ``` keywords: { $pattern: ... $modes: [ { begin: /__[a-z\d_]+/, className: "keyword" } ], builtin: ..., literal: ..., var UNDERSCORE_KEYWORDS_RE = ````...

Or perhaps something like `dynamic_pattern` would be better, no word list, if the regex matches, it's a keyword, period... ```js keywords: { $dynamic_patterns: { [/_{1,2}[a-z\d_]+/, "keyword"] ] ``` Or a...

Well, actually the intent when we added $pattern was to reserve the whole $ namespace for keyword configuration, not random values. So in the future you could imagine: ``` keywords:...

Maybe maybe just seeing the regex next to it makes `_re` clear enough in its intent? Actually the one worry I have here is that people could imagine they are...

I'm going to go back and review some of the grammars that make HEAVY use of modes for keywords and see if there is anything else we should keep in...

Interesting. ```cpp void static delayShort(uint16_t ms) __attribute__ ((noinline)); ``` What is `__attribute__` here, something else entirely? My editor (VS CODE) highlights such things and it seems helpful. (though it seems...

> Rule 3 can’t be implemented with lexical analysis alone. I'm totally open to just closing this, but also our goal has never been perfection. If we decided this was...