Re: Delayed warnings

[martin rudalics <rudalics@gmx.at>]

 > 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