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

using black as formatter will need two runs on four+ newlines #11001

Closed
hochreitercorpuls opened this issue Apr 7, 2020 · 7 comments
Closed
Labels
area-formatting bug Issue identified by VS Code Team member as probable bug

Comments

@hochreitercorpuls
Copy link

hochreitercorpuls commented Apr 7, 2020

Environment data

  • VS Code version: 1.43.2
  • Extension version (available under the Extensions sidebar): 2020.3.71659
  • OS and version: Windows 10 18363.752
  • Python version (& distribution if applicable, e.g. Anaconda): 3.7.7 (Anaconda)
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
  • Relevant/affected Python packages and their versions: black 19.10b0
  • Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version #3977): disabled
  • Black arguments: "python.formatting.blackArgs": []

Expected behaviour

given a python file like this (with 4+ lines between import statements and the first function definition):

import numpy as np




def test():
    return 0

I'd expect running black inside VS Code to reformat the given file would lead to a file like this:

import numpy as np


def test():
    return 0

with two newlines after the import statements. Running black link_to_file.py manually in a conda shell does exactly what is expected.

Actual behaviour

Actually a first run of black leads to three newlines inbetween imports and first definition

import numpy as np



def test():
    return 0

and a second run is needed to get to the expectet result.

Steps to reproduce:

see above

@hochreitercorpuls hochreitercorpuls added triage-needed Needs assignment to the proper sub-team bug Issue identified by VS Code Team member as probable bug labels Apr 7, 2020
@karthiknadig karthiknadig self-assigned this Apr 7, 2020
@ghost ghost removed the triage-needed Needs assignment to the proper sub-team label Apr 7, 2020
@karthiknadig
Copy link
Member

The issue seems to be with this line where we parse diffs:
https://github.com/Microsoft/vscode-python/blob/61b179b2092050709e3c373a6738abad8ce581c4/src/client/common/editor.ts#L74-L79

We should likely get rid of the diff-match-patch and generate the edits directly. somewhere between extracting the patches and re-applying line ending we are adding additional line endings.

@hochreitercorpuls
Copy link
Author

hochreitercorpuls commented Nov 2, 2020

Now with VS Code Python 2020.10.332... also the second black run fails - leaving the file with two lines between imports and function definition.

import numpy as np


def test():
    return 0

sorry for the confusion - @ichard26 is absolutely right - i got confused about what was exepcted and what wasn't

yet the other issues remain.

@ichard26
Copy link

ichard26 commented Nov 2, 2020

@hochreitercorpuls that is expected behaviour as top level functions (and classes too) are always surrounded by two empty lines (unless it's at the start or the end of the file) by Black.

@TBBle
Copy link

TBBle commented Dec 31, 2020

I've just found that the VSCode-black integration is not adding a newline to the end of a file that does not have one.

I suspect this is the same problem as this, based on other similar problems being duplicated to this issue.

Manually adding the missing line is not removed when saving, suggesting that it's the same issue as this.

With the same binary, black --check rejects such a file (as does my CI pipeline, thankfully), and manually running black without --diff (as used by VSCode) does add the missing newline.

As a workaround for this, I can set Python files to always insert the final newline in my setings.json.

  "[python]": {
    "files.insertFinalNewline": true
  },

although I'm not currently having problems with excess final newlines being removed, I assume setting files.trimFinalNewlines similarly would work around that form of this problem.

As a quick sanity check, I confirmed that the problem happens in both LF and CRLF file modes.

@ichard26
Copy link

@TBBle it's an issue on Black's side not VS Code's -> psf/black#1662

@TBBle
Copy link

TBBle commented Dec 31, 2020

Ah, thank you. Sorry for the noise.

@github-actions github-actions bot removed the needs PR label Aug 9, 2022
@karrtikr karrtikr added the needs PR Ready to be worked on label Aug 9, 2022
@karthiknadig
Copy link
Member

karthiknadig commented Oct 17, 2023

This should be working better with the formatter extension, please try that.
https://marketplace.visualstudio.com/items?itemName=ms-python.black-formatter

This feature is moved to the extension, and future features and bugs will be addressed there: https://github.com/microsoft/vscode-black-formatter

@karthiknadig karthiknadig closed this as not planned Won't fix, can't repro, duplicate, stale Oct 17, 2023
@github-actions github-actions bot removed the needs PR Ready to be worked on label Oct 17, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 17, 2023
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

6 participants