Greg Shrago

More Notes: 1. Let's map files directly in `run -> doGenerate` instead of `BnfRunJFlexAction#getFileIterator` (and indent the code nearby 2. Avoid copy-pasting `json.bnf` from IntelliJ repo 3. Inline `GeneratorBase.getFile()` and...

One last change, please, and we are good to go! 1. Use the same naming: `GeneratorBase.file` -> `GeneratorBase.myFile` (lots of unnecessary changes in `ParserGenerator`)

Current status: A year ago I and @vlad20012 discussed that a separate `mixedAST` flag is not needed. If possible, fast logic must always be used. `generate.exact-types` attribute can be used...

I think the static import trick is ok. We need to fix the resolution algo...

Let's process parser imports correctly. The patch is rather a hack to support that particular single case. General fix: Get all parser imports (no semicolons, btw), and cycle through `static...

FTR > > Why have a separate flag? Let us always go the fast route > It is not always clear whether there is a possibility. If generate.exact-types = "elements"...

> Without it developing a lexer is such a PITA. A simple lexer test makes it quite tolerable IMO.

JFlex is a state machine plus a user-defined java code that can also mess with states. The user-defined code sections limit our possibilities to only one option - to reuse...

"Existing lexer" is a program with any side-effects and 3rd party dependencies possible. So if the project compiles it can be run in a separate process in the module class...

The point is that *.flex can contain arbitrary java code, states, imports... It should be possible to hack and load the generated lexer as groovy script in the same VM...