unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Delayed warnings
@ 2011-03-20  5:44 Juanma Barranquero
  2011-03-21  8:01 ` martin rudalics
  0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-20  5:44 UTC (permalink / raw)
  To: Emacs developers

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)



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-20  5:44 Delayed warnings Juanma Barranquero
@ 2011-03-21  8:01 ` martin rudalics
  2011-03-21 12:01   ` Juanma Barranquero
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2011-03-21  8:01 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs developers

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21  8:01 ` martin rudalics
@ 2011-03-21 12:01   ` Juanma Barranquero
  2011-03-21 13:17     ` martin rudalics
  0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-21 12:01 UTC (permalink / raw)
  To: martin rudalics; +Cc: Emacs developers

> 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 12:01   ` Juanma Barranquero
@ 2011-03-21 13:17     ` martin rudalics
  2011-03-21 13:43       ` Eli Zaretskii
  2011-03-21 14:48       ` Juanma Barranquero
  0 siblings, 2 replies; 30+ messages in thread
From: martin rudalics @ 2011-03-21 13:17 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs developers

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 13:17     ` martin rudalics
@ 2011-03-21 13:43       ` Eli Zaretskii
  2011-03-21 18:06         ` martin rudalics
  2011-03-21 14:48       ` Juanma Barranquero
  1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-21 13:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: lekktu, emacs-devel

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 13:17     ` martin rudalics
  2011-03-21 13:43       ` Eli Zaretskii
@ 2011-03-21 14:48       ` Juanma Barranquero
  2011-03-21 18:06         ` martin rudalics
  1 sibling, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-21 14:48 UTC (permalink / raw)
  To: martin rudalics; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 13:43       ` Eli Zaretskii
@ 2011-03-21 18:06         ` martin rudalics
  0 siblings, 0 replies; 30+ messages in thread
From: martin rudalics @ 2011-03-21 18:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lekktu, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 14:48       ` Juanma Barranquero
@ 2011-03-21 18:06         ` martin rudalics
  2011-03-21 20:19           ` Juanma Barranquero
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2011-03-21 18:06 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs developers

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 18:06         ` martin rudalics
@ 2011-03-21 20:19           ` Juanma Barranquero
  2011-03-21 22:05             ` Stefan Monnier
  2011-03-22  7:58             ` martin rudalics
  0 siblings, 2 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-21 20:19 UTC (permalink / raw)
  To: martin rudalics; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 20:19           ` Juanma Barranquero
@ 2011-03-21 22:05             ` Stefan Monnier
  2011-03-22  7:59               ` martin rudalics
                                 ` (3 more replies)
  2011-03-22  7:58             ` martin rudalics
  1 sibling, 4 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-03-21 22:05 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers

> 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 20:19           ` Juanma Barranquero
  2011-03-21 22:05             ` Stefan Monnier
@ 2011-03-22  7:58             ` martin rudalics
  2011-03-22 12:04               ` Juanma Barranquero
  1 sibling, 1 reply; 30+ messages in thread
From: martin rudalics @ 2011-03-22  7:58 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs developers

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 22:05             ` Stefan Monnier
@ 2011-03-22  7:59               ` martin rudalics
  2011-03-22 11:59               ` Juanma Barranquero
                                 ` (2 subsequent siblings)
  3 siblings, 0 replies; 30+ messages in thread
From: martin rudalics @ 2011-03-22  7:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Juanma Barranquero, Emacs developers

 > 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 22:05             ` Stefan Monnier
  2011-03-22  7:59               ` martin rudalics
@ 2011-03-22 11:59               ` Juanma Barranquero
  2011-03-23 13:50               ` Jeff Sparkes
  2011-03-25 13:10               ` Juanma Barranquero
  3 siblings, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-22 11:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-22  7:58             ` martin rudalics
@ 2011-03-22 12:04               ` Juanma Barranquero
  0 siblings, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-22 12:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 22:05             ` Stefan Monnier
  2011-03-22  7:59               ` martin rudalics
  2011-03-22 11:59               ` Juanma Barranquero
@ 2011-03-23 13:50               ` Jeff Sparkes
  2011-03-25 13:10               ` Juanma Barranquero
  3 siblings, 0 replies; 30+ messages in thread
From: Jeff Sparkes @ 2011-03-23 13:50 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-21 22:05             ` Stefan Monnier
                                 ` (2 preceding siblings ...)
  2011-03-23 13:50               ` Jeff Sparkes
@ 2011-03-25 13:10               ` Juanma Barranquero
  2011-04-27  0:55                 ` Juanma Barranquero
  3 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-03-25 13:10 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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

   Juanma



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-03-25 13:10               ` Juanma Barranquero
@ 2011-04-27  0:55                 ` Juanma Barranquero
  2011-04-27  3:05                   ` Eli Zaretskii
  2011-04-27 17:32                   ` Stefan Monnier
  0 siblings, 2 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-27  0:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-27  0:55                 ` Juanma Barranquero
