Every one of the projects in this repository is available at the canonical
URL git://git.madduck.net/madduck/pub/<projectpath> — see
each project's metadata for the exact URL.
All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
Richard Si [Fri, 8 May 2020 14:26:29 +0000 (10:26 -0400)]
Add Black compatible configurations in documentation (#1366 & #1205) (#1371)
* Add Black compatible configs in docs ( #1366 & #1205)
When users of Black are starting a new project or are adding Black to their
existing projects, they will usually have to config their existing tools like
flake8 to be compatible with Black. Usually, these configs are the same across
different projects. Yet, there isn't any consolidated infomation on what configs
are compatible. Leaving users of Black to dig out any infomation they can find
in README.md.
* Fix a bad max-line-length value
* Clean up pylint's configs
* Add explanations for each configurations
Copying and pasting code without understanding it is a bad idea. This goes the same
for users copying and pasting configurations.
* Capitalize Pylint
* Link from the README
* Fix the isort configuration
I referenced the wrong source. I used a pesonal configuration, not a pure Black-
compatible configuration.
* Improve the config explanations
The explanation for the isort configuration was pretty bad. After having fixed the
configuration (see commit 01c55d1), improving the its explanation was necessary to
make it more user-friendly and understandable. Also added fenced code blocks of the
raw configuration options so the explanations make sense.
Allan Simon [Fri, 8 May 2020 13:46:07 +0000 (15:46 +0200)]
permits black to run in AWS Lambda: (#1141)
AWS Lambda and some other virtualized environment may not permit access
to /dev/shm on Linux and as such, trying to use ProcessPoolExecutor will
fail.
As using parallelism is only a 'nice to have' feature of black, if it fails
we gracefully fallback to a monoprocess implementation, which permits black
to finish normally.
David Lukes [Fri, 8 May 2020 13:13:54 +0000 (15:13 +0200)]
Make sure sys._base_executable is sane in Vim plugin (#1380)
The `venv` module relies on `sys._base_executable` to determine the
Python executable to run, but with recent versions of Vim, this is set
to the `vim` executable. A possible workaround is to just override it,
since the `black` plugin already overrides `sys.executable` (possibly
for similar reasons?) anyway.
Alex Vandiver [Fri, 8 May 2020 13:08:15 +0000 (06:08 -0700)]
Re-indent the contents of docstrings (#1053)
* Re-indent the contents of docstrings when indentation changes
Keeping the contents of docstrings completely unchanged when
re-indenting (from 2-space intents to 4, for example) can cause
incorrect docstring indentation:
```
class MyClass:
"""Multiline
class docstring
"""
def method(self):
"""Multiline
method docstring
"""
pass
```
...becomes:
```
class MyClass:
"""Multiline
class docstring
"""
This uses the PEP 257 algorithm for determining docstring indentation,
and adjusts the contents of docstrings to match their new indentation
after `black` is applied.
A small normalization is necessary to `assert_equivalent` because the
trees are technically no longer precisely equivalent -- some constant
strings have changed. When comparing two ASTs, whitespace after
newlines within constant strings is thus folded into a single space.
Co-authored-by: Luka Zakrajšek <luka@bancek.net>
* Extract the inner `_v` method to decrease complexity
This reduces the cyclomatic complexity to a level that makes flake8 happy.
* Blacken blib2to3's docstring which had an over-indent
Co-authored-by: Luka Zakrajšek <luka@bancek.net> Co-authored-by: Zsolt Dollenstein <zsol.zsol@gmail.com>
Bryan Bugyi [Fri, 8 May 2020 12:56:21 +0000 (08:56 -0400)]
Improve String Handling (#1132)
This pull request's main intention is to wraps long strings (as requested by #182); however, it also provides better string handling in general and, in doing so, closes the following issues:
Change exit code to 2 when config file doesn't exist (#1361)
Fixes #1360, where an invalid config file causes a return/exit code of 1. This
change means this case is caught earlier, treated like any other bad
parameters, and results in an exit code of 2.
`split("\n")` includes a final empty element `""` if the final line
ends with `\n` (as it should for POSIX-compliant text files), which
then became an extra `"\n"`.
`splitlines()` solves that, but there's a caveat, as it will split
on other types of line breaks too (like `\r`), which may not be
desired.
Cooper Lees [Wed, 4 Mar 2020 15:40:48 +0000 (15:40 +0000)]
Split out Change Log (#1117)
* Split out Change Log
- Move to CHANGES.md to allow bots to see changes
- MANIFEST.in already includes *.md so CHANGES.md will be included
- THis maintains format but the change log will now be after acknowledgements
- This also ensure this gets added to pypi.org via setup.py function
Paul Ganssle [Tue, 3 Mar 2020 12:00:52 +0000 (07:00 -0500)]
Notify users of missing Python lazily (#1210)
Currently this message shows up with no context prior to the start of
Vim. By changing this to a lazy message, the user will only be notified
of a problem with the Black plugin when they are attempting to use the
Black plugin.
Fix unstable formatting with some `# type: ignore`s (#1113)
`type: ignore` shouldn't block collapsing a line, since it will still
apply fine to the merged line. This prevents an issue where a reformat
causes it to shift lines and then be merged on a subsequent pass.
There is a downside to this, which is that it can cause a `type:
ignore` to apply to more code than was originally intended. There
might be a way to apply this in a more limited situation, but I'm not
sure what it is.
* Make most of blib2to3 directly typed and mypyc-compatible
This used a combination of retype and pytype's merge-pyi to do the
initial merges of the stubs, which then required manual tweaking to
make actually typecheck and work with mypyc.
Co-authored-by: Sanjit Kalapatapu <sanjitkal@gmail.com> Co-authored-by: Michael J. Sullivan <sully@msully.net>
* Make black able to compile and run with mypyc
The changes made fall into a couple categories:
* Fixing actual type mistakes that slip through the cracks
* Working around a couple mypy bugs (the most annoying of which being
that we need to add type annotations in a number of places where
variables are initialized to None)
Co-authored-by: Sanjit Kalapatapu <sanjitkal@gmail.com> Co-authored-by: Michael J. Sullivan <sully@msully.net>
Lawrence Chan [Mon, 28 Oct 2019 19:51:45 +0000 (14:51 -0500)]
Fix fmt on/off when multiple exist in leaf prefix (#1086)
The old behavior would detect the existence of a `# fmt: on` in a leaf
node's comment prefix and immediately mark the node as formatting-on,
even if a subsequent `# fmt: off` in the same comment prefix would turn
it back off. This change modifies that logic to track the state through
the entire prefix and take the final state.
Note that this does not fully solve on/off behavior, since any _comment_
lines between the off/on are still formatted. We may need to add
virtual leaf nodes to truly solve that. I will leave that for a separate
commit/PR.
Michael McClimon [Thu, 24 Oct 2019 04:15:12 +0000 (00:15 -0400)]
setup.py: rename _version.py to _black_version.py (#1089)
In #1082, _version.py was renamed to _black_version.py, but the
py_modules line in setup.py wasn't changed, which meant that when
installed from source, running it failed with something like:
```
Traceback (most recent call last):
File "~/.pyenv/versions/3.6.5/bin/black", line 5, in <module>
from black import patched_main
File "~/.pyenv/versions/3.6.5/lib/python3.6/site-packages/black.py", line 55, in <module>
from _black_version import version as __version__
ModuleNotFoundError: No module named '_black_version'
```
Łukasz Langa [Mon, 21 Oct 2019 13:03:01 +0000 (15:03 +0200)]
s/_version.py/_black_version.py/ (#1082)
Some users are installing Black as a dependency in their project. Having
a _version.py in site-packages is asking for a conflict sooner or later.
Ideally we shouldn't require a separate version file at all, that's an
additional import we need to make. But I'll leave that bikeshedding for
a different time.
projects / etc / vim.git / log