> > Something has broken in `mark-diary-entries' such that (setq
> > mark-diary-entries-in-calendar t) and related no longer work
> > correctly. It seems to be setting point to the beginning of the
> > calendar buffer (I think the previous behavior was to leave it on
> > the current date.)
>
> I
> You stopped maintaining the calendar code long ago, so I asked
> Glenn Morris to maintain it. He has been doing this for a year,
> and doing a good job.
*I* never stopped anything.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.
> Perhaps `calendar-latitude' and `calendar-longitude' should be set to
> 0.0 rather than nil by defcustom. (I have done that, but tested it
> only with a `make recompile', since I do not want to do a bootstrap
> again.)
Very bad idea. Then a user will never know that the times of events (solar/
> Perhaps it would be better to set `calendar-latitude' to 51.5 and
> `calendar-longitude' to 0.0 by default but then tell people who want
> to learn about solar and lunar times that that default location is for
> Greenwich, England. That info should go away if `calendar-latitude'
> and `calendar-
> Ed Reingold <[EMAIL PROTECTED]> writes:
>
> > This is a conundrum: Any value that lets the compilation proceed will
> > (necessarily) produce wrong results. Any value that stops the calculation
> > if
> > the latitude/longitude/zone are not set will sto
> Here's what I have as a possible fix. It will fix bootstrap, but it
> won't fix the case if someone is interactively compiling a file which
> requires appt, and doesn't have lat & long set.
Presumably anyone requiring appt AND using the solar/lunar stuff will have
that set already!
___
