Nathan

> I have no idea why I did this. The `senseVideoMotion` watcher used to do this. (https://github.com/LLK/scratch-flash-common/commit/05ead51dec0c42f599bba049949ef1b38ed53915)

👎 This falls afoul of our commandment not to parse RegExps. The reason we don't is because there are lots of edge cases and compatibility oddities we don't want to...

@tjvr thoughts? I really don't think we should use multiple RegExps at runtime, but parsing RegExps to find and alter backreferences still seems error-prone. However, it might be worthwhile here,...

> The following works fine for me: That only works for me if I have another token type in the list; otherwise it generates the regex `/(?:)/my` and then [fails](https://github.com/no-context/moo/blob/6d41d9a3fbb1c8a9808a901d27b21170991804e5/moo.js#L316)...

@moranje > Preferably there would a way itself to having access to the `offset`, `col` and `line` parameters of the offending token. The `moo.error` notation already gives you that information:...

@eemeli If I understand what you're describing, you can do that without modifying moo or using its internals: ```js const moo = require('moo') const main = { left: {match: /{/,...

```js const moo = require('moo') const lex = moo.compile({ ws: {match: /\p{White_Space}+/u, lineBreaks: true}, word: /\p{XID_Start}\p{XID_Continue}*/u, op: moo.fallback, }) ;[...lex.reset('while ( a < 3 ) { a += 1; }')]...

`moo.keywords` only works properly when you use it on a `match`er that matches anything that could be a word—not just keywords. For example, this lexer doesn't work the way you...

> I haven't found that in the doc nor in the tests. We should probably have a test for that. The `/u` tests are a bit sparse at the moment.

> Could you explain what `fast` is? It comes from https://github.com/no-context/moo/pull/40 / https://github.com/no-context/moo/pull/103. It makes single-character tokens significantly faster.