Add support for capture groups in onEnterRules

[alexdima]

From @siegebell in #3088 (comment)

---

Before:

// comment
//     indented|

After:

// comment
//     indented
//     |

For this case, onEnterRules could be extended to support matching groups like find/replace currently does...

languages.setLanguageConfiguration(modeID, {
    onEnterRules: [
        { // insert comment on new line while preserving the indent
            beforeText: /^\s*(\/\/\s*)\S.*$/,
            action: { indentAction: IndentAction.None, appendText: '$1' }
        }
    ]
});

[alexdima]

cc @jrieken

I would like to look into this in February, if I have the chance. But I would like to have it aligned with the way snippets do variables. From what I could tell snippets use both $VARIABLE_NAME syntax and ${VARIABLE_NAME} syntax. There is also a question of ambiguities in case afterText or previousLineText are used... which capture group is appendText referring to... The way out of that would be to number capture groups based on the text appearence, so the capture groups in previousLineText would get the first N values, the capture groups in beforeText would get the next M values, and finally the capture groups in afterText would get the next O values. Finally, the question is if this should attempt to support the transform operations of snippets, but I would leave that out for now.

[jrieken]

From what I could tell snippets use both $VARIABLE_NAME syntax and ${VARIABLE_NAME} syntax.

Yes, but a variable name is [_a-zA-Z], no numbers. That means ${1} from the sample isn't a variable but a tab-stop unless it is used in variable- or placeholder-transformations where it refers to regexp matching groups. But for that it must be embedded inside the complex transform syntax.

[alexdima]

To clarify: I don't intend that pressing Enter would bring the user into snippet mode. This is more about capturing the indentation of the line via a capture group and then reusing it in appendText. I initially thought about the find/replace widget, where we use $1, $2, etc. and maybe that is a good enough syntax. There is no need to cause confusion with ${1}, ${2}, etc.

So I would just go with $1, $2...

[jrieken]

Right, using $1 (no curly brackets) is a good fit

[hediet]

Before:

// comment
//     indented|

After:

// comment
//     indented
//     |

For me, there are two indentations in this example.
The indentation of the comment and the indentation of the text within the comment.
I find it strange to use two different strategies to handle these indentations (explicit indent/dedent/none actions of the onEnter rule vs regex whitespace group references in the insert text).

Is there a scenario where it makes sense to reference a regex group that matches non-whitespace text?

Also, should indentation/dedentation be supported for nested indentations (rather than just keeping the indentation as is)?

Maybe it might also be valuable to consider embedded languages in general. Imagine using a markdown codeblock in doc-comments:

/**
 * Example:
 * ```ts
 * class Foo { <<User types enter here>>
 *
 * ```
 *
 */
function bar() {}

Ideally, the outer and inner typescript rules would be combined somehow, yielding this:

/**
 * Example:
 * ```ts
 * class Foo {
 *     <<New Cursor Position>>
 *
 * ```
 *
 */
function bar() {}

Currently VS Code ignores the rules of the inner language.

This feature would not fix #66235 anyway.

I think this feature might require more discussions.
Until then, it could be investigated how parts of this feature can be implemented by extensions listening on onDidChangeTextDocument and issuing edits and selection updates instead.