black/tests/data
Hong Minhee (洪 民憙) ef6e079901
Let string splitters respect East_Asian_Width property (#3445)
This patch changes the preview style so that string splitters respect
Unicode East Asian Width[^1] property.  If you are not familiar to CJK
languages it is not clear immediately.  Let me elaborate with some
examples.

Traditionally, East Asian characters (including punctuation) have
taken up space twice than European letters and stops when they are
rendered in monospace typeset.  Compare the following characters:

```
abcdefg.
글、字。
```

The characters at the first line are half-width, and the second line
are full-width.  (Also note that the last character with a small
circle, the East Asian period, is also full-width.)  Therefore, if we
want to prevent those full-width characters to exceed the maximum
columns per line, we need to count their *width* rather than the number
of characters.  Again, the following characters:

```
글、字。
```

These are just 4 characters, but their total width is 8.

Suppose we want to maintain up to 4 columns per line with the following
text:

```
abcdefg.
글、字。
```

How should it be then?  We want it to look like:

```
abcd
efg.
글、
字。
```

However, Black currently turns it into like this:

```
abcd
efg.
글、字。
```

It's because Black currently counts the number of characters in the line
instead of measuring their width. So, how could we measure the width?
How can we tell if a character is full- or half-width? What if half-width
characters and full-width ones are mixed in a line? That's why Unicode
defined an attribute named `East_Asian_Width`. Unicode grouped every
single character according to their width in fixed-width typeset.

This partially addresses #1197, but only for string splitters. The other
parts need to be fixed as well in future patches.

This was implemented by copying rich's own approach to handling wide
characters: generate a table using wcwidth, check it into source
control, and use in to drive helper functions in Black's logic. This
gets us the best of both worlds: accuracy and performance (and let's us
update as per our stability policy too!).

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
2023-03-19 19:09:57 -04:00
..
fast Fix crash with walrus + await + with (#3473) 2023-01-17 22:25:05 -08:00
gitignore_used_on_multiple_sources Apply .gitignore correctly in every source entry (#3336) 2022-11-04 22:09:59 -07:00
ignore_subfolders_gitignore_tests Compare each .gitignore found with an appropiate relative path (#3338) 2022-11-08 07:50:04 -08:00
include_exclude_tests Do not use gitignore if explicitly passing excludes (#2170) 2021-05-07 14:54:21 +02:00
invalid_gitignore_tests Present a more user-friendly error if .gitignore is invalid (#2414) 2021-08-20 19:54:53 -04:00
invalid_nested_gitignore_tests Present a more user-friendly error if .gitignore is invalid (#2414) 2021-08-20 19:54:53 -04:00
jupyter Remove hard coded test cases (#3062) 2022-05-18 12:11:37 -07:00
miscellaneous Enforce a blank line after a nested class in stubs (#3564) 2023-03-18 14:04:13 -07:00
nested_gitignore_tests Fix: black only respects the root gitignore. (#2225) 2021-05-16 13:51:27 -04:00
preview Let string splitters respect East_Asian_Width property (#3445) 2023-03-19 19:09:57 -04:00
preview_context_managers Consistently format async statements similar to their non-async version. (#3609) 2023-03-16 13:31:27 -07:00
project_metadata Infer target version based on project metadata (#3219) 2023-01-31 18:00:17 -08:00
py_36 Remove hard coded test cases (#3062) 2022-05-18 12:11:37 -07:00
py_37 Remove hard coded test cases (#3062) 2022-05-18 12:11:37 -07:00
py_38 Draft for Black 2023 stable style (#3418) 2023-01-31 15:39:56 -08:00
py_39 Draft for Black 2023 stable style (#3418) 2023-01-31 15:39:56 -08:00
py_310 Draft for Black 2023 stable style (#3418) 2023-01-31 15:39:56 -08:00
py_311 Draft for Black 2023 stable style (#3418) 2023-01-31 15:39:56 -08:00
simple_cases Do not add an extra blank line to an import line that has fmt disabled (#3610) 2023-03-17 21:39:21 -07:00
type_comments Support files with type comment syntax errors (#3594) 2023-03-19 18:52:06 -04:00
conditional_expression.py Parenthesize conditional expressions (#2278) 2022-12-29 15:13:15 -08:00
empty_pyproject.toml Support pyproject.toml 2018-06-06 17:02:10 -07:00