From: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Should `cancel-timer' use `delete' instead of `delq'?
Date: Wed, 06 Sep 2006 08:38:02 +0200 [thread overview]
Message-ID: <85d5a9ijp1.fsf@lola.goethe.zz> (raw)
In-Reply-To: <EIENLHALHGIMHGDOLMIMMEBNCLAA.drew.adams@oracle.com> (Drew Adams's message of "Tue, 5 Sep 2006 19:09:11 -0700")
"Drew Adams" <drew.adams@oracle.com> writes:
> > To repeat my question: Is it a good idea to either document
> > the "traditional" `define-minor-mode' approach or define a new
> > macro for this, or should we just let people discover this on
> > their own?
>
> I think the macro is inappropriate; the problem generally
> doesn't occur in typical "define" contexts (for instance your
> defvar "protection" will never get executed, because of the way
> defvar works).
>
> I was able to be bitten by it, using C-M-x on the defvar. And the
> general point applies to setq as well.
I don't think we need to worry about what damage a user might to
manually. I really don't see this as a valid reason to stop multiple
timers from working.
> How many of them will be bit by this? Who knows? Why not help them
> avoid it?
We can't avoid people shooting themselves in the foot. We might add
some command for killing timers in an emergency if really necessary.
> we don't explicitly warn people about each of them because we
> assume than programmers know how to handle this sort of thing in
> general.
>
> You assume too much, I think.
>
> If I defvar or setq toto to (cons 1 2)), and I make no other
> assignments or bindings to that cons cell, and then I setq toto to
> (cons 3 4), should I assume that the first cons cell is still around
> causing mischief? Maybe, for a while.
A cons is not an active object. You'll not notice the difference of
it being around or not if it is not referenced. An active timer _is_
referenced.
> I think that one natural, if erroneous, expectation is that the
> orphan timer will naturally go by the wayside at some point, and
> need not be thought much about.
I don't see any such expectation as natural.
> There are other, just as natural, expectations that would be more
> correct, but that expectation is a possible and reasonable one:
> don't worry about that zombie timer;
An active timer is not a zombie. Really.
> it's history; it may be toast already.
A timer stopping to work of his own volition is a bug.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2006-09-06 6:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 0:14 Should `cancel-timer' use `delete' instead of `delq'? Drew Adams
2006-09-05 1:44 ` Miles Bader
2006-09-05 15:38 ` Stefan Monnier
2006-09-05 16:20 ` Drew Adams
2006-09-05 17:22 ` Stefan Monnier
2006-09-05 17:36 ` Drew Adams
2006-09-05 20:46 ` Kevin Rodgers
2006-09-05 21:24 ` Drew Adams
2006-09-06 1:11 ` Miles Bader
2006-09-06 2:09 ` Drew Adams
2006-09-06 2:38 ` Miles Bader
2006-09-06 6:31 ` Drew Adams
2006-09-06 6:48 ` Miles Bader
2006-09-06 7:29 ` David Kastrup
2006-09-06 14:00 ` Stefan Monnier
2006-09-06 15:27 ` Drew Adams
2006-09-06 6:38 ` David Kastrup [this message]
2006-09-05 21:56 ` David Kastrup
2006-09-06 0:59 ` Stefan Monnier
2006-09-06 19:05 ` Richard Stallman
2006-09-05 19:13 ` Stuart D. Herring
2006-09-05 19:22 ` Drew Adams
2006-09-06 8:49 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85d5a9ijp1.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).