djcb / mu

maildir indexer/searcher + emacs mail client + guile bindings
http://www.djcbsoftware.nl/code/mu
GNU General Public License v3.0
1.61k stars 390 forks source link

[mu4e rfe] Support HTML width parameter #2188

Closed moyamo closed 2 years ago

moyamo commented 2 years ago

Describe the bug

A clear and concise description of what the bug is

When I upgraded mu4e I noticed that the lines in HTML emails were very long. This seems to be caused by the GNUS based mu4e-view to ignore the shr-width variable. Setting shr-width to 80 tells shr to render HTML emails as if the "viewport" is only 80 columns wide (or something like that).

what you expected to happen

In the GNUS-based mu4e-view HTML emails should be wrapped at 80 columns when shr-width is set to 80 like in the just like in the old mu4e-view.

This is how HTML emails look in the old mu4e-view:

old mu4e-view with (setq shr-width 80)

what actually happened.

The GNUS-based mu4e-view HTML emails are not wrapped even though shr-width is set to 80

gnus-based mu4e-view with (setq shr-width 80)

To Reproduce

Any HTML message with long paragraphs.

Environment

Checklist

djcb commented 2 years ago

Would be nice to support that, indeed. But the value to track would probably be gnus-html-frame-width. Anyway, patch would be welcome.

moyamo commented 2 years ago

the value to track would probably be gnus-html-frame-width.

So gnus-html-frame-width is in gnus-html.el which doesn't seem to be loaded in my emacs ((featurep 'gnus-html) returns nil). Adding (require 'gnus-html) (setq gnus-html-frame-width 80) to my init.el didn't help. As far as I can tell gnus-html-frame-width is used for the w3m backend not the shr backend. Am I missing something?

Anyway, patch would be welcome.

I'm more than happy to try to fix this myself. I'm just a bit stumped as to what is going wrong. My understanding is the mu4e-view is using gnus-art which is rendering using shr which can be configured using the shr-width parameter. So there is some bug in mu4e that's causing shr to not respect shr-width.

I see you've changed this from a bug to a enhancement. Is there something wrong in my understanding (e.g. are we not using shr or gnus-art or something)?

(although it could be a bug in gnus-art, but I searched the emacs bug tracker and no one seems to have reported anything...)

thierryvolpiatto commented 2 years ago

Yaseen Mowzer @.***> writes:

  1. ( ) text/plain (*) text/html

    the value to track would probably be gnus-html-frame-width.

So gnus-html-frame-width is in gnus-html.el which doesn't seem to be loaded in my emacs ((featurep 'gnus-html) returns nil). Adding (require 'gnus-html) (setq gnus-html-frame-width 80) to my init.el didn't help. As far as I can tell gnus-html-frame-width is used for the w3m backend not the shr backend. Am I missing something?

Anyway, patch would be welcome.

I'm more than happy to try to fix this myself. I'm just a bit stumped as to what is going wrong. My understanding is the mu4e-view is using gnus-art which is rendering using shr which can be configured using the shr-width parameter. So there is some bug in mu4e that's causing shr to not respect shr-width.

Remember when fixing this that not everybody use shr (I don't for one).

-- Thierry

djcb commented 2 years ago

So, yeah, that was idea -- gnus-html-frame-width as the backend-independent value... but looking at the code it seems to be only used for w3m.

Anyway, when I check with the long-line message from github for this very issue, and switch to html-mode (h), it's rendered 80 cols (or whatever). Can you attach an example message that's not rendering correctly for you?

moyamo commented 2 years ago

I don't think it depends on the email. But here is the message you just sent: email_from_maildir.txt; and this is how it renders for me rendering of email from maildir

and switch to html-mode (h)

So interestingly when it's defaulting to html-mode for me and when I press h, in *Messages*, I get:

gnus-summary-select-article: This is a pseudo-article

I wonder if that's related.

moyamo commented 2 years ago

Okay, I don't think this is a bug in mu4e anymore. This seems to be an issue in emacs/gnus. This line https://github.com/emacs-mirror/emacs/commit/656caef3505e11b073d59b9c18d3fd21e199d77c#diff-c58d725eb12503fac78cea9c7b0d539db6483f6dc7e8d6c6d08c485d435db93fR1826 sets shr-width to nil if shr-use-fonts is t (shr-use-fonts is t by default https://github.com/emacs-mirror/emacs/commit/26d87ff86c4c64a8ca45bca1bbfd467b2c063a86).

@larsmagne Do you remember why you set shr-width to nil here?

larsmagne commented 2 years ago

Yaseen Mowzer @.***> writes:

@larsmagne Do you remember why you set shr-width to nil here?

Sorry -- this is a change from 2015? I don't recall.

Chris00 commented 2 years ago

Does it have to do with the fact that proportional fonts are usually used with shr?

moyamo commented 2 years ago

I sent a patch to upstream Emacs. I'm going to close this issue, since it isn't a bug with mu4e.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52825