screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[screen-devel] [bug #46273] screen 4.3.1 broken nmon's display and alsam


From: Micah Cowan
Subject: [screen-devel] [bug #46273] screen 4.3.1 broken nmon's display and alsamixer
Date: Tue, 27 Oct 2015 21:28:06 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]