From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: GTK file selector Date: Sat, 17 Dec 2005 16:22:31 +0100 Message-ID: <853bkr92a0.fsf@lola.goethe.zz> References: <1134552456.439fe58850f31@imp5-g19.free.fr> <878xuma53q.fsf@jurta.org> <17313.37186.344268.487103@parhasard.net> <87d5jxsgib.fsf@jurta.org> <17314.42778.220813.47226@parhasard.net> <17315.7877.155144.973236@kahikatea.snap.net.nz> <85irtoadgf.fsf@lola.goethe.zz> <87lkyk62zc.fsf@marant.org> <85acf0a9zx.fsf@lola.goethe.zz> <87zmmzoov9.fsf@marant.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1134833178 13995 80.91.229.2 (17 Dec 2005 15:26:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2005 15:26:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 17 16:26:15 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Endw1-0004so-JI for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2005 16:25:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Endwl-0001U1-Iv for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2005 10:26:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Endtf-0000sv-Ru for emacs-devel@gnu.org; Sat, 17 Dec 2005 10:22:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Endte-0000rt-Sf for emacs-devel@gnu.org; Sat, 17 Dec 2005 10:22:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Endtd-0000rN-Si for emacs-devel@gnu.org; Sat, 17 Dec 2005 10:22:54 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EndwG-0005iq-2o for emacs-devel@gnu.org; Sat, 17 Dec 2005 10:25:36 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EndrI-0005Rr-69; Sat, 17 Dec 2005 10:20:28 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 7F4411C4F93D; Sat, 17 Dec 2005 16:22:32 +0100 (CET) Original-To: =?iso-8859-1?Q?J=E9r=F4me?= Marant In-Reply-To: <87zmmzoov9.fsf@marant.org> (=?iso-8859-1?Q?J=E9r=F4me?= Marant's message of "Sat, 17 Dec 2005 14:05:30 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:47952 Archived-At: J=E9r=F4me Marant writes: > David Kastrup writes: > >>> I think it could be fixed by making bugfix releases as I already >>> proposed many times (I also proposed to add myself as manpower for >>> such a purpose). So far, supporting the current released version >>> is not wanted, as far as I understood. >> >> We have already too little manpower to support the coming release. > > Really? There are more than one hundred committers, according to the > Emacs page at Savannah. Most of the work is done by very few people. Committers are basically just people comfortable with CVS, who have signed the necessary assignments and are expected not to do anything really bad too often. However, that does not mean that you can rely on them doing useful stuff all too frequently. >>> Also, I wonder if the modular design -- separating core and >>> modules -- makes it easier to release often. >> >> One has to be aware that in the case of XEmacs, this is snake oil. >> XEmacs' code base, while frequently released, has not yet even >> caught up to Emacs-21.0 in core areas. The packages, while >> frequently released, are often in a state of disarray and various >> levels of outdatedness. XEmacs-21.5 is quite unstable. And so on. >> There is the occasional package that is kept more up to date in >> that manner, but the overall effect is not consistently convincing >> to me. > > I'm not promoting anything but IMHO XEmacs did it right from the > very beginning by focusing on what users expect the most from, that > is user interface: But we are not talking about the user interface here. We are talking about the release process. All that is relevant in that regard is: > a package system. And as I said, the overall effect does not seem too convincing to me. Many packages have not even caught up to the state of Emacs-21. I actually had quite a bit of fallout with the XEmacs developers over integrating AUCTeX as a package into XEmacs. > I'd even say that there are enough features for most end users. But we are not talking about "features", but usability, both for users and programmers. Whenever I have had contact with XEmacs, lot of the stuff was unusable to me. Documentation and stuff of the features tends to be so bad that it is hard to programmatically interface to it. Those features just don't get used. As an example: when working with preview-latex, it was found that images displayed from a binary file format were garbled when dired was loaded. This was analyzed and reported by a programmer in our project who subsequently went silent. Several years later, nobody had bothered fixing the stuff. I don't think it is fixed even now. Now I think you will agree that displaying images are sort of a feature for which XEmacs was renowned (this does not concern the normal icons and toolbars who are read from a non-binary image format), and dired is pretty basic. And yet, nobody apparently used this functionality for years and years. A lot of the stuff in XEmacs is like that: implemented, and left unused because it has, maybe because of the roughness of APIs and documentation, not been tied into any application in frequent use. And the package system partly is a way not to feel bad about material in various states of disarray. How many people actually use the package system? It actually is likely to interfere with the package systems of operating system distributions if you actually use it. XEmacs has always had a much larger overlap between developers and users. In contrast, Emacs has for a long time had a pretty closed inner circle. As a result, Emacs development and maintainance has turned out to care a lot more for users who neither are nor want to be developers. Of course, not releasing any of the work for such a long time is not a good thing for the end user. But it does not look to me like a package system would lead to a better situation. > The only necessary improvement I can see is related to Unicode > support (which Emacs is doing quite right). Which is partly because people involved with it are actively using it. With XEmacs, there is currently Ben Wing working in the background on stuff that will at one time emerge while everybody is waiting with bated breath, and it will not magically solve all problems. The link between engineering and actual use in the real world is in my opinion what is the strongest ailment of XEmacs. And I don't think the package system is much of a help there. And getting more frequent releases which still don't work well does not cut it, either. > Catching-up with Emacs is only necessary because Emacs APIs do > change, are enriched, and mode authors who mostly use Emacs update > their software accordly. Sure, and your point was? We don't change Emacs just for fun, but to improve it, for users as well as developers. And catching-up means passing on those improvements. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum