bug#63253: 29.0.90; with-delayed-message fails in combination with inhibit-message

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  mail@daniel-mendler.de,  63253@debbugs.gnu.org
> Date: Wed, 10 May 2023 11:15:54 -0400
> 
> >> The code already falls back to a default behavior of displaying the
> >> message in the echo area when calls to ELisp can't be used.
> >
> > You mean, the changes that you just installed?  If so, that is AFAIU
> > conditioned on garbage_collection_inhibited, which doesn't necessarily
> > disable Lisp calls from delayed messages in all situations.  Plus, we
> > might at some point decide that garbage_collection_inhibited is not
> > necessary in probably_quit.
> >
> > What I meant was to completely disable customizing
> > set-message-function for delayed messages.  We don't have to support
> > that, and the fact that we call 'message' is just an implementation
> > detail.  If nothing else, this will make the effect on delayed
> > messages consistent no matter when and how they are actually
> > displayed.
> 
> Hmm... I think "customizing `set-message-function` for delayed messages"
> is actually desirable

Why? we use that for a single facility, which has a well-defined
purpose: show an echo-area message if BODY takes longer than some
time.  Why do we have to allow customization of the message displayed
by this facility?

> (which is why I left a FIXME in my patch).
> So I regard the new behavior as a bug, just one that is hopefully less
> severe than the problem it intends to avoid.

How you envision that FIXME to be fixed, if atimers cannot safely run
any Lisp?  What kind of customizations will we be able to offer, and
how?  maybe_quit can be called from any kind of context, and that is a
feature that we cannot give up.