search

grantjenks / blue

The slightly less uncompromising Python code formatter.
https://blue.readthedocs.io/
Other
395 stars 21 forks source link

Consider supporting tabs #64

Open grantjenks opened 2 years ago

grantjenks commented 2 years ago

See “tan” at https://github.com/jleclanche/tan/commit/e23c038167528bdacddd6779c6b4234e2634cfa3

There seem to be some arguments around accessibility for supporting tabs.

warsaw commented 2 years ago

I personally agree with @ambv in that thread. Tabs are fundamentally problematic because no one can agree on whether they should equal 4 spaces or 8. Mixing tabs and spaces is an impossibility for this reason, but even supporting all tabs is a problem because source files will not be portable (your IDE says tab=4 spaces, mine says they = 8).

KOLANICH commented 2 years ago

Tabs are fundamentally problematic because no one can agree on whether they should equal 4 spaces or 8

Tabs take the amount of spaces configured in .editorconfig file.

KOLANICH commented 2 years ago

If an IDE/text editor doesn't support .editorconfig files aleady, it should be replaced. Every sensible IDE (Qt Creator, Kate, Notepad++, Sublime, Atom, VS Code, Visual Studio, NetBeans, IDEA, Eclypse, ...) already supports them for a long time (either itself, or via a plugin). If it doesn't, it is a non-sensible IDE.

so-rose commented 1 year ago

+1 for tabs! Would a PR be welcome?

KOLANICH commented 1 year ago

Barely a vanilla black, but with tabs: https://github.com/KOLANICH-tools/antiflash.py

Note: it currently has issue with tabs in multiline comments.

so-rose commented 1 year ago

@KOLANICH tan is relatively frequently updated. I figure it could be merged painlessly into blue. Maybe after a rebase.

Considering the philosophy of blue, maybe it's best to just suggest the PR (along with a good argument for it) and see what happens?

I like the idea of grouping all these sorts of black customizations into one effort; it kind of helps the case, support, etc. . blue is, for example, already nicely supported in the null-ls plugin feeding neovims LSP client, right alongside black.

KOLANICH commented 1 year ago

tan is relatively frequently updated.

3 months obsolete, 82 commits behind psf:main

I figure it could be merged painlessly into blue. Maybe after a rebase.

Wrong approach, as I have said. Most of tools based on black making it more compromising maintain own forks of it. My tool is not a fork, it is an AST-level monkey-patch, in some situations when there are conflicts in line-based tools like git, AST-level patches have no conflicts. It allows me to apply it automatically to black and not to touch its source code at all, while black is just updated. I don't have to update 2 tools, instead I just update only black. But thank you for the hint.

But there is a problem with black. It is terribly slow, even with uvloop. Though autopep8 is even slower.

sciyoshi commented 1 year ago

@KOLANICH FWIW we just updated tan against the latest release of black (22.12.0).