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

Implement format on type for proper indentation #1613

Closed
brettcannon opened this issue Jul 28, 2021 · 8 comments
Closed

Implement format on type for proper indentation #1613

brettcannon opened this issue Jul 28, 2021 · 8 comments
Assignees
Labels
enhancement New feature or request fixed in next version (main) A fix has been implemented and will appear in an upcoming version

Comments

@brettcannon
Copy link
Member

microsoft/vscode-python#481 is the most requested feature in PVSC. Solving it via format-on-type is probably the easiest and most consistent way. Since Pylance knows what the indentation level is, when things would only be syntactically appropriate if it was dedented, etc., Pylance is probably in a great position to be able to support this via https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#textDocument_onTypeFormatting.

@savannahostrowski
Copy link
Contributor

savannahostrowski commented Jul 28, 2021

I was under the impression that indentation was something that the Python extension in VS Code was going to handle (I'd previously brought this up). I would also think we'd want this to work regardless of the language server the user has selected?

@brettcannon
Copy link
Member Author

I think it's something to discuss since fixing someone's indentation to make the code valid is "formatting", but also somewhat of an implicit linting fix.

@erictraut
Copy link
Contributor

Is auto-indent something that can be controlled through the LSP interface? I'm not aware of any facility for this. Maybe @jakebailey is aware of something here.

I'll also point out that since that feature request was filed, auto-formatters have become much more popular and prevalent in the Python world. The black auto-formatter, in particular, is really popular. I wouldn't want to code without it. When an auto-formatter is installed, the value of auto-indent drops to close to zero. I wonder if we have data about how many VS Code Python users have an auto-formatter installed and configured?

@brettcannon
Copy link
Member Author

We do know the percentage of machines that do have formatting turned on and it isn't very high (depending your definition of "very high" 🙂).

@jakebailey
Copy link
Member

jakebailey commented Jul 28, 2021

VS Code has a thing called "on enter rules" which are intended to do indention when you enter a new block. These rules are statically declared by a language provider in a config with regexes that say "if you see this, then insert one indention", and so on. https://github.com/microsoft/vscode-python/blob/3698950c97982f31bb9dbfc19c4cd8308acda284/src/client/language/languageConfiguration.ts#L13

The problem is that it's really difficult to get this right with regexes alone; it works better in brace languages, but not so much in Python. There's a really long discussion about this, and I had tried to get the API expanded out to be a little more powerful so we could better see the context and offer indentions that aren't multiples-of-indent. microsoft/vscode#66235

On enter rules are a VS Code thing, and are not a part of the LSP spec.

As a workaround for not having a better on enter rule, on-type formatting could be used with a \n trigger character, such that an extension or LS is called instead, and can then send the correct text edits to perform the same operation that an on-enter rule might.

There are downsides to this; on-type formatting is not enabled by default in VS Code, so we'd need to force enable it for all Python users, which then means ripping out any other on-type formatters that don't simply do on-enter fixups. It's also slower (done via APIs/out of proc versus static rules), and may mismatch with whole-file formatting done by formatters like black or autopep8 (none of which support formatting at a finer grain than the entire file at once). Some users' issue with the current rule (as microsoft/vscode-python#481 shows) is not that it's "invalid", but that it's not their particular formatting choice, which adds more complexity.

@jakebailey jakebailey added enhancement New feature or request needs decision Do we want this enhancement? labels Jul 29, 2021
@github-actions github-actions bot removed the triage label Jul 29, 2021
@gramster
Copy link
Member

Do we really have to force this and disable others? We could make it a setting and leave it to users to enable it and make sure there are no conflicting handlers. That seems like an MVP that we could use to evaluate if more is needed.

@jakebailey
Copy link
Member

We could ask them to set:

{
    "[python]": {
        "editor.formatOnType": true
    }
}

Manually. It's just not super discoverable.

@debonte debonte removed the needs decision Do we want this enhancement? label Apr 19, 2022
@debonte debonte self-assigned this Apr 19, 2022
@debonte debonte added the fixed in next version (main) A fix has been implemented and will appear in an upcoming version label Sep 9, 2022
@debonte
Copy link
Contributor

debonte commented Sep 15, 2022

This issue has been fixed as an experiment in prerelease version 2022.9.21, which we've just released. You can find the changelog here: CHANGELOG.md

The experiment will be enabled for a percentage of prerelease users in the near future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed in next version (main) A fix has been implemented and will appear in an upcoming version
Projects
None yet
Development

No branches or pull requests

6 participants