Re: Xterm, rxvt, mrxvt, etc....

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

[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 
below):
  http://cygwin.com/problems.html
     http://www.catb.org/~esr/faqs/smart-questions.html
     http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
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, 
dadgummit...


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 
"maintainer".


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:
    http://www.cygwin.com/ml/cygwin-apps/2005-05/msg00327.html
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 
support.

> > 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 
> liar.

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 -- 
> > > > because
> > >
> > > 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
  LC_CTYPE=en_US.UTF-8 urxvt-X.exe
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
  /usr/share/doc/Cygwin/rxvt-unicode-X-7.7.README



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
> mentioned.

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 
involved:

   libW11
   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 
distribution.

   rxvt-unicode-X
      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
   plain-old-rxvt-X-only
      rip out the in-built W11 stuff, and configure this
      package as an all-frills version (instead of least-
      common-denominator supported by W11)
   rxvt-unicode-W
These are only a glimmer in my mind's eye, at present.


The idea was/is, a combination of:
   checkX's 'run' functionality +
   rxvt-W
   rxvt-X
would transparently replace the existing split-personality rxvt.  Plus, 
a similar combination of
   checkX's 'run' functionality +
   rxvt-unicode-W
   rxvt-unicode-X
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.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/