From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: redisplay system of emacs Date: Sat, 30 Jan 2010 14:39:48 +0900 Message-ID: <87aavwrw0r.fsf@xemacs.org> References: <4B633B7C.8030700@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264829277 17014 80.91.229.12 (30 Jan 2010 05:27:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2010 05:27:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 30 06:27:54 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nb5s8-0007to-J7 for ged-emacs-devel@m.gmane.org; Sat, 30 Jan 2010 06:27:52 +0100 Original-Received: from localhost ([127.0.0.1]:59014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nb5s5-0006Z9-Ll for ged-emacs-devel@m.gmane.org; Sat, 30 Jan 2010 00:27:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nb5rz-0006Yu-Sp for emacs-devel@gnu.org; Sat, 30 Jan 2010 00:27:43 -0500 Original-Received: from [199.232.76.173] (port=52825 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nb5ry-0006Ym-K1 for emacs-devel@gnu.org; Sat, 30 Jan 2010 00:27:42 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nb5rw-0003bO-S5 for emacs-devel@gnu.org; Sat, 30 Jan 2010 00:27:42 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:46561) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nb5rw-0003bG-7O for emacs-devel@gnu.org; Sat, 30 Jan 2010 00:27:40 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id C38251535B3; Sat, 30 Jan 2010 14:27:37 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C477C120643; Sat, 30 Jan 2010 14:39:48 +0900 (JST) In-Reply-To: <4B633B7C.8030700@gmx.de> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:120675 Archived-At: grischka writes: > But as is, emacs comes with an implicit structural clause to its > license, as in "[You may convey a work based on the Program, ...] > BUT WE DO OUR BEST TO PREVENT THAT." That's simply not true. There have historically been a large number of editors based on Emacs code, some of which are in active development (of course XEmacs is an example, and many wilder alternatives have existed: pymacs, perlmacs). And every long time user has more or less substantial app-specific code in their init file, while many have private branches, sometimes shared with friends. Corporate IT departments often have quite substantial applications built on Emacs (a friend of mine feeds his family by maintaining a bug database query frontend in Emacs Lisp for a leading technology company -- that's his fulltime job). I can say to those who say "we can rebuild Emacs using third-party libraries and it would be more maintainable and flexible" that XEmacs has tried that several times for different areas of functionality, and for one reason or another the code has always come back out again. In fact, those third party libraries have always either turned out to lack the flexibility demanded by an editor application, or to be less stable than XEmacs itself, and since they didn't offer any high-level capabilities that couldn't be coded in three lines of Lisp, they went back on the shelf. Of course low-level facilities like displaying glyphs from fonts are best done with specialized libraries. Guess what? Emacs uses native X for legacy fonts, but it doesn't go to Xrender for scalable fonts, it uses freetype and/or Xft. But even at the level of displaying images which you would think would be eminently suitable for a third- party library like libmagick or maybe netpbm, XEmacs was forced to abandon its attemtp to use libmagick as a common interface to all image formats, and go back to direct support of the various underlying libraries such as libjpeg and libungif -- which itself turned out to be too unstable, so instead of using it, we had until recently a locally hacked code based on an older version. Today, we've gone back to using giflib directly and libmagick is probably stable enough to use as a replacement for our custom high-level code, but if you were to try to use all of the various libraries proposed to replace core Emacs functionality, some would be lemons and you'd take two steps back for every step forward. You can complain that "plugins" should be written in a more popular language like Python or Visual BASIC, of course, but as several others have pointed out, you would not be able to take advantage of 3 decades worth of Lisp libraries in doing that, and often the libraries available in Python or Ruby are more buggy because much younger. And if you look at what people who want a non-Emacs advanced editor for their Python or Ruby projects do, they don't write it in Python or Ruby. (Yes, I know about IDLE, and it's not an advanced editor, nor is it as easy to extend as Emacs.) No, they go hack on vim! As for browsing 1GB (well, for Emacs it would be 256MB, I guess?) log files, there's nothing like (X)Emacs!