Delayed warnings

Delayed warnings

[Juanma Barranquero]

I want to warn the user for the case that the Windows port defaults to
setting HOME=C:\ because HOME is not set but C:/.emacs exists.

The only problem is that I want to use a warning, not a message,
because a warning is much more visible and less easy to overlook.

So, I need to set up a warning, delaying it until the right moment
(during startup.el, when the display is set up, lisp code can be
executed and everything's just right).

To such effect I want to add a new C-level variable Vdelayed_warnings
that C code can use to warn the user of problems during
initialization.

Already existing similar facilities are the
pending_malloc_warning/display_malloc_warning stuff and
deferred_action_list/deferred_action_function:

- *_malloc_warning could be used, but it is too specifically tied to
malloc, and it's best left alone.
- deferred_action_* is undocumented (see my other message).

Am I missing some other facility that would make Vdelayed_warnings unnecessary?

The following patch is just a proof-of-concept for discussion, BTW.

    Juanma



2011-03-20  Juanma Barranquero  <lekktu@gmail.com>

	* emacs.c (syms_of_emacs) <Vdelayed_warnings>: New variable.
	* w32.c (init_environment): Use it to warn about default HOME=C:\.


2011-03-20  Juanma Barranquero  <lekktu@gmail.com>

	* startup.el (command-line): Show delayed warnings.



=== modified file 'lisp/startup.el'
--- lisp/startup.el	2011-03-19 18:27:55 +0000
+++ lisp/startup.el	2011-03-20 04:41:59 +0000
@@ -1249,6 +1249,10 @@
   ;; If -batch, terminate after processing the command options.
   (if noninteractive (kill-emacs t))

+  ;; If we have delayed warnings, show them
+  (dolist (warning (nreverse delayed-warnings))
+    (apply 'display-warning warning))
+
   ;; In daemon mode, start the server to allow clients to connect.
   ;; This is done after loading the user's init file and after
   ;; processing all command line arguments to allow e.g. `server-name'

=== modified file 'src/emacs.c'
--- src/emacs.c	2011-03-17 16:32:03 +0000
+++ src/emacs.c	2011-03-20 04:22:09 +0000
@@ -2484,6 +2484,16 @@
   Vdynamic_library_alist = Qnil;
   Fput (intern_c_string ("dynamic-library-alist"), Qrisky_local_variable, Qt);

+  DEFVAR_LISP ("delayed-warnings", Vdelayed_warnings,
+               doc: /* List of warnings to be displayed during startup.
+For each item of the list,
+
+   (apply 'display-warning ITEM)
+
+is called, so ITEM must be a list of (TYPE MESSAGE [LEVEL [BUFFER-NAME]]),
+as per the args of `display-warning' (which see). */);
+  Vdelayed_warnings = Qnil;
+
   /* Make sure IS_DAEMON starts up as false.  */
   daemon_pipe[1] = 0;
 }

=== modified file 'src/w32.c'
--- src/w32.c	2011-03-14 17:07:53 +0000
+++ src/w32.c	2011-03-20 05:25:36 +0000
@@ -1554,6 +1554,7 @@
     char locale_name[32];
     struct stat ignored;
     char default_home[MAX_PATH];
+    int appdata = 0;

     static const struct env_entry
     {
@@ -1607,7 +1608,10 @@

 	  /* If we can't get the appdata dir, revert to old behavior.  */
 	  if (profile_result == S_OK)
+	      {
 	    env_vars[0].def_value = default_home;
+		appdata = 1;
+	      }
 	}
     }

@@ -1694,6 +1698,14 @@
 		lpval = env_vars[i].def_value;
 		dwType = REG_EXPAND_SZ;
 		dont_free = 1;
+		if (!strcmp (env_vars[i].name, "HOME") && !appdata)
+		  {
+		    Lisp_Object warning[2];
+		    warning[0] = intern ("initialization");
+		    warning[1] = build_string ("Setting HOME to C:\\ by default is
deprecated");
+		    Vdelayed_warnings = Fcons (Flist (2, warning),
+					       Vdelayed_warnings);
+		  }
 	      }

 	    if (lpval)

Re: Delayed warnings

[martin rudalics]

 > To such effect I want to add a new C-level variable Vdelayed_warnings
 > that C code can use to warn the user of problems during
 > initialization.

Couldn't we handle this inside (a possibly improved) add_to_log?

martin

Re: Delayed warnings

[Juanma Barranquero]

> Couldn't we handle this inside (a possibly improved) add_to_log?

Well, the whole point of my proposal is that I want to give a warning,
not just a message (which is very easily overlooked when starting
Emacs).

Also, as the process of delayed-warnings happens very late (after
.emacs), the user can remove warnings he doesn't really want with

   (setq delayed-warnings (delete* "unwanted warning" delayed-warnings
:key 'cadr :test 'string-match-p))

or equivalent non-CL code. This is a plus, because we want to warn the
user, but not punish him in case he does really have a reason to
continue doing whatever causes the warning.

In fact, if we adopt delayed-warnings, there are other warnings (quite
a few in startup.el, for example, like the one I recently added about
_emacs) that could be converted to using it and so give the user more
control over them.

    Juanma

Re: Delayed warnings

[martin rudalics]

 > Well, the whole point of my proposal is that I want to give a warning,
 > not just a message (which is very easily overlooked when starting
 > Emacs).
 >
 > Also, as the process of delayed-warnings happens very late (after
 > .emacs), the user can remove warnings he doesn't really want with
 >
 >    (setq delayed-warnings (delete* "unwanted warning" delayed-warnings
 > :key 'cadr :test 'string-match-p))
 >
 > or equivalent non-CL code. This is a plus, because we want to warn the
 > user, but not punish him in case he does really have a reason to
 > continue doing whatever causes the warning.
 >
 > In fact, if we adopt delayed-warnings, there are other warnings (quite
 > a few in startup.el, for example, like the one I recently added about
 > _emacs) that could be converted to using it and so give the user more
 > control over them.

Fully agreed.  But the same arguments hold for redisplay errors which
currently pass through add_to_log where they are treated like messages.
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.

martin

Re: Delayed warnings

[Eli Zaretskii]

> Date: Mon, 21 Mar 2011 14:17:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Fully agreed.  But the same arguments hold for redisplay errors which
> currently pass through add_to_log where they are treated like messages.

That's different, I think: redisplay errors are the kind that the user
typically cannot do anything useful about.

Re: Delayed warnings

[martin rudalics]

 > That's different, I think: redisplay errors are the kind that the user
 > typically cannot do anything useful about.

I thought about messages signalling wrong font-lock settings or modeline
specifications.  ISTR that I found some of them only incidentally when
scrolling back my message buffer, probably because they were obscured by
some other text (maybe eldoc) displayed in the echo area.

martin

Re: Delayed warnings

[Juanma Barranquero]

On Mon, Mar 21, 2011 at 14:17, martin rudalics <rudalics@gmx.at> wrote:

> Fully agreed.  But the same arguments hold for redisplay errors which
> currently pass through add_to_log where they are treated like messages.

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' :-)

> 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?

    Juanma

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

Re: Delayed warnings

[Juanma Barranquero]

On Mon, Mar 21, 2011 at 19:06, martin rudalics <rudalics@gmx.at> wrote:

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

That's more or less. I wanted to call display-warning, found that it
was too soon, and looked for a way to delay it.

> 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'.

Yes, like the malloc low-memory warning code does. Fine by me. The
problem I wanted to tackle was warning about default HOME, not
designing a delayed warning facility :-)

