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

Colon-triggered block formatter and line formatter do not coexist #2714

Closed
jakebailey opened this issue Sep 27, 2018 · 2 comments
Closed

Colon-triggered block formatter and line formatter do not coexist #2714

jakebailey opened this issue Sep 27, 2018 · 2 comments
Assignees
Labels
area-formatting bug Issue identified by VS Code Team member as probable bug

Comments

@jakebailey
Copy link
Member

In working on the line formatter (#2690), I discovered the registration of the OnEnterFormater overrides the registration of BlockFormatProviders in extension.ts.

The current code looks like this (after the introduction of the second line in #649):

context.subscriptions.push(languages.registerOnTypeFormattingEditProvider(PYTHON, new BlockFormatProviders(), ':'));
context.subscriptions.push(languages.registerOnTypeFormattingEditProvider(PYTHON, new OnEnterFormatter(), '\n'));

The last registration appears to take precedence, so you can hit enter to format a line, but if you type a :, nothing happens, say after the else in this example:

if x:
    pass
    else

If you swap the registration order so that BlockFormatProviders comes last, line formatting no longer works, but hitting : in the above code gets reformatted into:

if x:
    pass
else:

I think this may be the cause of (or at least fix) #771, since you hit : after else before you would hit enter, meaning that the else would have already been moved left to the correct position.

The documentation for registerOnTypeFormattingEditProvider states that multiple providers can be registered, and will be selected based on a "score". If the score is the same, then the last one wins, which is what is happening here. The "first" trigger character differing between two registrations doesn't seem to matter. The solution is probably to make a single OnTypeFormattingEditProvider which then dispatches based on the trigger character, like:

context.subscriptions.push(languages.registerOnTypeFormattingEditProvider(PYTHON, new NewfangledProvider(), '\n', [':']));
@jakebailey
Copy link
Member Author

jakebailey commented Sep 27, 2018

I have a working fix in a branch on my fork, but I haven't implemented the tests for the new code yet.

It'd probably also be a good idea to write some tests to ensure that this sort of thing doesn't happen again. @DonJayamanne mentioned to me that this is probably a consequence of only testing the individual parts and not together.

@DonJayamanne
Copy link

I have a working fix in a branch on my fork, but I haven't implemented the tests for the new code yet.

Please do publish a PR, or point us to the solution.

It'd probably also be a good idea to write some tests to ensure that this sort of thing doesn't happen

We can write the tests if you aren't planning on doing. If you aren't, then please do create an issue, so we do not forget about it. Thanks

DonJayamanne pushed a commit that referenced this issue Oct 9, 2018
For #2690.

Similar to #2612. Note that `:`-based formatting isn't implemented in language server yet (microsoft/python-language-server#165), but it hasn't been enabled in the extension for anyone for a while now either (fixed in #2714/#2724).

Since line formatting is relatively new in language server, this likely shouldn't make it out into a release until the language server downloaded by default is new enough to include that functionality. I haven't been monitoring that side of things, so feel free to hold off on merging this until the right time.
@lock lock bot locked as resolved and limited conversation to collaborators Nov 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-formatting bug Issue identified by VS Code Team member as probable bug
Projects
None yet
Development

No branches or pull requests

3 participants