How to toggle between text and HTML view?

129 views
Skip to first unread message

Martin

unread,
Jan 2, 2024, 11:51:53 AM1/2/24
to mu-di...@googlegroups.com
Dears,

how can toggle different views (HTML, richtext, text) of alternative
email parts in mu4e 1.10.8? I had hoped, `mu4e-view-toggle-html` would
do that, but it only messages me: "This is a pseudo-article".

I do not want to disable HTML etc. permanently, but change to text view
now and then. Any help appreciated!

Cheers


Christophe Troestler

unread,
Jan 2, 2024, 12:19:03 PM1/2/24
to Martin, mu-di...@googlegroups.com
Hi,

On 2 January 2024 at 17:51 +01, Martin <deb...@debian.org> wrote:
> […] how can toggle different views (HTML, richtext, text) of
> alternative email parts in mu4e 1.10.8? I had hoped,
> `mu4e-view-toggle-html` would do that, but it only messages me: "This
> is a pseudo-article".

Normally, at the beginning of each multipart message, you have a line such as:

--8<---------------cut here---------------start------------->8---
1. ( ) text/plain (*) text/html
--8<---------------cut here---------------end--------------->8---

You can click on the option of your choice.

Best,
C.

Martin

unread,
Jan 2, 2024, 3:03:57 PM1/2/24
to Christophe...@umons.ac.be, mu-di...@googlegroups.com
On 2024-01-02 18:18, Christophe Troestler wrote:
> Normally, at the beginning of each multipart message, you have a line such as:
>
> 1. ( ) text/plain (*) text/html

It looks different here:

Attachment: [2. text/plain]...

But a click (or pressing RET) on "text/plain" toggles the view, indeed!

Thanks!

Hong Xu

unread,
Dec 8, 2024, 10:00:43 PM12/8/24
to mu-discuss
Is there a way to bind this to a key?

Sorry for reviving this thread, but it is quite highly ranked in Google search and I think the followup is likely interesting to many readers coming here.

Hong

Dirk-Jan C. Binnema

unread,
Dec 9, 2024, 3:03:51 PM12/9/24
to mu-di...@googlegroups.com
I've added mu4e-view-jump-to-mime-part (bound to 'J') in master.

So I guess you can do something like

M-1 J RET RET

for a typical text/html mail to toggle between the two.

If you use that a lot, a keyboard-macro can be handy; but I don't want
to further automate it in mu4e at this point until it's clear when it
works and when it doesn't, since we're depending on the Gnus machinery
for this, which was not written for mu4e.

Kind regards,
Dirk.

--
DIRK-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Hong Xu

unread,
Dec 19, 2024, 5:20:36 PM12/19/24
to Dirk-Jan C. Binnema, mu-di...@googlegroups.com
On 2024-12-09 Mon 12:03 GMT-08, "Dirk-Jan C. Binnema" <dj...@djcbsoftware.nl> wrote:

> On Sunday Dec 08 2024, Hong Xu wrote:
>
>> On Tuesday, January 2, 2024 at 12:03:57 PM UTC-8 Martin wrote:
>>
>> On 2024-01-02 18:18, Christophe Troestler wrote:
>>> Normally, at the beginning of each multipart message, you have a line
>> such as:
>>>
>>> 1. ( ) text/plain (*) text/html
>>
>> It looks different here:
>>
>> Attachment: [2. text/plain]...
>>
>> But a click (or pressing RET) on "text/plain" toggles the view, indeed!
>>
>>
>> Is there a way to bind this to a key?
>>
>> Sorry for reviving this thread, but it is quite highly ranked in Google
>> search and I think the followup is likely interesting to many readers
>> coming here.
>
> I've added mu4e-view-jump-to-mime-part (bound to 'J') in master.
>
> So I guess you can do something like
>
> M-1 J RET RET
>
> for a typical text/html mail to toggle between the two.
>
> If you use that a lot, a keyboard-macro can be handy; but I don't want
> to further automate it in mu4e at this point until it's clear when it
> works and when it doesn't, since we're depending on the Gnus machinery
> for this, which was not written for mu4e.

Thank you for the new function.

This is what I ended up using in my config:

;; Quickly switching between plain text/html mime type.
(keymap-set mu4e-view-mode-map (kbd "K")
(lambda ()
(interactive)
(gnus-article-jump-to-part 1)
(gnus-article-press-button)
(gnus-article-press-button)))

Yuri D'Elia

unread,
Dec 20, 2024, 5:19:29 AM12/20/24
to mu-di...@googlegroups.com
On Tue, Jan 02 2024, Christophe Troestler wrote:
> Normally, at the beginning of each multipart message, you have a line such as:
>
> --8<---------------cut here---------------start------------->8---
> 1. ( ) text/plain (*) text/html
> --8<---------------cut here---------------end--------------->8---
>
> You can click on the option of your choice.

Excuse me for hijacking this thread :D

I'd just put a comment here that I'm not superfond of how this looks,
although I vaguely remember a discussion in github of the implementation
details about it...

I wish this was hidden, with a keybinding for toggle at best, since this
is effectively visual noise in 99.9% of the cases. (I'm guilty of not
trying to fix it myself, I know some properties to hide it would do.. I
know...)

