On a fresh checkout:

$ python3 setup.py update
running update
data/ created.
retrieving http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt.
data/EastAsianWidth.txt saved.
parsing data/EastAsianWidth.txt ..
Traceback (most recent call last):
  File "setup.py", line 252, in <module>
    main()
  File "setup.py", line 248, in main
    cmdclass={'update': SetupUpdate},
  File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 64, in run
    self.do_east_asian()
  File "setup.py", line 72, in do_east_asian
    properties=(u'W', u'F',)
  File "setup.py", line 127, in _parse_east_asian
    uline = line.decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 2: ordinal not in range(128)

The width for these are not correct:

• COMBINING CYRILLIC HUNDRED THOUSANDS SIGN
• COMBINING CYRILLIC HUNDRED MILLIONS SIGN

Test case:

import unicodedata
import math
import wcwidth

charnames = [u'COMBINING CYRILLIC HUNDRED THOUSANDS SIGN',
             u'COMBINING CYRILLIC HUNDRED MILLIONS SIGN',
             u'CIRCLED LATIN CAPITAL LETTER A',
             u'KANGXI RADICAL BIRD']

for charname in charnames:
    print(u'Character: {}'.format(charname))
    c = unicodedata.lookup(charname)
    cwidth = wcwidth.wcwidth(c)
    spacing = int(math.floor(2 - cwidth)) * u' '
    print(u"123456789")
    print(u"123{}{}6789".format(c, spacing))
    print(u"Char width: {}".format(cwidth, spacing))

This is printed with Python 2.7 and wcwidth 0.1.4:

Character: COMBINING CYRILLIC HUNDRED THOUSANDS SIGN
123456789
123҈ 6789
Char width: 1
Character: COMBINING CYRILLIC HUNDRED MILLIONS SIGN
123456789
123꙱ 6789
Char width: 1
Character: CIRCLED LATIN CAPITAL LETTER A
123456789
123Ⓐ 6789
Char width: 1
Character: KANGXI RADICAL BIRD
123456789
123⿃6789
Char width: 2

Related: dbcli/mycli#149

Please could you upload a wheel for 0.2.6 and future releases?

I recommend using https://pypi.org/project/build/

$ python -m pip install -U build
...
$ python -m build
...
Successfully built wcwidth-0.2.6.tar.gz and wcwidth-0.2.6-py2.py3-none-any.whl
$ ls dist
wcwidth-0.2.6-py2.py3-none-any.whl wcwidth-0.2.6.tar.gz

Variation selectors (U+FE0E, U+FE0F) can change column widths of some preceding characters. For example, U+270F (✏) is a single-column glyph by itself, but with a succeeding U+FE0F it occupies 2 columns as shown in the snapshot below.

I haven't tried to use wcwidth yet, but I built and installed it without issues.
With pip3 I get:

Collecting wcswidth
  Could not find a version that satisfies the requirement wcswidth (from versions: )
No matching distribution found for wcswidth

Would it be possible to create a pip3 version so that we don't have to build from source?

From the work and results of ucs-detect, https://ucs-detect.readthedocs.io/results.html

I have discovered that terminals do not support a single version of Unicode. At this time, very few support a single version of the specification completely.

• For specific types, like wide characters, they may very at any version, fe. gnome terminal, https://ucs-detect.readthedocs.io/sw_results/GNOMETerminal.html#gnometerminal supports 93% of characters unique to version 15.0, and 90% of characters unique to version 14.
• It may not be immediately obvious, as, "Language Support" is a bit of a proxy for "Zero-Width support", because combining characters are best tested with the characters expected to be combined with, but their support for combining characters or the tables used in their code not necessarily match their latest wide table. In fact, most terminals only update their wide tables for the most popular demand of emoji support.
• And of course, though ZWJ and VS-16 came out at roughly unicode version 8 and 9, very few terminals that support unicode 9 or higher of the wide tables support ZWJ and VS-16, see this specific part of the table:

Because of those results, I think its perfectly fine to drop support for this UNICODE_VERSION, I very much doubt it is used, or useful to anyone when it is, because it cannot correctly describe the terminal's support to wcwidth.

