On Sun, Aug 23, 2026 at 04:45:48PM +0800, Kevin J. McCarthy wrote:
On Sun, Aug 23, 2026 at 08:46:52AM +0200, Rene Kita wrote:
I can't remember I ever saw that message, but I don't quite get it:
Attachment #2 modified. Update encoding for /tmp/f? ([yes]/no):
This is after an 'echo a >> /tmp/f'. Why "Update encoding"?
Mutt scans the attachment to determine whether to use 7-bit, 8-bit, QP,
or Base64 encoding. It wants to make sure the encoding is still
appropriate. This can also manually be edited via ^E <edit-encoding> in
the compose menu.
It also scans text types to determine the charset to be used.
but that's not what this is referring to.
it's asking whether to update the mime-encoded copy in the draft
message. it's an overly technical formulation.
I wonder what behaviour people would expect these days, when attaching
a file is it a link to the current version or a snapshot of the file when
it was attached?
the current behavior is just fine. i regularly trigger it by modifying
files after i already scheduled them for attaching. and while i usually
want to update the attachment, this isn't always the case.
By default it points directly at the attachment, but you can use
<get-attachment> to copy it to tmpdir, to prevent updates from touching
mutt's version.
I'd guess it is the former. So I'd say that the reason
that no one reported an issue might that people don't expect it and
never notice. I don't look at the attachments in my +Sent.
Yeah, they might not. The receiver might notice if the encoding was
wrong for a text attachment that suddenly had 8-bit chars added. I
agree though, this is hard to say.
there is some serious disconnect with reality in these paragraphs.
