From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: TODO additions Date: 29 Oct 2002 18:04:56 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035914858 24389 80.91.224.249 (29 Oct 2002 18:07:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2002 18:07:38 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 186am8-0006L6-00 for ; Tue, 29 Oct 2002 19:07:36 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 186aqr-0002yB-00 for ; Tue, 29 Oct 2002 19:12:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 186akt-0004t7-00; Tue, 29 Oct 2002 13:06:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 186ajn-0004Ov-00 for emacs-devel@gnu.org; Tue, 29 Oct 2002 13:05:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 186ajf-0004I0-00 for emacs-devel@gnu.org; Tue, 29 Oct 2002 13:05:10 -0500 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 186ajZ-0004Fx-00; Tue, 29 Oct 2002 13:04:58 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 186ajY-0000YE-00; Tue, 29 Oct 2002 18:04:56 +0000 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8922 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8922 Richard Stallman writes: > I see no need for background images. You don't think W3 should be able to render stuff which essentially depends on them? I agree that the main use of HTML background images is to make pages more-or-less unusable, but that's not the point. Anyhow, I think there are other applications of miles' implementation, which is what I was thinking of. > * Convert the XPM bitmaps to PPM, replace the PBMs with them and scrap > the XPMs so that the colour versions work generally. (Requires care > with the colour used for the transparent regions.) > > Could someone explain what good this would do? Surely it's useful not to have to maintain two versions of each (or nearly each) image, and code to deal with them? (That's assuming PPM actually works well in practice.) It also allows colour images in Emacsen without XPM support -- PBM/PPM doesn't require an additional library. I don't know whether or not libXpm is even usable on platforms without X. > * Use automake and use autoconf fully, preferably avoiding src/{m,s} > entirely. [Maintaining the build process _is_ a major problem.] > > I don't think this would make it easier. It might be harder, > because it would require solving every problem in a general way. The whole point is to use general solutions, most of which are already available and easy to follow. If the general GNU build framework can't support Emacs, it should be enhanced to do so, but I don't think that's necessary. I've suffered a lot with the current framework, especially having to cope with random problems on proprietary systems that you don't have to deal with, and I've got a lot of autoconf experience, including introducing it into GCC. As far as I remember, eggert and others have similar opinions and have also done work in that direction. > * Do something to make rms happy with fx's dynamic loading, and use it > to implement things like auto-loaded buffer parsers and database > access in cases which need more than Lisp. > > The problem here is too fundamental to suppose it can necessarily be > solved. Well, you asked me for solutions and I thought others might do better. The issue already exists in other GNU software -- even versions of Emacs others have produced -- so if it's fundamental, it needs to be tackled.