Re: add mailto: support to exmhcomp (+patch)

Brent Welch <[email protected]> Thu, 17 Mar 2005 16:38:04 -0800
Newsgroups gmane.mail.exmh.devel
Message-ID <[email protected]>
I picked up your exmhcomp patch - thanks!

I'm all for making the ancient decoder more useful.
Would ncgi::decode suffice ?

proc ::ncgi::decode {str} {
    # rewrite "+" back to space
    # protect \ from quoting another '\'
    set str [string map [list + { } "\\" "\\\\"] $str]

    # prepare to process all %-escapes
    regsub -all -- {%([A-Fa-f0-9][A-Fa-f0-9])} $str {\\u00\1} str

    # process \u unicode mapped chars
    return [subst -novar -nocommand $str]
}

>>>Alexander Zangerl said:

 > it would be very nice if exmhcomp did support processing
 > of mailto: urls. (some webbrowsers allow external handlers for 
 > such urls.)
 > 
 > as exmh has the Msg_Mailto procedure for just that purpose, 
 > adding this as a send argument to exmhcomp is trivial; could somebody
 > with cvs commit rights please add the attached few lines of patch?
 > 
 > there's two minor problems remaining with mailto handling in exmh in
 > general:
 > 
 > .) why is MsgDecodeURL (which is used to un-urlencode) only implemented
 >    for a very few characters? why not use the equivalent of this:
 > 
 > proc urldec { s } 
 > {subst -nocom -novar [string map {\\ \\\\ %\n "" % \\u00} $s]}
 > (maybe plus extra handling of %0d and %0a)
 > 
 > in my humble opinion, being generous with what is accepted would be a 
 > good idea here; the url rfcs only say that certain characters must be
 > encoded but don't prohibit encoding of others.
 > 
 > mailto: urls with other than the few recognised encoded characters
 > currently
 > don't work in exmh; they are passed undecoded.
 > 
 > .) rfc2368, section 2 says that & must be treated specially 
 > if in html context, because a) it delimits the header components in the 
 > mailto scheme and b) html uses it as the character entity special
 > character.
 > 
 > (don't we all *love* mixing contexts and the associated quoting rules!
 > *yuck*)
 > 
 > rfc2368 says "use &amp;" - which confuses exmh badly, because the code
 > splits the url at the & characters. the alternative, using %26, doesn't
 > work as MsgDecodeURL doesn't substitute it (sofar).
 > 
 > suggestion: before splitting the url, why not subst all '&amp;'
 > occurrences by '%26', then doing the split and having MsgDecodeURL clean
 > up things later, when the semantic of & is no longer important.
 > 
 > regards
 > az
 > 
 > 
 > 
 > ------_=_NextPart_000_01C52300.F9AB1C40
 > Content-Type: text/plain;
 > 	name="04_exmhcomp.dpatch"
 > Content-Disposition: attachment;
 > 	filename="04_exmhcomp.dpatch"
 > 
 > #! /bin/sh /usr/share/dpatch/dpatch-run
 > ## 04_exmhcomp.dpatch by  <[email protected]>
 > ##
 > ## All lines beginning with `## DP:' are a description of the patch.
 > ## DP: add mailto: support to exmhcomp
 > 
 > @DPATCH@
 > diff -urNad exmh-2.7.2/exmhcomp /tmp/dpep.jFc3X1/exmh-2.7.2/exmhcomp
 > --- exmh-2.7.2/exmhcomp	Tue Mar  2 09:00:30 2004
 > +++ /tmp/dpep.jFc3X1/exmh-2.7.2/exmhcomp	Mon Mar  7 19:50:09 2005
 > @@ -16,6 +16,10 @@
 >      send exmh Msg_Compose
 >      exit 0
 >  } else {
 > -    send exmh Msg_CompTo $argv
 > +    if { 0 == [string first "mailto:" $argv 0] } {
 > +	send exmh Msg_Mailto $argv
 > +    } else {
 > +	send exmh Msg_CompTo $argv
 > +    }
 >      exit 0
 >  }
 

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]