Subject: Re: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer

From: Eli Zaretskii <[email-masked]>
Date: Thu, 10 Dec 2020 22:14:01 +0200

> From: João Távora <[email-masked]>
> Date: Thu, 10 Dec 2020 19:58:12 +0000
> Cc: Stefan Monnier <[email-masked]>, [email-masked]
> 
> > I think that's the wrong question.  The right question is how probable
> > is it that the user presses C-g to abort a timer function that just
> > happens to run at this very moment.  I think the answer is "extremely
> > improbable".  It is much more probable that C-g was meant for
> > something else, some activity that is much more evident to the user.
> > Like getting out of the minibuffer after deciding that the command
> > does not need to be invoked after all, for example.
> 
> I see. Yes it makes sense.  But Stefan is arguing that some "special" timer
> functions should be abortable by mere input.

That makes sense mainly for idle timers.  Or for timer functions that
take a lot of time to execute (something that generally shouldn't
happen in the first place).  But while-no-input cannot abort its
caller, so as long as the body of while-no-input can handle being
interrupted, that is okay.

> And that changes thoses odds considerably. But at the same time, it
> doesn't change the fact, as you well put it, that that input is
> _not_ meant for the timer function.

I think if a timer function should be interruptible by input, that
function should itself call while-no-input.  It is not the job of
outside code to interrupt bad timers by aborting them by these
measures.