If is a useful idea?

I was interested whether terminal emulator authors would have feedback about UNICODE_VERSION, and whether they would consider exporting it. I have not received any feedback.

However, with tools like 'ucs-detect', we can very programmatically determine with black-box testing, which wide, zero-width, and whether ZWJ and VS-16 are supported, right down to exactly which ones. By making this a delta of expected terminal support, and using ranges with codepoints, maybe it is possible to describe with a complex environment variable.

Just spitballing an idea of what it might look like,

UNICODE_SUPPORT="zero[8.0:!category:Mc,Mn,!1001-1002,!1003],wide[15.1:!zwj,!vs16,!9009-9010]"

if wc is an empty string, an TypeError: ord() expected a character... exception will be raised

if there would be a statement if len(wc) == 0: return 0 before ord(wc), it will be better, I think.

Hi,

Can wcwidth help me with multi-codepoint emojis?

For instance, here I want to get the cell width for a "woman_mechanic_dark_skin_tone" emoji, which renders in the terminal as 2 cells, but wcswidth reports a width of 6 because it is adding up all the modifiers.

>>> s="👩\U+1F3FF\u200d🔧"
>>> print(repr(s))
'👩🏿\u200d🔧'
>>> from wcwidth import wcswidth
>>> wcswidth(s)
6
>>> print(s+"\n--")
👩🏿‍🔧
--

I've found support for these kind of emojis to be inconsistent across terminals, so maybe this is a lost cause, but is there some kind of standard for these emoji modifiers?

Thoughts,

• some version of setuptools/pip have added support to restrict installations by python version, https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires
• and so we should be able to safely drop support for these minority languages
• are the last releases of pip+setuptools for py2.7 able to honor this variable?
• if we drop 2.7, we should also drop 3.5, from this graph from https://pypistats.org/packages/wcwidth

I am a strong believer in backporting and so on, having worked in many restrictive environments, I can sympathize with the small number of the tens of thousands of wcwidth downloads performed every day by python 2.7. And, though they should be version-pinning when working with such legacy software versions, there are cases where they are not.

The reason I held onto python 2 support so long was because it wasn't too difficult, we had found simple 2/3 switches that work in the codebase and the tests have provided nearly 100% coverage.

However I think a majority of the bugs of wcswidth calculations have been resolved, and python 2.7 users can now benefit from this. And that I cannot expect any python 2.7 users will want to make use of any new API's that are discussed in open issues. And for that reason, I am a proponent of dropping support of older python releases.

While I actually appreciate this because I use typing and it allows me to drop a #type: ignore marker when importing the package, based on #71 not being merged, I assume they actually shouldn't be there.

The sdist does not have typing info leading me to think the wheel may have been created on a different branch?

Also, the wheel looks to have a spurious .DS_Store file, similar to what's mentioned here: pypa/wheel#297

I haven't checked the CI yet, so i don't know if you're doing sdist/wheel builds and uploads there, my guess is no, but maybe they can be triggered on tags.

Previously discussed,

• #58 (comment)
• #61 (comment)

I'm open to any specific solution. Plenty were discussed in the past.

Why compile?

• As wcwidth is likely a "hot path" to intensive applications (like pymux, a terminal emulator)
• and, the _bisearch() and code tables are basic "if/else" statements and large arrays of integers.
• pre-compiling machine code and providing build hooks could very significantly improve the performance of any dependent applications.
• and, with our jinja2 framework in bin/update-tables.py, it would be very easy to systematically generate these "code tables" for any type language

My only suggested requirement is that wcwidth install without error on minority operating systems/environments that can't build or fetch a matching pre-built package: that those systems should succeed to install anyway and continue to use the pure-python implementation.

I think using just the basic C language is a fine choice, our use of the language and build would be the most basic and supportable across all kinds of systems and I know C well enough so I don't mind that at all.

Python-like languages like Cython are also very "inclusive" for outside developers to dissect and contribute to, as they are very likely to be python developers, whereas using Rust or something to create a foreign function interface might be very alienating.

Firstly, this isn't a problem for me, I just wanted to let you know about it.

