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: Sun, 18 Dec 2005 14:40:02 +0100 Message-ID: <8564pm5xsd.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> <853bkr92a0.fsf@lola.goethe.zz> <871x0apnrl.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 1134914800 18534 80.91.229.2 (18 Dec 2005 14:06:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 18 Dec 2005 14:06:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 18 15:06:39 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EnzAg-0006sT-4b for ged-emacs-devel@m.gmane.org; Sun, 18 Dec 2005 15:05:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EnzBS-0007mk-N2 for ged-emacs-devel@m.gmane.org; Sun, 18 Dec 2005 09:06:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Enym5-0001Md-7T for emacs-devel@gnu.org; Sun, 18 Dec 2005 08:40:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Enym2-0001LV-LD for emacs-devel@gnu.org; Sun, 18 Dec 2005 08:40:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Enym1-0001LB-RZ for emacs-devel@gnu.org; Sun, 18 Dec 2005 08:40:26 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Enyoo-0007lN-4F for emacs-devel@gnu.org; Sun, 18 Dec 2005 08:43:18 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EnyjV-0003NU-5a; Sun, 18 Dec 2005 08:37:50 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 9B5B21C4F93D; Sun, 18 Dec 2005 14:40:02 +0100 (CET) Original-To: =?iso-8859-1?Q?J=E9r=F4me?= Marant In-Reply-To: <871x0apnrl.fsf@marant.org> (=?iso-8859-1?Q?J=E9r=F4me?= Marant's message of "Sun, 18 Dec 2005 13:56:14 +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:47995 Archived-At: J=E9r=F4me Marant writes: > David Kastrup writes: > >> 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. Where? >>> 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, And that's the whole point. There is no automatic "mainline" after a fork with regard to developer involvement. And yet Emacs has regained the "mainline" moniker in the eyes of some. > so updated package would be painless for developers and users would > get bugfixes more quickly. You are presumably talking about a package system like XEmacs' in the use of Emacs. It is wishful thinking to assume that its effects on Emacs would be magically different than on XEmacs. A package system's intent is to decrease the number of collisions between an abundance of workers by organizing them into more independent departments with separate release policies and timelines. We don't have an abundance of workers. Neither does XEmacs. The XEmacs package system is, in its current state, just overengineering. Almost nobody uses anything except the Sumo collections, and it will likely cause interference with operating system package systems if you attempt actually using the XEmacs package system. > 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. But why is XEmacs dependent on adapting modes that are written for Emacs? Because people choose Emacs as their first platform. >> 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. Except for better syntax highlighting (enabled by default), better filling, strikingly better handling of images, better scrolling, working Unicode support including cut&paste between applications, basic drag&drop support, automatical support of mouse wheels, working image support on platforms beyond X11, mouse-induceable temporary transient-mark-mode (this is a _very_ important improvement for the average user), CUA-mode, tramp, Leim, a large number of included documents like the Elisp programming manual and tutorial, a much improved Gnus, a spreadsheet, a symbolic calculator and so forth and so on. Just type C-h C-n. > But for the average end users, I can say there is not anything worth > waiting 4+ years. Beg to differ. > 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_. But there has been room for lots of improvement within Emacs. The reason we are getting tense here about the release of Emacs-22 is not because Emacs-22 would be just the same as Emacs-21. Maybe you consider it similar in the core feature set, but core features alone don't cut it. You don't get anywhere just by implementing some fancy feature and then letting it rot away. It has to get tied into the average person's work flow. > The package system could be just fine _iff_ packaged modes did not > come from the Emacs land. So why do they come from the Emacs land? And if the package system is just something important for dealing with packages coming "from Emacs land", why would Emacs need one? > 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). Well, it fares pretty well considering that it is not able to compete. > And let's be honest, Emacs is not going to provide any of the nice > features that Eclipse provides these days. Well, that certainly would seem to work in both ways. --=20 David Kastrup, Kriemhildstr. 15, 44793 Bochum