search

pazz / alot

Terminal-based Mail User Agent
GNU General Public License v3.0
696 stars 164 forks source link

Fix utf8 encoding with a text/plain mailcap entry. #1526

Closed ryneeverett closed 4 years ago

ryneeverett commented 4 years ago

This seems to essentially revert 777823f414aab5dfa130174dc7c80cda8036d13f, the reasoning of which I don't yet follow.

This may resolve the issue in #1522.

pazz commented 4 years ago

I think that the email module's behaviour has changed since that ugly work-around was written, so good riddance. I'm surprised that our tests did not pick it up! Time for new tests?

ryneeverett commented 4 years ago

This issue only exists if one has a text/plain mailcap entry (which apparently is commonly included in distributions). This comes down to the logic of the change I made in #1477. If there is no text/plain mailcap entry then the behavior does not change at all. If there is a text/plain mailcap entry, after #1477 the mail gets encoded and written to a temporary file where it is read by the mailcap program. This encoding step is where the bug lies.

As was pointed out in #1522, the mock I added on the plaintext test prevents this issue from emerging by emulating the behavior as if there were no text/plain entry.

Not sure if you noticed but this commit does add a test of utf8 with a text/plain entry.

pazz commented 4 years ago

Thanks for the explanation. And yes, I did not notice the test :) I'll push this as is. Cheers,