caseInsensitive lexer rule option not yet supported

[amarach78]

Hi, I noticed that the option caseInsensitive is not yet supported. It can be used for a specific rule. example: options { caseInsensitive=true; } STRING options { caseInsensitive=false; } : 'N'? '\'' (~'\'' | '\'\'')* '\'';

source: https://github.com/antlr/antlr4/issues/3436

[mike-lischke]

Keep in mind this is only available for ANTLR 4.10, which is not supported in the extension right now.

[david542542]

@mike-lischke also wondering when this item might be available?

[mike-lischke]

This will happen not before I have a 4.10 TS runtime. The runtime I'm currently using (antlr4ts) will not support 4.10, so I'm working on a new TS runtime, which is in fact a full port of ANTLR4 to Typescript. This will, however, take some time.

[david542542]

@mike-lischke that's so cool, and thanks for the response. Out of curiosity, how long do you think this might take -- 6 months? a year? a couple months? etc. Just wanted to see when I should check back in for an update and good luck with the port can't wait for it!

[mike-lischke]

Good question. You know, programmers are notoriously bad at guessing an ETA. So, I'm really not sure how long this will take, given my time constraints and other factors. I'm also working on a tool that can convert Java to Typescript (which is used for this port). This has grown pretty well and I'm mostly in the process of cleaning up the generated code (and improve the converter tool, if something comes up that could be handled automatically). As you can see in the repo I already have converted all files in the ANTLR4 Java runtime folder (but not all are cleaned up and I might have to write more shims for Java SDK classes).

My hope is to get a first working version at the end of the year.

[jillesmc]

Hi @mike-lischke. I'm new to this world of parser generators using antlr4. I'm currently just running some tests, but I can already tell that you've done an excellent job.

I found that version 4.12 of Antlr4 supports Typescript natively. Wouldn't it be better to migrate to the official version to have these new features?

I'm a complete newbie to the subject, so this is a legitimate question. :sweat_smile:

[mike-lischke]

Thanks @jillesmc for your nice words. Unfortunately, the "typescript support" in ANTLR4 is incomplete. While the tool generates TS parsers, lexer, listeners etc. it does not provide a full TS runtime, but rather just a couple of typings on top of the Javascript target, which is just enough to accomplish some standard parsing tasks. By far not enough for advance use cases like what's needed in this extension. I'm afraid I have to complete the full TS runtime first, before I can continue with new features.

[matthew-dean]

@mike-lischke Is there a way to "escape" the option in the lexer so that it isn't flagged as an error? Maybe the options block could just support setting any identifier?

[mike-lischke]

tbh. I hesitate to hack this in, while working on the real solution at the same time (and later remove it again). The new runtime I'm working on comes along pretty well already. I'm actively porting my code completion library to it currently. Next step is adding the same benchmarks like antlr4ts has to compare speed and functionality and after that probably the extension is ported as well.

[mike-lischke]

Fixed after switching to the new ANTLR4 TypeScript runtime.