small patch for nnmail (lowercase expand option)

small patch for nnmail (lowercase expand option)

[dhedbor]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Hello. I just recently started using fancy splitting of mailing
lists. It worked great except for one thing - if someone sent a mail
to Mailing-List-dev@domain, it got sorted into lists.dev.Mailing-List
rather than the desired lists.dev.mailing-list.

After some research it seems like Gnus doesn't support lowercasing the
expanded text so I decided to add it. The patch is attached.

One small note: It might be more correct to add support for the
features used in replace-match, i.e \l, \L and such (or perhaps it's
possible to use the replace-match somehow, I don't know). However all
_I_ needed was lowercasing and also my lisp skills are somewhat
lacking so I don't want to attempt to make such a change.

Never the less, I figured I could just as well ship this patch to the
list for possible inclusion.

-- 
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org

[-- Attachment #2: nnmail-expand-lowercase.patch --]
[-- Type: text/x-patch, Size: 1257 bytes --]

Index: lisp/nnmail.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnmail.el,v
retrieving revision 7.9
diff -u -r7.9 nnmail.el
--- lisp/nnmail.el	20 May 2004 08:02:40 -0000	7.9
+++ lisp/nnmail.el	8 Jul 2004 23:03:39 -0000
@@ -574,6 +574,15 @@
   :group 'nnmail
   :type 'boolean)
 
+(defcustom nnmail-split-fancy-lowercase-expanded nil
+
+  "Whether to match lowercase expanded entries (i.e \\N) or leave them
+as-is when using fancy splitting. This avoids the creation of multiple
+groups when users send to an address using different case (i.e 
+mailing-list@domain vs Mailing-List@Domain)."
+  :group 'nnmail
+  :type 'boolean)
+
 ;;; Internal variables.
 
 (defvar nnmail-article-buffer " *nnmail incoming*"
@@ -1464,8 +1473,11 @@
 	      (setq N 0)
 	    (setq N (- c ?0)))
 	  (when (match-beginning N)
-	    (push (buffer-substring (match-beginning N) (match-end N))
-		  expanded))))
+	    (let ((tmp-match (buffer-substring (match-beginning N)
+					       (match-end N))))
+	      (if nnmail-split-fancy-lowercase-expanded
+		  (push (downcase tmp-match) expanded)
+		(push tmp-match expanded))))))
       (setq pos (1+ pos)))
     (if did-expand
 	(apply 'concat (nreverse expanded))

Re: small patch for nnmail (lowercase expand option)

[dhedbor]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

dhedbor@real.com writes:

> +  "Whether to match lowercase expanded entries (i.e \\N) or leave them

Typo in the documentation. That "match" shouldn't be there. New patch attached.

-- 
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org

[-- Attachment #2: nnmail-expand-lowercase.patch --]
[-- Type: text/x-patch, Size: 1251 bytes --]

Index: lisp/nnmail.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnmail.el,v
retrieving revision 7.9
diff -u -r7.9 nnmail.el
--- lisp/nnmail.el	20 May 2004 08:02:40 -0000	7.9
+++ lisp/nnmail.el	8 Jul 2004 23:10:35 -0000
@@ -574,6 +574,15 @@
   :group 'nnmail
   :type 'boolean)
 
+(defcustom nnmail-split-fancy-lowercase-expanded nil
+
+  "Whether to lowercase expanded entries (i.e \\N) or leave them as-is
+when using fancy splitting. This avoids the creation of multiple
+groups when users send to an address using different case (i.e 
+mailing-list@domain vs Mailing-List@Domain)."
+  :group 'nnmail
+  :type 'boolean)
+
 ;;; Internal variables.
 
 (defvar nnmail-article-buffer " *nnmail incoming*"
@@ -1464,8 +1473,11 @@
 	      (setq N 0)
 	    (setq N (- c ?0)))
 	  (when (match-beginning N)
-	    (push (buffer-substring (match-beginning N) (match-end N))
-		  expanded))))
+	    (let ((tmp-match (buffer-substring (match-beginning N)
+					       (match-end N))))
+	      (if nnmail-split-fancy-lowercase-expanded
+		  (push (downcase tmp-match) expanded)
+		(push tmp-match expanded))))))
       (setq pos (1+ pos)))
     (if did-expand
 	(apply 'concat (nreverse expanded))

Re: small patch for nnmail (lowercase expand option)

[Katsumi Yamaoka]

>>>>> In <87y8luhz6i.fsf@real.com>
>>>>>	dhedbor@real.com wrote:

> +(defcustom nnmail-split-fancy-lowercase-expanded nil
> +
> +  "Whether to lowercase expanded entries (i.e \\N) or leave them as-is
> +when using fancy splitting. This avoids the creation of multiple
> +groups when users send to an address using different case (i.e 
> +mailing-list@domain vs Mailing-List@Domain)."
> +  :group 'nnmail
> +  :type 'boolean)

Is the option really needed?  The value seems always one good at
T because users cannot do case-sensitive splitting.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: small patch for nnmail (lowercase expand option)

[Marcelo Toledo]

I've also ran into this problem, I fixed using regexp but I agree with
this patch.

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Is the option really needed?  The value seems always one good at
> T because users cannot do case-sensitive splitting.

-- 
Marcelo Toledo
marcelo@marcelotoledo.org
http://www.marcelotoledo.org
Mobile: 55 71 9141-7181

Re: small patch for nnmail (lowercase expand option)

[Katsumi Yamaoka]

>>>>> In <87hdsh9vn0.fsf@kali.intranet> 
>>>>>	Marcelo Toledo <marcelo@marcelotoledo.org> wrote:

> I've also ran into this problem, I fixed using regexp but I agree with
> this patch.

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Is the option really needed?  The value seems always one good at
>> T because users cannot do case-sensitive splitting.

I also agree with that change.  I simply asked whether the
change can be made without flexibility. :)
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: small patch for nnmail (lowercase expand option)

[Katsumi Yamaoka]

>>>>> In <b9yllhu54qh.fsf@jpl.org> Katsumi Yamaoka wrote:

>>>>>> In <87y8luhz6i.fsf@real.com>
>>>>>>	dhedbor@real.com wrote:

>> +(defcustom nnmail-split-fancy-lowercase-expanded nil

> Is the option really needed?  The value seems always one good at
> T because users cannot do case-sensitive splitting.

I've installed it with the default value T, considering no one
can decide whether to delete it.  Since it affects not only the
fancy mail splitting but the standard one, I changed the variable
name into:

nnmail-split-lowercase-expanded

Regards,

Re: small patch for nnmail (lowercase expand option)

[dhedbor]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <b9yllhu54qh.fsf@jpl.org> Katsumi Yamaoka wrote:
>
>>>>>>> In <87y8luhz6i.fsf@real.com>
>>>>>>>	dhedbor@real.com wrote:
>
>>> +(defcustom nnmail-split-fancy-lowercase-expanded nil
>
>> Is the option really needed?  The value seems always one good at
>> T because users cannot do case-sensitive splitting.
>
> I've installed it with the default value T, considering no one
> can decide whether to delete it.  Since it affects not only the
> fancy mail splitting but the standard one, I changed the variable
> name into:
>
> nnmail-split-lowercase-expanded
>
> Regards,
Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <b9yllhu54qh.fsf@jpl.org> Katsumi Yamaoka wrote:
>
>>>>>>> In <87y8luhz6i.fsf@real.com>
>>>>>>>	dhedbor@real.com wrote:
>
>>> +(defcustom nnmail-split-fancy-lowercase-expanded nil
>
>> Is the option really needed?  The value seems always one good at
>> T because users cannot do case-sensitive splitting.

(seems like I missed a few mails here for some reason)

Perhaps the option isn't needed just because splitting is case
insensitive as you say. However I didn't want to supply a patch that
unconditionally changed the old behavior.

> I've installed it with the default value T, considering no one
> can decide whether to delete it.  Since it affects not only the
> fancy mail splitting but the standard one, I changed the variable
> name into:
>
> nnmail-split-lowercase-expanded

This is true, I didn't think about that since I never used this kind
of splitting before (pattern with replace) prior to using fancy
splitting.


-- 
David Hedbor, Software Development Engineer - Real Networks
Helix Community: http://helixcommunity.org