GNU bug report logs - #19202
Suggestions for mml-attach-file

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: dieter <at> duenenhof-wilhelm.de (H. Dieter Wilhelm)
Cc: 19202 <at> debbugs.gnu.org
Subject: bug#19202: Suggestions for mml-attach-file
Date: Wed, 25 Jan 2017 21:53:07 +0100

Sorry for the late response; the bug report has been sitting in a part
of the bug tracker that nobody has looked at due to a misunderstanding.

dieter <at> duenenhof-wilhelm.de (H. Dieter Wilhelm) writes:

> would you mind to enhance the mml-attach-file command so that it doesn't
> ask interactively for Type, Description and Disposition?  I'm mostly
> happy with your defaults for them and it is becoming annoying to type,
> especially for multiple attachments, RET RET RET all the time.

Yes, I agree.  In almost all the cases it guesses correctly, and if
there's anything I want to change (say "inline" to "attachment"), then I
can just edit the MML tags inserted.  That requires some expert
knowledge, though, so I'm not quite sure that everybody would be happy
with such a change...

> What do you think of an optional prefix argument of C-c C-a for
> triggering the queries?  Or making two distinct commands: C-c C-a and
> C-c RET f where the latter is querying by default and the former not?

Hm...  Or perhaps `C-u C-c C-a' would avoid all the prompts?  That would
be backwards-compatible...

> It might also be helpful if the disposition could be guessed somehow.
> For example for well know image file suffixes as inline MIME.

I think it already guesses the disposition?

(mml-content-disposition "image/png")
=> "attachment"

But it defaults images to attachment.  I'm not sure...  do people
usually want images to be inline or attachments?  I'm not attached (heh
heh) to the current defaults...

Does anybody have opinions here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.