This is the mail archive of the
mailing list for the Cygwin project.
Re: ITP: rxvt-unicode-X
- From: "Charles Wilson" <cygwin at cwilson dot fastmail dot fm>
- To: mined at towo dot net, cygwin-apps at cygwin dot com
- Date: Tue, 21 Mar 2006 16:54:11 -0500
- Subject: Re: ITP: rxvt-unicode-X
- References: <441F9CCD.firstname.lastname@example.org> <200603211640.k2LGecHO013433@ns-srv-2.bln1.siemens.de>
On Tue, 21 Mar 2006 17:40:38 +0100 (MET), XXXXdadgum webmail quoting
addresses by defaultXXXX said:
> I have some questions on porting rxvt.
> * How did you get it to compile 7.7? When I try it myself, it fails with
> rxvtfont.C:1328: error: 'struct rxvt_term' has no member named
That looks like an error in how configure.ac harmonizes configure
options (or in how rxvtfont.C uses them). The way rxvtfont.C is coded,
you can't have transparency support without also enabling xpm support.
That restriction may be true for obscure X11 reasons -- in which case
configure.ac should flag an error if you try otherwise -- or the
restriction may be bogus -- in which case rxvtfont.C should be more
In any event, for now either enable both transparency and xpm, or
> * I was previously able to compile rxvt-unicode 4.8 myself on cygwin.
> Missing the Unicode support, I first tried to trick out the
> dogmatic locale dependency of rxvt (as the cygwin locale mechanism is
> unfortunately bogus). I patched rxvt around its locale requests so
> it was forced to assume a UTF-8 environment. There was nothing around
> these positions in the code that suggested further dependencies.
> So what is the actual "newlib" problem that prevents rxvt from
> supporting Unicode - apparently even from trying to support it?
I don't know. All I know is that (a) I didn't see it actually work, and
(b) I've read other reports that unicode doesn't actually work on
cygwin. Maybe I'm wrong. I'm pretty clueless on unicode issues: do I
need a specific unicode font to even try it? How many LC_* variables
*should* I have to set in order to "enable" unicode -- say, if I were on
a Linux system will full unicode support? I dunno. I was hoping others
with more experience could use my package -- or my build system -- and
experiment, reporting successess and failures. I know, that's fairly
pollyanna-ish of me, but... I was eventually planning on building
rxvt-unicode with identical options over on my Linux box, and play
around with it there, but that's a roudtuit item.
> * Did you notice that the Backspace key enters a quote character rather
> than Backspace? This is since rxvt-unicode version 5 or so and also
> happens with the Linux-compiled version. I have the impression that
> a program that carries such a striking bug over 3 versions has some
> maintenance deficiencies. That leads me to my next question:
I do not observe this behavior. It may be related to your TERM setting
and the current state of your terminfo/termcap databases. I've
explicitly compiled rxvt-unicode to report 'TERM=rxvt-unicode'; I do not
override that value in my startup scripts. The package I've created
will install the appropriate termcap and terminfo entries if necessary.
Try *my package* and not some older one you've compiled, ensure 'echo
$TERM' says rxvt-unicode, and see if that works. I can't debug your
private, older versions for you.
> * Why deal with rxvt at all? Wouldn't it be feasible with the same
> effort to make a native version of xterm with your (highly appreciated)
> libW11 plans?
> That would be of even higher advantage as Unicode is already working
> with xterm on cygwin because xterm is not so dogmatic about its
> environment when asked to support Unicode.
Several reasons. One, xterm requires much more support from X than rxvt:
(I suppose, just like with rxvt-unicode, the following could be turned
So it's a much higher mountain to climb before we'd have something that
kinda-sorta works. Read /usr/share/doc/Cygwin/libW11-20050610.README
for more info, but although the upstream version of libW11 is intended
as a "drop in" *replacement* for cygX11-6.dll, that's not the way I'm
envisoning cygwin-libW11. THEIR way, you replace the real cygX11-6.dll
with a fake one that contains libW11 code -- and all of the other X libs
will use the new libW11 stuff and it'll all "just work"
Except that it doesn't. libW11 isn't complete enough for that, and it's
an all-or-nothing major system mod: you can't have some apps in "X" mode
and others in "libW11" mode. So basically, their way breaks almost
everything. That's bad.
MY way, libW11 code is in a specific, cygW11-6.dll library. Apps (and
other DLLs) that use it must explicitly be built (e.g. link) against it
[that is, -L/usr/lib/W11 -lX11]. So, we'd need cygSM-W11.dll and
cygICE-W11.dll and cygXmu-W11.dll and ... which are all built against
libW11. Now, that may eventually be possible -- especially if we use
the modular x.org sourcecode. However, since not even the official
cygwin-X guys have released a "true" X using the modular sourcecode, I'm
not brave enough to guinea pig THAT on *top* of the incomplete libW11.
I'm convinced my plan is much less work than all that rot, and gets to
my desired end goal faster: a maintained replacement for X- and native-
rxvt that is upstream-supported as far as the rxvt-unicode sourcecode is
concerned. (Unicode support is "nice" but not necessary in this
conception; current rxvt doesn't support it, so it's not an immediate
goal for "my" rxvt, either, no matter the "name" of the package).
Second, and related, rxvt is much lighter weight -- just look at all
those DLLs that xterm needs.
Third, geez, xterm is just so gosh-darned ugly. :-) Not "important" --
but never underestimate the appeal of eye-candy. It's also personal
preference: I despise the xterm scrollbar: middle click, no arrows, no
keep-scrolling, blech. The only terminal in existence worse than xterm
is command.com. :-)
cygwin at removespam cwilson dot fastmail dot fm