GNU bug report logs - #70221
[PATCH] New function `funcall-later`

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70221 <at> debbugs.gnu.org
Subject: bug#70221: [PATCH] New function `funcall-later`
Date: Sat, 06 Apr 2024 11:46:28 -0400

> timer-event-handler uses condition-case-unless-debug, so I don't see a
> problem with timers, and I think your use of safe_call2 was not a
> mistake.

`condition-case-unless-debug` is very different from `safe_calln`.
It doesn't prevent non-local exits nor prevent showing a debugger.

>> I can't see any good reason why we'd need to protect the
>> C code from non-local exits in `timer_check_2`.
> Because it will prevent timers from being called?

Why would it?  after the non-exit is caught somewhere up the stack, we'd
eventually come back to `timer_check_2` and run the timer then.

> From my POV, any code that runs from some background facility must
> inhibit QUIT, because the user can type C-g at any moment.

Agreed, and `funcall-later` doesn't run it "in the background", it runs
it at the end of the current code.

> You are converting several places to using this new facility, so the
> prudent thing, in a program as complex and devious as Emacs, is to
> keep compatibility even if our hubris tempts us to think we are
> smarter.  Bitter experience has taught me that we are not smarter, so
> I now prefer humility instead.

Ah, you're talking about the second patch.  Yes, I'm not really sure we
want that one.  I included it more to show that there is interest in
such a facility, but I don't think the risk of breakage justifies
installing it.

>> AFAICT we don't document anywhere that `deactive-mark` is bound
>> around timers, so I guess fixing that would be the best way to document
>> the difference.
> I mean where we explain the differences between zero-delay timers and
> funcall-later.  We _will_ explain those, right?

As soon as we've figured the main "when is it run" question 🙂

>> That's the big question, really.  E.g. I currently use `funcall-later`
>> in `track-changes.el` and in `futur.el`.  I use it because it's handy.
>> But fundamentally those two need different things:
[...]
> I don't think I disagree with what you write, but I fail to see how it
> is relevant to the need to explain better what is that "next
> convenient time" when the function will run.  In particular, I don't
> see how the different uses of funcall-later affect that "next
> convenient time".

It's relevant in two ways:

- It determines which part of the time-behavior we should consider as
  something we want to document and guarantee, as opposed to the part
  which is incidental and which we may prefer to document as not to be
  relied on.
- It might mean that `funcall-later` is ill-defined and should be
  rejected, or split into two, or should take extra arguments, or ...


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.