terminals w/o UTF8 support (was Re: Bug#847809: ITP: tcvt -- multicolumn virtual terminal)
On Mon, Dec 12, 2016 at 11:20:33AM +0100, Adrien CLERC wrote:
> Multibyte encodings such as utf8 are not supported
>
> Is that still an issue? I highly doubt that a terminal application that
> doesn't support UTF8 is useful nowadays.
Right. This reminds me of a 2011 debian-devel thread:
Me:
} I'd say there should be no place in Debian in 2011 for software that can't
} do UTF-8, especially if near-identical forks exist.
Josselin Mouette:
] Kicking out software that doesn’t work at all in UTF-8 locales and
] requires the user to set a broken locale, OTOH, sounds like a sanitary
] emergency.
We're in Dec 2016, what about mass removal (perhaps leaving a few and making
a more thorough cleaning in buster)? With the freeze near that's not the
best timing but removals work fine.
I'd like to propose one migration:
let's replace "rxvt" and "rxvt-unicode" with dummy packages pulling current
"rxvt-unicode-256color" (renamed to the base name or not). Same with
"aterm" whose changes have been merged into "rxvt-unicode" ages ago. These
have non-negligible popcon thus should be transitioned.
Why care? Because of rxvt's history. Two decades ago, when you planted
your butt next to a fine IRIX machine[1], you had a vendor-shipped "xterm"
that sucked so first thing you did was was running rxvt for then-modern
goodness. That Solaris machine in the same lab shipped some generic-named
"terminal" which sucked even more -- again, you ran rxvt and were happy.
Preferences of this kind ossify and are hard to change, even nowadays you
have old people running rxvt because it's what they're used to. They use a
language like English with no diacritics so they don't care -- but once in a
while they see mangled characters in someone's name or in an email, and
complain about "sending broken stuff". This is one service we should do for
such users, as it's trivial to do. Red Hat/Fedora use rxvt-unicode-256color
since ages, let's not be worse.
Why -unicode, that's obvious. Here's why -256color: thanks to a misdesign,
there's no way to detect 256 color support nor the used palette and trying
to use it when not supported results in visual breakage. All other
terminals support that nowadays[2], thus programmers sometimes print 256
colors unconditionally.
Vanilla RXVT is dead upstream since 2001, that "new upstream" upload in 2013
was switching to a beta from 2003.
George (rxvt maintainer): would you be ok with this?
Meow!
[1]. Indygo/Indy were made of pure awesomeness, especially their displays.
[2]. Linux console only approximates that by mapping to the nearest of 16
VGA colors, but at least there's no blinking or fruit salad.
--
u-boot problems can be solved with the help of your old SCSI manuals, the
parts that deal with goat termination. You need a black-handled knife, and
an appropriate set of candles (number and color matters). Or was it a
silver-handled knife? Crap, need to look that up.
Reply to: