On Sun, Aug 23, 2026 at 11:14:43AM +0200, Oswald Buddenhagen via Mutt-dev wrote:
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.

The message/attachment is not encoded yet. It's scanning to determine how it will be encoded when it's sent.

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.

Thanks for the confirmation that it's worked for you regularly.

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.

The paragraphs were saying that the sender might not notice because they didn't check. The receiver might notice, but not in all cases (e.g. just flipping qp to base64). So it's hard to say how effective the check has been..

I'll charitably assume that was a lame attempt at humor on your part. It wasn't funny though.

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

Attachment: signature.asc
Description: PGP signature

Reply via email to