Xterm, rxvt, mrxvt, etc....
Tue May 8 05:43:00 GMT 2007
[consolidating two subthreads]
Thomas Dickey wrote:
>> Not so fast, Thomas. I did not and do not agree with your previous
>> posts: neither of your messages claimed that "upstream rxvt has no
>> maintainer". (If they did, then I would have agreed with that.)
>> Your messages claimed that rxvt had no cygwin maintainer. That claim
>> is false: I am the cygwin maintainer for rxvt.
> I don't much care for the role of "cygwin maintainer" in a discussion
> related to _support_, since you're deliberatly confusing the issue of
> putting the file on someone's disk in contrast to making it work.
Sigh. cygwin's rxvt is not broken. It works for me, and about 2000
others. A few people seem to need additional help, and usually they
seem to work it out themselves (typically, the problem is in their
xserver configuration, or PIBKAC, because they haven't bothered to read
the man pages, READMEs, other documenation, or STFW). If somebody
having a problem with rxvt ever followed the instructions on cygwin's
problem page (and followed any of the embedded links, also reproduced
and demonstrated that they HAD, in fact, RTFMed and STFWed and read the
READMEs and other documentation...
first, I'd faint.
Then, I'd be more than willing to help (and my first question would be,
"does xterm work?" <G> ). But short of that, I've little motivation to
answer repeated questions already answered elsewhere. I'd much rather
engage in tendentious discussions like this one. No, scratch that. I
don't enjoy wasting time this way, either -- but since we're here,
On the cygwin lists, there are typically two possible meanings of the
word "maintainer". However, there is a third meaning, and it appears we
are failing to communicate because you're assuming only definitions A
and C, and I was assuming only definitions A and B:
A: the "upstream" maintainer. E.g:
the x.org folks for most of X
you, for xterm, ncurses, etc
me, for cygutils and a few other even more obscure things
the "committers" for gcc.
nobody, for rxvt
B: the "cygwin" maintainer. The person responsible for the package on
the cygwin mirror system, for accepting/acting on bug reports and
patches *reported on the cygwin mailing lists*, for occasionally
monitoring the upstream lists and feeding patches upstream. And
sometimes, if one is really lucky, providing 24/7 call-center-style
end-user hand-holding. This person approaches package 'X' as a member
of the cygwin community, rather than the other way around. E.g.
Harold Hunt, for xterm (yes, he's gone; so in cygwin parlance,
xterm is "unmaintained" (but see category C, below)
me, for ncurses and rxvt and about 30 others
Dave Korn, for gcc (but Dave is now, also, a committer for gcc,
which puts him in category A *and* C, as well!)
I don't do much end-user hand-holding, for any of my packages. Maybe
that makes me a *bad* maintainer. But it does NOT mean, in the sense
most often used on the cygwin lists, that cygwin's rxvt (or zlib, or
unzip, or gettext, or...) package is "unmaintained".
Quick: who's the maintainer of ncurses? Depends on what you mean by
C: a project maintainer with a focus on portability to a particular
platform. That is, a member of the project 'X' community, who is either
responsible for, or otherwise cares about, whether 'X' works on
[linux|cygwin|mingw|darwin|whathaveyou]. This person may (or may not)
be a "regular" on the target platform's (cygiwn's?) mailing lists --
they may instead do all their porting work within the 'X' community's
mailing lists. This is typically the case for those projects that have
cygwin ports, but do not, for whatever reason, submit them as "official"
packages for the cygwin mirror system. E.g.
Yaakov Selkowitz (cygwin-ports) provides Gnome, KDE, and xFCE
packages -- but uses /those/ projects' mailing lists and bugzillas
to manage it. He specifically requests that users of cygports
use the mailing lists he has set up, and NOT cygwin's lists.
However, he also hangs out on the cygwin lists, so...
You, for xterm (and ncurses, and terminfo). You answer questions
here, but do not take responsibility for the xterm package on
the cygwin mirrors.
Dave Korn, gcc: he now spends as much time/posts as many messages
on the various gcc lists as he does the cygwin lists, and has
been given commit-after-approval access to gcc svn. So, with
regards to gcc, Dave is a hat trick: A, B, and C.
Obviously, there can be a lot of overlap. And often, cooperation: I'm
the 'B' maintainer for both gettext and libintl, but Bruno (the 'A'
maintainer) takes a lot of interest in the cygwin and mingw platforms.
I'll often send him patches, either directly or via bug-gettext, and he
often notifies me directly of upcoming changes and asks for testing. So
who is the 'C' maintainer: probably Bruno, but I reckon I help, somewhat.
Anyway, back on topic: I apologize for ignoring category C; that
confusion is what led to our miscommunication (see below).
> When I've seen - say - more than 10% of your work in the latter, you'll
> have something to argue about. You're not there.
Fine. In your opinion I'm a "bad" maintainer. But I do release
updates, and I do fix bugs. Since rxvt has no 'A', nor 'C' -- you call
it unmaintained. We say it IS maintained -- because there is a 'B'
maintainer (and let's defer arguing about how *well* it is maintained,
even in the 'B' sense, ok?)
Now, consider xterm: it has an 'A' maintainer, and a 'C' maintainer --
both you. However, on the cygwin lists, we'd call it "unmaintained" --
because there is no 'B' at all. In fact, cygwin's xterm package is
almost two years old:
And Harold, who released that package, is no longer "with" cygwin,
having taken a job with StarNet(?) -- there were some contractual
issues, IIRC. Because there is no 'B' maintainer, I'd say that *xterm*
is unmaintained -- at least as far as *cygwin* is concerned -- even
though cygwin users of Harold's ancient package still benefit from your
>> Don't try to retcon this thread.
> that remark reflects poorly on you.
> For the casual reader, google suggests that Charles Wilson called me a
No, it looked to me like you were trying to redefine the terms used in
earlier emails, to change the meaning of those emails to something other
than what they meant at the time they were originally sent.
I now realize that both you *and* I were using different semantics ALL
ALONG. Sorry for the confusion.
>>>> Frankly, I prefer rxvt-unicode on X -- even in non-unicode mode --
>>> yes (does cygwin finally have unicode support? - no one's mentioned it
>>> on this list at all).
>> No, cygwin does not. Cygwin's rxvt-unicode port has limited unicode
>> support because Thomas Wolff provided me with a patch (to
>> rxvt-unicode) that shims unicode support by intercepting certain X calls.
> You're apparently still confused: the terminal emulator can certainly
> implement something, but if the applications running in it can't (except
> as implied, for self-contained locale support), then it's of limited use.
That's why I said it was limited, and why I said *I* only used it
regularly in non-unicode mode. However, if you
you WILL get UTF-8 support on display, and with appropriate kbd settings
in your X-server and .inputrc, limited UTF-8 input support. Also, the
'mined' package provides a fully unicode-aware editor that works pretty
well within a unicode-mode urxvt window. See
But all that's not important. Forget that 'unicode' appears in the name
of the package, or that the package has some limited support for unicode
if you jump thru enough hoops and use some limited set of application
progs that understand unicode. Let's call it rxvt-new-version, instead:
rxvt-new-version has an upstream maintainer, and active upstream
development. So there is an 'A' maintainer for rxvt-new-version. I
figured 'A' + 'B' is better than 'B' alone; so I'm promoting
rxvt-new-version over plain old rxvt, even if nobody EVER sets LC_CTYPE
to anything other than "C". But I still maintain (in the 'B' sense,
"badly", if you like) plain old rxvt.
Look, it's not a competition. I like rxvt-new-version AND plain old
rxvt, so I'll keep maintaining both for cygwin (however "bad" I may be
doing at that job, in your opinion). If the rest of the world switches
to using xterm, more power to 'em, I'll cheer them on. xterm has an 'A'
maintainer, and a 'C' maintainer -- both you. It'd be nice if it had a
'B' maintainer, tho...
[[[ subthread #2 ]]]
> Again, if there were an upstream _maintainer_ for rxvt (the point of this
> thread), they'd have done something useful with the win32 bits
Well, back when there WAS an upstream maintainer, they kinda DID do
something useful with the win32 bits that existed at that time. All of
the /old/ win32 bits are in the upstream CVS (such as it is). But all
that happened when SteveO was still around, and was the 'B' maintainer
for cygwin's rxvt (he also worked closely with the 'A' folks). But all
of them, and SteveO, disappeared long ago.
So I picked up the pieces as best I could: the current cygwin version of
rxvt has a few additional patches beyone what those guys did, but
nothing spectacular. Mostly mechanical, and adapting to our build
systems (first g-b-s, then cygport).
The really *new* win32 bits are in the (currently incomplete) standalone
libW11 package, but that and rxvt-W, is a wholly separate effort.
> There's certainly no cygwin maintainer for that,
Here, I believe you mean a "cygwin maintainer" in the sense of 'C'
above. Of course, without an 'A' maintainer and an active upstream
community, it's a little hard to have a 'C' maintainer, unless you fork:
and become the 'A' of a brand new package.
> noting that
> the cited announcement was just a call for help rather than a notice of
> completed work.
Not entirely. IMO, the existing split-personality 'rxvt' IS a completed
work. If anyone disagrees, then point out the bugs, follow the bug
reporting guidelines, and as always, PTC.
As I said in my first message on this thread:
"I certainly got no interest in libW11, or rxvt-W11 -- such
that their ITP's expired."
Note the package names: 'libW11' and 'rxvt-W11' (ne' rxvt-W). These
are/were separate from the split-personality rxvt.
I did, however, interpret the lack of interest in the 'grand plan' as a
lack of interest in the existing split-personality 'rxvt' package.
Perhaps that was a mistake; I anxiously await P to TC.
With regards to the call for help: I *WANT* to go forward to a
standalone libW11, and build a non-X-enabled, purely Win32 GDI version
of rxvt that uses the new, external libW11 (I called it rxvt-W [ne'
rxvt-W11]). But that would be a *separate* effort from continuing to
maintain the existing, split-personality X11/nativeGDI 'rxvt' package.
But back to the "grand plan" and the "call for help". The grand plan
libXpm-W11 (just for fun!)
rxvt-W - plain old rxvt that uses the external libW11 instead of
the half-baked inbuilt version currently used.
The preceeding three packages were ITPed and are available at the link
below. The following two packages are already part of the cygwin
more-or-less completed, although actual "unicode" support,
per se, is limited because of cygwin's underlying issues.
checkX and a companion 'run.exe'-like program
checkX is coded and part of cygwin now; a little more
work needed for 'run'-like behavior
and finally, once all the above was working
rip out the in-built W11 stuff, and configure this
package as an all-frills version (instead of least-
common-denominator supported by W11)
These are only a glimmer in my mind's eye, at present.
The idea was/is, a combination of:
checkX's 'run' functionality +
would transparently replace the existing split-personality rxvt. Plus,
a similar combination of
checkX's 'run' functionality +
would be even better.
The uncompleted work was represented by the libW11 and rxvt-W ITPs,
which are still available at http://cygutils.fruitbat.org/ITP/ .
However, those are completely separate from the existing rxvt.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin-xfree