-
Notifications
You must be signed in to change notification settings - Fork 28.4k
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
Allow more powerful onEnterRules for cursor alignment #66235
Comments
(Experimental duplicate detection) |
This thread is related (I missed this thread when looking around): #3088 (comment) |
fyi @jrieken Yes, I think #17281 could be a promising solution for this use case. With a lot of inspiration from snippets, I imagine the following rule could cover the above: def func(a,
| {
beforeText: /^\s*(def \w+\().*,$/,
action: { indentAction: IndentAction.None, appendText: '${1/./ /g}' }
}
|
That's definitely a compelling solution; I wasn't aware of that snippet grammar. One concern I had with anything using {
beforeText: /^\s*(def \w+\().*,$/,
action: { indentAction: IndentAction.None, appendText: '${1/[^\t]/ /g}' }
} And be able to mostly do the right thing, though we'd have to figure out how to ensure hitting enter doesn't insert something that makes the Python interpreter fail. (That's part of the reason I included |
That's why I am very much in favour of the format-on-type-solution. @jakebailey Sure, it's called format-on-type but no rule exist that it must do the full formatting cycle, e.g. for a start you could implement (one shared) formatter that does exactly (and only) what is desired here.
Maybe you can implement it once, in the TS portion of your extension. The provider knows for what character and position it is invoked.
What the formatter does it up to your implementation and your extension is also free to enable format-on-type for it self. |
Thanks, but we will only need this for the language server (one place). @jakebailey /cc
@jrieken |
Could it be done same way on type formatting works? I.e. ask for text edits on enter and apply the returned whitespace indent? We would prefer to keep on-type formatting separate from indentation, like VS IDE does. Many people like smart indentation but do not enable on-type formatter. Also, having full information and AST makes it easier and faster to calculate the indentation, as well as easier to debug as compared to regex. The AST is in C# in the language server. |
Yeah, you would need to change the setting on behalf on the user (for that language). We have API for this and I know that some extensions do these things. |
Something like an indentation provider? That's something we have briefly talked about and this is obviously the most powerful solution. The challenge is that it makes pressing Enter async, e.g we need to check the with the extension host process first, and that means pressing Enter might feels sticky (when the extension is slow or blocked) |
@jrieken Please could you point us in this direction.
|
@jrieken 'Something like an indentation provider?' - yes, exactly. It does can feel sticky if extension is badly written :-) (happens in VS IDE). But generally it is up to the extension to decide and deal with how to do it fast, IMO. |
Hi, can we get an update on this? Is this actively being worked on or currently somewhere in the backlog? |
@alexandrudima, @jakebailey, something along the lines of #66235 (comment) should work, but it will not meet all our needs without multi-line regex support (#50952). Dealing with regexes is a pain (as opposed to AST a la the language server), but it seems more feasible. |
One alternative, perhaps more appropriate, is to change The new types would looks like this: interface BracketRule {
brackets: CharacterPair;
onEnterAction?: BracketEnterAction[];
}
interface BracketEnterAction {
afterText?: RegExp;
indentAction: IndentAction.None | IndentAction.Indent | IndentAction.Continue;
indentActionClose?: IndentAction.None | IndentAction.Indent | IndentAction.Continue;
} The current default appears to be: { // BracketEnterAction
indentAction: IndentAction.Indent,
indentActionClose: IndentAction.None
} (This could also help with #67678.) |
Another reason we are after more powerful rules: if a:
print("a")
else: # Should be dedented after pressing Enter. With the current Even extending |
Yep, that's a good feature. Just wanted to add on a complex interaction I had to solve for in my extension recently, in case someone uses this thread as a place to find requirements :) if a:
return a # next line should be dedented
def f(a):
if a:
return a # next line should be dedented
else: # since this line was already dedented because of the return, do NOT dedent on Enter
return not a |
In the Python extension, we'd like to add support for variable-length indents on enter to better support PEP8 formatting (microsoft/vscode-python#481 and others). For example:
Hitting enter on the first line should stick the cursor where
|
is, not just a single indent. In this second case, it should do a single indent:There appears to only be two ways to handle this:
onEnterRules
We'd like to avoid the latter, as we currently support both Jedi and our own language server, which means implementing on-type formatting in two different places (since a single language cannot have multiple on-type formatting providers). Plus, on-type formatting is not enabled by default nor is very popular (and enables a slew of formatting rules other than cursor alignment), so forcing users to enable on-type formatting as a whole would be good to avoid.
The other candidate is
onEnterRules
, but it's not powerful enough to be able to do something like this, as:appendText
would be required, but...appendText
is only allowed to be a static string, and cannot be generated on the fly.My initial thought was to allow a function to be provided in
onEnterRules
instead of just specifyingappendText
. For example, something like:However, on closer inspection of how
onEnterRules
works, it appears that it needs to be serializable, so I'm not sure it'd be able to have a callback like the above.Is there something that can be added to allow more powerful rules on-enter? Or, is there something that already exists that we've missed?
The text was updated successfully, but these errors were encountered: