Don't do rfc 2045 decoding on the mu4e html body

[jsravn]

It is not encoded, so this isn't necessary, at least in mu4e 1.4.x. Doing this corrupts the temporary HTML file that is saved.

Also add the tab indenting settings to the local file props.

Fix https://github.com/jeremy-compostella/org-msg/issues/46

[jsravn]

The mu4e reply function still needs some work - for example, the reply header isn't properly filled in. But this at least gets it working, if not perfectly.

[jeremy-compostella]

The mu4e reply function still needs some work - for example, the reply header isn't properly filled in. But this at least gets it working, if not perfectly.

Could you provide some details ?

[jsravn]

Okay, I will remove the indentation configuration. Like you said, dtrt-indent should pick this up. Regarding #19 I will have to dig. The html content is already decoded by mu4e, so I'm not sure why it is necessary to decode a second time (which I believe erroneously decodes certain html characters and causes this problem). I think mu4e uses gmime for this - perhaps the user had an older version which didn't handle certain characters properly?

[jsravn]

dtrt-indent seems to struggle to guess the indentation - I guess that's why I wasn't seeing proper indents (I have indent-tabs-mode set to nil similar to https://github.com/emacs-mirror/emacs/blob/master/.dir-locals.el). For now I'll just use local dir vars to fix it.

Guessing offset for /home/james/.emacs.d/.local/straight/repos/org-msg/org-msg.el

Elapsed time for analysis: 0.021 seconds

Total relevant lines: 562 out of 1151 (limit: 5000)

Histogram:

     1x   1 spaces
   172x   2 spaces
    26x   3 spaces
   140x   4 spaces
    17x   5 spaces
    63x   6 spaces
    29x   7 spaces
    39x   8 spaces
    15x   9 spaces
    16x  10 spaces
    17x  11 spaces
     7x  12 spaces
     5x  13 spaces
    10x  14 spaces
     2x  15 spaces
     3x  16 spaces

Analysis:

  offset 2 works for  80.07% of relevant lines, matching 8 distinct offsets - CONSIDERED
  offset 4 works for  33.63% of relevant lines, matching 4 distinct offsets - CONSIDERED
  offset 3 works for  20.11% of relevant lines, matching 5 distinct offsets - merged with offset 6 (7.65% deviation, limit 20.00%)
  offset 6 works for  12.46% of relevant lines, matching 2 distinct offsets - CONSIDERED
  offset 8 works for   7.47% of relevant lines, matching 2 distinct offsets - CONSIDERED
  offset 7 works for   6.94% of relevant lines, matching 2 distinct offsets - CONSIDERED
  offset 5 works for   6.23% of relevant lines, matching 3 distinct offsets - CONSIDERED

Summary:

  Best guess is offset 2 with 80.07% matching lines (80.00% required)
  Hard tab percentage: 49.47% (278 lines), -2.11% superior to soft tabs (threshold 300.00%)
  Soft tab percentage: 50.53% (284 lines), 2.16% superior to hard tabs (threshold 300.00%)

Conclusion:

  Guessed offset 2 with 80% confidence.
  Change indent-tab-setting: no

[jsravn]

The mu4e reply function still needs some work - for example, the reply header isn't properly filled in. But this at least gets it working, if not perfectly.

Could you provide some details ?

I have (setq org-msg-greeting-fmt "\nHi %s,\n\n"), but as you can see in this image it doesn't fill in the sender's name.

[jsravn]

I renamed the commit and dropped the indentation line. #19 puzzles me - the =3D (equals sign) wasn't decoded, but it looks like everything else was decoded correctly. That is very strange - it could have been a mu4e bug in an older version. Doing the quoted-printable decoding again breaks almost every HTML message I try to reply to. In #19 it probably only works to double decode because it is the equal sign itself that is not being decoded.

[jeremy-compostella]

The mu4e reply function still needs some work - for example, the reply header isn't properly filled in. But this at least gets it working, if not perfectly.

Could you provide some details ?

I have (setq org-msg-greeting-fmt "\nHi %s,\n\n"), but as you can see in this image it doesn't fill in the sender's name.

Hmmm. What is the value of (org-msg-get-to-first-name) ? If this is "", what is the value of (org-msg-message-fetch-field "to") ?

[jeremy-compostella]

I renamed the commit and dropped the indentation line. #19 puzzles me - the =3D (equals sign) wasn't decoded, but it looks like everything else was decoded correctly. That is very strange - it could have been a mu4e bug in an older version. Doing the quoted-printable decoding again breaks almost every HTML message I try to reply to. In #19 it probably only works to double decode because it is the equal sign itself that is not being decoded.

Do you mind making it a simple revert of the original patch e4185c9 ? This is better for code tracking.

[jsravn]

Do you mind making it a simple revert of the original patch e4185c9 ? This is better for code tracking.

Okay, done.

[jsravn]

Hmmm. What is the value of (org-msg-get-to-first-name) ? If this is "", what is the value of (org-msg-message-fetch-field "to") ?

• (org-msg-get-to-first-name) returns ""
• (org-msg-message-fetch-field "to") returns no-reply@amazon.co.uk

Okay, my mistake! I see there isn't a name on the reply-to.