TODO additions

TODO additions

[Dave Love]

I'd like to see these added to etc/TODO.  The last three are
maintenance problems that have bitten me again recently; I know rms
thinks they're not a problem, but they've all bitten me again recently
and have done often in the past.  The rest are mostly of particular
interest for W3, but are more generally applicable.

* Provide a means to display a background image in a window [miles
  started on this?] and extract image-relative coordinates from mouse
  clicks on images.  (Both needed for W3.)  Also useful for W3 and Gnus:
  allow scrolling images properly.

* 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.)

* Allow unknown image types to be rendered via an external program
  converting them to, say, PBM (in the same way as PostScript?).

* 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.]

* Allow images (not just text) in the margin to be mouse-sensitive.
  (Requires recursing through display properties).  Provide some way
  to simulate mouse-clicks on marginal text without a mouse.

* Implement Lisp functions to determine properly whether a character
  is displayable (particularly needed in XFree 4, sigh).  Use it to
  define useful glyphs that may be displayed as images or unicodes
  (with ASCIIfied fallback via latin1-disp).  Examples include
  box-drawing graphics in Custom buffers, W3 rules and tables, and
  tree displays generally, mode-line mail indicator.  [See work done
  already for Emacs 22 and consult fx.]

* 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.

* Extend ps-print to deal with multiple font sizes, images, and extra
  encodings.

* Provide portable undumping using mmap (per gerd design).  [unexec
  _is_ a major headache.]

* Use automake and use autoconf fully, preferably avoiding src/{m,s}
  entirely.  [Maintaining the build process _is_ a major problem.]

* Replace gmalloc.c with the modified Doug Lea code from the current
  GNU libc so that the special mmapping of buffers can be removed  --
  that apparently loses under Solaris, at least.

Re: TODO additions

[Miles Bader]

On Fri, Oct 18, 2002 at 01:41:43PM +0100, Dave Love wrote:
> * Provide a means to display a background image in a window [miles
>   started on this?]

I did two implementations, one which worked quite well, but was a bit limited
(frame-relative images at 0 offset only), and another which was intended to
replace the first (frame/display/window/line relative + offset), but which I
never fully debugged (i.e., it worked with display glitches).

I stopped maintaining these because having large local changes really kills
CVS performance over a slow link, and they've probably bit-rotted quite a bit
since, but could probably be re-merged with a bit of effort.

Note that my implementation let you add a background image to any _face_
(including the default face), which can be pretty cool, e.g., you can make
your mode-line or region or whatever use a different image).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: TODO additions

[Stefan Monnier]

> I stopped maintaining these because having large local changes really kills
> CVS performance over a slow link, and they've probably bit-rotted quite a bit

I believe Subversion has fixed this problem (which is both a performance
and a privacy problem since you end up sending your private file over to
the server and most people aren't aware of it).
The problem could also be solved on the CVS client, but I don't know of any
such effort.  Maybe if we all complain enough...


	Stefan

Re: TODO additions

[Dave Love]

Miles Bader <miles@gnu.org> writes:

> Note that my implementation let you add a background image to any _face_
> (including the default face)

That's what I was thinking of.

Re: TODO additions

[Stefan Monnier]

> * Provide a means to display a background image in a window [miles
>   started on this?] and extract image-relative coordinates from mouse
>   clicks on images.  (Both needed for W3.)  Also useful for W3 and Gnus:
>   allow scrolling images properly.

I couldn't care less about background images (my browser config
explicitly disrergards background settings), but image scrolling is
important and deserves its own TODO entry.

> * 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 sadly have no experience with such things at all,
so I wouldn't even know what to look for.

> * 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).

> * 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) ?

> * 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.  Haven't heard much more about it, tho.

I generally agree with the rest, of course.
Please add it to etc/TODO.


	Stefan

Re: TODO additions

[Oliver Scholz]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
[Dave Love writes:]
> > * Provide a means to display a background image in a window [miles
> >   started on this?] and extract image-relative coordinates from mouse
> >   clicks on images.  (Both needed for W3.)  Also useful for W3 and Gnus:
> >   allow scrolling images properly.
> 
> I couldn't care less about background images (my browser config
> explicitly disrergards background settings), but image scrolling is
> important and deserves its own TODO entry.

When background images can be displayed on arbitrary positions in the
buffer (I understand that this is possible with Miles' code) they
could be used for other fancy things, not only for decorative
background images in the actual sense of the word. I am thinking of
widgets implemented as pictures behind the text or similar things.

Moreover, as soon as some kind soul implements a way to change images
in the image cache directly, this type of background images could
allow simple vector graphics. Like drawing arrows from one part of the
text to other parts, drawing a vertical ruler line and such stuff. :-)

> > * 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 sadly have no experience with such things at all,
> so I wouldn't even know what to look for.

I assume this is about the XPM images for the toolbar and the splash
screen?  I would like to do the conversion as soon as I have a
GNU/Linux on my new computer; this will be in a week or two
(university has just started again ...).

But: While replacing the XPM with PPM would have the benefit that even
an Emacs compiled without XPM support could have coloured icons on the
toolbar, getting rid of the PBMs would cause a problem for mono
displays (black&white, not grayscale), wouldn't it?

    Oliver

-- 
30 Vendémiaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: TODO additions

[Stefan Monnier]

> When background images can be displayed on arbitrary positions in the
> buffer (I understand that this is possible with Miles' code) they
> could be used for other fancy things, not only for decorative
> background images in the actual sense of the word. I am thinking of
> widgets implemented as pictures behind the text or similar things.
> 
> Moreover, as soon as some kind soul implements a way to change images
> in the image cache directly, this type of background images could
> allow simple vector graphics. Like drawing arrows from one part of the
> text to other parts, drawing a vertical ruler line and such stuff. :-)

I don't want to argue against background images since I simply don't
care about them at all, but note that the applications you have
in mind will have to deal with problems linked to the variable line
height, line wrapping, variable char width, ... and that those variable
values can be different for the same buffer but displayed in two
different windows.  So maybe a different approach than background
images will prove easier and more robust.


	Stefan

Re: TODO additions

[Dave Love]

"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).

Re: TODO additions

[Richard Stallman]

    * Provide a means to display a background image in a window [miles
      started on this?] and extract image-relative coordinates from mouse
      clicks on images.  (Both needed for W3.)  Also useful for W3 and Gnus:
      allow scrolling images properly.

I see no need for background images.  Scrolling through images is very
important, and already listed in TODO.  I will clarify that item.

    * 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?  I don't know much
about these image formats.

    * 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.

    * 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.

The rest all seem desirable in principle at least, so I will
add them to etc/TODO.

    * Allow unknown image types to be rendered via an external program
      converting them to, say, PBM (in the same way as PostScript?).

    * 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.]

    * Allow images (not just text) in the margin to be mouse-sensitive.
      (Requires recursing through display properties).  Provide some way
      to simulate mouse-clicks on marginal text without a mouse.

    * Implement Lisp functions to determine properly whether a character
      is displayable (particularly needed in XFree 4, sigh).  Use it to
      define useful glyphs that may be displayed as images or unicodes
      (with ASCIIfied fallback via latin1-disp).  Examples include
      box-drawing graphics in Custom buffers, W3 rules and tables, and
      tree displays generally, mode-line mail indicator.  [See work done
      already for Emacs 22 and consult fx.]

    * 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.

    * Extend ps-print to deal with multiple font sizes, images, and extra
      encodings.

    * Provide portable undumping using mmap (per gerd design).  [unexec
      _is_ a major headache.]

    * Replace gmalloc.c with the modified Doug Lea code from the current
      GNU libc so that the special mmapping of buffers can be removed  --
      that apparently loses under Solaris, at least.

Re: TODO additions

[Dave Love]

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.

Re: TODO additions

[Miles Bader]

On Tue, Oct 29, 2002 at 06:04:56PM +0000, Dave Love wrote:
> I agree that the main use of HTML background images
> is to make pages more-or-less unusable, but that's not the point.

