GNU bug report logs - #63253
29.0.90; with-delayed-message fails in combination with inhibit-message

Previous Next

Full log

Message #47 received at 63253 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, larsi <at> gnus.org, 63253 <at> debbugs.gnu.org
Subject: Re: bug#63253: 29.0.90; with-delayed-message fails in combination
 with inhibit-message
Date: Thu, 11 May 2023 18:55:41 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org,  mail <at> daniel-mendler.de,  63253 <at> debbugs.gnu.org
> Date: Thu, 11 May 2023 11:00:28 -0400
> 
> >> 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?
> 
> We still want that message to be moved to the end of the minibuffer
> when that minibuffer is active, and users may still want to be able
> to silence some of those messages.

It's highly unlikely that maybe_quit will be called when we are in the
minibuffer in recursive-edit, because maybe_quit is called from
potentially prolonged processing.  As for silencing, I see no reason
why these messages should be silenced, since a Lisp program that calls
with-delayed-message explicitly wants the message to appear, so as to
provide important feedback about some long processing.

> > How you envision that FIXME to be fixed, if atimers cannot safely run
> > any Lisp?
> 
> Apparently, we do run ELisp code from `maybe_quit` via the GUI's event
> handling (according to Po Lu, not just under macOS but also under X11),
> so maybe we should strive to make it "safe" to run ELisp from `maybe_quit`
> (and hence atimers).
> 
> It's inherently dangerous since it amounts to preemptive concurrency, so
> by "safe" I mean that we should strive to make it safe with some
> side-conditions about the risks of concurrency bugs.

AFAIU, the danger is because some places that call maybe_quit are
stateful.  So to make that safe, we'd need to save and restore the
state around the call, something that could be expensive if at all
possible.  And having to do that is a misfeature in itself: we just
got rid of doing so due to problems with ralloc and stuff, so why
would we want to get into another such trouble?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.