Re: TODO additions

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

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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).