Re: delayed-warnings-list and delayed-warnings-hook

[Juanma Barranquero]

On Mon, Apr 2, 2012 at 15:58, Chong Yidong <address@hidden> wrote:

> Because of the default value (collapse-delayed-warnings
> display-delayed-warnings), in order not to deal with uncollapsed
> messages, third party code needs to append to the hook, and must not
> prepend to it.

Curious. My idea is that people who writes a filter for delayed
warnings would prefer to deal with uncollapsed messages. Collapsing is
just done to make them somewhat nicer in *Messages* (I could have just
made collapsing a part of display-delayed-warnings, but leaving it
separate allows users to remove it). Also, if you append to the hook
you will get nothing, as display-delayed-warnings display the
remaining warnings and clears the list.

>  But this makes it difficult for one third party package
> to give its function priority over other third party packages.  This
> design kind of bothers me.

Even at the point we are in the pretest, we can tweak it (or redesign
it) to our hearts' content. It does not interfere with anything else.

> To clarify the situation a little, could you explain what kind of
> functions you envision third party code adding to this hook?

The foremost one is filtering out unwanted warnings. For example,
delayed warnigns are currently used for a couple of Windows-related
situations (defaulting to C:/_emacs, for example). If someone wants to
really default to C:/_emacs and not set HOME=C:/, s/he can just filter
the warning out and be happy. Though, really, what I'd like to do in
the future is to add a defcustom to allow filtering warnings through a
predefined filter function of our own.

Other possible uses are upgrading warnings into errors, and displaying
warnings in buffers others than *Message*.

Another example, which I implemented in some bug thread (I don't
remember which one right now) is showing redisplay errors as warnings
with an idle delay, so they are not lost (currently they go straight
to *Messages* and you can be a long time without noticing them) but
they are still not so obnoxious that Emacs turns unusable.

The original reason to implement delayed warnings was having non-error
situations in low-level code, before the lisp engine could deal with
them. But I think that many warnings that we currently show
straightaway should be turned into delayed warnings, giving the user
more control over them.

    Juanma