Open AlanFoster opened 6 years ago
@AlanFoster, thanks for reporting. Your description was very clear and it was easy to reproduce.
From a first look, this is the result of ANTLR4 producing a seemingly "flawed" lexer ATN. Looking at this ATN I get the impression that SELECT is just as valid as SELELECT and SELELELELECT and SELELELELELECT, which (me being now the auto-suggester) makes me not suggest anything.
However when testing this grammar with ANTLR4 directly, it seems that ANTLR4 is somehow able to distinguish between these inputs and only accept SELECT as valid. I will look more deeply into why this is happening, and ask around.
@oranoran Thanks for the quick response! I poked around a bit and added the-atn
flag to antlr and copied the results in graphviz to learn a bit more about the concept of ATNs, as it's all a new concept to me.
Interestingly I found that the following grammar doesn't have the same problem:
grammar Expr;
prog: SELECT ;
SELECT : [sS] [eE] [lL] [eE] [cC] [tT] ;
WS: [ \t\n] -> channel(HIDDEN);
The above grammar generates the correct output now:
{
"input": "",
"errors": [],
"suggestions": [
"select"
]
}
Hey, I like the idea of this module - but I'm running into a bit of an issue with a simple auto-completion scenario.
I haven't taken a look at the source code yet but the npm module isn't generating any suggestions for an empty string and the following grammar:
When there is no output, I would have expected an auto suggestion of
select
, but there is no suggestion given:However, if I change the grammar to remove the repeated
E
letter withinSELECT
it works as expected:With the above change to the grammar, the autocomplete now suggests the initial token as expected, without the additional e of course:
I am using Antlr 4.7.1, and the code is mostly from the read me:
I can create a failing test / provide an example test project to help with debugging, just let me know how I can help :+1: