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: 22 Oct 2002 18:03:03 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200210211307.g9LD76b15675@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035306306 9979 80.91.224.249 (22 Oct 2002 17:05:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 22 Oct 2002 17:05:06 +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 1842Sj-0002Zk-00 for ; Tue, 22 Oct 2002 19:05:01 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1842U1-0005dS-00 for ; Tue, 22 Oct 2002 19:06:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 1842Rv-0006tL-00; Tue, 22 Oct 2002 13:04:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1842Qu-0005zs-00 for emacs-devel@gnu.org; Tue, 22 Oct 2002 13:03:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1842Qs-0005yl-00 for emacs-devel@gnu.org; Tue, 22 Oct 2002 13:03:08 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 1842Qs-0005xt-00 for emacs-devel@gnu.org; Tue, 22 Oct 2002 13:03:06 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 1842Qp-0005Ub-00; Tue, 22 Oct 2002 18:03:03 +0100 Original-To: "Stefan Monnier" Original-Lines: 87 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:8657 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8657 "Stefan Monnier" writes: > I couldn't care less about background images (my browser config > explicitly disrergards background settings), That's not really the point, and I remembered that miles' stuff was more general. I couched it in terms of W3 for concreteness. > > * 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.) > > It seems more energy is spent on this list talking about such a thing > than doing it. I don't know about that, but I did quite a lot of work on the icons. I just didn't realize at the time that the XPMs were probably not necessary, and I don't have an interest in redoing it. I thought MS Windows users might be interested, in particular. > I sadly have no experience with such things at all, > so I wouldn't even know what to look for. As far as I know, only that the background is chosen well to work nicely with the toolbar-rendering code. > > * Allow displaying an X window from an external program in a buffer, > > e.g. to render graphics from Java applets. [gerd and/or wmperry > > thought this was feasible.] > > XEmacs allows something very similar, where a glyph can be any > widget from the underlying toolkit (that's how they added > progress-meters). I know, and I thought it wasn't entirely satisfactory, but this wasn't meant to be a toolkit widget (unless that turns out to be an easy way to do it). [Progress meters extending across the minibuffer ought to be simple to implement if people actually want them.] > > * 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. > > What exactly is Richard unhappy about ? I thought it was the fact > that it allows dynamic linking with non-GPL libraries, right ? > If so, what can we do (apart from trying to convince Richard otherwise) ? He wanted a way of ensuring that extensions had to be linked with GPLed code to work, whereas my design was for them to be essentially the same as normal components like, say, md5.c. If libltdl was GPL'ed that would be enough, but it isn't, and the whole idea was to do this simply in the normal libtool way. I don't remember why checking the loadable module for canned licence text wasn't OK. (Linux has a system of `tainting' by modules without explicit free licences.) Someone probably needs to come up with some better hack round things than I have. Perhaps treating modules as executable (at least for ELF) helps some way? $ /lib/libc.so.6|head -5 GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > * Provide portable undumping using mmap (per gerd design). [unexec > > _is_ a major headache.] > > Grepping emacs-devel for dump or pdump or portable dump or something > like that should get you to an article posted by a guy who said he > was working on exactly that. handa sent me mail from Meadow (?) people who appeared to be working on something `like XEmacs'. You could do something simpler/better (c.f. XEmacs dynamic loading and what I did). rms didn't like having to locate the heap to map at runtime (which might just be on the end of the executing file); I don't think that's an issue given that you can't now successfully run interactively without being able to find libraries like disp-table. > Please add it to etc/TODO. Not if rms disagrees with it. I sent to the list in the hope of sparking others' interest since plenty of things previously rejected now seem to be included (sometimes even as new implementations).