dealing with ambiguous-width chars('\u2500')

[tgfjt]

Hi.
I found something wrong display, When I try to solve this issue (workshopper/levelmeup#37) on my own repo(WIP) (https://github.com/tgfjt/levelmeup-jp/tree/update-workshopper-latest)

My ENV

• OS X 10.10
• iTerm2 2.0.0.20141103

\u2500 on menu.js is used to display as a line. This chars is ambiguous-width chars.

My setting with iTerm2 below:

Treat ambiguous-width characters as double width

settings's background

I'm a Japanese, and usually edit some files that has multibyte chars.

not as double width:

as double width:

I think that the easy way is use a half-width hyphen. menu.write(util.repeat('-', opts.width) + '\n')
But you used '-' first time and changed '\u2500', so do you have any idea?

related:
nodeschool/organizers#64

[max-mapper]

see also: #69

[rvagg]

U+2500 is a standard box drawing character, do you run in to this problem with other terminal applications (box drawing characters are usually used for pseudo-menu terminal applications)? I know they are listed as having ambiguous width but this is a pretty crappy state of affairs for box drawing!

I don't have a solution for this atm but I'd like to know more about the prevalence of this setting, I didn't know it was something that people even did.

[martinheidegger]

@rvagg It happened to me too, it seems like the U+2500 character on a standard font on mac seems to be too long. #69 uses visual-width which is not reliable as it only uses a character lookup to determine its size. I have this theory that it might be possible to figure out the size of a character by evaluating auto breaks but its not more than a theory atm.

[tgfjt]

@rvagg

This is a screenshot for learnyounode-jp on Terminal.app(Mac default) that is checked Unicode East Asian Ambiguous character are wide

It also happen in this case: (I just guess) e.g. env VTE_CJK_WIDTH=1 gnome-terminal on Ubuntu.

[rvagg]

well that's just unpleasant, where's our feature detection for ansi drawing darn it