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 &" - 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 '&'
> 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]