@ 2011-04-27  3:05                   ` Eli Zaretskii
  2011-04-27 11:27                     ` Juanma Barranquero
  2011-04-27 17:32                   ` Stefan Monnier
  1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-04-27  3:05 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rudalics, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-27  3:05                   ` Eli Zaretskii
@ 2011-04-27 11:27                     ` Juanma Barranquero
  0 siblings, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-27 11:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-27  0:55                 ` Juanma Barranquero
  2011-04-27  3:05                   ` Eli Zaretskii
@ 2011-04-27 17:32                   ` Stefan Monnier
  2011-04-27 22:11                     ` Juanma Barranquero
  1 sibling, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-04-27 17:32 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers

> 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-27 17:32                   ` Stefan Monnier
@ 2011-04-27 22:11                     ` Juanma Barranquero
  2011-04-28  0:40                       ` Stefan Monnier
  0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-27 22:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-27 22:11                     ` Juanma Barranquero
@ 2011-04-28  0:40                       ` Stefan Monnier
  2011-04-28  0:59                         ` Juanma Barranquero
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-04-28  0:40 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-28  0:40                       ` Stefan Monnier
@ 2011-04-28  0:59                         ` Juanma Barranquero
  2011-04-28 15:26                           ` Stefan Monnier
  0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-28  0:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-28  0:59                         ` Juanma Barranquero
@ 2011-04-28 15:26                           ` Stefan Monnier
  2011-04-28 16:22                             ` Juanma Barranquero
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-04-28 15:26 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers

> 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-28 15:26                           ` Stefan Monnier
@ 2011-04-28 16:22                             ` Juanma Barranquero
  2011-04-28 18:39                               ` Stefan Monnier
  2011-05-08 17:58                               ` Chong Yidong
  0 siblings, 2 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-28 16:22 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: martin rudalics, Emacs developers

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.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-28 16:22                             ` Juanma Barranquero
@ 2011-04-28 18:39                               ` Stefan Monnier
  2011-05-08 17:58                               ` Chong Yidong
  1 sibling, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-28 18:39 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Emacs developers

> 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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-04-28 16:22                             ` Juanma Barranquero
  2011-04-28 18:39                               ` Stefan Monnier
@ 2011-05-08 17:58                               ` Chong Yidong
  2011-05-08 18:43                                 ` Juanma Barranquero
  1 sibling, 1 reply; 30+ messages in thread
From: Chong Yidong @ 2011-05-08 17:58 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Stefan Monnier, Emacs developers

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.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-05-08 17:58                               ` Chong Yidong
@ 2011-05-08 18:43                                 ` Juanma Barranquero
  2011-05-09 14:15                                   ` Stefan Monnier
  2011-05-09 18:28                                   ` Richard Stallman
  0 siblings, 2 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-05-08 18:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: martin rudalics, Stefan Monnier, Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-05-08 18:43                                 ` Juanma Barranquero
@ 2011-05-09 14:15                                   ` Stefan Monnier
  2011-05-09 18:28                                   ` Richard Stallman
  1 sibling, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-05-09 14:15 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: martin rudalics, Chong Yidong, Emacs developers

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Delayed warnings
  2011-05-08 18:43                                 ` Juanma Barranquero
  2011-05-09 14:15                                   ` Stefan Monnier
@ 2011-05-09 18:28                                   ` Richard Stallman
  1 sibling, 0 replies; 30+ messages in thread
From: Richard Stallman @ 2011-05-09 18:28 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rudalics, cyd, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2011-05-09 18:28 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-20  5:44 Delayed warnings Juanma Barranquero
2011-03-21  8:01 ` martin rudalics
2011-03-21 12:01   ` Juanma Barranquero
2011-03-21 13:17     ` martin rudalics
2011-03-21 13:43       ` Eli Zaretskii
2011-03-21 18:06         ` martin rudalics
2011-03-21 14:48       ` Juanma Barranquero
2011-03-21 18:06         ` martin rudalics
2011-03-21 20:19           ` Juanma Barranquero
2011-03-21 22:05             ` Stefan Monnier
2011-03-22  7:59               ` martin rudalics
2011-03-22 11:59               ` Juanma Barranquero
2011-03-23 13:50               ` Jeff Sparkes
2011-03-25 13:10               ` Juanma Barranquero
2011-04-27  0:55                 ` Juanma Barranquero
2011-04-27  3:05                   ` Eli Zaretskii
2011-04-27 11:27                     ` Juanma Barranquero
2011-04-27 17:32                   ` Stefan Monnier
2011-04-27 22:11                     ` Juanma Barranquero
2011-04-28  0:40                       ` Stefan Monnier
2011-04-28  0:59                         ` Juanma Barranquero
2011-04-28 15:26                           ` Stefan Monnier
2011-04-28 16:22                             ` Juanma Barranquero
2011-04-28 18:39                               ` Stefan Monnier
2011-05-08 17:58                               ` Chong Yidong
2011-05-08 18:43                                 ` Juanma Barranquero
2011-05-09 14:15                                   ` Stefan Monnier
2011-05-09 18:28                                   ` Richard Stallman
2011-03-22  7:58             ` martin rudalics
2011-03-22 12:04               ` Juanma Barranquero

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).