> Peter S Galbraith <[email protected]> writes: > > > The patch applies fine, and queries interactively correctly with a bug > > report against the apt package, but the info is not entered as mime > > attachments for me using mh-e. > > Thanks for looking into this! Right, I've mostly used Gnus and Message > mode when testing this patch, even though initially I think I tested it > with the other MUAs too. Now I've checked with mh-e also, and I see > the two problems.
Thanks for getting back to me so promptly. > > The problem is two-fold. First, I would change: > > > > (when (and (boundp 'mml-mode) mml-mode) > > to: > > (when (boundp 'mml-mode) > > > > and " disposition=inline" to " disposition=attachment" > > > > e.g. don't limit to mml-mode, and use "attachment" instead of "inline". > > > > Any downside to that for other MUAs that you can think of? > > I don't quite remember how I came up with that test, but I think the > idea was to check whether the MUA supports embedding MIME parts using > MML. Gnus and Message mode enables mml-mode by default, but apparently > mh-e doesn't even though it supports MML. So it seems not sufficient to > check if mml-mode is true. > > Also, I don't perhaps think testing (boundp 'mml-mode) is robust enough, > because the mml library could be loaded, although maybe unlikely, even > when using an MUA that doesn't support MML. You are quite right. > I've attached a new patch, slightly modified according to the > above suggestion, and which uses disposition=attachment instead > of disposition=inline. That's great, thanks! > > Second, the search for mml directives is too restrictive in mh-e in > > `mh-mml-tag-present-p'. I get: > > > > Debugger entered--Lisp error: (error "Stack overflow in regexp matcher") > > I see, mh-e doesn't seem to cope with text inserted between > the #part ...> and #/part> elements. I can't see the error Hmmm. Had to delete the leading < characters because it was also confusing MH-E mml directive detection... > message though, but when the mail is sent the MML part is just > sent as is and not translated to MIME as it should. (Hmm, incidentally > it seems this problem only occurs when the message buffer is entirely > ASCII, since the call to mh-ascii-buffer-p in mh-send-letter ensures > that buffers with other encodings are properly MIME encoded.) Right... > > I think just finding the beginning should be enough, and I can patch > > mh-e for that. The alternative is saving the attachment in a tmp file > > and referencing that file in the mml construct. > > If you can patch mh-e I think that's the best solution, because relying > on the temporary file with the bug script output can be problematic if > the user decides to postpone sending the report. The temp file could be > gone when the user finally decides to send it, for example after a > reboot. This also means that we're unable to clean up by removing the > temporary file, because we can't easily determine when it's not needed > anymore, but that's admittedly only a minor annoyance. I suppose you are right about the temporary file. Yeah, I can fix MH-E since I am both it's Debian Maintainer and am in the upstream team (although I haven't contributed there in a few years...) Thanks! Peter -- Peter S. Galbraith, Debian Developer <[email protected]> http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
