🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.vm.bug
Article #8750

Re: vm-su-do-author

#8750
From: Kevin Rodgers
Date: Fri, 25 Jun 1993 21:26
108 lines
5613 bytes
In article <1993Jun24.193940.5265@den.mmc.com> I wrote:
>There appear to be a couple bugs in vm-su-do-author, which is
>responsible for determining the 'from' and 'full-name' message
>attributes.  When a "From:" header header is present, vm-su-do-author
>uses regexps to parse the address and person's name; in particular, it
>looks for these formats
>
>	full-name <address>		e.g. First Last <user@host.domain>
>	address (full-name)		e.g. user@host.domain (First Last)
>
>by matching these regexps, respectively
>
>	"^\\([^< \t\n]+\\([ \t\n]+[^< \t\n]+\\)*\\)?[ \t\n]*\\(<\\([^>]+\\)>\\)"
>	"[\000-\177]*(\\([^)]+\\))[\000-\177]*"
>
>The problems I've found are that:
>
>1. Nested parentheses in second format aren't handled correctly.  For
>   instance, "user@host.domain (First Last (position))" gets parsed as
>   full-name = "position" and from = "user@host.domain (First Last )".
>
>2. Only two white-space separated words are allowed in the full-name
>   part of the first format.  For example, "First Middle Last
>   <user@host.domain>" isn't recognized.

The following patch fixes both problems.

>I can fix vm-su-do-author and post the patch, but I have a couple
>questions about the way it's implemented that I'd like to have answered
>before I proceed:
>
>1. Why not use rfc822-addresses, like vm-su-do-recipients, to extract
>   the 'from' attribute?

My thinking here was to use the result of rfc822-addresses as the value
of the 'from' attribute, then use regexp-quote and string-match to get
the rest of the header as the value of the 'full-name' attribute.  I
decided against this, since (1) rfc822-addresses indicates errors by
returning a string that's got to be parsed, rather than returning nil or
signalling an error, which would be more convenient, and (2) getting the
rest of the header begs the question of how to correctly strip the
parentheses in the second format.

>2. Since the two formats are analogous in that they consist of two parts
>   separated by whitespace, one of which is enclosed by matching
>   delimiters, why aren't they parsed by analogous regexps?
>
>   In particular, why is the regexp for "full-name <address>" anchored
>   at the beginning but not at the end, and why isn't the regexp for
>   "address (full-name)" anchored at all?

I've anchored both regexps at the beginning and end so that any initial
or final whitespace is trimmed from the attributes.  There is one minor
deficiency: any whitespace between the attributes isn't yet stripped
from the attribute which it follows.  If this proves to be a problem, it
will be necessary to trim the attribute's trailing whitespace with a
separate string-match and substring call, since adding "\\s *" to the
header regexps would just be subsumed by the immediately preceding
"[^<]+" and "[^(]+" patterns.

SCCS/s.vm-summary.el: 1.1 vs. 1.2
*** /tmp/geta7643	Fri Jun 25 15:24:29 1993
--- /tmp/getb7643	Fri Jun 25 15:24:30 1993
***************
*** 573,592 ****
  	   (setq from "???")
  	   (if (null full-name)
  	       (setq full-name "???")))
! 	  ((string-match "^\\([^< \t\n]+\\([ \t\n]+[^< \t\n]+\\)*\\)?[ \t\n]*\\(<\\([^>]+\\)>\\)"
! 			 from)
! 	   (if (and (match-beginning 1) (null full-name))
  	       (setq full-name
  		     (substring from (match-beginning 1) (match-end 1))))
! 	   (setq from (substring from (match-beginning 4) (match-end 4))))
! 	  ((string-match "[\000-\177]*(\\([^)]+\\))[\000-\177]*" from)
  	   (if (null full-name)
! 	       (setq full-name (substring from (match-beginning 1)
! 					  (match-end 1))))
  	   (setq from
! 		 (concat
! 		  (substring from (match-beginning 0) (1- (match-beginning 1)))
! 		  (substring from (1+ (match-end 1)) (match-end 0))))))
      ;; ewe ewe see pee...
      (if (and vm-gargle-uucp (string-match
  "\\([^!@:.]+\\)\\(\\.[^!@:]+\\)?!\\([^!@: \t\n]+\\)\\(@\\([^!@:. \t\n]+\\)\\(.[^ \t\n]+\\)?\\)?[ \t\n]*$"
--- 573,589 ----
  	   (setq from "???")
  	   (if (null full-name)
  	       (setq full-name "???")))
! 	  ((string-match "^\\s *\\([^<]+\\)<\\(.+\\)>\\s *$" from)
! 	   (if (null full-name)
  	       (setq full-name
  		     (substring from (match-beginning 1) (match-end 1))))
! 	   (setq from (substring from (match-beginning 2) (match-end 2))))
! 	  ((string-match "^\\s *\\([^(]+\\)(\\(.+\\))\\s *$" from)
  	   (if (null full-name)
! 	       (setq full-name
! 		     (substring from (match-beginning 2) (match-end 2))))
  	   (setq from
! 		 (substring from (match-beginning 1) (match-beginning 1)))))
      ;; ewe ewe see pee...
      (if (and vm-gargle-uucp (string-match
  "\\([^!@:.]+\\)\\(\\.[^!@:]+\\)?!\\([^!@: \t\n]+\\)\\(@\\([^!@:. \t\n]+\\)\\(.[^ \t\n]+\\)?\\)?[ \t\n]*$"
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS DC5695		(303) 971-2396
P.O. Box 179
Denver CO 80201 USA			GO BUFFS!
Technical Details
Message-ID: <1993Jun25.212650.23625@den.mmc.com>
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!traffic!kevin
References: <1993Jun24.193940.5265@den.mmc.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f6829,5d57888019b47500
X-Google-Attributes: gidf6829,public
X-Google-ArrivalTime: 1993-06-25 15:04:39 PST
Newsgroups: gnu.emacs.vm.bug
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!traffic!kevin
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: vm-su-do-author
Message-ID: <1993Jun25.212650.23625@den.mmc.com>
Sender: news@den.mmc.com (News)
Nntp-Posting-Host: traffic.den.mmc.com
Organization: Martin Marietta Information Systems, Western Internal Systems
References: <1993Jun24.193940.5265@den.mmc.com>
Date: Fri, 25 Jun 1993 21:26:50 GMT
Lines: 108