Expose matched rule name

[AlanFoster]

I wonder if it's possible to expose the matching rule name as part of the autosuggest API? i.e. Let's consider the following SQL input string that we would like to provide suggestions for:

SELECT * from <cursor>

If we've defined the following grammar:

grammar Expr;

prog:
    SELECT
    selection
    FROM table
    ;

selection:
    '*'
    ;

table: IDENTIFIER  ;

// Keywords
SELECT : [sS] [eE] [lL] [eE] [cC] [tT] ;
FROM : [fF] [rR] [oO] [mM] ;

IDENTIFIER: [a-zA-Z] [a-zA-Z_0-9]+ ;

WS: [ \t\n] -> channel(HIDDEN);

I can see from where the cursor is, that the grammar would expect parse the table rule name next, which happens to be an IDENTIFIER token.

Currently if we use this library we'll get given the following autosuggestions list:

{
    "input": "select * from ",
    "errors": [],
    "suggestions": [
        "aa",
        "ab",
        "ac",
        "ad",
        "ae",
        "af",
        // ... etc etc ...
        "zr",
        "zs",
        "zt",
        "zu",
        "zv",
        "zw",
        "zx",
        "zy",
        "zz"
    ]
}

This module generates a list of valid identifiers, but if it exposed the matched rule name as part of this module's API, we could see that the matching rule name is table, and we could apply our own domain knowledge to provide a richer auto suggestion list, i.e. Looking at the database schema and suggesting the available table names instead of guessing valid identifiers.

Let me know your thoughts! 👍

[AlanFoster]

This is pretty cool too: https://github.com/mike-lischke/antlr4-c3

[oranoran]

I was thinking of doing a slightly different idea for the same purpose, where as part of the configuration for the auto-suggester, the user can provide an optional mapping of token name => callback.
Then if the cursor is at a token type that has a callback defined, we use that callback to generate suggestions. The callback may, for example, call the server, to get a list of completions.

So basically it's the same idea, except that we'd be using a callback mechanism, which I think makes the experience more streamlined.
The upside of your approach though is that the complexity of what to do with asynchronous callbacks (e.g. calling a server) is left up to the user. I'm not 100% decided on the right approach, guess the time to decide will be before implementing it! LMK if you want to try to implement it yourself.

[AlanFoster]

Hey, I've been playing around with antlr4-c3 more, and it seems to offer the most flexibility to the end user by having a very unopinionated API, and as a result the library is very composable

[unsupervisednn]

I would like this too, I need to provide fuzzy matches for some rules instead of the explicit values.

Will look into antlr4-c3