Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose matched rule name #9

Open
AlanFoster opened this issue Aug 12, 2018 · 4 comments
Open

Expose matched rule name #9

AlanFoster opened this issue Aug 12, 2018 · 4 comments

Comments

@AlanFoster
Copy link

AlanFoster commented Aug 12, 2018

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
Copy link
Author

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

@oranoran
Copy link
Owner

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
Copy link
Author

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
Copy link

unsupervisednn commented Jan 21, 2020

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

Will look into antlr4-c3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants