* Re: [PATCH] Better error reporting in Gnus splitting.
2006-07-18 23:49 [PATCH] Better error reporting in Gnus splitting Karl Fogel
@ 2006-07-19 8:08 ` Reiner Steib
2006-07-19 8:14 ` Reiner Steib
2006-07-20 2:24 ` Karl Fogel
2 siblings, 0 replies; 7+ messages in thread
From: Reiner Steib @ 2006-07-19 8:08 UTC (permalink / raw)
Cc: emacs-devel
On Wed, Jul 19 2006, Karl Fogel wrote:
> Any objections if I commit this patch?
>
> Without this patch, when splitting encounters an error (say, an
> invalid regular expression) in the nnmail-split-fancy list, then the
> user is simply told that there is an error, but is given no details
> about the error's nature. The mail gets split into the 'bogus' mail
> group, and the user has no idea why.
>
> With this patch, the user is informed about the general nature of the
> error and may then be able to track it down. (The error report could
> theoretically be even more informative than this, but I didn't want to
> make a large change.) The mail is still filtered into 'bogus' group.
>
> See simple patch below.
>
> -Karl
>
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/ChangeLog,v
> retrieving revision 1.474
> diff -u -r1.474 ChangeLog
> --- ChangeLog 19 Jul 2006 01:06:00 -0000 1.474
> +++ ChangeLog 19 Jul 2006 01:51:44 -0000
> @@ -1,3 +1,9 @@
> +2006-07-18 Karl Fogel <kfogel@red-bean.com>
> +
> + * nnmail.el (nnmail-article-group): If splitting raises an error, give
> + some information about the error when saying that the `bogus' mail
> + group will be used.
> +
> 2006-07-18 Andreas Seltenreich <uwi7@rz.uni-karlsruhe.de>
>
> [ Backported bug fixes from No Gnus. ]
> Index: nnmail.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/nnmail.el,v
> retrieving revision 1.33
> diff -u -r1.33 nnmail.el
> --- nnmail.el 9 Mar 2006 07:11:51 -0000 1.33
> +++ nnmail.el 19 Jul 2006 01:51:45 -0000
> @@ -1131,7 +1131,7 @@
> (if (and (symbolp nnmail-split-methods)
> (fboundp nnmail-split-methods))
> (let ((split
> - (condition-case nil
> + (condition-case error-info
> ;; `nnmail-split-methods' is a function, so we
> ;; just call this function here and use the
> ;; result.
> @@ -1139,7 +1139,7 @@
> '("bogus"))
> (error
> (nnheader-message
> - 5 "Error in `nnmail-split-methods'; using `bogus' mail group")
> + 5 "Error in `nnmail-split-methods'; using `bogus' mail group: %S" error-info)
> (sit-for 1)
> '("bogus")))))
> (setq split (mm-delete-duplicates split))
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Better error reporting in Gnus splitting.
2006-07-18 23:49 [PATCH] Better error reporting in Gnus splitting Karl Fogel
2006-07-19 8:08 ` Reiner Steib
@ 2006-07-19 8:14 ` Reiner Steib
2006-07-19 15:27 ` Karl Fogel
2006-07-20 2:24 ` Karl Fogel
2 siblings, 1 reply; 7+ messages in thread
From: Reiner Steib @ 2006-07-19 8:14 UTC (permalink / raw)
Cc: Gnus, emacs-devel
[ Sorry for the prematurely sent mail. Cc-ing the Gnus list. ]
On Wed, Jul 19 2006, Karl Fogel wrote:
> Any objections if I commit this patch?
I don't see a problem with it. Anyone?
> Without this patch, when splitting encounters an error (say, an
> invalid regular expression) in the nnmail-split-fancy list, then the
> user is simply told that there is an error, but is given no details
> about the error's nature. The mail gets split into the 'bogus' mail
> group, and the user has no idea why.
>
> With this patch, the user is informed about the general nature of the
> error and may then be able to track it down. (The error report could
> theoretically be even more informative than this, but I didn't want to
> make a large change.)
Would you like to post this version too?
> The mail is still filtered into 'bogus' group.
>
> See simple patch below.
>
> -Karl
>
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/ChangeLog,v
> retrieving revision 1.474
> diff -u -r1.474 ChangeLog
> --- ChangeLog 19 Jul 2006 01:06:00 -0000 1.474
> +++ ChangeLog 19 Jul 2006 01:51:44 -0000
> @@ -1,3 +1,9 @@
> +2006-07-18 Karl Fogel <kfogel@red-bean.com>
> +
> + * nnmail.el (nnmail-article-group): If splitting raises an error, give
> + some information about the error when saying that the `bogus' mail
> + group will be used.
> +
> 2006-07-18 Andreas Seltenreich <uwi7@rz.uni-karlsruhe.de>
>
> [ Backported bug fixes from No Gnus. ]
> Index: nnmail.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/nnmail.el,v
> retrieving revision 1.33
> diff -u -r1.33 nnmail.el
> --- nnmail.el 9 Mar 2006 07:11:51 -0000 1.33
> +++ nnmail.el 19 Jul 2006 01:51:45 -0000
> @@ -1131,7 +1131,7 @@
> (if (and (symbolp nnmail-split-methods)
> (fboundp nnmail-split-methods))
> (let ((split
> - (condition-case nil
> + (condition-case error-info
> ;; `nnmail-split-methods' is a function, so we
> ;; just call this function here and use the
> ;; result.
> @@ -1139,7 +1139,7 @@
> '("bogus"))
> (error
> (nnheader-message
> - 5 "Error in `nnmail-split-methods'; using `bogus' mail group")
> + 5 "Error in `nnmail-split-methods'; using `bogus' mail group: %S" error-info)
> (sit-for 1)
> '("bogus")))))
> (setq split (mm-delete-duplicates split))
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Better error reporting in Gnus splitting.
2006-07-19 8:14 ` Reiner Steib
@ 2006-07-19 15:27 ` Karl Fogel
0 siblings, 0 replies; 7+ messages in thread
From: Karl Fogel @ 2006-07-19 15:27 UTC (permalink / raw)
Cc: emacs-devel
Reiner Steib <reinersteib+gmane@imap.cc> writes:
> On Wed, Jul 19 2006, Karl Fogel wrote:
>
>> Any objections if I commit this patch?
>
> I don't see a problem with it. Anyone?
>
>> Without this patch, when splitting encounters an error (say, an
>> invalid regular expression) in the nnmail-split-fancy list, then the
>> user is simply told that there is an error, but is given no details
>> about the error's nature. The mail gets split into the 'bogus' mail
>> group, and the user has no idea why.
>>
>> With this patch, the user is informed about the general nature of the
>> error and may then be able to track it down. (The error report could
>> theoretically be even more informative than this, but I didn't want to
>> make a large change.)
>
> Would you like to post this version too?
Oh, I don't have that version -- I just traced far enough in the code
to know that it's possible. Unfortunately, I don't have time to write
it right now, hence this smaller patch (which is likely to be a subset
of the larger one anyway).
-Karl
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Better error reporting in Gnus splitting.
2006-07-18 23:49 [PATCH] Better error reporting in Gnus splitting Karl Fogel
2006-07-19 8:08 ` Reiner Steib
2006-07-19 8:14 ` Reiner Steib
@ 2006-07-20 2:24 ` Karl Fogel
2006-07-20 4:37 ` Miles Bader
2006-07-20 15:28 ` Stefan Monnier
2 siblings, 2 replies; 7+ messages in thread
From: Karl Fogel @ 2006-07-20 2:24 UTC (permalink / raw)
I was about to commit the patch below, when I realized that our Emacs
tree might not be master repository for Gnus. When I do 'cvs log' on
lisp/gnus/<whatever>.el, it seems to indicate that changes generally
get merged in from somewhere else -- i.e., that we are not the master.
Is it okay to check new changes into lisp/gnus/, or should they go to
some other tree and get merged from there into ours? Or is Arch magic
taking care of this whole problem and I shouldn't worry about it?
-Karl
Karl Fogel <kfogel@red-bean.com> writes:
> Any objections if I commit this patch?
>
> Without this patch, when splitting encounters an error (say, an
> invalid regular expression) in the nnmail-split-fancy list, then the
> user is simply told that there is an error, but is given no details
> about the error's nature. The mail gets split into the 'bogus' mail
> group, and the user has no idea why.
>
> With this patch, the user is informed about the general nature of the
> error and may then be able to track it down. (The error report could
> theoretically be even more informative than this, but I didn't want to
> make a large change.) The mail is still filtered into 'bogus' group.
>
> See simple patch below.
>
> -Karl
>
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/ChangeLog,v
> retrieving revision 1.474
> diff -u -r1.474 ChangeLog
> --- ChangeLog 19 Jul 2006 01:06:00 -0000 1.474
> +++ ChangeLog 19 Jul 2006 01:51:44 -0000
> @@ -1,3 +1,9 @@
> +2006-07-18 Karl Fogel <kfogel@red-bean.com>
> +
> + * nnmail.el (nnmail-article-group): If splitting raises an error, give
> + some information about the error when saying that the `bogus' mail
> + group will be used.
> +
> 2006-07-18 Andreas Seltenreich <uwi7@rz.uni-karlsruhe.de>
>
> [ Backported bug fixes from No Gnus. ]
> Index: nnmail.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/gnus/nnmail.el,v
> retrieving revision 1.33
> diff -u -r1.33 nnmail.el
> --- nnmail.el 9 Mar 2006 07:11:51 -0000 1.33
> +++ nnmail.el 19 Jul 2006 01:51:45 -0000
> @@ -1131,7 +1131,7 @@
> (if (and (symbolp nnmail-split-methods)
> (fboundp nnmail-split-methods))
> (let ((split
> - (condition-case nil
> + (condition-case error-info
> ;; `nnmail-split-methods' is a function, so we
> ;; just call this function here and use the
> ;; result.
> @@ -1139,7 +1139,7 @@
> '("bogus"))
> (error
> (nnheader-message
> - 5 "Error in `nnmail-split-methods'; using `bogus' mail group")
> + 5 "Error in `nnmail-split-methods'; using `bogus' mail group: %S" error-info)
> (sit-for 1)
> '("bogus")))))
> (setq split (mm-delete-duplicates split))
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread