On Sun, Aug 23, 2026 at 12:46:34PM +0200, Oswald Buddenhagen via Mutt-dev wrote:
On Sun, Aug 23, 2026 at 05:41:38PM +0800, Kevin J. McCarthy wrote: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.are you sure? was this always the case?
I can't speak to always, but since I've been involved it's been like that.
When first composing a new email, unless you use <get-attachment>, Mutt points directly at an attachment. The prompt is actually asking whether to run mutt_update_encoding(). You can see this in compose.c L530 (in master branch). That function scans the attachment, but it only updates mutt's data structures. It doesn't touch the attachment at all.
The encoding take place until you *send* the message, or alternatively, *postpone* it.
i deduced the postulated behavior from the fact that postponed messages do actually include an encoded copy. this is consistent with a past bug where they were losing the links to the original files, and things continued to mostly work.it would be rather surprising if fresh drafts would behave this differently from recalled ones.
Recalled postponed messages decode the message parts into new files, which are saved in $tmpdir. The "links" then point to those instead of to the original attachments on the filesystem. So yes, they are behaving differently from when you initially composed the message. It's, in effect, as if you had called <get-attachment> on all your attachments.
well, if you are right, then it actually hasn't, and i unintentionally sent updated files a few times.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.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?Thanks for the confirmation that it's worked for you regularly.
:-( It may have been the case. If someone who has been using mutt as you have were confused, then it seems like there is room for improvement in the interface or manual,
i'm actually not trying to be funny at all; i've noticed a long time ago that this just doesn't work with you.there is some serious disconnect with reality in these paragraphs.I'll charitably assume that was a lame attempt at humor on your part.i originally had written "?!?", because things just didn't connect. i may have to expand the scope of "these" to include my own paragraphs.
I see. I misunderstood your statement to say that I was babbling nonsense. I know my writing isn't always the clearest or articulate, but I was a bit surprised.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
