From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?J=C3=A9r=C3=B4me_Marant?= Newsgroups: gmane.emacs.devel Subject: Re: GTK file selector Date: Sun, 18 Dec 2005 13:56:14 +0100 Message-ID: <871x0apnrl.fsf@marant.org> 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> <853bkr92a0.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1134910504 8000 80.91.229.2 (18 Dec 2005 12:55:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 18 Dec 2005 12:55:04 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 18 13:55:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Eny3D-0000KT-1x for ged-emacs-devel@m.gmane.org; Sun, 18 Dec 2005 13:54:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eny3y-0003eU-Ew for ged-emacs-devel@m.gmane.org; Sun, 18 Dec 2005 07:54:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Eny1w-0003eG-QT for emacs-devel@gnu.org; Sun, 18 Dec 2005 07:52:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Eny1u-0003e2-Im for emacs-devel@gnu.org; Sun, 18 Dec 2005 07:52:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Eny1t-0003dy-FR for emacs-devel@gnu.org; Sun, 18 Dec 2005 07:52:45 -0500 Original-Received: from [212.27.42.35] (helo=smtp5-g19.free.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Eny4d-0002uM-RR; Sun, 18 Dec 2005 07:55:36 -0500 Original-Received: from localhost.localdomain (mol92-4-82-227-97-206.fbx.proxad.net [82.227.97.206]) by smtp5-g19.free.fr (Postfix) with ESMTP id B8AE617009; Sun, 18 Dec 2005 13:51:52 +0100 (CET) Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 6E86AC0F94B; Sun, 18 Dec 2005 13:56:14 +0100 (CET) Original-To: David Kastrup User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (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:47993 Archived-At: David Kastrup writes: >> 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: I'll explain later why I think it is indirectly relevant. >> 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 I've already been publicly accused of trying to undermine the Emacs project when dealing this subject. The situtation with Emacs would be different since it is the mainline, so updated package would be painless for developers and users would get bugfixes more quickly. I think the problem with XEmacs is mostly due to the fact that adapting modes that are written for Emacs is more and more difficult as mode writers tend to use newer Emacs features. > actually had quite a bit of fallout with the XEmacs developers over > integrating AUCTeX as a package into XEmacs. Quite loudly ;-) [...] >> 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. I think the unicode support is out of the scope of the package system. It is a core feature which requires a major release update. >> 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. OK, I'm going to explain my point. No offence meant. For end users -- that is, people who use the text editor as a text editor and are not spending time customizing the editor nor editing the editor -- (and being myself an end user) there is not anything really new to expect from Emacs 22. I used to fire it up many times while working on emacs-snapshot, and did my usual work (coding in C, Perl, Python, Make, Shell and so on) and I did not feel it was different from Emacs 21.3, which provides just fine all what I need these days. Of course, there is the GTK interface for the eye-candy (to the detriment of performance) and better unicode support for non-European countries. But for the average end users, I can say there is not anything worth waiting 4+ years. What I was saying with XEmacs is that they decided at the very beginning to prodive UI features that users wants these days, such as buffer tabs, rich menu entry avoiding the use of the ugly "customize" as much as possible, a gutter, and so on, which is just enough for the average end user these days. So, except from the lack of unicode support, there is not much in the land of improvement but bugfixes, for a _text editor_. The package system could be just fine _iff_ packaged modes did not come from the Emacs land. Emacs still does not have the necessary features for competing with bare text editors (I'm not talking about displaying images, reading mail or chating with irc). And let's be honest, Emacs is not going to provide any of the nice features that Eclipse provides these days. And Eclipse is free, runs with a free Java Platform, is extensible, and so on. Furthermore, there is no more performance argument against Java since Eclipse compiled with GCJ is pretty fast (congratulations to CGJ and GNU Classpath people!). --=20 J=C3=A9r=C3=B4me Marant