bug#70221: [PATCH] New function `funcall-later`

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 70221@debbugs.gnu.org
> 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.

It catches errors, doesn't it?  That's what bothers me with CALLN.

> >> 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.

Unless the same buggy funcall-later is again in the list, right?  Or
do we have a machinery to disable them, like we disable faulty timers?

> > 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.

How is this different from running timers?

> > 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.

I'm not sure I understand where you are going with this.  It seems
very easy to tell when the delayed functions will be called, so why
are we arguing?

> - It might mean that `funcall-later` is ill-defined and should be
>   rejected, or split into two, or should take extra arguments, or ...

If the implementation changes, we will change the documentation to go
along.  But Lisp programmers who want to use this facility must have
a pretty good idea of when the delayed code will be called, or else
they are in for a bumpy ride.