I'm not sure that background images as I implemented them are actually all
that suitable for a typical html browser usage.  The reason is that a typical
web-site background image is `document relative' -- that is, the image is
logically tiled starting from the beginning of the document, and scrolls with
the image, etc.  In emacs, this is very hard to do, because there's no easy
metric one can use to translate a document position (which is all you
reasonably have available in redisplay) into a vertical offset; I guess this
is the same reason that scroll bars sometimes act in surprising ways.

My background image implementation provided several options for the origin of
the image, but they were all things that were easy to calculate in redisplay
-- e.g., window or frame relative.  [The result being that background images
_don't_ scroll with the document, but rather the document scrolls against
them]

It'd be nice to implement the HTML style too, but I'm not sure how.

As far as I could see the main uses of my background images are (1) to make
emacs look really cool (and it does do that), and (2) to provide a better
answer for the constant `can I make emacs transparent' questions on usenet.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: TODO additions

[Richard Stallman]

    As far as I could see the main uses of my background images are (1) to make
    emacs look really cool (and it does do that),

If it is easy and painless, I have nothing against it.

						  and (2) to provide a better
    answer for the constant `can I make emacs transparent' questions on usenet.

What does "transparent" mean in this context?

Re: TODO additions

[Dave Love]

Miles Bader <miles@gnu.org> writes:

> I'm not sure that background images as I implemented them are actually all
> that suitable for a typical html browser usage.

Then sorry, I mis-remembered.  I thought it did basically the same
thing as the XEmacs version and, as far as I remember, that DTRT in
W3, but I can't check just now.

Re: TODO additions

[Richard Stallman]

    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.

I wasn't thinking in terms of W3, but now that you mention it,
why *isn't* that the point?

    Anyhow, I think there are other applications of miles' implementation,
    which is what I was thinking of.

What are the other applications?

    >     * 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?

Could you explain the connection?  You're being rather terse, and I
don't understand the situation enough to understand.  I don't know
anything about these image formats except their names.  I don't know
their capabilities, and I don't know which systems support them.

Re: TODO additions

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     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.
>
> I wasn't thinking in terms of W3, but now that you mention it,
> why *isn't* that the point?

I think Dave mentioned that background images could be a way to
implement image maps which seems to be a good idea.

A spreadsheet-like mode could color alternating lines differently
with a bg image.  (But this one could be done with faces, too, I
guess.)

One could draw pictures and put annotations on top of them with
text.  I think it would be useful to do something like this in word
processing style applications.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: TODO additions

[Miles Bader]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
> I think Dave mentioned that background images could be a way to
> implement image maps which seems to be a good idea.

That would require a `document anchored' background image, which is
hard to do (I explained why in a recent post on this same thread).

Anyway, why not just use a normal image for this, since that's what
most web browsers do for image-maps?

> One could draw pictures and put annotations on top of them with
> text.  I think it would be useful to do something like this in word
> processing style applications.

Again this would probably run afoul of the `document anchored' image
restriction, though I admit it would be kinda cool.

Hmm, maybe there's some cheezy heuristic which would get the average
case mostly right.  E.g., just use the line count [is this available to
redisplay if mode-line line-numbers are turned on?] and multiply by the
default face's height.  It'd be wrong for some cases, but it would
usually result in coherent display behavior (the image would scroll in
unison with the text ... most of the time).

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: TODO additions

[Richard Stallman]

    I think Dave mentioned that background images could be a way to
    implement image maps which seems to be a good idea.

What is an image map?

Re: TODO additions

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     I think Dave mentioned that background images could be a way to
>     implement image maps which seems to be a good idea.
>
> What is an image map?

Clicking on different spots of the image invokes different
hyperlinks.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: TODO additions

[Richard Stallman]

    Clicking on different spots of the image invokes different
    hyperlinks.

That is a useful feature, but I don't see how it relates to background
images.  You would usually want to use this feature on an image
that isn't background.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     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.
> 
> I wasn't thinking in terms of W3, but now that you mention it,
> why *isn't* that the point?

I think that a browser should be able to render such stuff regardless.
In some cases pages are actually unusable without the background
because of what losing `designers' have put on top.

>     Anyhow, I think there are other applications of miles' implementation,
>     which is what I was thinking of.
> 
> What are the other applications?

I seem to have misunderstood or mis-remembered the implementation, so
maybe I shouldn't comment.

>     >     * 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?
> 
> Could you explain the connection?

PPM does colour and is supported generally, so it may be able to
replace both PBM and XPM.

> You're being rather terse, and I
> don't understand the situation enough to understand.  I don't know
> anything about these image formats except their names.  I don't know
> their capabilities, and I don't know which systems support them.

Stefan has already explained more if I wasn't explicit enough before.
I thought this was documented somewhere, but if not, I guess it should
be.

