bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 10 Dec 2020 19:58:12 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 45117@debbugs.gnu.org
> 
> > 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.