[Alpine-info] links contained in forwarded emails.

[Mike Miller]

My idea was a little different than what Goeffrey, Joshua and Eduardo have 
been discussing.  I would just want the alternative HTML of the message 
being forwarded to be included as an attachment (multipart) of the 
forwarded message, not as an alternative form of the message body.

To achieve that with Alpine as it is, I have to view the attachments, save 
the HTML to a file, initiate forwarding of the message, then attach the 
HTML to the message before sending.  Why not make it an option to have 
that happen automatically whenever a message is forwarded?

Is there something wrong with that idea?

Mike


On Sat, 26 Nov 2011, Geoffrey Thomas wrote:


> On Sat, 26 Nov 2011, Joshua Miller wrote:

>

>> Anyway... I'm back to saying I think the answer lies in support for 

>> creating and sending multipart/alternative messages (of text/plain and 

>> text/html). This can simply be some flag that says what one is editing is 

>> HTML - no need for a built in WYSIWYG editor (allow them to use alternative 

>> editors for that), and then use alpines built in HTML rendering (or, via 

>> option, an external filter, such as w3m -dump) to make the text/plain part. 

>> Alpine would have to recognize the new header (multipart/alternative) and 

>> respect it. That *should* solve the forwarding problem, and add a very 

>> handy feature.

>

> So are you proposing that, in the absence of an external editor, the composer 

> window should show raw HTML?

>

> While you're right about editing the HTML and rendering that down to plain 

> text being the "right" approach, given alpine's constraint as a 

> terminal-based editor, that seems close to unusable: the HTML being forwarded 

> is often going to be pretty horrendous. For the example I gave, redacting 

> some private info or a paragraph you don't want to forward, it seems 

> difficult to believe that anyone's going to be able to find that info, let 

> alone edit the HTML and keep it formatting properly (avoid forgetting some 

> close tag, etc.).

>

> This is why I'd dismissed the possibility out of hand, and assumed that the 

> composer was only ever going to do plain text for us. Sorry for not being 

> clear on that point. As Eduardo just mentioned, the composer becoming a rich 

> HTML editor is also an option, but seems infeasible.

>

> I also think that it's not particularly useful to have a feature that more or 

> less requires an external editor to be useful, but maybe it is? To be honest, 

> I'm not even sure what external editor I would use for this -- I can't think 

> of either a command-line or GUI program that's good at quick HTML editing in 

> this way and would be less painful to use than just using e.g. Thunderbird.

>

> -- 

> Geoffrey Thomas

> http://ldpreload.com

> geofft at ldpreload.com

>