* delayed-warnings-list and delayed-warnings-hook
@ 2012-03-20 9:56 Chong Yidong
2012-03-20 10:07 ` Juanma Barranquero
2012-03-20 16:24 ` Glenn Morris
0 siblings, 2 replies; 6+ messages in thread
From: Chong Yidong @ 2012-03-20 9:56 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: emacs-devel
Is there any reason the NEWS entry for this is tagged `---'? As far as
I can tell, it is an ordinary new feature and should be documented.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: delayed-warnings-list and delayed-warnings-hook
2012-03-20 9:56 delayed-warnings-list and delayed-warnings-hook Chong Yidong
@ 2012-03-20 10:07 ` Juanma Barranquero
2012-04-02 13:58 ` Chong Yidong
2012-03-20 16:24 ` Glenn Morris
1 sibling, 1 reply; 6+ messages in thread
From: Juanma Barranquero @ 2012-03-20 10:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
> Is there any reason the NEWS entry for this is tagged `---'? As far as
> I can tell, it is an ordinary new feature and should be documented.
Glenn added the --- and the following comment in the code:
+;; At present this is only really useful for Emacs internals.
+;; Document in the lispref if it becomes generally useful.
+;; Ref http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00085.html
It is only used for Emacs internals, but I think it is useful in general.
Juanma
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: delayed-warnings-list and delayed-warnings-hook
2012-03-20 9:56 delayed-warnings-list and delayed-warnings-hook Chong Yidong
2012-03-20 10:07 ` Juanma Barranquero
@ 2012-03-20 16:24 ` Glenn Morris
1 sibling, 0 replies; 6+ messages in thread
From: Glenn Morris @ 2012-03-20 16:24 UTC (permalink / raw)
To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel
Chong Yidong wrote:
> Is there any reason the NEWS entry for this is tagged `---'? As far as
> I can tell, it is an ordinary new feature and should be documented.
That was my conclusion based on the discussion in
http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00085.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: delayed-warnings-list and delayed-warnings-hook
2012-03-20 10:07 ` Juanma Barranquero
@ 2012-04-02 13:58 ` Chong Yidong
2012-04-02 14:20 ` Juanma Barranquero
0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2012-04-02 13:58 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
>> Is there any reason the NEWS entry for this is tagged `---'? As far as
>> I can tell, it is an ordinary new feature and should be documented.
>
> Glenn added the --- and the following comment in the code:
>
> +;; At present this is only really useful for Emacs internals.
> +;; Document in the lispref if it becomes generally useful.
> +;; Ref http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00085.html
>
> It is only used for Emacs internals, but I think it is useful in general.
`delayed-warnings-list' should certainly be documented; I will work on
that.
As for `delayed-warnings-hook', maybe we should mark it explicitly as
internal, because it seems a bit delicate with respect to third party
usage. 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. 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.
To clarify the situation a little, could you explain what kind of
functions you envision third party code adding to this hook?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: delayed-warnings-list and delayed-warnings-hook
2012-04-02 13:58 ` Chong Yidong
@ 2012-04-02 14:20 ` Juanma Barranquero
2012-04-02 14:22 ` Juanma Barranquero
0 siblings, 1 reply; 6+ messages in thread
From: Juanma Barranquero @ 2012-04-02 14:20 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On Mon, Apr 2, 2012 at 15:58, Chong Yidong <cyd@gnu.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: delayed-warnings-list and delayed-warnings-hook
2012-04-02 14:20 ` Juanma Barranquero
@ 2012-04-02 14:22 ` Juanma Barranquero
0 siblings, 0 replies; 6+ messages in thread
From: Juanma Barranquero @ 2012-04-02 14:22 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
On Mon, Apr 2, 2012 at 16:20, Juanma Barranquero <lekktu@gmail.com> wrote:
> warnings in buffers others than *Message*.
s/*Message*/*Warnings*/
Juanma
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-02 14:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-20 9:56 delayed-warnings-list and delayed-warnings-hook Chong Yidong
2012-03-20 10:07 ` Juanma Barranquero
2012-04-02 13:58 ` Chong Yidong
2012-04-02 14:20 ` Juanma Barranquero
2012-04-02 14:22 ` Juanma Barranquero
2012-03-20 16:24 ` Glenn Morris
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).