manticore-projects

> The naming of this RelObjectName ... methods is sure an issue that should be adressed in futher improvements. So sorry for that: its grown ... ;) You would do...

> I am not a fan of injecting those keywords, since not every keyword could be introduced this way and needs other parts of the grammar to be modified. However,...

Allow me to ask please: 1) what was your preferred way to manage and document RESERVED KEYWORDs 2) what was your preferred way to maintain any allowed Token/Keyword in `RelObjectName()`...

> The reserved keywords are introduced for syntactic rules. I do not get what you mean by documenting the keywords. How exactly does a user know what keywords are reserved...

Thank you so much for this discussion, I do appreciate looking into this topic with you. > So if I understand this right, that is the workflow: > 1. build...

BTW, rebuilding `RelObjectNames` and friends is **only necessary, when new `Token` have been added**. The situation I have in mind is: User submits a PR and introduces new `Token`, but...

The Gradle Task `updateKeywords` now updates and replaces ` RelObjectNameWithoutValue()` automatically without manual interaction. It is still an optional call, so a full build would look alike: ``` gradle updateKeywords...

> I took some days to think about this again. The goal is to automate all allowed keywords tests. Right? Maybe the documentation. Yes, and also: to automatically allow all...

> So this externalization of keywords in `getReservedKeywords` is a helper method to build parameterized tests for all this stuff. But this results in this weird workflow regenerating the grammer....

Greetings. I have modified the approach and read the Tokens directly from the Grammar file without invoking JTREE. Thus all the Keywords have been moved our of the Grammar into...