>>>> "Matthew" == Matthew O Persico <mpersico(a)erols.com&gt; writes:

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

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&gt; | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."