Re: Delayed warnings

[martin rudalics]

> Of course there's a hierarchy of "errors": those that the user cannot
> do anything about (and should go to *Messages*), those that the user
> *must* attend to (and should either interrupt the user or bring Emacs
> to a halt), and warnings that inform the user about what he should
> do/know, but can be ignored.
>
> I'm mostly concerned about the third kind, specially when they happen
> in low-level code, because they are difficult to make (from C) both
> visible and, user wishing, easily ignorable. Sending them to
> *Messages* is not enough, unless we're going to (pop-to-buffer
> "*Messages*") and that's basically duplicating `display-warning' :-)

I thought you had something in mind like `display-warning' tailored for
the case that `display-warning' isn't callable for some reason.

>> What I wanted is a mechanism that handles (and optionally ignores) all
>> sorts of errors/warnings which currently can't be issued prominently
>> because Emacs is in an inconsistent state.
>
> Which kind of design have you in mind?

A `display-delayed-warnings' function run after `post-command-hook' more
or less from where `deferred-action-function' was or is called.  That
function would display all (appropriately filtered) warnings that have
accumulated in the `delayed-warnings' list since the last time it was
called and reset the list to nil.  Ideally, `display-delayed-warnings'
would call `display-warning' for each element of `delayed-warnings'.

Warnings from asynchronous processes or functions run by timers are a
different issue.

martin