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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 70221@debbugs.gnu.org
> Date: Sat, 06 Apr 2024 16:00:53 -0400
> 
> >> `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?
> 
> What's good about it?
> 
> > That's what bothers me with CALLN.
> 
> With CALLN the errors don't get caught by `safe_calln` so they get
> caught further up the stack, which seems fine by me.
> What problem/scenario are you thinking about?

That we throw to top-level from a normal processing loop.  Why should
we not prevent that if we can?  Why are you so objected to doing what
we have always done there?

> >> >> 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?
> 
> No: we bump it off the list before the CALLN, specifically to
> avoid this problem.  They don't auto-repeat like some timers.

The Lisp program that initiated it could initiate another one soon
enough.  Why risk that when the solution is so easy?  I really don't
understand your objections here.  Is there any harm that can possibly
be done by catching errors, like timers do?  If not, why not do it?

> >> > 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?
> 
> Non-0s timers are run in the context of some future command (or in the
> middle of "idle" time).  `funcall-later` are run before we get to idle
> time or to the next user input

The funcall-later functions are run in exactly the same context.  Look
at the code: they are called inside the same loop in timer_check_2.
So the context is exactly the same.

> so if the user hits C-g during them, it's no different from hitting
> C-g during the main part of the command.  It's realy more like
> `post-command-hook` (incidentally, I've been thinking that maybe we
> should call `internal--run-pending-funcalls` when we run
> `post-command-hook`).

Whatever happens with zero timers happens also with funcall-later
functions.  So the same considerations apply.  From the user POV,
Emacs is idle, so the user can press C-g at any moment.  E.g., it is
customary to press C-g when Emacs sits at the prompt in the
minibuffer: both timers and funcall-later functions can be run at that
time.

> >> - 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?
> 
> I'm not sure the current implementation provides the behavior we want.
> So I think it's worthwhile thinking about what it is that we want.
> E.g. another implementation could be to have a separate thread running
> those functions.  Or as mentioned above we could run them from
> `post-command-hook`. ...

As long as the code is on the branch, I don't really care.  But the
moment it lands on master, it should have the proper documentation,
and if by that time the implementation doesn't change, I insist on
saying something about when these functions are called, because I
think it's important.  If the implementation does change, I will, of
course, revisit my opinion (hopefully, during the review of the
modified code that is to follow).