delayed-warnings-hook versus deferred-action-function

delayed-warnings-hook versus deferred-action-function

[Glenn Morris]

In 24.1, deferred-action-function has been deprecated in favour of just
using post-command-hook. Fair enough, the former was never really used
for anything.

However, delayed-warnings-hook has been added, and, although it has a
more clearly documented purpose, seems to be functionally equivalent to
the deprecated interface. Eg from command_loop_1:

      if (!NILP (Vdelayed_warnings_list))
        safe_run_hooks (Qdelayed_warnings_hook);

      if (!NILP (Vdeferred_action_list))
        safe_run_hooks (Qdeferred_action_function);

Aren't these two changes inconsistent? Why couldn't an element just be
added to post-command-hook to process delayed-warnings?

Re: delayed-warnings-hook versus deferred-action-function

[Juanma Barranquero]

On Sun, Feb 5, 2012 at 01:06, Glenn Morris <rgm@gnu.org> wrote:

> In 24.1, deferred-action-function has been deprecated in favour of just
> using post-command-hook. Fair enough, the former was never really used
> for anything.

deferred-function-action was deprecated for the two reasons you
mention: it was never used (I think googling it gave just one use, and
it was used just like post-command-hook), and it was poorly
documented. There was not way to resolve conflicts between two
applications wanting to use it for different purposes.

> However, delayed-warnings-hook has been added, and, although it has a
> more clearly documented purpose, seems to be functionally equivalent to
> the deprecated interface.

It is functionally equivalent, but the documented API of
deferred-function-(action|list) was so vague that using it for delayed
warnings made impossible to guarantee that someone else would not
trample over the warnings. So deprecating one and adding the other is
a way of documenting the delayed warnings use. For non-warnings,
post-command-hook is enough.

> Why couldn't an element just be
> added to post-command-hook to process delayed-warnings?

The idea is, some day, to add a defcustom interface to allow the user
adding other warnings-processing functions. In my .emacs I have one to
filter out specific warnings, for example. That could be done from
post-command-hook, but it would be messier.

    Juanma

Re: delayed-warnings-hook versus deferred-action-function

[Glenn Morris]

Juanma Barranquero wrote:

> The idea is, some day, to add a defcustom interface to allow the user
> adding other warnings-processing functions.

Thanks, that makes sense.

Re: delayed-warnings-hook versus deferred-action-function

[Glenn Morris]

Trying to document this, I'm confused as to what this functionality is
for. It only seems to be used for warning about a _emacs file on MS
Windows? Is it supposed to be used by external Lisp libraries for
something (if so, what?), or is it fully internal to Emacs (in which it
may not need documenting anywhere)?

Re: delayed-warnings-hook versus deferred-action-function

[Juanma Barranquero]

> Trying to document this, I'm confused as to what this functionality is
> for. It only seems to be used for warning about a _emacs file on MS
> Windows?

And also for the case that HOME is being defaulted to C:\ (because
there's a .emacs in C:\) but not set explicitly. That was, in fact,
the original use, because at that point elisp code can not yet run.

> Is it supposed to be used by external Lisp libraries for
> something (if so, what?), or is it fully internal to Emacs (in which it
> may not need documenting anywhere)?

I'd say it is more for internal use. I'd like to see some warnings
that currently are generated through l?warn and display-warning turned
into delayed warnings, for two reasons: eventually it will allow the
user to filter them out or otherwise customize them, and it allows
more control in some cases. For example, in bug#10578 I proposed it as
a way to display errors from the redisplay and image library code in a
relatively unobtrusive way (using an idle timer).

Anway, if we supply a trivial macro

  (defmacro delay-warning (&rest args)
    "...
  \n(fn type message &optional level buffer-name)"
    `(push args delayed-warnings-list))

there's no reason it could not be used from external libraries.

    Juanma

Re: delayed-warnings-hook versus deferred-action-function

[Glenn Morris]

Juanma Barranquero wrote:

> Anway, if we supply a trivial macro
>
>   (defmacro delay-warning (&rest args)
>     "...
>   \n(fn type message &optional level buffer-name)"
>     `(push args delayed-warnings-list))
>
> there's no reason it could not be used from external libraries.

Can you give an example of something I might want to use this for?

Re: delayed-warnings-hook versus deferred-action-function

[Juanma Barranquero]

On Wed, Feb 8, 2012 at 09:32, Glenn Morris <rgm@gnu.org> wrote:

> Can you give an example of something I might want to use this for?

Anything for which you would use display-warning, if you want the user
to be able to filter it.

Or any warning that happens at an inconvenient time and would be
better delayed. The only specific example I have in mind right now of
this case is the one I already mentioned: errors during redisplay.

    Juanma