Re: TODO additions

[Dave Love <d.love@dl.ac.uk>]

Richard Stallman <rms@gnu.org> 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.