Ben, I'm sorry for my overreaction. It's just that I have such an
intense dislike for the "use Mozilla 'coz it's cool" attitude of
Netscape people that I'm unable to express it with words. But that's
another matter.
I agree with you about the XEmacs project being understaffed.
However, you are missing one important point about this "fix for
redisplay" thread, which is:
This is not only about W3. Whenever one tries to use the "advanced"
features of XEmacs, such as images, toolbars, flashy colors, various
complex interactions, etc., XEmacs has a very good chance of becoming
either abysmally slow or unacceptably unstable. Packages such as W3,
VM and SparcWorks are only examples of this. Any fix to XEmacs
redisplay that would make W3 run fast would also make faster many
other XEmacs components.
The goal is not to have an XEmacs with a built-in web browser that
works, but to have an XEmacs so powerful and so flexible that it is
possible to implement a web browser that works within it. Do you see
the difference?
You also say:
Currently, we try to act as if we support all sorts of extensions
to XEmacs, and sometimes their priorities get shifted above the
priorities of much more basic things, such as getting the web site
completed.
One of the banes of volunteer-based projects is that there is no way
to force people to do what they don't like to do. Doing interesting
stuff is the main reason we're here, after all. Otherwise, they might
as well do some more work for our employers and get more money.
Because of the "understaffed", the result is that XEmacs does a
lot of things, but doesn't do any of them very well at all... In
a state like this, its user-base is never going to be very high.
I disagree with this. Most of what XEmacs does, it does fairly well,
and I fail to see the problems that would scare away the users and the
hackers. The reasons why XEmacs does not gain a larger user-base are
rooted elsewhere; some of the hackers simply dislike its interface;
some dislike the sheer size of the product; and yet others find it too
slow. Some people simply favor FSF Emacs because of the name "FSF".
These things are IMHO much more important than the up-to-datedness of
the web site, and they won't go away any time soon.
...[if we make XEmacs just work] we can probably get done all of
those add-on features, like making a better web-browser, and so
on, that we might be not able to get done at all if we try to
concentrate on those features first.
Please note, again, the difference between speed/robustness issues and
the mere presence of features. I am arguing for the former, and you
are arguing against pushing the latter.
However, even when applied to speed/robustness, your argument relies
on the assumption that "making XEmacs just work" will attract a horde
of new users and developers. I am not convinced that this is the
case.
I am also not convinced that it is really possible to fully respect
priorities in a volunteer project, unless you really have a bunch of
people to work with (this is the case with Linux.)
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls."
