Feature request: Ignore leading whitespace for SQL detection

[tysonstewart]

In our code, our queries often look like this:

const query = {
    text: `
        SELECT id
        FROM my_neat_table
...

The leading whitespace is helpful for keeping the queries aligned and tidy. Unfortunately, it also prevents the extension from detecting SQL. I recognize that I can use --sql at the beginning of the query but not everyone uses this extension. My request is to use trimStart() before checking the beginning of the string constant for a matching keyword.

[RivenSkaye]

+1 for this, especially considering multiline string literals in C# must start on the next line as well as being indented up to the depth of the closing quotes

[RivenSkaye]

Relevant additional information here is the difference between @"verbatim string literals" which are currently supported, and """raw string literals""" which include some compile-time processing to strip leading whitespace off lines which helps in visually aligning the query. Luckily the fix would be rather simple, albeit I haven't tested this yet with a local build:

// syntaxes/c-sharp-multiline.json
// Add this to the patterns array
        {
            "comment": "C# multi-line raw string literals",
            "begin": "(\"\"\"\\n\\s*)(SELECT |INSERT INTO |DELETE |UPDATE |CREATE TABLE |CREATE INDEX)",
            "beginCaptures": {
                "2": {
                    "name": "keyword.sql"
                }
            },
            "end": "(\"\"\")",
            "patterns": [
                {
                    "include": "source.sql"
                }
            ]
        },
        {
            "comment": "C# multi-line raw string literals",
            "begin": "(\"\"\"\\n\\s*)(--\\s*sql)",
            "beginCaptures": {
                "2": {
                    "name": "comment.sql"
                }
            },
            "end": "(\"\"\")",
            "patterns": [
                {
                    "include": "source.sql"
                }
            ]
        }

Edit: never mind, the current setup for this plugin depends on vscode.TextDocument.lineAt(int).text which means it's actively incapable of multiline matching... It'd need a rewrite of that logic, or at least a way to grab the next/previous line for additional checking. It could do this, based on the code of the SQL document mode, but it'd require a little extra effort.