Whether this works or not depends on the Emacs image-handling code
dealing well with the chosen background for the image (since PPM
doesn't have transparency) and how the images behave on monochrome and
greyscale displays.  Even if you need to keep PBM for the such
displays it would be worth having colour images available on all
platforms when they display colour.

Re: TODO additions

[Richard Stallman]

    I think that a browser should be able to render such stuff regardless.
    In some cases pages are actually unusable without the background
    because of what losing `designers' have put on top.

Many pages are unusable without Internet Explorer, or unusable without
Flash--by comparison, would these be significant in number?

I don't have personal experience with either kind of page, so I can't
say whether supporting background images "correctly" does more harm or
more good.  What I can say is that people should not blindly assume
that supporting them "correctly" is the right choice.  Maybe it is,
and maybe not.

But maybe the issue is not a real one.  If "correct" implementation of
background images is not a possible, then why worry about the issue?

    PPM does colour and is supported generally, so it may be able to
    replace both PBM and XPM.

If this works, I agree it is a good idea.  So it's just a matter of
verifying that this really works.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Many pages are unusable without Internet Explorer, or unusable
> without Flash

I know only too well, but Flash isn't in HTML 3.2, for instance.

> I don't have personal experience with either kind of page, so I can't
> say whether supporting background images "correctly" does more harm or
> more good.

I don't think it can actually harm.

> What I can say is that people should not blindly assume
> that supporting them "correctly" is the right choice.

I'm not assuming anything like that blindly.  In fact facilities for
the blind is one of the things I'm interested in supporting, though I
haven't been able to devote time to raman's W3 issues recently.

> But maybe the issue is not a real one.  If "correct" implementation of
> background images is not a possible, then why worry about the issue?

If XEmacs does it, presumably there isn't actually a fundamental
difficulty.  It's not worth further argument, anyhow.

Re: TODO additions

[Miles Bader]

On Mon, Nov 11, 2002 at 08:15:48PM +0000, Dave Love wrote:
> > But maybe the issue is not a real one.  If "correct" implementation of
> > background images is not a possible, then why worry about the issue?
> 
> If XEmacs does it, presumably there isn't actually a fundamental
> difficulty.  It's not worth further argument, anyhow.

What I wonder is if xemacs actually supports it _correctly_, or whether they
just use a sort of `mostly works' heuristic like I mentioned before.  I think
that emacs' display model makes it impossible to actually do it right without
rendering the entire document before the current window to calculate the
correct vertical offset (and they certainly aren't going to do that).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: TODO additions

[Richard Stallman]

    What I wonder is if xemacs actually supports it _correctly_, or whether they
    just use a sort of `mostly works' heuristic like I mentioned before.

If something that "mostly works" is good enough when used in XEmacs,
maybe it is worth doing.

Re: TODO additions

[Dave Love]

Miles Bader <miles@gnu.org> writes:

> What I wonder is if xemacs actually supports it _correctly_, or whether they
> just use a sort of `mostly works' heuristic like I mentioned before.

I don't know, and I suspect it's inadequately documented.  I have now
tried W3 with background images in it, and they appear to work as I
expect on a quick test, but that's all I can say.

Re: TODO additions

[Richard Stallman]

    >     * 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.

When Autoconf handles a specific issue, it is a good idea to switch
over to using Autoconf to handle it.  But I'd be extremely surprised
if Autoconf handled all the issues that Emacs needs to know about.

To implement an Autoconf test for any given issue might be easy or it
might be hard.  Even when it seems easy enough to write the Autoconf
test, verifying that it really tests the right thing is substantial
effort.  This is not worth the trouble, when the code is stable
and not giving us trouble.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> When Autoconf handles a specific issue, it is a good idea to switch
> over to using Autoconf to handle it.  But I'd be extremely surprised
> if Autoconf handled all the issues that Emacs needs to know about.

It may not have canned tests for everything, but I don't think writing
tests where necessary and providing explicit info which can't be
tested is so difficult.  I don't see how Emacs is special, especially
compared with gcc and gdb, say (having been through this with gcc).
If a test is useful for Emacs, it's likely to be useful elsewhere.

> To implement an Autoconf test for any given issue might be easy or it
> might be hard.

Yes, but I have a fair idea what's involved, since I did a lot of it
once.

> Even when it seems easy enough to write the Autoconf
> test, verifying that it really tests the right thing is substantial
> effort.

The point is that you don't have to test everywhere.  I know that
doesn't provide real guarantees, but it's better than the current
situation, where the configuration keeps falling over on mainstream
platforms (even on GNU at least once).  There doesn't seem to be much
testing of the sort of systems I have to deal with anyhow.  I've
recently addressed issues on current versions of Solaris, Irix and
Tru64 which wouldn't have occurred with canonical autoconf.  The
Solaris issue with bcopy & al was actually the same as what I'd
already addressed specifically for Irix; using autoconf tests in that
case avoids more systems breaking that way in future.

> This is not worth the trouble, when the code is stable
> and not giving us trouble.

But the code isn't stable -- a change since the emacs-unicode branch
broke the Tru64 build -- and it's certainly still giving me trouble.
That's why I raised the topic again.

Re: TODO additions

[Richard Stallman]

    It may not have canned tests for everything, but I don't think writing
    tests where necessary and providing explicit info which can't be
    tested is so difficult.

That is trivial, since we have already done it.

Chances are we could easily use Autoconf for more than we do now.
It does take some work.  If someone wants to do it, that is fine.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     It may not have canned tests for everything, but I don't think writing
>     tests where necessary and providing explicit info which can't be
>     tested is so difficult.
> 
> That is trivial, since we have already done it.

What's there now is often incorrect, at least as it's used --
e.g. breakage in Solaris and Irix -- or otherwise dubious and
untestable.  I say this after getting far too familiar with it on
multiple platforms.

> Chances are we could easily use Autoconf for more than we do now.
> It does take some work.  If someone wants to do it, that is fine.

I'm pleased that's OK, at least.

Re: TODO additions

[Stefan Monnier]

>     * 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?  I don't know much
> about these image formats.

The PPM format is supported by all Emacsen, whereas the XPM format
is only supported if you have the libXpm library.

>     * 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.

We have already installed changes that make the configuration process
rely more on autoconf and less on src/{s,m}.  We should keep going in
this direction because it makes things easier to handle.  Whether we'll
ever be able to remove src/{s,m} is not relevant I think (it would be
good but is not a prerequisite to using autoconf/automake).

>     * 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.

I find it distressing that GPL programs should not be able to dynamically
load a GPL library just because of some legal issues.  I understand the
legal issues, but I still think that there has to be some way (either
technical or legal) to allow dynamic loading without endangering the
overarching goal of the FSF.  I (and I guess Dave as well) can't try to
solve the problem on the legal side, but we can try to address it
technically.


	Stefan

Re: TODO additions

[Richard Stallman]

    >     * 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?  I don't know much
    > about these image formats.

    The PPM format is supported by all Emacsen, whereas the XPM format
    is only supported if you have the libXpm library.

Are you saying that we simply have to convert all the images to PPM
form, and they will work as well as they do now and work portably?

Re: TODO additions

[Dave Love]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Whether we'll
> ever be able to remove src/{s,m} is not relevant I think (it would be
> good but is not a prerequisite to using autoconf/automake).

The most important thing is to avoid the cpp preprocessing of .in
files (which relies on there even being a cpp with the right
behaviour).  However, the current {s,m} system is a mess and it
definitely contributes to the maintenance nightmare.

A case in point is finding out how and why something is happening on
an Irix 6 system.  There's a horrible stack of s files involved,
conflated with a non-orthogonal m file, processed in a way that's very
hard to follow and debug.

> I understand the legal issues,

I don't...

> but I still think that there has to be some way (either technical or
> legal) to allow dynamic loading without endangering the overarching
> goal of the FSF.

Indeed.

> I (and I guess Dave as well) can't try to solve the problem on the
> legal side, but we can try to address it technically.

Actually, I tried to address the legal issue with the technical
approach of allowing either static or dynamic linking of identical
module source.  I thought that would make copyright issues clear as
well as being clean from a programming point of view.

Re: TODO additions

[Richard Stallman]

    > Whether we'll
    > ever be able to remove src/{s,m} is not relevant I think (it would be
    > good but is not a prerequisite to using autoconf/automake).

    The most important thing is to avoid the cpp preprocessing of .in
    files (which relies on there even being a cpp with the right
    behaviour).

That would be very difficult.  Even if we could have Autoconf figure
out every relevant parameter, and have eliminate the s and m
directories, that would not eliminate the need for preprocessing of
src/Makefile.in.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> That would be very difficult.  Even if we could have Autoconf figure
> out every relevant parameter, and have eliminate the s and m
> directories, that would not eliminate the need for preprocessing of
> src/Makefile.in.

I don't understand why.  That's the canonical use of autoconf, and
it's clearly more reliable than using a cpp which may not exist.

Here's another example of lossage I've just found, from an attempt to
build on RedHat 8.0.  I've no idea what's going on.

creating lib-src/Makefile
creating src/Makefile
cd lib-src; make all  \
  CC='gcc' CFLAGS='-g -O2' CPPFLAGS='-D_BSD_SOURCE  ' \
  LDFLAGS='-L/usr/X11R6/lib' MAKE='make'
make[1]: Entering directory `/.automount/pxfs5/root/scr1/fx/emacs-rh/lib-src'
gcc -g -O2 -D_BSD_SOURCE   -L/usr/X11R6/lib  Makefile.c -lc  -o Makefile
Makefile.c:1:3: invalid preprocessing directive #Makefile

[...]

$ ls -l src/Ma*
-r--r--r--    1 fx       dlpxprog    20069 Nov  5 11:19 src/Makefile
-rw-r--r--    1 fx       dlpxprog    42351 Nov  5 11:19 src/Makefile.c

Re: TODO additions

[Richard Stallman]

    > That would be very difficult.  Even if we could have Autoconf figure
    > out every relevant parameter, and have eliminate the s and m
    > directories, that would not eliminate the need for preprocessing of
    > src/Makefile.in.

    I don't understand why.  That's the canonical use of autoconf, and
    it's clearly more reliable than using a cpp which may not exist.

Sorry, I don't understand that response at all.

Autoconf substitutes various values into config.h and Makefile.in.
The preprocessing operates on the result.  Right now the symbols that
it tests are mostly defined in {s,m}*.h, but if those symbols were
instead defined in config.h thanks to Autoconf, we would still need to
use them to edit the makefile.

I think it will be hard to make Autoconf set those symbols.  For
instance, consider the variable ORDINARY_LINK.  How would Autoconf
determine that?  It is possible that all modern systems use
ORDINARY_LINK and we can eliminate the conditional, but otherwise
I see no substitute for handling it the way we do now.

Re: TODO additions

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|> I think it will be hard to make Autoconf set those symbols.  For
|> instance, consider the variable ORDINARY_LINK.  How would Autoconf
|> determine that?  It is possible that all modern systems use
|> ORDINARY_LINK and we can eliminate the conditional, but otherwise
|> I see no substitute for handling it the way we do now.

Instead of letting autoconf determine the right [sm]/*.h file, it just
defines the respective symbols instead.  I.e, the configuration database
just moves to a different file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: TODO additions

[Richard Stallman]

    |> I think it will be hard to make Autoconf set those symbols.  For
    |> instance, consider the variable ORDINARY_LINK.  How would Autoconf
    |> determine that?  It is possible that all modern systems use
    |> ORDINARY_LINK and we can eliminate the conditional, but otherwise
    |> I see no substitute for handling it the way we do now.

    Instead of letting autoconf determine the right [sm]/*.h file, it just
    defines the respective symbols instead.

Autoconf does not determine which *.h files to use.
configure decides that based on the configuration name.
Indeed, the proposal that was made was that Autoconf should
determine on its own the definitions that are now in the *.h files.

ORDINARY_LINK is one of those symbols.  Right now it is defined in
certain *.h files.  Part of this proposal is that Autoconf should
define it directly.

I therefore challenge anyone to show a way that Autoconf can determine
the proper value for ORDINARY_LINK.  I don't think this is easy.

Re: TODO additions

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

|>     |> I think it will be hard to make Autoconf set those symbols.  For
|>     |> instance, consider the variable ORDINARY_LINK.  How would Autoconf
|>     |> determine that?  It is possible that all modern systems use
|>     |> ORDINARY_LINK and we can eliminate the conditional, but otherwise
|>     |> I see no substitute for handling it the way we do now.
|> 
|>     Instead of letting autoconf determine the right [sm]/*.h file, it just
|>     defines the respective symbols instead.
|> 
|> Autoconf does not determine which *.h files to use.
|> configure decides that based on the configuration name.

Exactly, that's what I meant.

|> I therefore challenge anyone to show a way that Autoconf can determine
|> the proper value for ORDINARY_LINK.  I don't think this is easy.

Based on the configuration name?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: TODO additions

[Richard Stallman]

    |> I therefore challenge anyone to show a way that Autoconf can determine
    |> the proper value for ORDINARY_LINK.  I don't think this is easy.

    Based on the configuration name?

Using Autoconf means doing it by experiments on the system.
configure.in can also test the configuration name,
which means not using Autoconf.

If it is going to do that, the present method (with .h files) is
easier than listing all the values directly on configure.in.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Using Autoconf means doing it by experiments on the system.
> configure.in can also test the configuration name,
> which means not using Autoconf.

I don't think that's what most people using autoconf mean by `using
autoconf'.  The configuration name is actually derived by the autoconf
macro AC_CANONICAL_HOST.  However, I guess to most of us, substituting
config info into Makefiles using cpp is `not using autoconf', whereas
doing it directly with AC_OUTPUT and AC_SUBST is.

> If it is going to do that, the present method (with .h files) is
> easier than listing all the values directly on configure.in.

You could use shell fragments instead of .h files to abstract some of
the work if that was useful.  It isn't necessary to do that, though.
configure currently extracts info from the .h files, and that could be
extended to do everything with AC_SUBST & al.  It wouldn't help with
the current .h files being a mess, though.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Autoconf does not determine which *.h files to use.
> configure decides that based on the configuration name.

If the configuration files were organized to match the canonical
system name components (derived by autoconf), I expect you could avoid
the big case analysis in configure.in (some of which currently
references non-existent files).

> Indeed, the proposal that was made was that Autoconf should
> determine on its own the definitions that are now in the *.h files.

By who?  It should certainly do a lot more, and it shouldn't process
everything with cpp, but shell fragments are fine for storing info
that can't (easily or reliably?) be determined automatically.

> ORDINARY_LINK is one of those symbols.  Right now it is defined in
> certain *.h files.  Part of this proposal is that Autoconf should
> define it directly.

What proposal?  I haven't said that, at least.

> I therefore challenge anyone to show a way that Autoconf can determine
> the proper value for ORDINARY_LINK.  I don't think this is easy.

It's not clear to me exactly what it means, even.  That is part of the
problem with the current setup.  (I mean in instances of real problems
with it that I've tackled.  I don't remember crossing swords with
ORDINARY_LINK specifically.)

[Why would Emacs need to be linked differently from any other program?
It's not as if others don't use unexec, for instance.]

Re: TODO additions

[Richard Stallman]

    > ORDINARY_LINK is one of those symbols.  Right now it is defined in
    > certain *.h files.  Part of this proposal is that Autoconf should
    > define it directly.

    What proposal?  I haven't said that, at least.

Someone proposed to eliminate the *.h files and determine the
information with Autoconf.  That means either defining ORDINARY_LINK
with Autoconf or eliminating it entirely.

If nobody is advocating that now, then there is no need to argue about
it.

    [Why would Emacs need to be linked differently from any other program?

I don't know "Why would it?" but I can answer the question "Why does
it?"  Emacs needed to use its own special crt0.o file and that
required calling ld directly.  At first it was always done that way.
Later on some systems we arranged to use cc.  So we added the
ORDINARY_LINK flag for those systems.

The question is relevant if you are thinking of implementing a
replacement for this code, which would always use cc to link.  I think
that would be a nice simplification if it works, but hard to do.

Unless and until that change is made, we need to keep supporting the
use of ORDINARY_LINK, which means that one way or another configure.in
must decide the value of ORDINARY_LINK.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> I don't know "Why would it?" but I can answer the question "Why does
> it?"  Emacs needed to use its own special crt0.o file and that
> required calling ld directly.

My point is that if this is a consequence of using unexec, for
instance, it applies to things like SCM (and TeX?) too -- as well as
Guile if that ever reinstates SCM's dump facility.

> At first it was always done that way.
> Later on some systems we arranged to use cc.  So we added the
> ORDINARY_LINK flag for those systems.

So if I understand correctly, ORDINARY_LINK just means use `$(CC)' for
what would normally be the Makefile LINK variable.

> The question is relevant if you are thinking of implementing a
> replacement for this code, which would always use cc to link.  I think
> that would be a nice simplification if it works, but hard to do.

It seems to me that Libtool is the right place for knowledge of such
things so that it can be shared usefully.  I don't know whether that's
worthwhile, though.

> Unless and until that change is made, we need to keep supporting the
> use of ORDINARY_LINK, which means that one way or another configure.in
> must decide the value of ORDINARY_LINK.

I doubt anyone disputes that.  It's a question of the most
maintainable way to do it.

Here's another example of the difficulty of understanding things if
one was to improve matters.  src/Makefile.in says:

  /* GNU libc requires ORDINARY_LINK so that its own crt0 is used.
     Linux is an exception because it uses a funny variant of GNU libc.  */

I don't know about the first sentence, but I think the second isn't
true on modern systems, and it's not clear whether it would be an
advantage if the gnu-linux configuration was be changed for
configurations using libc6.

Re: TODO additions

[Richard Stallman]

    > At first it was always done that way.
    > Later on some systems we arranged to use cc.  So we added the
    > ORDINARY_LINK flag for those systems.

    So if I understand correctly, ORDINARY_LINK just means use `$(CC)' for
    what would normally be the Makefile LINK variable.

Yes.

      /* GNU libc requires ORDINARY_LINK so that its own crt0 is used.
	 Linux is an exception because it uses a funny variant of GNU libc.  */

    I don't know about the first sentence, but I think the second isn't
    true on modern systems,

Could you explain at greater length how it is not true?

			    and it's not clear whether it would be an
    advantage if the gnu-linux configuration was be changed for
    configurations using libc6.

I don't understand--what change are you contemplating?

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>       /* GNU libc requires ORDINARY_LINK so that its own crt0 is used.
> 	 Linux is an exception because it uses a funny variant of GNU libc.  */
> 
>     I don't know about the first sentence, but I think the second isn't
>     true on modern systems,
> 
> Could you explain at greater length how it is not true?

Well, it's not true unless, for instance, you consider the diffs in
the current Debian source package to constitute a `funny version'.
They are relatively small changes which I think mainly are mainly
picked from glibc development anyhow.  (In a recent discussion I saw
about the next upload for Debian libc6, the advice was actually to
package source directly from glibc's CVS.)  The old `libc5' was a
different kettle of fish.

> 			    and it's not clear whether it would be an
>     advantage if the gnu-linux configuration was be changed for
>     configurations using libc6.
> 
> I don't understand--what change are you contemplating?

I'm not particularly, but you said it might be good to eliminate
ORDINARY_LINK.  The libc situation seems to have changed for modern
systems from the old libc5, so perhaps there's some advantage to
updating the configuration file.  I don't know, but I think the
comment above is incorrect anyhow.

The message is that a lot of the stuff in the m&s files is obscure and
under-documented and tends to cause trouble when included by another
configuration.  (I think you have to have worked on several random
configurations recently to get a feel for this.)  It would help if all
the macros which have an effect in the source were documented
AC_DEFINE or AH_TEMPLATE doc strings in configure.in.

It would also be worth discarding configurations for systems that
you're confident aren't running now.  Going through them all makes
life harder when doing general cleanups, such as for alloca to make
sure it's always properly declared.  I recently deleted GEC 63 since I
worked on the last of those, and I'm sure there are other candidates.

Re: TODO additions

[Richard Stallman]

    Well, it's not true unless, for instance, you consider the diffs in
    the current Debian source package to constitute a `funny version'.

It is a nonstandard version.  Perhaps some of their patches
ought to be installed in Emacs--we would have to judge them one by one.

      It would help if all
    the macros which have an effect in the source were documented
    AC_DEFINE or AH_TEMPLATE doc strings in configure.in.

The lists in configure.in would be painfully long, and we would want
to move them into separate files--which is where they are now.

The inheritance chains of *.h files are often long.  Perhaps it would
simplify matters in some situations to eliminate some of the inheritance
by making some of the files self-contained.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     Well, it's not true unless, for instance, you consider the diffs in
>     the current Debian source package to constitute a `funny version'.
> 
> It is a nonstandard version.  Perhaps some of their patches
> ought to be installed in Emacs--we would have to judge them one by one.

The question was about libc for Linux, not about Emacs on Debian.

[Actually I think the basic Debian Emacs patches are both unnecessary
and annoying (he says, typing at such an Emacs).]

>       It would help if all
>     the macros which have an effect in the source were documented
>     AC_DEFINE or AH_TEMPLATE doc strings in configure.in.
> 
> The lists in configure.in would be painfully long,

Just one line per option (unless the description is longer than a
line).  That's surely no longer than the info would be if the
template.h files had been kept up-to-date concerning all the flags.

> and we would want
> to move them into separate files--which is where they are now.

I don't know what you mean.  The information I'm talking about is just
missing.

> The inheritance chains of *.h files are often long.  Perhaps it would
> simplify matters in some situations to eliminate some of the inheritance
> by making some of the files self-contained.

That would be better.  It's not just a question of simplification.
Things down the chain typically break systems higher up, as usg5-4.h
did, when they specify things that are not true for more recent or
more specific systems.

Re: TODO additions

[Richard Stallman]

    The question was about libc for Linux, not about Emacs on Debian.

I didn't realize that, but the answer is the same: maybe we
should put some of those patches into the standard version.

It's actually GNU libc for GNU/Linux.  Please don't call the whole
system "Linux", because that means giving someone else credit for our
work (including your work).

    >       It would help if all
    >     the macros which have an effect in the source were documented
    >     AC_DEFINE or AH_TEMPLATE doc strings in configure.in.
    > 
    > The lists in configure.in would be painfully long,

    Just one line per option (unless the description is longer than a
    line).  That's surely no longer than the info would be if the
    template.h files had been kept up-to-date concerning all the flags.

I don't see why these macro definitions would be any shorter 
if they were copied into configure.in.  They are long enough
that it is much better to keep them in separate files, as
they are now.

    > and we would want
    > to move them into separate files--which is where they are now.

    I don't know what you mean.  The information I'm talking about is just
    missing.

Precisely what information are you talking about, then?
I thought your proposal was to specify directly in
configure.in the values that are now specified in
the s/ and m/ files.

    > The inheritance chains of *.h files are often long.  Perhaps it would
    > simplify matters in some situations to eliminate some of the inheritance
    > by making some of the files self-contained.

    That would be better.

Would you like to propose specific files to change so that they
do not inherit?

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     The question was about libc for Linux, not about Emacs on Debian.
> 
> I didn't realize that, but the answer is the same: maybe we
> should put some of those patches into the standard version.

I don't know whether this means Emacs or libc.  If the latter, as far
as I know, there aren't Debian-specific patches.

The current set of diffs for Emacs does appear to suggest that mail
locking will get configured wrongly on Debian, and you could lose
mail.  I don't understand this offhand -- I originally put in autoconf
tests which I thought were consistent with the then-current Debian
changes.

[I'm actually using the XEmacs movemail from Debian, not the vanilla
one, because my mail spool isn't fed by a Debian system and I need to
be able to set the locking appropriately.  I did look at merging those
changes, since they're probably covered by assignments, but it wasn't
straightforward.  Doing that, or making equivalent changes, should be
in TODO.]

For 21.3, you might want other changes for gnu-linux mipsle, hp and
s390 targets, but they're inconsistent with the treatment in the
current head sources.  (I just made a trivial change which should get
mipsle OK.)

I can send a pared-down version of the diffs if that's useful.

> It's actually GNU libc for GNU/Linux.  Please don't call the whole
> system "Linux",

I'm not.  I'm referring to one of the two kernels the library
currently supports, like node `Linux' in the libc manual.

> I don't see why these macro definitions would be any shorter 
> if they were copied into configure.in.

I'm talking about doc strings for them (which can't be copied if they
don't exist).

>     I don't know what you mean.  The information I'm talking about is just
>     missing.
> 
> Precisely what information are you talking about, then?

What macros _mean_.  Consider some of the things used in systty.h:
BSD_TERMIOS, HAVE_TCATTR, HAVE_TERMIO, NO_TERMIO, HAVE_TERMIOS.  Does
HAVE_TERMIOS mean _POSIX_ termios?  When should HAVE_TERMIO, NO_TERMIO
be defined?  That sort of thing.

> I thought your proposal was to specify directly in
> configure.in the values that are now specified in
> the s/ and m/ files.

I didn't say that.  I'd want to avoid specifying as much as possible.
E.g. autoconf has AC_SYS_POSIX_TERMIOS, and I can detect termio.h &c,
but without information like the above, that doesn't help.

>     > The inheritance chains of *.h files are often long.  Perhaps it would
>     > simplify matters in some situations to eliminate some of the inheritance
>     > by making some of the files self-contained.
> 
>     That would be better.
> 
> Would you like to propose specific files to change so that they
> do not inherit?

I'll try to later.

Re: TODO additions

[Richard Stallman]

    [I'm actually using the XEmacs movemail from Debian, not the vanilla
    one, because my mail spool isn't fed by a Debian system and I need to
    be able to set the locking appropriately.

Could you (or someone) find the necessary changes (in Debian perhaps)
so we can install them?

    For 21.3, you might want other changes for gnu-linux mipsle, hp and
    s390 targets, but they're inconsistent with the treatment in the
    current head sources.  (I just made a trivial change which should get
    mipsle OK.)

Could you say more concretely which part of the code we're talking
about?  Which precisely are the versions that are inconsistent?  (If
you would like to solve the problem yourself then you don't need to
explain it.)

    I can send a pared-down version of the diffs if that's useful.

Would the pared-down version of the diffs be a working fix?

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Could you (or someone) find the necessary changes (in Debian perhaps)
> so we can install them?

I don't think there are simple changes -- if I remember correctly, the
structure was quite different, which was why I didn't just do it.
You'd need to look in XEmacs CVS anyhow to (try to) verify the
provenance of the code.  The bulk of it was apparently done by
Sperber, but I didn't check it thoroughly.  The server is at
:pserver:cvs@sunsite.dk:/pack/xemacscvs.

Apart from the locking stuff, Debian has other changes to movemail for
specifying the spool directory (but only at configure time).

>     For 21.3, you might want other changes for gnu-linux mipsle, hp and
>     s390 targets, but they're inconsistent with the treatment in the
>     current head sources.  (I just made a trivial change which should get
>     mipsle OK.)
> 
> Could you say more concretely which part of the code we're talking
> about?

Just the {m,s}/*.h files, and trivial changes to configure.in.

> Which precisely are the versions that are inconsistent?

The s390 config file is different and differently named and the
changes in the hp800.h file are different.  I've no evidence anything
in the Emacs head versions is wrong.

> (If you would like to solve the problem yourself then you don't need
> to explain it.)

It only applies to the release branch.  I don't know if you want to
support the targets there.  I think SuSE are s390 experts, so perhaps
schwab could advise on that.

>     I can send a pared-down version of the diffs if that's useful.
> 
> Would the pared-down version of the diffs be a working fix?

I don't know whether the movemail locking changes can be made safe for
other systems.  The readme says the following about the movemail
changes.  Note that comments about `upstream authors'.

  ** The location of the mail spool has been centralized.
  
  [ This modification is currently only available in the Debian source,
    but the upstream authors and I are in the process of working out the
    appropriate upstream patch.
  
    Please do *NOT* use mail-spool-directory in any public code until
    and unless this variable makes it into the upstream source. ]
  
  Determination of the location of the mail spool has now been
  centralized.  There is a new lisp-level variable mail-spool-directory
  that should always contain the location of the mail spool (normally a
  directory like /usr/spool/mail).
  
  There is a related configure option --with-mail-spool-directory that
  allows you to override the default mail spool location detected, if
  any, at configure time.  The proper setting for a particular
  architecture may also be set in src/s/*.h with
  SYSTEM_MAIL_SPOOL_DIRECTORY, but note that --with-mail-spool-directory
  always takes precedence.
  
  At the C level, the mail spool directory is available from
  lib-src/mailspool.h which provides a MAIL_SPOOL_DIRECTORY definition.
  
  nnmail, rmail, and movemail have all been modified to respect this new
  arrangement.
  
  ** Mailbox locking improved and brought into line with Debian policy.
  
  [ This modification is currently only available in the Debian source,
    but the upstream authors and I are in the process of working out the
    appropriate upstream patch. ]
  
  Configure now looks for liblockfile before libmail (liblockfile is a
  free software replacement for libmail).  Either library, if found, is
  propagated to the movemail (lib-src) Makefile through the
  MOVEMAIL_LOCK_LIBS variable.
  
  Also MAIL_USE_FLOCK is disabled since it is wrong for a Debian system.

Re: TODO additions

[Richard Stallman]

    > Could you (or someone) find the necessary changes (in Debian perhaps)
    > so we can install them?

    I don't think there are simple changes -- if I remember correctly, the
    structure was quite different, which was why I didn't just do it.

I am completely confused now.  Are you talking about Emacs changes
made by Debian, or something else?

    >     I can send a pared-down version of the diffs if that's useful.
    > 
    > Would the pared-down version of the diffs be a working fix?

    I don't know whether the movemail locking changes can be made safe for
    other systems.

That problem isn't crucial if we can conditionalize them.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > Could you (or someone) find the necessary changes (in Debian perhaps)
>     > so we can install them?
> 
>     I don't think there are simple changes -- if I remember correctly, the
>     structure was quite different, which was why I didn't just do it.
> 
> I am completely confused now.  Are you talking about Emacs changes
> made by Debian, or something else?

I'm talking about the version of movemail from XEmacs.  I just happen
to be using the Debian-distributed binary.  I don't know if Debian
made any changes to the XEmacs version like to the Emacs one.

>     I don't know whether the movemail locking changes can be made safe for
>     other systems.
> 
> That problem isn't crucial if we can conditionalize them.

Sure, but I'm not clear what the conditions should be.

What's the status of the contact with the Debian maintainer mentioned
in the Debian readme?  If nothings' happening, does someone want to
take a look at this for 21.3?  It's unfortunate if people running
self-built binaries on Debian risk losing mail.

Re: TODO additions

[Richard Stallman]

    > I am completely confused now.  Are you talking about Emacs changes
    > made by Debian, or something else?

    I'm talking about the version of movemail from XEmacs.  I just happen
    to be using the Debian-distributed binary.  I don't know if Debian
    made any changes to the XEmacs version like to the Emacs one.

I am not sure how movemail from XEmacs relates to the issue
of mail locking in Debian.  What is its relevance?

I will ask rlb if he can recommend changes to make movemail do the
right kind of mail locking on Debian GNU/Linux.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > I am completely confused now.  Are you talking about Emacs changes
>     > made by Debian, or something else?
> 
>     I'm talking about the version of movemail from XEmacs.  I just happen
>     to be using the Debian-distributed binary.  I don't know if Debian
>     made any changes to the XEmacs version like to the Emacs one.
> 
> I am not sure how movemail from XEmacs relates to the issue
> of mail locking in Debian.  What is its relevance?

It can DTRT both for mail delivered by Debian and by other systems
(Irix in my case).

> I will ask rlb if he can recommend changes to make movemail do the
> right kind of mail locking on Debian GNU/Linux.

As I tried to explain, that is a necessary change to the current build
if mail is delivered by a Debian system, but not a sufficient change
to movemail if mail is delivered to the spool by a non-Debian system.

It's not clear to me whether a non-Debian client can actually lock the
spool properly when Debian is doing the delivery, since it system
seems to depend on a Debian-specific library.

(This exchange seems to be going round in circles.)

Re: TODO additions

[Richard Stallman]

    > I will ask rlb if he can recommend changes to make movemail do the
    > right kind of mail locking on Debian GNU/Linux.

    As I tried to explain, that is a necessary change to the current build
    if mail is delivered by a Debian system, but not a sufficient change
    to movemail if mail is delivered to the spool by a non-Debian system.

I can see too many possible meanings for this.

Have you looked at rlb's code?  Are you saying it DOES have a
shortcoming compared with the XEmacs code?  Or are you speculating
about it based on my description?  (My description is NOT accurate
enough to be useful for that.)

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > I will ask rlb if he can recommend changes to make movemail do the
>     > right kind of mail locking on Debian GNU/Linux.
> 
>     As I tried to explain, that is a necessary change to the current build
>     if mail is delivered by a Debian system, but not a sufficient change
>     to movemail if mail is delivered to the spool by a non-Debian system.
> 
> I can see too many possible meanings for this.
> 
> Have you looked at rlb's code?

I've only seen the changes in the latest diffs for the Debian package,
not what you said is supposed to do the same thing as sperber's
version.

> Are you saying it DOES have a
> shortcoming compared with the XEmacs code?

The version in the latest debian package has such a shortcoming.

> Or are you speculating about it based on my description?  (My
> description is NOT accurate enough to be useful for that.)

I was only commenting on what you wrote above.  Mail isn't always
delivered by the same sort of system on which you read it.  That's
especially so with a site-wide spool.  It looks as though the
mechanism in Debian has even been changing, so an older system doing
the delivery may not be consistent with a new client.

Re: TODO additions

[Richard Stallman]

    >     For 21.3, you might want other changes for gnu-linux mipsle, hp and
    >     s390 targets, but they're inconsistent with the treatment in the
    >     current head sources.  (I just made a trivial change which should get
    >     mipsle OK.)
    > 
    > Could you say more concretely which part of the code we're talking
    > about?

    Just the {m,s}/*.h files, and trivial changes to configure.in.

What is "inconsistent" about this?

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     >     For 21.3, you might want other changes for gnu-linux mipsle, hp and
>     >     s390 targets, but they're inconsistent with the treatment in the
>     >     current head sources.  (I just made a trivial change which should get
>     >     mipsle OK.)
>     > 
>     > Could you say more concretely which part of the code we're talking
>     > about?
> 
>     Just the {m,s}/*.h files, and trivial changes to configure.in.
> 
> What is "inconsistent" about this?

Maybe `inconsistent' was the wrong word to use.  The Debian changes
are different to the ones made in the Emacs sources after 21.2.

Re: TODO additions

[Richard Stallman]

    The bulk of it was apparently done by
    Sperber, but I didn't check it thoroughly.

Would you be willing to check thoroughly, so we could tell if we could
use that code?

Or do you have a different implementation to recommend to do the same
job?

movemail re-write [was Re: TODO additions]

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     The bulk of it was apparently done by
>     Sperber, but I didn't check it thoroughly.
> 
> Would you be willing to check thoroughly, so we could tell if we could
> use that code?

I thought it made sense for anyone doing the work to see what code
they needed first, but to save another round of mail I checked.  [Most
people could do this, but time I spend time on it is taken from mule
work that nobody else helps handa with.]

I can supply someone willing to do the work with a diff that's all
Sperber's work, and thus assigned.  It's between _old versions_ of the
_XEmacs_ source, though.

> Or do you have a different implementation to recommend to do the same
> job?

No.  It may not be so difficult to change the compile-time checks in
movemail to runtime ones; I don't know and I probably don't understand
enough about locking methods.  The idea is to specify a lock method
that the system can support via environment variable EMACSLOCKMETHOD
or a flag.  E.g. on Debian with the binary from the XEmacs package:

$ ./movemail --help
Usage: movemail [-rvxkh] [-l lines ] [-m method ] [-i] inbox [-o] destfile [[-p] POP-password]
where method is one of: dot, lockf, flock
Default is: dot
$ EMACSLOCKMETHOD=flock
$ ./movemail --help
Usage: movemail [-rvxkh] [-l lines ] [-m method ] [-i] inbox [-o] destfile [[-p] POP-password]
where method is one of: dot, lockf, flock
Default is: flock

To allow reading several spools with different lock methods, any Lisp
which runs movemail would probably have to be more flexible, of
course.

Re: movemail re-write [was Re: TODO additions]

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     I can supply someone willing to do the work with a diff that's all
>     Sperber's work, and thus assigned.  It's between _old versions_ of the
>     _XEmacs_ source, though.
> 
> I guess that would do for a start.  However, Rob Browning
> <rlb@defaultvalue.org> says he has code that he himself wrote
> to do the job.  Starting with that should be easier.

I hope so, if someone can get hold of it and check that it does the
same things as Sperber's (with the same interface).  It's a pity stuff
like this from Debian doesn't actually get contributed; one has to go
looking.

>       The idea is to specify a lock method
>     that the system can support via environment variable EMACSLOCKMETHOD
>     or a flag.  E.g. on Debian with the binary from the XEmacs package:
> 
> That seems ok.  It doesn't by itself solve the problem of how to
> make the right thing happen on Debian, though.  Does Debian define
> this variable by default?

No.  The default is (I assume) correct on Debian, as chosen by
configure.  I thought I showed the help from movemail initially:

Usage: movemail [-rvxkh] [-l lines ] [-m method ] [-i] inbox [-o] destfile [[-p] POP-password]
where method is one of: dot, lockf, flock
Default is: flock

Re: movemail re-write [was Re: TODO additions]

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Dave" == Dave Love <d.love@dl.ac.uk> writes:

Dave> Richard Stallman <rms@gnu.org> writes:

>>     The bulk of it was apparently done by
>>     Sperber, but I didn't check it thoroughly.
>> 
>> Would you be willing to check thoroughly, so we could tell if we could
>> use that code?

Dave> I thought it made sense for anyone doing the work to see what code
Dave> they needed first, but to save another round of mail I checked.  [Most
Dave> people could do this, but time I spend time on it is taken from mule
Dave> work that nobody else helps handa with.]

Dave> I can supply someone willing to do the work with a diff that's all
Dave> Sperber's work, and thus assigned.  It's between _old versions_ of the
Dave> _XEmacs_ source, though.

I'm willing to help, if anyone's interested.  (Yes, I did sign papers
for work on the XEmacs code long ago.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: movemail re-write [was Re: TODO additions]

[Richard Stallman]

    Dave> I can supply someone willing to do the work with a diff that's all
    Dave> Sperber's work, and thus assigned.  It's between _old versions_ of the
    Dave> _XEmacs_ source, though.

If the code does what we need and is assigned, it doesn't matter what
diff it came from.  Getting it by diffing two old versions of XEmacs
is fine.

    I'm willing to help, if anyone's interested.  (Yes, I did sign papers
    for work on the XEmacs code long ago.)

Thanks for offering to help.  Would you like to start writing the
code we need?

Re: movemail re-write [was Re: TODO additions]

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

Dave> I can supply someone willing to do the work with a diff that's all
Dave> Sperber's work, and thus assigned.  It's between _old versions_ of the
Dave> _XEmacs_ source, though.

Richard> If the code does what we need and is assigned, it doesn't matter what
Richard> diff it came from.  Getting it by diffing two old versions of XEmacs
Richard> is fine.

Richard>     I'm willing to help, if anyone's interested.  (Yes, I did sign papers
Richard>     for work on the XEmacs code long ago.)

Richard> Thanks for offering to help.  Would you like to start writing the
Richard> code we need?

I didn't gather from this thread what "the code we need" is.  It seems
to me you're looking for doing proper locking in movemail, and that is
code I've already written for the XEmacs movemail.

Thus, my main interest is with helping to integrate these changes, and
maintaining a shared code base for movemail.  If you're talking about
other additions, you need to clarify.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: movemail re-write [was Re: TODO additions]

[Richard Stallman]

    I didn't gather from this thread what "the code we need" is.  It seems
    to me you're looking for doing proper locking in movemail, and that is
    code I've already written for the XEmacs movemail.

Yes, that's the overall goal.  Dave Love has looked at it in more
detail and has made more specific suggestions for what the goal should
be.

Re: TODO additions

[Richard Stallman]

    > Which precisely are the versions that are inconsistent?

    The s390 config file is different and differently named and the
    changes in the hp800.h file are different.

I am confused now.  What does "inconsistent" mean?
Are you saying that the s390 config file is different in two
versions of Emacs?  If so, what are these two versions?

						I've no evidence anything
    in the Emacs head versions is wrong.

If it isn't broken, then perhaps it is best if we do not fix it.

    > (If you would like to solve the problem yourself then you don't need
    > to explain it.)

    It only applies to the release branch.  I don't know if you want to
    support the targets there.

I would rather not add any new targets there if it isn't trivial to do
so.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > Which precisely are the versions that are inconsistent?
> 
>     The s390 config file is different and differently named and the
>     changes in the hp800.h file are different.
> 
> I am confused now.  What does "inconsistent" mean?
> Are you saying that the s390 config file is different in two
> versions of Emacs?  If so, what are these two versions?

The machine file for the configuration s390-*-linux-gnu which is
supplied by the Debian patch to Emacs 21.2 is not the same as
src/m/ibms390.h in the Emacs tree.  It has different contents and a
different name.

> 						I've no evidence anything
>     in the Emacs head versions is wrong.
> 
> If it isn't broken, then perhaps it is best if we do not fix it.

Of course.  The issue is the release branch, which doesn't have
support for these configurations.  I was only comparing the Debian
changes to support them with the changes that have been installed in
the Emacs head.

> I would rather not add any new targets there if it isn't trivial to
> do so.

I thought GNU targets might be wanted, especially since 21.2
introduced non-GNU new targets.  mipsel is trivial, though I can't
test it.  The changes for s390 and hp800 might count as trivial -- I
don't know.  I guess the original revision of m/ibms390.h would just
drop in to the 21.3 source with a trivial change to configure.in.

Re: TODO additions

[Richard Stallman]

    > I would rather not add any new targets there if it isn't trivial to
    > do so.

    I thought GNU targets might be wanted, especially since 21.2
    introduced non-GNU new targets.  mipsel is trivial, though I can't
    test it.  The changes for s390 and hp800 might count as trivial -- I
    don't know.

If they are totally safe, a matter of adding new files and changing
configure.in, then it is ok to add them.  Are you talking about
copying this support from HEAD to RC?  If so, please go ahead and do
it.

Re: TODO additions

[Richard Stallman]

    What macros _mean_.  Consider some of the things used in systty.h:
    BSD_TERMIOS, HAVE_TCATTR, HAVE_TERMIO, NO_TERMIO, HAVE_TERMIOS.  Does
    HAVE_TERMIOS mean _POSIX_ termios?  When should HAVE_TERMIO, NO_TERMIO
    be defined?  That sort of thing.

Some of them I don't know either.  The best way to figure out what one
of these macros means is to grep for the macro in the source files and
see what it controls.  Some may already be obsolete.

If someone would like to do this and document these macros better,
please do.

I think that HAVE_TERMIOS means something more or less like POSIX
termios.  HAVE_TERMIO refers to something that SysV used to have,
which was I believe the basis for the design of termios in Posix but
was not exactly the same, so Posix changed the name of it.
TCATTR is a specific system call or ioctl (I don't recall which)
so that could probably be tested for by Autoconf easily.

Re: TODO additions

[Francesco Potorti`]

Dave Love <d.love@dl.ac.uk> writes:
>It would also be worth discarding configurations for systems that
>you're confident aren't running now

Then I suggest dropping support for Motorola Delta 147.  It is sad,
because I wrote src/m/delta.h and that was my first work on Emacs :-(

But the box is very old now, and since the fastest processor on them
that I know of was a 25MHz Motorola 68040, I don't think that anyone
ever tried to compile and run Emacs 20 on them.  Emacs 19 was already a
really big program for that box.  In fact, the last Emacs version
reported to work is 19.26.

So I suggest removing src/m/delta.h and the following from etc/MACHINES:

================
Motorola Delta 147 (m68k-motorola-sysv)

  The EMacs 19.26 pretest was reported to work.

  Motorola Delta boxes running System V/68 release 3.
  Tested on 147 board with SVR3V7, no X and gcc.
  Tested on 167 board with SVR3V7, no X, cc, gnucc and gcc.
  Reports say it works with X too.

  The installation script chooses the compiler itself.  gnucc is
  preferred.
================

About the Delta 187, which had a Motorola risc processor named something
like 88010, I do not know if it is equally obsolete (never used one of
those boxes).  Here is the relative entry in etc/MACHINES:

================
Motorola Delta 187 (m88k-motorola-sysv,
		    m88k-motorola-sysvr4, or
		    m88k-motorola-m88kbcs)

  The 19.26 pretest was reported to run on SVR3.  However, if you
  use --with-x-toolkit on svr3, you will have problems compiling some
  files because time.h and sys/time.h get included twice.
  One fix is to edit those files to protect against multiple inclusion.

  As of version 19.13, Emacs was reported to run under SYSVr3 and SYSVr4.
================

Re: TODO additions

[Miles Bader]

Francesco Potorti` <pot@gnu.org> writes:
> Then I suggest dropping support for Motorola Delta 147.  It is sad,
> because I wrote src/m/delta.h and that was my first work on Emacs :-(
> 
> But the box is very old now, and since the fastest processor on them
> that I know of was a 25MHz Motorola 68040, I don't think that anyone
> ever tried to compile and run Emacs 20 on them.  Emacs 19 was already a
> really big program for that box.  In fact, the last Emacs version
> reported to work is 19.26.

I don't know about the Delta, but I compiled emacs 20 on one of the old
HP machines the FSF had, which I think used a 25MHz* 680x0, and it ran
just fine (I used it every day; it took untold ages to compile though).

I'd really be curious to see how the emacs 21 display engines fares on
such a machine.

-Miles

* I mean `geech'; somebody please correct me if I'm wrong!
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: TODO additions

[Eli Zaretskii]

On 28 Nov 2002, Miles Bader wrote:

> I don't know about the Delta, but I compiled emacs 20 on one of the old
> HP machines the FSF had, which I think used a 25MHz* 680x0, and it ran
> just fine (I used it every day; it took untold ages to compile though).
> 
> I'd really be curious to see how the emacs 21 display engines fares on
> such a machine.

I expect it to be slow, sometimes unbearably slow.  I'm running Emacs 21 
on a 166MHz DOS machine sometimes, and even though it's character-mode 
display, Emacs has a difficulty paging through some files, like 
lisp/internal.el, which have lots of faces.

Re: TODO additions

[Richard Stallman]

    But the box is very old now, and since the fastest processor on them
    that I know of was a 25MHz Motorola 68040,

Do you know when the last one was made?

Re: TODO additions

[Francesco Potorti`]

>    But the box is very old now, and since the fastest processor on them
>    that I know of was a 25MHz Motorola 68040,
>
>Do you know when the last one was made?

I found that the first one (with 68030 cpu) was made in 1989, and I was
still using it in the first months of 1994 (with 68040 cpu), at which
time I don't think that Motorola was manufacturing them any more.
However, I have no way to be sure.

Re: TODO additions

[Richard Stallman]

I guess we can drop that configuration, if it is 8 years old.

Re: TODO additions

[Richard Stallman]

    Here's another example of lossage I've just found, from an attempt to
    build on RedHat 8.0.  I've no idea what's going on.


    cd lib-src; make all  \
      CC='gcc' CFLAGS='-g -O2' CPPFLAGS='-D_BSD_SOURCE  ' \
      LDFLAGS='-L/usr/X11R6/lib' MAKE='make'

It should not be executing those commands at all.  Where do they come
from?

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     cd lib-src; make all  \
>       CC='gcc' CFLAGS='-g -O2' CPPFLAGS='-D_BSD_SOURCE  ' \
>       LDFLAGS='-L/usr/X11R6/lib' MAKE='make'
> 
> It should not be executing those commands at all.

??

> Where do they come from?

The first dependency of the target `all'.

The problem is that make decided to build Makefile from Makefile.c for
some reason.  I suspect this has something to do with NFS and system
times, but it isn't initially clear what, especially as it only
happens against my copy of source from the CVS HEAD.

[I don't need sysadmin advice on NFS, NTP et al if I need to diagnose
this.]

Re: TODO additions

[Richard Stallman]

That code loked strange to me before, but I see now--it is this rule.

${SUBDIR}: maybe_bootstrap ${SUBDIR_MAKEFILES} FRC
	cd $@; $(MAKE) all $(MFLAGS) \
	  CC='${CC}' CFLAGS='${CFLAGS}' CPPFLAGS='${CPPFLAGS}' \
	  LDFLAGS='${LDFLAGS}' MAKE='${MAKE}'

I see only one change since March 2001 that appears to have
affected this code.

    (all): Don't depend on maybe_bootstrap here.
    (${SUBDIR}): Depend on it here instead.

Re: TODO additions

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> That code loked strange to me before, but I see now--it is this rule.
> 
> ${SUBDIR}: maybe_bootstrap ${SUBDIR_MAKEFILES} FRC
> 	cd $@; $(MAKE) all $(MFLAGS) \
> 	  CC='${CC}' CFLAGS='${CFLAGS}' CPPFLAGS='${CPPFLAGS}' \
> 	  LDFLAGS='${LDFLAGS}' MAKE='${MAKE}'
> 
> I see only one change since March 2001 that appears to have
> affected this code.
> 
>     (all): Don't depend on maybe_bootstrap here.
>     (${SUBDIR}): Depend on it here instead.

I doubt it has anything (directly?) to do with such changes in Emacs.
It's probably some NFS/make obscurity which I'm not going to
investigate at the moment.