Xterm, rxvt, mrxvt, etc....
Sun May 6 01:43:00 GMT 2007
Thomas Dickey wrote:
>>> "support" is relative. There's apparently no X maintainer, so no
>>> packages. On the other hand, while I respond to xterm issues(*) on this
>>> and other lists, I don't recall _ever_ seeing support from rxvt's
>>> maintainers on this list.
It's a two-way street. I put out a call for assistance -- backed up with
ITPs of five packages, so I put my money where my mouth was -- and a
whole long forward-looking plan concerning a revived libW11
(and other messages in this thread, plus):
but no one cared. I certainly got no interest in libW11, or rxvt-W11 --
such that their ITP's expired.
The fact is, rxvt upstream is dead, dead, dead. It has shuffled off this
mortal coil. Joined the choir invisible. It is an EX-terminal. The
terminal is terminal.
Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode --
because it's actively maintained upstream. That's why I also maintain
THAT package for cygwin. Being monolingual, I can't vouch for the
actual unicode support as I never use anything other than ASCII and US
english. For US/en input and non-unicode display, it works well and I
use it daily. For unicode display, it seems alright if you work very
hard -- that is, read LOTS of FM and do LOTS of STFW -- at getting
appropriate fonts installed. For input other than US/en, I've had mixed
success using US-intl kbd -- but then, I'm not really certain what true
success should look like. Please see /usr/share/doc/rxvt-unicode-7.7/*
Concerning cygwin's rxvt-unicode-X: Yes, yes, I know: I need to update
from 7.7 to 8.x. But there's two problems there: (1) I need to forward
port Wolff's unicode shims, and I'm not looking forward to that, and (2)
I don't know what's going on with cygwin-1.7.0; IIRC there was talk --
just TALK -- about switching over to the *W win32api functions instead
of the *A win32api ones. Is that actually going to happen? Will that
affect the shims? Obsolete them? Require changes? I dunno -- and I
don't want to waste time on it before 1.7.0 is released.
>> rxvt is not an X package...
> rxvt could run in X, but I agree it has a win32-specific chunk of code.
> However, the last I read of _that_ was that it was no longer supported.
> For example
Wait: an announcement of a release (and not even the most recent
announcement) is your evidence that a package is unmaintained? Isn't
that a bit backwards?
Granted, there have been only a few releases since I picked up that
package: the one you mention last May, two last June, and the most
recent last December.
All three updates were specifically in response to bug reports. *BUGS* I
try to fix, if I have time. *PATCHES* to fix existing bugs are even
better. But since the upstream is dead, there's no real impetus for
releasing new versions -- except when bugs are reported or patches are
Helping people fix their borked-up Xserver is not my bag. Nor is
providing the same old answer to the same old questions, that could be
answered by reading any one of
(a) the man page
(b) the shipped documentation (/usr/share/doc/Cygwin/rxvt* and
(c) or if the questioner would simple STFW.
or simply spending some time testing a few alternatives rather than
running to the mailing list at the first sign of difficulty. Like
everyone else, my time for cygwin is a scarce resource -- I prefer to
spend it on coding, bugfixing or functionality improvements (recently,
gcc-4.x and, separately, libtool-2.x) than pretending to be a human
interface to the man pages and READMEs.
> google's not showing me a recent maintainer for the code.
rxvt-20050409-3 (and also belatedly mentioned the unannounced -2)
was only a year ago.
> If there's no maintainer, it's not supported, no matter what the mailing
> list is.
Your algorithm for determining which packages are maintained and which
are not seems somewhat suspect.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin-xfree