Is it possible to set a length-limit for html-emails to render in mu4e?

46 views
Skip to first unread message

henkjan gersen

unread,
Jan 18, 2017, 12:16:39 PM1/18/17
to mu-di...@googlegroups.com
I'm currently using the shr-renderer to display html format emails,
which I find works faster and better than W3M with Emacs 25.1 & mu
0.9.18.

The problem is that I receive some very long html formatted
content-alerts (Scientific Reports). When these get selected in the
header-view freeze up emacs will freeze up for many seconds. One of
those emails which is just text and URL-links is 1.3M in size and a
bit over 2000 lines long!

GMail gets around this problem of everything freezing by limiting the
total length of an email that get rendered when selecting in the
header list. Is there an option or suggested way to do something
similar and prevent shr to render this type of enormously long
html-emails and for example just suggest to open in browser instead?

Best wishes,
Henkjan Gersen

Dirk-Jan C. Binnema

unread,
Jan 24, 2017, 11:58:28 AM1/24/17
to mu-di...@googlegroups.com
Hi Henkjan,
You could create a function for `mu4e-html2text-command' to do something
like that. That might however be a bit tricky... until now!

I've reworked the code a bit, so now (mu4e git), you can define a
function like this:

--8<---------------cut here---------------start------------->8---
(defun my-mu4e-html2text (msg)
"My html2text function; shows short message inline, show
long messages in some external browser (see `browse-url-generic-program')."
(let ((html (or (mu4e-message-field msg :body-html) "")))
(if (> (length html) 20000)
(progn
(mu4e-action-view-in-browser msg)
"[Viewing message in external browser]")
(mu4e-shr2text msg))))

(setq mu4e-html2text-command 'my-mu4e-html2text)
--8<---------------cut here---------------end--------------->8---

Not sure if that exactly does what you want, but should be a good
starting point.

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Henkjan Gersen

unread,
Jan 27, 2017, 2:12:36 PM1/27/17
to mu-discuss
Many thanks for that change in the code Dirk! This works very nicely as with this change mu4e no longer hangs for 20-30 seconds on very long html messages and that code example is easy to adapt to how I use this.

btw) On these extremely long messages it still takes ~5 before the [viewing ..] message pops up with my maildir on an SSD, but for most others this is very fast indeed. These insanely long emails are an exception so really not something to worry about.

Best wishes,
Henkjan

Dirk-Jan C. Binnema

unread,
Jan 28, 2017, 6:07:25 AM1/28/17
to mu-di...@googlegroups.com

On Friday Jan 27 2017, Henkjan Gersen wrote:

> Many thanks for that change in the code Dirk! This works very nicely as
> with this change mu4e no longer hangs for 20-30 seconds on very long html
> messages and that code example is easy to adapt to how I use this.
>
> btw) On these extremely long messages it still takes ~5 before the [viewing
> ..] message pops up with my maildir on an SSD, but for most others this is
> very fast indeed. These insanely long emails are an exception so really not
> something to worry about.

Hmmm, that must be really big messages then... can you see where the
slowness is? I.e., is it in firing up a browser or something inside
emacs?

Kind regards,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl

Henkjan Gersen

unread,
Jan 29, 2017, 3:44:04 AM1/29/17
to mu-discuss

Hmmm, that must be really big messages then... can you see where the
slowness is? I.e., is it in firing up a browser or something inside
emacs?

These are insanely big indeed as one of those emails is 1.3M in size and that is with just text and URL-links. The delay in opening is in emacs itself as it displays "Waiting for message.." for six or seven seconds before displaying "[Viewing message in external browser]".

I have disabled the automatic opening in the browser, so that doesn't play a role in the delay itself.
Reply all
Reply to author
Forward
0 new messages