Using wc_rjust() from the readme, if text contains any non-printable characters, the result is longer than length, which should never happen.

For example, '\n' is non-printable:

>>> wc_rjust('\n', 2, '.')
'...\n'

For reference, the width-naive version:

>>> '\n'.rjust(2, '.')
'.\n'

The problem is because of the math here:

max(0, (length - wcswidth(text)))

If wcswidth(text) is negative, the max is length + 1.

The simple solution is to just add a note in the readme warning about this situation, but if you wanted, you could expand the function to raise an error:

>>> def wc_rjust(text, length, padding=' '):
...    from wcwidth import wcswidth
...    width = wcswidth(text)
...    if width < 0:
...        raise ValueError('text contains non-printable characters')
...    return padding * max(0, (length - width)) + text
...
>>> wc_rjust('\n', 2, '.')
Traceback (most recent call last):
  ...
ValueError: text contains non-printable characters

Ultimately, it seems like the problem is using -1 as a sentinel return value instead of raising an error, but it looks like that's inherited from the C function, so fixing that would be a lot of work.

Hello,

The wcswidth function seems to be incorrectly calculating the width of the heart "❤️" ("\u2764\ufe0f") moji. An example:

>>> from wcwidth import wcswidth
>>> wcswidth("❤️")
1
>>> wcswidth("💞")
2
>>> wcswidth("💘")
2

The heart emoji occupies 2 cells and should be returning 2 as per the other examples above.

Hi, thanks for your work on this project. It's been invaluable!

According to this document emoji presentation sequences should be treated as "East Asian Wide".

[UTS51] emoji presentation sequences behave as though they were East Asian Wide, regardless of their assigned East_Asian_Width property value.

When wcwidth reads in the EastAsianWide.txt file, it discards all the emoji presentation sequences it finds, rather than treating them as being wide (since it discards everything without W or F properties).

The full list of 353 emojis affected is available at:
https://unicode.org/emoji/charts/emoji-variants.html

wcwidth will report all of the emoji in the above list as having width 1 instead of width 2.

I would be happy to PR this, but I'm not sure the master branch is clean - I noticed some walrus operators etc. despite my understanding being that this project is 2.7 compatible

I'd also be excited about this functionality - is anyone else already working on it? I'm going to start work on a first pass implementation.

Hi,

on PyPi there is version 0.2.5 released, but in the change log the last entry is for 0.2.0.

It would be great to add them - so I know what to expect when I update this package.

Thanks!

The sdist package at PyPI is missing both emoji-variation-sequences.txt and emoji-zwj-sequences.txt files. Without both files testing of wcwidth fails. Please add missing files to sdist. Thank you.

In the readme, we talk about the example of writing our own custom rjust function. If the most common use case is text alignment, let's just offer it as a public API. They would be the same name and signature as python's,

• https://docs.python.org/3/library/stdtypes.html#str.ljust
• https://docs.python.org/3/library/stdtypes.html#str.lstrip
• https://docs.python.org/3/library/stdtypes.html#str.center

And text-wrapping interface,

• https://docs.python.org/3/library/textwrap.html

I have previously added support of these (with terminal sequences) in blessed, https://github.com/jquast/blessed/blob/a34c6b1869b4dd467c6d1ab6895872bb72db7e0f/blessed/sequences.py#L141-L239

From https://www.unicode.org/faq/unsup_char.html#3:

All default-ignorable characters should be rendered as completely invisible (and non advancing, i.e. “zero width”), if not explicitly supported in rendering.

However, this library incorrectly considers some of them, for example U+3164 HANGUL FILLER, to have non-zero width.

(There is one exception, where this library is correct in assigning a non-zero width to a Default_Ignorable_Code_Point: U+115F HANGUL CHOSEONG FILLER is meant to be combined with other Hangul jamo to form a width-2 syllable block, so it should be assigned width 2 even though it has no display on its own.)

The pypi version is 0.2.4 but there's not a matching git tag or release. Can these be added?

Thanks

Just let you know.

Inspired by jquast/wcwidth, I code a javascript version, just translate python into javasript which namd word-width.

Hi, I was looking at your wcwidth library for comparison, since in the utf8proc library we are also implementing a similar feature (see JuliaStrings/utf8proc#2). The first disagreement that I came across between your implementation and ours was for U+00AD (soft hyphen), where you seem to give 1

>>> from wcwidth import wcwidth
>>> wcwidth(unichr(173))
1

and we give zero (a soft hyphen is used for line breaking, but is ordinarily not printed). In general, we return 0 for most characters in category Cf (formatting control characters). The wcwidth function on MacOS 10.10.2 also returns -1 (not printable) for this code point.

Am I calling your implementation incorrectly? This is for git master of wcwidth.

DerivedCombiningClass.txt contains the Canonical_Combining_Class field from UnicodeData.txt (see http://www.unicode.org/reports/tr44/#Canonical_Combining_Class_Values). This field is intended to be used for the collation algorithm.

wcwidth.py is currently assuming that characters are zero width combining characters if and only if they have a non-zero combining class. I think this is an invalid assumption. For example, characters that are enclosing marks (General Category = Me) all have a zero combining class, but they are also zero width combining characters.

I'm not sure what the standard way to determine zero width combining characters is. One possibility is to check for a General Category of Mn or Me, but I don't know if there are any exceptions to this. Also note that there are combining characters that do have a width (category Mc).

Hi,

Got below hash error today. Do you have an idea what could have caused it?

Thanks!

ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
    wcwidth==0.2.6 from https://files.pythonhosted.org/packages/20/f4/c0584a25144ce20bfcf1aecd041768b8c762c1eb0aa77502a3f0baa83f11/wcwidth-0.2.6-py2.py3-none-any.whl (from -r requirements/develop.txt (line 1712)):
        Expected sha256 a5220780a404dbe3353789870978e472cfe477761f06ee55077256e509b156d0
             Got        795b138f6875577cd91bba52baf9e445cd5118fd32723b460e30a0af30ea230e

Like P1868R2, "🦄 width: clarifying units of width and precision in std::format", Published Proposal, 2020-02-11 https://fmt.dev/papers/p1868.html

Why can't Python just do the right thing? For example, here it gets it wrong,

>>> print(f'|{"\u231a":x<5s}|\n'
...       f'|{"watch":x<5s}|\n')
|⌚xxxx|
|watch|

This emoji is measured as a width of 1, but it is actually a width of 2, causing rjust() to format it wrong. It also fails to account correctly when zero-width, ZWJ, and variation selectors are used. Python fails to get this measurement "right" for any kind of display device at all, but I think it goes without saying that the only purpose of this function is for monospace character displays such as terminals.

I believe the Built-in format string alignment functions, str.rjust, str.ljust, str.center, and textwrap.wrap should measure these unicode characters for their printable width, and not just the "number of codepoints".

The built-in REPL also gets this wrong in the readline-like library input. It becomes impossible to edit strings containing these characters, the cursor position and the result of input is unpredictable and disorienting.

IPython, which uses wcwidth, does a better job and should fare better with #91 closed, but it should not be required to use a large project like IPython as a REPL as a solution.

It would be good to experiment with the source code of Python, to see which parts of the codebase need changing. See #93 for the basic high-level functions

And, it would be better to draft and submit a PEP.

I am trying to tabulate entries containing Devanagari characters using python-tabulate. The library uses wcwidth to calculate the visible length of a string, apparently on line 768 here.

I had opened an issue in astanin/python-tabulate#68 a while ago. The dev directed me to also open an issue here, so here I am. I will quote myself directly from the issue:

This is how it renders

Name            Score
------------  -------
राष्ट्र परीक्षण    19.25
Test             0

versus

Name               Score
---------------  -------
Devanagari here    19.25
Test                0

How it should render:

Name            Score
------------  -------
राष्ट्र परीक्षण         19.25
Test             0

Hopefully this is enough to reproduce:

>>> import wcwidth
>>> a = u"3\ufeff4"
>>> wcwidth.wcswidth(a)
3
>>> a
'3\ufeff4'
>>> print(a)
34
>>>

Rather than:

>>> wcwidth.wcwidth(u'\ufeff')
1

I would expect:

>>> wcwidth.wcwidth(u'\ufeff')
0

I believe the fundamental reason that POSIX C API returned -1 for all c0 and c1 control codes, was as if to say, "this is a terminal emulator's job to parse, not mine", and so it was an error to pass a string containing terminal sequences, a terminal emulator should have partitioned the string and managed any cursor movements or attribute changes before sending the ESC sequence to wcwidth.

Should wcwidth measure terminal sequences, or should we leave this up to other libraries?

I think it could only do more help and be otherwise harmless.

The current situation for developers

• They don't even want to have to use wcswidth() in the first place!
• They would rather use print(f'{emoji_val:<30s') for text alignment !
• They don't care about why this first line works perfectly, and the second gets it wildly wrong:

print(term.red + wc_rjust(emoji_val, 30))
print(wc_rjust(term.red + emoji_val, 30))

Wouldn't it be nice if both approaches were correct?

On '\b',

I noticed this Ruby library measures -1 for '\b', https://github.com/particle-iot/ruby-unicode-display-width#how-this-library-handles-widths -- It is the only such sequence that is measured this way by that library.

• string\b is ambiguous, but any non-error value would be preferred. See #96 about returning 5.:
  • it has occupied 6 characters on the screen
  • but the cursor is positioned at the 5th cell
  • how the developer wishes us to measure this?

Only if in #79, we decide for a new function with a new signature, can we then allow return value of -1 for a single character, '\b', to be interpreted as a non-error. This function or signature change of wcswidth would also correctly return '0' for other, immeasurable control codes.

But why stop at '\b' ?? Why not also parse the CSI code patterns for moving cursor left and right?

On '\t',

It might not be immediately obvious, but tab cannot be safely measured. But I do like this ruby's approach of user-provided parameter table. This would allow us to interpret tab as 0 and allow any developer who really wishes to hint at the distance to next tabstop, though unlikely.

On CSI

Control Sequence Inducer (CSI) are terminal sequences beginning with '\x1b[' and require some advanced parsing mechanisms to discover the "end" of such sequences.

I have taken an approach in the "blessed" library to dynamically generate terminal sequences from termcap and to mixin a few custom ones, to programmatically create a regular expression to match terminal sequences in two categories,

• sequences that cause movement (home, move_yx, )
• sequences that do not (all others)

I think this code could be simplified, and also changed from dynamic runtime to static definitions of regular expressions of common terminal sequences labeled or grouped by their measured effect.

https://github.com/jquast/blessed/blob/a34c6b1869b4dd467c6d1ab6895872bb72db7e0f/blessed/sequences.py#L57C8-L84

Hey this is a popular and useful project, it's a 2rd degree transitive dependency in a project I'm using, tabulate -> wcwidth.

Unfortunately some of our slightly dimmer witted customers who refuse to use virtual environments, and live within a hosted Jupyter notebook are getting this kind of error.

 File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/tabulate.py", line 54, in <module>
    import wcwidth  # optional wide-character (CJK) support
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/wcwidth/__init__.py", line 12, in <module>
    from .wcwidth import ZERO_WIDTH  # noqa
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/wcwidth/wcwidth.py", line 72, in <module>
    import pkg_resources
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3260, in <module>
    @_call_aside
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3244, in _call_aside
    f(*args, **kwargs)
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3273, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/Users/rollokonig-brock/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 583, in _build_master
    ws.require(__requires__)
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 900, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/.pyenv/versions/3.7.3/envs/sdk/lib/python3.7/site-packages/pkg_resources/__init__.py", line 786, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'ipython' distribution was not found and is required by mypackage

Because importing pkg_resources actually requires that the dependency structure of an environment be 100% okay, and this is actually a bit of an unexpected side effect (as we get non-devs messing about with pip).

(I'm going to raise this as a bug with the python core team).

Please include the tar.gz source archive distribution on pypi.

• Version wcwidth-0.1.7 contains source archive
• Version wcwidth-0.1.8 does not.

Helpful for homebrew packages that depend on this lib.

just noting that iTerm2 has a methodology to determine version,

Unicode Version

iTerm2 by default uses Unicode 8's width tables. The user can opt to use Unicode 9's tables with a preference (which render emoji more nicely, but requires applications that expect Unicode 9 width tables). Since not all apps will be updated at the same time, you can tell iTerm2 to use a particular set of width tables with:

^[]1337;UnicodeVersion=n^G

Where n is 8 or 9

https://www.iterm2.com/documentation-escape-codes.html

This is something that I've been struggling with. Consider the following example:

>>> print('\U0001f6cd')
🛍
>>> wcwidth.wcwidth('\U0001f6cd')
1

In this case the display width of the symbol is 2 (as I believe is appropriate per Unicode standard). What is annoying though is that the terminal (default terminal on MacOS 10.13, with the default font SF Mono Regular) also thinks that the character has width 1, and draws the following character on top of this emoji.

I wonder if it is possible to create a special "print" method that knows to insert a superficial space after characters like this, ensuring that the output in terminal is not buggy?

UAX 44, Prepended_Concatenation_Mark:

A small class of visible format controls, which precede and then span a sequence of other characters, usually digits. These have also been known as "subtending marks", because most of them take a form which visually extends underneath the sequence of following digits.

As they have visible display before the characters they modify, these should not be considered zero-width, however this library incorrectly treats them as such.

Thanks , that's just the kind of feedback I was looking for ..

I chose to return -1 because thats what libc wcwidth(3) returns on my OSX and travis-ci.org's linux systems

(unless I'm doing it wrong, bin/wcwidth-libc-comparator.py),

Although there are a few cases where libc returns 1 where wcwidth.py returns -1, there aren't any cases of libc returning 0 ..

Matching values:

libc,ours=-1,-1 [--o͔o--] name=COMBINING LEFT ARROWHEAD BELOW val=852 http://codepoints.net/U+354

libc,ours=-1,-1 [--o᷇o--] name=COMBINING ACUTE-MACRON val=7623 http://codepoints.net/U+1DC7

libc 1 vs. wcwidth.py -1:

libc,ours=1,-1 [--o֭o--] name=HEBREW ACCENT DEHI val=1453 http://codepoints.net/U+5AD

libc,ours=1,-1 [--oฺo--] name=THAI CHARACTER PHINTHU val=3642 http://codepoints.net/U+E3A

Anyway you may be right .. I was hoping for some feedback.

My thoughts were:: If somebody wants to know the printable width of a string, and it contains a combining, until I fully understand their effect in full string as part of wcswidth, I should return -1 as if to say "indeterminate".

Examining a few consumers of wcwidth.c, they often return 0 in such cases, one example:

https://github.com/sickill/libtsm/blob/master/src/tsm_unicode.c#L393

Anyway, feedback appreciated. I'll open a bug, reading http://pubs.opengroup.org/onlinepubs/009696699/functions/wcwidth.html it seems it should return -1 for anything but wide characters and NULL.

jq

On May 5, 2014, at 12:24 AM, wrote:

Hi Mr Quast,

I was wondering if there was a reason behind your choice to return -1 for combining characters when in the original C code it returned 0.

Regards,

I haven't looked into the code yet but i would think you check for variation selector VS16 (U+FE0F) and give that width 2 and width 1 for VS15 (U+FE0E) and that this should be spesificed in the specs

https://en.wikipedia.org/wiki/Variation_Selectors_%28Unicode_block%29

Hi,

please update MANIFEST.in to make the source tarball include all configs and tools required to build the sources.

Thanks,
Nik ([email protected])

Hello,

I created a simple Odin lang port of this library:

https://github.com/greenm01/wcwidth

Please add to the "Other Languages" list if you will.

I tried using wcwidth to calculate the length of the name for the city of Mumbai in Hindi (बॉम्बे हिंदी)

from wcwidth import wcswidth
wcswidth('बॉम्बे हिंदी')
9

On macOS 10.13.5 using Python 3.6.5, I see a visual width of 5 characters and a calculated width of 9 characters.

On Ubuntu 18.04 using Python 3.6.5, I see a visual width of 9 characters and a calculated width of 9 characters.

Thank you by the way for creating a very useful module!

Looks like on redndering documentation sphinx shows some sissues. Despite that documentation seems is generated.

+ /usr/bin/python3 setup.py build_sphinx -b man --build-dir build/sphinx
running build_sphinx
Running Sphinx v4.3.2
making output directory... done
WARNING: html_static_path entry '_static' does not exist
loading intersphinx inventory from https://docs.python.org/3/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [man]: all manpages
updating environment: [new config] 4 added, 0 changed, 0 removed
reading sources... [100%] unicode_version
WARNING: autodoc: failed to import function '_get_package_version' from module 'wcwidth'; the following exception was raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/sphinx/util/inspect.py", line 448, in safe_getattr
    return getattr(obj, name, *defargs)
AttributeError: module 'wcwidth' has no attribute '_get_package_version'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/sphinx/ext/autodoc/importer.py", line 110, in import_object
    obj = attrgetter(obj, mangled_name)
  File "/usr/lib/python3.8/site-packages/sphinx/ext/autodoc/__init__.py", line 332, in get_attr
    return autodoc_attrgetter(self.env.app, obj, name, *defargs)
  File "/usr/lib/python3.8/site-packages/sphinx/ext/autodoc/__init__.py", line 2780, in autodoc_attrgetter
    return safe_getattr(obj, name, *defargs)
  File "/usr/lib/python3.8/site-packages/sphinx/util/inspect.py", line 464, in safe_getattr
    raise AttributeError(name) from exc
AttributeError: _get_package_version

/home/tkloczko/rpmbuild/BUILD/wcwidth-0.2.5/wcwidth/wcwidth.py:docstring of wcwidth.wcwidth._wcmatch_version:1: WARNING: duplicate object description of wcwidth._wcmatch_version, other instance in api, use :noindex: for one of them
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... python-wcwidth.3 { intro unicode_version api } done
build succeeded, 3 warnings.

https://github.com/jquast/wcwidth#uses should contain https://github.com/prompt-toolkit/ptpython/ because https://github.com/prompt-toolkit/ptpython/#special-thanks-to.

And maybe executablebooks/mdformat-tables#16 will use this project, too.

Problem

As for the need for "width" function, just about every downstream library has some issue with the POSIX wcwidth() and wcswidth() functions, either in C or in this python library.

This is mainly because both functions may return -1, and the return value must be checked, but it often is not.

Although using wcswidth() on a string is the most popular use case, it has the possibility to return -1 by POSIX definition, and Markus Kuhn's 2007 implementation returns -1 for control characters.

The return value is often unchecked where it is used with sum(), slice() or screen positioning functions with surprising results.

Solution

Provide new function signature, width that always returns a "best effort" of measured distance. It may ignore or measure control codes, instead. If "catching unexpected control codes" is a desired function, we can continue to provide it as an optional keyword argument, and, rather than return -1, raise an exception.

Maybe new keyword argument control_codes with default argument 'ignore', in similar spirit to 'errors' for https://docs.python.org/3/library/stdtypes.html#bytes.decode,

• 'ignore': measure all individual control codes and terminal sequences as 0 width.
• 'strict': raise ValueError on any control codes.
• 'replace': make best effort to account for horizontal width movement in terminal sequences.

Workaround

As a workaround, I have suggested to use wcwidth() directly on each individual character and clip the possible -1 return value to 0, example: https://github.com/jquast/blessed/blob/a34c6b1869b4dd467c6d1ab6895872bb72db7e0f/blessed/sequences.py#L364

This provides the same function as wcswidth but provides a "best guess", however, this method cannot handle coming changes to wcswidth to handle zero width joiner (ZWJ) sequences.

The tox.ini file needs requirements-tests39.txt for deps, but the file is missing from sdist. Please add requirements-tests39.txt to sdist. Thank you.

ping @jquast, can you please let me know your interest in updating the travis-ci job to maintained versions of python. It will be very helpful to others whoever is working with updated python releases.

Please, add the LICENSE file in the version that is being distributed via pypi

as reported in xonsh/xonsh#1569 some (maybe all) emojis are reported as being 2 char wide, while most (all?) terminals think they are 1 char wide:

The difference in position is because while editing a command xonsh is using wcwidth but to print the line it just prints and let the terminal position things