Follow-up Comment #18, bug #46273 (project screen):
> > I don't understand the reasoning behind the conditional setting of
cjkwidth.
> Um... didn't you apply of this patch? ;)
LOL, well now, apparently I did! Guess I missed that pertinent fact while I
was perusing the git log. :D
Well then. I guess I wish _I_ had avoided the locale-specific defaulting
behavior. :) ...You certainly have my blessing to change the default for
consistency (not that you need it anyway). Historic practice should trump
"improvement" here, anyway - obviously I broke things for Joe that had been
working for eons.
> because from what I've read so far, there is no standard for how wide
characters are in terminal.
So, I'm not quite sure I'd say that: Unicode definitely represents a number of
codepoints as unambiguously full-width, and it's pretty much impossible to
represent most CJK characters in a standard terminal column. Identifying a
character like 機 is difficult enough without trying to squeze it into half
the real estate!
But, obviously, there are gaps in the standards that exist, and the
"ambiguous" set of characters identified in Unicode are probably intended to
represent characters that have varied between different implementations. I
suspect the interpretation of some of those characters (such as the latin1
ones) as full width, even in East Asian software, is not as common practice
these days as it might have been in the past... but there may still be
exceptions, and I don't know whether some characters in that same "ambiguous"
set might be more likely than others to be displayed in full-width versions.
Your plan to allow per-character override is probably a sensible one. You'd
probably be safe to restrict overrides to ambiguous characters only... but as
long as you're adding the feature, I don't really see the point in doing so.
I think there's maybe also a zero-width control character in Unicode that
controls whether to display following characters as full-width, even if they
otherwise wouldn't have been (like for ascii). I have no idea if that's
supported in screen (but a look at utf8_is_double suggests it's not, unless
that's handled elsewhere). But it must not see wide use, as I've never
encountered a complaint about it.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46273>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
