Re: Should `cancel-timer' use `delete' instead of `delq'?

[David Kastrup <dak@gnu.org>]

"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