On Mon, 2004-09-13 at 12:35 -0700, Eric Ewanco wrote: > --- Jeffrey Stedfast <[EMAIL PROTECTED]> wrote: > > > the rationale is: > > > > - if it's not sent by you, then you shouldn't be > > editing it > > Hmmm. Ok, I'm trying to understand the concerns here. > Now, obviously, you'd want to use the (new) sender's > outgoing address -- we are not talking about forging a > message. What we're basically talking about is like > an inline forward, only without including the headers, > and with the destination filled in with the original > destination (and no "[Fwd:]" prepended to the > subject). You can accomplish mostly the same thing by > dropping a copy of the message into the Drafts folder > and bringing it up, or cut and pasting (and > saving/reattaching the attachments) (although the > latter may lose formatting). > Would you have an objection to doing any of these > things as well? I guess I'm still not understanding > why it is "wrong" to use a message you've received > from someone else as a template for a new message, > especially when it's not hard to do without "Edit As > New", just more inconvenient.
this is what "Redirect" is for.
>
> > - evolution's composer is not capable of handling
> > all mime structures
> > (it's an impossible task)
>
> Ok, that sounds like a fairly compelling reason. I
> can understand that someone might have decided a while
> ago, "We don't have the resources to handle this
> properly in all cases, therefore we will only edit
> messages which we composed" (although, there is the
> hole of copying a message to the drafts folder).
>
> Maybe I just need to make sure Evolution gracefully
> ignores mime types it can't handle.
*sigh*. it has nothing to do with mime-types and everything to do with
structure
Evolution's composer can only create the following structures:
text/plain
multipart/alternative
text/plain
text/html
multipart/mixed
text/plain
application/octet-stream
...
multipart/mixed
multipart/alternative
text/plain
text/html
application/octet-stream
...
it can also generate any of the above 4 wrapped inside
multipart/encrypted and/or multipart/signed
however, it cannot represent (for example):
multipart/mixed
multipart/alternative
text/plain
text/html
multipart/mixed
multipart/mixed
text/x-patch
application/octet-stream
image/png
multipart/signed
multipart/mixed
text/plain
message/rfc822
application/pgp-signature
are you starting to grasp what I mean?
Evolution's composer can pretty much only handle:
- a message body
- attachments
- with the option to sign/encrypt only the entire message
it cannot handle nested multiparts (with the exception of the few cases
listed above)
>
> > also, there exists an option
> > Actions->Forward->Redirect for at least
> > some of the needs you brought up.
>
> Yeah but it won't let you change it, which, in many
> cases, is the whole point.
I feel you are approaching this problem from the wrong direction then.
this is precisely what the Drafts/Templates (not-yet-implemented)
folders are for.
I suggest you implement Template folders instead.
Jeff
--
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED] - www.novell.com
smime.p7s
Description: S/MIME cryptographic signature
