On 2016-12-16, I wrote: > Because it's a shame to ship terminals incapable of UTF-8 when a > fully-capable fork exists, please produce dummy transitional packages > that depend on rxvt-unicode-256color: > * rxvt > * rxvt-unicode > * aterm
As I filed this just before Stretch's freeze, and you didn't act immediately, the freeze precluded us from killing old rxvt. It'd be nice if you could do so for Buster. > This has been OKed by rxvt's maintainer, rxvt-unicode is produced by your > source, aterm is orphaned. All of these come from the same codebase > origins, and none have drastic changes that would make users complain. aterm is done (even was in time for Stretch). > As for why -256color, that's a separate issue. There's no real way to > detect lack of 256 color support rxvt and rxvt-unicode are the only terminals with 88 color. Thus, getting rid of them (replaced by rxvt-unicode-256color), would mean any terminal can take 256 color codes and do a reasonable thing. In theory, the palette for both 88 and 256 color is supposed to be settable, but 1. not every terminal allows redefining (osso-xterm, linux console, kfreebsd console, ... don't), 2. the vast majority of programs just assume the default palette unconditionally. So this ship has sailed, and let's better make it work. I think, though, that instead of migrating to rxvt-unicode-256color, it might be better to take over rxvt, make it the primary package, and make all other variants be dummy transitionals for it. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
