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

[bug] logging line reduced with ... still wrapped #1377

Closed
mo-han opened this issue Mar 13, 2021 · 3 comments
Closed

[bug] logging line reduced with ... still wrapped #1377

mo-han opened this issue Mar 13, 2021 · 3 comments

Comments

@mo-han
Copy link
Contributor

mo-han commented Mar 13, 2021

图片

Although these lines are already reduced by replacing the middle part with ellipsis ("..."), they are still wrapped by the terminal.
I'm not sure but maybe it's caused by some full-width chars 〇〇, which make the line occupying more length than what len() tells.

If my guess was correct, then to fix it we need to re-calculate the "visual length" of the text string, e.g. via a function like this:

def visual_len(s: str):
    eaw = unicodedata.east_asian_width
    n = len(s)
    n += sum([1 for c in s if eaw(c) == 'W'])
    return n
@mo-han mo-han changed the title [bug (logging)] short logging line (with ellipsis in middle) is wrapped by one more char [bug (logging)] logging line reduced with ... still wrapped Mar 13, 2021
@mo-han mo-han changed the title [bug (logging)] logging line reduced with ... still wrapped [bug] logging line reduced with ... still wrapped Mar 13, 2021
@mikf
Copy link
Owner

mikf commented Mar 14, 2021

I'm not sure but maybe it's caused by some full-width chars 〇〇, which make the line occupying more length than what len() tells.

That's exactly the problem here. Happens for all paths containing characters wider than a regular ASCII character.

I've known about this for a long time, but never found a way to compute the display size / width of a string or character until you mentioned unicodedata.east_asian_width. Thank you for that!

The next problem is cmd.exe (maybe Powershell as well?), which usually can't display Japanese / East Asian characters and replaces them with a ?. At least on Windows 7 this is only 1 character wide instead of the expected 2, resulting in shortened lines that only span half the terminal: ??????? foo... ??????????

@mo-han
Copy link
Contributor Author

mo-han commented Mar 15, 2021

which usually can't display Japanese / East Asian characters and replaces them with a `?``

If it's me, I'll just leave them as they are, right now can't figure out a soultion for that.

BTW, in my env those chars are usually displayed as blocks - which can still be selected to copy / paste the correct text - or, as question marks. Situation vary with different fonts for cmd.exe, or when something like cygwin is involved.

mikf added a commit that referenced this issue Sep 14, 2021
(#1377)

Setting 'output.shorten' to "eaw" (East-Asian Width) uses a slower
algorithm that also considers characters with a width > 1.
@mikf
Copy link
Owner

mikf commented Dec 3, 2022

This was fixed in bd84530 by implementing the ability to set output.shorten to "eaw" (East Asian Width).

It's not enabled by default since it produces the wrong results without the needed fonts being available and it is at least an order of magnitude slower than the other, simpler algorithm.

@mikf mikf closed this as completed Dec 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants