> This could be a good approach. But I am not sure, because probably
> most people that use this package activate it from the .emacs file.
That was why I suggested using a timer, to give the rest of .emacs
time to be processed.
If it works well in that case too, it's a good solut
Richard Stallman <[EMAIL PROTECTED]> writes:
> Perhaps a better approach is to start a timer on load, and if appt is
> not "activated" within a few seconds, then warn the user that loading
> the package no longer activates it, and tell them the prefered way of
> activating appt (us
Marcelo Toledo <[EMAIL PROTECTED]> writes:
> Create a convention that it will not be activated when loaded
That convention already exists.
> Warning the user after loading the package doesn't seem
> correct, imagine if he loads 10 packages that warn him of something.
I didn't mean to do that fo
Richard Stallman wrote:
> He will just have to change his init file. Please take this out now.
Okay. Separately, I'll see if I can achieve backwards compatibility
some other way.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/m
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 stop compilation. Silly.
The value should not be used at compile time.
Perhaps a better approach is to start a timer on load, and if appt is
not "activated" within a few seconds, then warn the user that loading
the package no longer activates it, and tell them the prefered way of
activating appt (usually via an autoloaded function).
This could be a go
As the comment says, it's necessary for backwards compatibility, and I
wasn't particularly happy about having to do it.
Backwards compatibility is not sufficient reason for this.
Loading appt.el used to activate the appointment package (in a
convoluted way, I think; can't remember
* calendar/appt.el: Only activate appt if in an interactive
session. This stops appt from prompting during Emacs bootstrap.
Just loading appt.el probably should not activate the feature.
In the 90s it was not unusual for packages to work that way,
but when Custom was added
Jason Rumney <[EMAIL PROTECTED]> writes:
> Perhaps a better approach is to start a timer on load, and if appt is
> not "activated" within a few seconds, then warn the user that loading
> the package no longer activates it, and tell them the prefered way of
> activating appt (usually via an autoloa
Glenn Morris <[EMAIL PROTECTED]> writes:
> Loading appt.el used to activate the appointment package (in a
> convoluted way, I think; can't remember the details now). When I
> changed it so it did not, I had an email from someone saying he had
> missed a bunch of appointments.
>
> So I had to make
Glenn Morris <[EMAIL PROTECTED]> writes:
> As the comment says, it's necessary for backwards compatibility, and I
> wasn't particularly happy about having to do it.
I think you should add the following paragraph to the comment,
to explain why "backwards compatibility" is needed:
>
> Loading appt.
Stefan Monnier wrote:
>> On load, appt.el calls (appt-activate 1).
>
> That's a bug.
As the comment says, it's necessary for backwards compatibility, and I
wasn't particularly happy about having to do it.
Loading appt.el used to activate the appointment package (in a
convoluted way, I think; can
> On load, appt.el calls (appt-activate 1).
That's a bug.
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Alan Shutko wrote:
> -(appt-activate 1)
> -
> +(if (not noninteractive)
> +(appt-activate 1))
I think a better solution might be to make solar-setup barf if called
non-interactively, since it can't do anything in that case anyway. The
call to diary in appt.el is already in a condition-case,
Alan Shutko wrote:
> So, here's the problem.
Thanks for the diagnosis Alan!
Clearly, ignore my previous mailing on this subject, and a thousand
apologies for casting (however vague) aspersions in the direction of
org.el! :)
___
Emacs-devel mailing li
"Robert J. Chassell" wrote:
> The bad news is that the bootstrap failed once.
>
> One bug appeared when I used this command:
>
> (progn
>(cd "/usr/local/src/emacs/")
>(compile
> "./configure --with-type1 \
> --with-x-toolkit=gtk \
> --prefix=/usr/loca
Alan Shutko <[EMAIL PROTECTED]> writes:
> Why does it need to use the latitude and longitude at compilation
> time? If we fix that, it doesn't matter what the default is.
So, here's the problem.
On load, appt.el calls (appt-activate 1). That activates the
appointment stuff, which loads the dia
> 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!
___
> 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 stop compilation. Silly.
>
> Why does it
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 stop compilation. Silly.
Why does it need to use the la
> 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-
During a bootstrap build, compilation halted at a prompt from
emacs/lisp/calendar/solar.el
However, I could not enter that information into the *compilation*
buffer, since it is read-only.
As a fix, I suggested
Perhaps `calendar-latitude' and `calendar-longitude' should be se
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
> Today, I removed *all* my Emacs' CVS sources using `rm -rf emacs' and
> checked out fresh sources. The `59 Temple Place' zipcode is now
> correct. My earlier report was based on a damaged set of sources.
> Please ignore it.
>
> Since I had new s
> 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/
Today, I removed *all* my Emacs' CVS sources using `rm -rf emacs' and
checked out fresh sources. The `59 Temple Place' zipcode is now
correct. My earlier report was based on a damaged set of sources.
Please ignore it.
Since I had new sources, I could configure and bootstrap build with a
complete
25 matches
Mail list logo
