unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Should `cancel-timer' use `delete' instead of `delq'?
Date: Wed, 6 Sep 2006 08:27:24 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMMECECLAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwv8xkx3xsh.fsf-monnier+emacs@gnu.org>

    > Well, I think that's exactly what I used in my defvar (after
    > having been bitten once), so I could henceforth re-eval it
    > ("abnormally") without worry or forethought. In any case, the
    > "traditional" way to do that is apparently to use
    > `define-minor-mode'...

    The traditional example I showed is not exempt from the OP.
    When you re-evaluate the defvar with C-M-x, the timer var is forcefully
    reset to nil, thus potentially forgetting a running timer, which then
    becomes again difficult to stop.

    Maybe you did realize that, but I got the feeling that you
    thought it didn't suffer from this problem.

I did realize that. I was attempting irony...

    And the same thing could/would happen if you use `timer-create'.
    The problem is not how you define/create your timer, but simply the fact
    that if you "forget" your timer object, it'll still be active as long as
    it's in the timer-list.

    One way to "solve" this problem is to change C-M-x so that in
    the case the variable's current value is a timer, it first cancels it,
    before resetting the var.  Similarly to my "recent" patch which cancels
    timers when unloading a package.

Yes. That's similar to what I proposed via a macro (to do the same thing).
If the first-cancel-then-define part is all that would be done, then your
suggestion is better. If more might be done (the activation and
toggle-command options I suggested), then a macro could be better.

Before this is laid to rest, let me request one more time that at least some
mention be made of this in the Elisp manual - in some form or other, whether
it's mentioned as a potential problem or whether some particular
practice/guideline is suggested/recommended.

If nothing else, it might be useful to point out that list `timer-idle-list'
is what controls whether an idle timer is active (similarly, `timer-list'),
so users will better understand that their defvar or whatever is not the
only pointer to the timer object. This may be obvious to some, but I'm sure
it is not obvious to some others.

IOW, even if `cancel-timer' needs to be handed a timer object (which you
might not have a handle for), you can always, as a last resort, delete your
timers by hand from `timer(-idle)-list', assuming that you can recognize
them (that is, you can reconstruct the list without them). Of course,
someone bitten by this pitfall and desperate to cancel timers will examine
the code of `cancel-timer' and find this out anyway, but foreknowledge of
this wouldn't hurt.

  reply	other threads:[~2006-09-06 15:27 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 [this message]
2006-09-06  6:38                   ` David Kastrup
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=EIENLHALHGIMHGDOLMIMMECECLAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /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).