My reasoning is that at some point shr got good enough, and email
clients such as outlook started to emit text/plain which is SOO
OUTRAGEOUSLY BAD, that essentially I stopped caring about text/plain
completely. shr output just became superior, always.

Once in a while i do toggle views, just to be reminded of how far we've
fallen in netiquette :'(

Joost Kremers

unread,
Dec 20, 2024, 5:40:33 AM12/20/24
to 'Yuri D'Elia' via mu-discuss
On Fri, Dec 20 2024, 'Yuri D'Elia' via mu-discuss wrote:
> On Tue, Jan 02 2024, Christophe Troestler wrote:
>> Normally, at the beginning of each multipart message, you have a line such as:
>>
>> --8<---------------cut here---------------start------------->8---
>> 1. ( ) text/plain (*) text/html
>> --8<---------------cut here---------------end--------------->8---
>>
>> You can click on the option of your choice.
>
> I wish this was hidden, with a keybinding for toggle at best, since this
> is effectively visual noise in 99.9% of the cases.

I disagree. I have text/plain as default, and this line is often the only
indication that there is an HTML version of the email available. So, yes,
visually, it's unappealing and Emacs nowadays has the ability to make it
look much nicer, but I don't think it should be hidden by default.

> My reasoning is that at some point shr got good enough, and email
> clients such as outlook started to emit text/plain which is SOO
> OUTRAGEOUSLY BAD, that essentially I stopped caring about text/plain
> completely. shr output just became superior, always.

That's not my experience, unfortunately. Perhaps the HTML mail I get
doesn't come from Outlook, I don't know, but I find the HTML version
unusable sometimes, even up to the point where I can't seem to activate
links...

What I don't understand, though, is why all this talk about how to toggle
the view. In `mu4e-view-mode`, `h` is bound to `mu4e-view-toggle-html` by
default.


--
Joost Kremers
Life has its moments

Yuri D'Elia

unread,
Dec 20, 2024, 6:59:11 AM12/20/24
to mu-di...@googlegroups.com
On Fri, Dec 20 2024, Joost Kremers wrote:
> I disagree. I have text/plain as default, and this line is often the only
> indication that there is an HTML version of the email available. So, yes,
> visually, it's unappealing and Emacs nowadays has the ability to make it
> look much nicer, but I don't think it should be hidden by default.

There is the Attachment: part still, but I see the point indeed. It's
not nice to have the actual content mixed within the attachments list.

> That's not my experience, unfortunately. Perhaps the HTML mail I get
> doesn't come from Outlook, I don't know, but I find the HTML version
> unusable sometimes, even up to the point where I can't seem to activate
> links...

oh well, I didn't say it was perfect. But just to pick the latest
example I've got on hands.. ryanair notifications have both text/html.
The html is a horrid mess, exactly as you would expect. And the text?
Well, it's html too.

> What I don't understand, though, is why all this talk about how to
> toggle the view. In `mu4e-view-mode`, `h` is bound to
> `mu4e-view-toggle-html` by default.

Been so long that I didn't use it I forgot it existed, but at least on
current emacs + current mu (rebuilt from master that is), it doesn't
work for me. I get "This is a pseudo-article" message, and nothing
happens... (didn't check why).

Dirk-Jan C. Binnema

unread,
Dec 20, 2024, 11:33:15 AM12/20/24
to mu-di...@googlegroups.com
On Friday Dec 20 2024, 'Yuri D'Elia' via mu-discuss wrote:

> On Tue, Jan 02 2024, Christophe Troestler wrote:
>> Normally, at the beginning of each multipart message, you have a line such as:
>>
>> --8<---------------cut here---------------start------------->8---
>> 1. ( ) text/plain (*) text/html
>> --8<---------------cut here---------------end--------------->8---
>>
>> You can click on the option of your choice.
>
> Excuse me for hijacking this thread :D
>
> I'd just put a comment here that I'm not superfond of how this looks,
> although I vaguely remember a discussion in github of the implementation
> details about it...
>
> I wish this was hidden, with a keybinding for toggle at best, since this
> is effectively visual noise in 99.9% of the cases. (I'm guilty of not
> trying to fix it myself, I know some properties to hide it would do.. I
> know...)

We're re-using the Gnus code for this and to be able to get information
for all attachments / inline / mime-parts etc. we need to enable some
things; which have the visual side-effect shown above; this is not
really under our control (without some hackery).

Now, one way to do it would be generate the "full" version in some
hidden buffer, and showing the civilized one, while using that hidden
buffer to extract information. But that's a bit of work, which might
happen some day...

> My reasoning is that at some point shr got good enough, and email
> clients such as outlook started to emit text/plain which is SOO
> OUTRAGEOUSLY BAD, that essentially I stopped caring about text/plain
> completely. shr output just became superior, always.
>
> Once in a while i do toggle views, just to be reminded of how far we've
> fallen in netiquette :'(

To always prefer HTML mail, you could try something like

--8<---------------cut here---------------start------------->8---
(with-eval-after-load "mm-decode"
(setq mm-discouraged-alternatives '("text/plain" "text/html")))
--8<---------------cut here---------------end--------------->8---

However, that precludes easy switching to the plain-text version.

Kind regards,
Dirk.


--
Dirk-Jan C. Binnema Helsinki, Finland
Reply all
Reply to author
Forward
0 new messages