Only I would process `display-delayed-warnings' in reverse, so C code
can add with

  Vdisplay_delayed_warnings = Fcons (..., Vdisplay_delayed_warnings);

but the user still gets the warnings in order.

    Juanma

Re: Delayed warnings

[Stefan Monnier]

> Only I would process `display-delayed-warnings' in reverse, so C code
> can add with

>   Vdisplay_delayed_warnings = Fcons (..., Vdisplay_delayed_warnings);

> but the user still gets the warnings in order.

Or you could have your C code all `add-hook-once' on post-command-hook
which would be a new function that adds a function onto a hook such that
the function is only run once and then automatically removed.
Something like:

   (defun add-hook-once (hook function &optional append local)
     "Same as `add-hook', but FUN is only run once.
   Also contrary to `add-hook', this is not idempotent."
     ;; FIXME: need to check if `function' was already added to the hook.
     (let ((code (list 'lambda)))
       (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
       (add-hook hook code append local)))


-- Stefan

Re: Delayed warnings

[martin rudalics]

 > Or you could have your C code all `add-hook-once' on post-command-hook
 > which would be a new function that adds a function onto a hook such that
 > the function is only run once and then automatically removed.
 > Something like:
 >
 >    (defun add-hook-once (hook function &optional append local)
 >      "Same as `add-hook', but FUN is only run once.
 >    Also contrary to `add-hook', this is not idempotent."
 >      ;; FIXME: need to check if `function' was already added to the hook.
 >      (let ((code (list 'lambda)))
 >        (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
 >        (add-hook hook code append local)))

When there's a bug in `post-command-hook' and that hook gets cleared we
won't be able to display any warnings.  In particular, those about what
just happened in the `post-command-hook'.

The idea of `add-hook-once' itself sounds good but could be also done -
symmetrically to `run-with-idle-timer' - with an optional REPEAT
argument for `add-hook'.  Obviously, any function called in a hook could
easily remove itself in the call.

martin

Re: Delayed warnings

[Juanma Barranquero]

On Mon, Mar 21, 2011 at 23:05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Or you could have your C code all `add-hook-once' on post-command-hook
> which would be a new function that adds a function onto a hook such that
> the function is only run once and then automatically removed.

I like Martin's proposal more, for two reasons (in addition to the
concern expressed by him about errors in post-command-hook):

1.- I want to allow the user to easily disable these warnings from
their .emacs; it's cleaner to locate '(initialization "such and such
warning" :warning) in the delayed-warnings variable than a lambda
expression.

2.- What you propose is more general, but it adds complexity for the
simple case of just wanting to display a warning, and that generality
is not really needed IMO, unless you envision there's a common need to
delay things other than errors and warnings and the like. I'd say the
limited success of `deferred-action-*' would seem to indicate there
isn't any such need, and for those rare cases, they have
post-command-hook.

So, summarizing: I have nothing again `add-hook-once' and surely will
find it useful (my .emacs would benefit from it right now); but I
don't think it's the right thing to use for delayed initialization
warnings.

    Juanma

Re: Delayed warnings

[Jeff Sparkes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Only I would process `display-delayed-warnings' in reverse, so C code
>> can add with
>
>>   Vdisplay_delayed_warnings = Fcons (..., Vdisplay_delayed_warnings);
>
>> but the user still gets the warnings in order.
>
> Or you could have your C code all `add-hook-once' on post-command-hook
> which would be a new function that adds a function onto a hook such that
> the function is only run once and then automatically removed.

FWIW, in XEmacs it's called `add-one-shot-hook'.

Re: Delayed warnings

[Juanma Barranquero]

So, which path are we going to follow? Is not like it's hard to
implement, just to decide...

   Juanma

Re: Delayed warnings

[Juanma Barranquero]

No decision was reached about delayed warnings, so I'm proposing
installing the attached patch.

It is basically a trio of variables:

- delayed-warnings-list: the list where desired warnigns are added.
- delayed-warnings-function: the function to show warnings and reset
`delayed-warning-list'. Defaults to `display-delayed-warnings'.
- delayed-warnings-filter: a function that sould be called from
`delayed-warnings-function' to filter out unwanted messages.

plus one function:

- display-delayed-warnings: Default value of
`delayed-warnings-function'. It calls `display-warning' on the
warnings (after filtering them with `delayed-warnings-filter'), then
resets the warnings list to nil.

I think this is conveniently flexible, and allows the user to filter
out unwanted warnings with ease:

(lexical-let* ((unwanted '("unwanted warning 1" "unwanted warning 2" ...))
               (unwanted-re (regexp-opt unwanted)))
  (defun my-delayed-warnings-filter (warning)
    (let ((text (cadr warning)))
      (and (string-match-p unwanted-re text)
           (message "%s: %s" (car warning) text)))))


    Juanma



2011-04-26  Juanma Barranquero  <lekktu@gmail.com>

	* subr.el (display-delayed-warnings): New function.
	(delayed-warnings-function, delayed-warnings-filter): New variables.

2011-04-26  Juanma Barranquero  <lekktu@gmail.com>

	* keyboard.c (Qdelayed_warnings_function): Define.
	(command_loop_1): Run Qdelayed_warnings_function "hook" if
	Vdelayed_warnings_list is non-nil.
	(syms_of_keyboard) <Qdelayed_warnings_function>: DEFSYM it.
	(syms_of_keyboard) <delayed-warnings-list, delayed-warnings-function>:
	DEFVAR_LISP them.



=== modified file 'lisp/subr.el'
--- lisp/subr.el	2011-04-26 10:44:03 +0000
+++ lisp/subr.el	2011-04-27 00:01:44 +0000
@@ -1773,6 +1773,31 @@
   (eval-after-load file (read)))
 (make-obsolete 'eval-next-after-load `eval-after-load "23.2")
 \f
+(defun display-delayed-warnings ()
+  "Display delayed warnings in `delayed-warnings-list'.
+Warnings are filtered through `delayed-warning-filter' (which see).
+This is the default function for `delayed-warnings-function'."
+  (dolist (warning (nreverse delayed-warnings-list))
+    (unless (and delayed-warnings-filter
+                 (funcall delayed-warnings-filter warning))
+      (apply 'display-warning warning)))
+  (setq delayed-warnings-list nil))
+
+(defvar delayed-warnings-function 'display-delayed-warnings
+  "Function called to display delayed warnings.
+The function should access variables `delayed-warnings-list', containing
+the warnings waiting to be displayed, and `delayed-warnings-filter',
+a function used to filter out warnings.
+It is the responsibility of this function to clear `delayed-warnings-list'
+as needed.")
+
+(defvar delayed-warnings-filter nil
+  "Function to filter delayed warnings.
+It must be nil, meaning do not filter out any warning, or a function
+of one argument, a list (TYPE MESSAGE [LEVEL [BUFFER-NAME]]), which must
+return nil for warnings that should be displayed, non-nil otherwise.")
+
+\f
 ;;;; Process stuff.

 (defun process-lines (program &rest args)

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2011-04-26 18:02:10 +0000
+++ src/keyboard.c	2011-04-26 23:47:10 +0000
@@ -267,6 +267,8 @@

 static Lisp_Object Qdeferred_action_function;

+static Lisp_Object Qdelayed_warnings_function;
+
 static Lisp_Object Qinput_method_exit_on_first_char;
 static Lisp_Object Qinput_method_use_echo_area;

@@ -1356,6 +1358,10 @@
       if (!NILP (echo_area_buffer[0]))
 	resize_echo_area_exactly ();

+      /* If there are warnings waiting, process them.  */
+      if (!NILP (Vdelayed_warnings_list))
+        safe_run_hooks (Qdelayed_warnings_function);
+
       if (!NILP (Vdeferred_action_list))
 	safe_run_hooks (Qdeferred_action_function);
     }
@@ -1573,6 +1579,10 @@
       if (!NILP (echo_area_buffer[0]))
 	resize_echo_area_exactly ();

+      /* If there are warnings waiting, process them.  */
+      if (!NILP (Vdelayed_warnings_list))
+        safe_run_hooks (Qdelayed_warnings_function);
+
       safe_run_hooks (Qdeferred_action_function);

       /* If there is a prefix argument,
@@ -11498,6 +11508,7 @@
   DEFSYM (Qpre_command_hook, "pre-command-hook");
   DEFSYM (Qpost_command_hook, "post-command-hook");
   DEFSYM (Qdeferred_action_function, "deferred-action-function");
+  DEFSYM (Qdelayed_warnings_function, "delayed-warnings-function");
   DEFSYM (Qfunction_key, "function-key");
   DEFSYM (Qmouse_click, "mouse-click");
   DEFSYM (Qdrag_n_drop, "drag-n-drop");
@@ -12069,6 +12080,14 @@
 whenever `deferred-action-list' is non-nil.  */);
   Vdeferred_action_function = Qnil;

+  DEFVAR_LISP ("delayed-warnings-list", Vdelayed_warnings_list,
+               doc: /* List of warnings to be displayed as soon as possible.
+Each element must be a list (TYPE MESSAGE [LEVEL [BUFFER-NAME]]),
+as per the args of `display-warning' (which see).
+If this variable is non-nil, `delayed-warnings-function' will be called
+immediately after running `post-command-hook'.  */);
+  Vdelayed_warnings_list = Qnil;
+
   DEFVAR_LISP ("suggest-key-bindings", Vsuggest_key_bindings,
 	       doc: /* *Non-nil means show the equivalent key-binding when
M-x command has one.
 The value can be a length of time to show the message for.

Re: Delayed warnings

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 27 Apr 2011 02:55:57 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> - delayed-warnings-list: the list where desired warnigns are added.
> - delayed-warnings-function: the function to show warnings and reset
> `delayed-warning-list'. Defaults to `display-delayed-warnings'.
> - delayed-warnings-filter: a function that sould be called from
> `delayed-warnings-function' to filter out unwanted messages.
> 
> plus one function:
> 
> - display-delayed-warnings: Default value of
> `delayed-warnings-function'. It calls `display-warning' on the
> warnings (after filtering them with `delayed-warnings-filter'), then
> resets the warnings list to nil.
> 
> I think this is conveniently flexible, and allows the user to filter
> out unwanted warnings with ease:
> 
> (lexical-let* ((unwanted '("unwanted warning 1" "unwanted warning 2" ...))
>                (unwanted-re (regexp-opt unwanted)))
>   (defun my-delayed-warnings-filter (warning)
>     (let ((text (cadr warning)))
>       (and (string-match-p unwanted-re text)
>            (message "%s: %s" (car warning) text)))))

Is it possible to also arrange from critical parts of the C code, such
as display engine, to automatically display any delayed warnings when
redisplay is done?

Re: Delayed warnings

[Juanma Barranquero]

On Wed, Apr 27, 2011 at 05:05, Eli Zaretskii <eliz@gnu.org> wrote:

> Is it possible to also arrange from critical parts of the C code, such
> as display engine, to automatically display any delayed warnings when
> redisplay is done?

In a sane world, I should be asking that, and you should be answering it...

    Juanma

Re: Delayed warnings

[Stefan Monnier]

> No decision was reached about delayed warnings, so I'm proposing
> installing the attached patch.

I guess it's OK.
You might want to add some code to avoid/detect repetitions.
For redisplay-triggered warnings, this is going to be very important.


        Stefan

Re: Delayed warnings

[Juanma Barranquero]

On Wed, Apr 27, 2011 at 19:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> You might want to add some code to avoid/detect repetitions.

(delete-dups '(A A B A B B C B C C D)) => A B C D

or

(uniqify '(A A B A B B C B C C D)) => A B A B C B C D

?

    Juanma


P.S.: Assuming

(defun uniqify (list)
  "Destructively remove consecutive `equal' duplicates from LIST.
Store the result in LIST and return it.  LIST must be a proper list."
  (let ((l list))
    (while (cdr l)
      (if (equal (car l) (cadr l))
          (setcdr l (cddr l))
        (setq l (cdr l))))
    list))

which should be in subr.el, because its functionality is duplicated in
quite a few .el files.

Re: Delayed warnings

[Stefan Monnier]

>> You might want to add some code to avoid/detect repetitions.

> (delete-dups '(A A B A B B C B C C D)) => A B C D

> or

> (uniqify '(A A B A B B C B C C D)) => A B A B C B C D

> ?

Neither.  I'm thinking about messages which would be displayed once
after almost every command (because redisplay will bump into the same
error after each command).  This can't be applied generally to all
messages (it would be incorrect to silence the 2nd/3rd occurrences of
a message if the message is really linked to the particular command
executed which happens to be the same several times), so the squashable
messages would need to be flagged.


        Stefan

Re: Delayed warnings

[Juanma Barranquero]

On Thu, Apr 28, 2011 at 02:40, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm thinking about messages which would be displayed once
> after almost every command (because redisplay will bump into the same
> error after each command).

OK, but that makes the logic a bit more complex because the squashing
is carried from one run of `delayed-warnings-function' to the next.
How do you propose to detect that? By scanning the *Warnings* buffer?
(Though, to be fair, redisplay warnings could use their own buffer
*Redisplay Warnings*...)

> This can't be applied generally to all
> messages (it would be incorrect to silence the 2nd/3rd occurrences of
> a message if the message is really linked to the particular command
> executed which happens to be the same several times)

Even so, perhaps some strategy like the current message consolidation
("such&such [10 times]") could be used.

> so the squashable
> messages would need to be flagged.

In my design, the contents of `delayed-warnings-list' are arglists for
`display-warning': (TYPE MESSAGE [LEVEL [BUFER-NAME]]). So simple ways
to flag them would be:
 - Use TYPE = redisplay for all redisplay warnings, and make
`display-delayed-warnings' know about it, or
 - Add a variable `delayed-warnings-squashable-types', a list of TYPEs
that can be squashed, or
 - As suggested above, send the redisplay warnings to their own buffer
via the BUFFER-NAME arg.

    Juanma

Re: Delayed warnings

[Stefan Monnier]

> OK, but that makes the logic a bit more complex because the squashing
> is carried from one run of `delayed-warnings-function' to the next.

Yup.  Let's wait to get some experience with it first.


        Stefan

Re: Delayed warnings

[Juanma Barranquero]

On Thu, Apr 28, 2011 at 17:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yup.  Let's wait to get some experience with it first.

OK. I want to install this patch, with is a simplifed version of the
previous one: `delayed-warnings-filter' does not exist, and
`delayed-warnings-function' has become `delayed-warnings-hook', a true
hook.

The idea is that functions in the hook can process and remove as many
elements from `delayed-warnings-list' as they want. The function
`display-delayed-warnings', which is set by default to run last, of
course removes and displays them all.

That makes the delayed warnings infrastructure both simpler and more
flexible. Redisplay warnings would mean (other than pushing the
relevant warnings to `delayed-warnings-list', of course) just adding a
new `display-redisplay-warnings' to the hook.

    Juanma



2011-04-28  Juanma Barranquero  <lekktu@gmail.com>

	* subr.el (display-delayed-warnings): New function.
	(delayed-warnings-hook): New variable.


2011-04-28  Juanma Barranquero  <lekktu@gmail.com>

	* keyboard.c (Qdelayed_warnings_hook): Define.
	(command_loop_1): Run `delayed-warnings-hook'
	if Vdelayed_warnings_list is non-nil.
	(syms_of_keyboard) <delayed-warnings-hook>: DEFSYM it.
	(syms_of_keyboard) <delayed-warnings-list>: DEFVAR_LISP it.



=== modified file 'lisp/subr.el'
--- lisp/subr.el	2011-04-27 07:56:55 +0000
+++ lisp/subr.el	2011-04-28 08:31:03 +0000
@@ -1773,6 +1773,19 @@
   (eval-after-load file (read)))
 (make-obsolete 'eval-next-after-load `eval-after-load "23.2")
 \f
+(defun display-delayed-warnings ()
+  "Display delayed warnings in `delayed-warnings-list'.
+This is the default value of `delayed-warnings-hook'."
+  (dolist (warning (reverse delayed-warnings-list))
+    (apply 'display-warning warning))
+  (setq delayed-warnings-list nil))
+
+(defvar delayed-warnings-hook '(display-delayed-warnings)
+  "Normal hook run to process delayed warnings.
+Functions in this hook should access the `delayed-warnings-list'
+variable (which see) and remove from it the warnings they process.")
+
+\f
 ;;;; Process stuff.

 (defun process-lines (program &rest args)

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2011-04-26 18:02:10 +0000
+++ src/keyboard.c	2011-04-28 08:28:51 +0000
@@ -267,6 +267,8 @@

 static Lisp_Object Qdeferred_action_function;

+static Lisp_Object Qdelayed_warnings_hook;
+
 static Lisp_Object Qinput_method_exit_on_first_char;
 static Lisp_Object Qinput_method_use_echo_area;

@@ -1356,6 +1358,10 @@
       if (!NILP (echo_area_buffer[0]))
 	resize_echo_area_exactly ();

+      /* If there are warnings waiting, process them.  */
+      if (!NILP (Vdelayed_warnings_list))
+        safe_run_hooks (Qdelayed_warnings_hook);
+
       if (!NILP (Vdeferred_action_list))
 	safe_run_hooks (Qdeferred_action_function);
     }
@@ -1573,6 +1579,10 @@
       if (!NILP (echo_area_buffer[0]))
 	resize_echo_area_exactly ();

+      /* If there are warnings waiting, process them.  */
+      if (!NILP (Vdelayed_warnings_list))
+        safe_run_hooks (Qdelayed_warnings_hook);
+
       safe_run_hooks (Qdeferred_action_function);

       /* If there is a prefix argument,
@@ -11498,6 +11508,7 @@
   DEFSYM (Qpre_command_hook, "pre-command-hook");
   DEFSYM (Qpost_command_hook, "post-command-hook");
   DEFSYM (Qdeferred_action_function, "deferred-action-function");
+  DEFSYM (Qdelayed_warnings_hook, "delayed-warnings-hook");
   DEFSYM (Qfunction_key, "function-key");
   DEFSYM (Qmouse_click, "mouse-click");
   DEFSYM (Qdrag_n_drop, "drag-n-drop");
@@ -12069,6 +12080,14 @@
 whenever `deferred-action-list' is non-nil.  */);
   Vdeferred_action_function = Qnil;

+  DEFVAR_LISP ("delayed-warnings-list", Vdelayed_warnings_list,
+               doc: /* List of warnings to be displayed as soon as possible.
+Each element must be a list (TYPE MESSAGE [LEVEL [BUFFER-NAME]]),
+as per the args of `display-warning' (which see).
+If this variable is non-nil, `delayed-warnings-hook' will be run
+immediately after running `post-command-hook'.  */);
+  Vdelayed_warnings_list = Qnil;
+
   DEFVAR_LISP ("suggest-key-bindings", Vsuggest_key_bindings,
 	       doc: /* *Non-nil means show the equivalent key-binding when
M-x command has one.
 The value can be a length of time to show the message for.

Re: Delayed warnings

[Stefan Monnier]

> OK. I want to install this patch, with is a simplifed version of the
> previous one: `delayed-warnings-filter' does not exist, and
> `delayed-warnings-function' has become `delayed-warnings-hook', a true
> hook.

Looks fine to me,


        Stefan

Re: Delayed warnings

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> OK. I want to install this patch, with is a simplifed version of the
> previous one: `delayed-warnings-filter' does not exist, and
> `delayed-warnings-function' has become `delayed-warnings-hook', a true
> hook.
>
> The idea is that functions in the hook can process and remove as many
> elements from `delayed-warnings-list' as they want. The function
> `display-delayed-warnings', which is set by default to run last, of
> course removes and displays them all.
>
> That makes the delayed warnings infrastructure both simpler and more
> flexible. Redisplay warnings would mean (other than pushing the
> relevant warnings to `delayed-warnings-list', of course) just adding a
> new `display-redisplay-warnings' to the hook.

I think it's cleaner to have a separate delayed-warnings-hook and
delayed-warnings-function.  The former should be nil by default, and
should be called prior to delayed-warnings-function.

In general, it's good to avoid putting default values in hook variables.

Re: Delayed warnings

[Juanma Barranquero]

On Sun, May 8, 2011 at 19:58, Chong Yidong <cyd@stupidchicken.com> wrote:

> I think it's cleaner to have a separate delayed-warnings-hook and
> delayed-warnings-function.  The former should be nil by default, and
> should be called prior to delayed-warnings-function.
> In general, it's good to avoid putting default values in hook variables.

I think that boat has sailed long ago. There are quite a few hooks
with default values. And having to split a hook into a hook *and* a
-function variable just to avoid the default doesn't seem too clean
IMHO.

    Juanma

Re: Delayed warnings

[Stefan Monnier]

>> I think it's cleaner to have a separate delayed-warnings-hook and
>> delayed-warnings-function.  The former should be nil by default, and
>> should be called prior to delayed-warnings-function.
>> In general, it's good to avoid putting default values in hook variables.
> I think that boat has sailed long ago. There are quite a few hooks
> with default values. And having to split a hook into a hook *and* a
> -function variable just to avoid the default doesn't seem too clean
> IMHO.

FWIW, I agree.  Non-nil hooks have their problem, indeed, but the worse
problem does not affect hooks that are preloaded and the second worse
only affects the use of Custom to configure such hooks, so for
non-defcustom preloaded hooks I think we can live with non-nil default
values, as evidenced by my "recent" introduction of
post-self-insert-hook.


        Stefan

Re: Delayed warnings

[Richard Stallman]

    > I think it's cleaner to have a separate delayed-warnings-hook and
    > delayed-warnings-function.  The former should be nil by default, and
    > should be called prior to delayed-warnings-function.
    > In general, it's good to avoid putting default values in hook variables.

    I think that boat has sailed long ago.

That kind of argument is invalid in general.
If something is generally undesirable, accepting it
in one place is no reason to accept it in another.

There are many sorts of bad practice in Emacs
that we are trying to gradually get rid of,
and in the meantime, we don't want to add more of it.

I have no opinion about this specific issue.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Delayed warnings

[martin rudalics]

 > Only I would process `display-delayed-warnings' in reverse, so C code
 > can add with
 >
 >   Vdisplay_delayed_warnings = Fcons (..., Vdisplay_delayed_warnings);
 >
 > but the user still gets the warnings in order.

As in your patch, I presume.  Only that there you never reset the
variable (obviously so, since you run the function once only).

And I would run this after the post-command-hook and before the
resize-echo-area call.

martin

Re: Delayed warnings

[Juanma Barranquero]

On Tue, Mar 22, 2011 at 08:58, martin rudalics <rudalics@gmx.at> wrote:

> As in your patch, I presume.  Only that there you never reset the
> variable (obviously so, since you run the function once only).

Yes. My code was intended for one-off warnings, yours is more general.

> And I would run this after the post-command-hook and before the
> resize-echo-area call.

I wrap `display-warning' in an advice that shrinks the buffer
displaying *Warnings* (basically a call to fit-window-to-buffer).
It'll be interesting to see how these two interact.


    Juanma