Re: Sending attachments

[Stephen J. Turnbull]

Richard Stallman writes:

 >     Neither does Gnus (and probably MH-E, too).  Viewing inline
 >     vs. attachment can be toggled interactively or specified through
 >     `mm-inline-override-types'.
 > 
 > In theory, that kind of recommendation might be useful.
 > But in practice, since the readers decide heuristically

True, but shouldn't we focus on users of smarter readers, and on our
own use cases?  Most Emacs users don't use such dumb readers.  They
use Gnus or another advanced implementation which will normally
respect the recommendation.

 > whether to display inline, users mostly have no reason
 > to go out of their way to offer a recommendation.
 > It is better normally not to ask.

That may be true in many users' practice.  However, I find myself
offering a recommendation about 10-20% of the time, because I disagree
with the default.  For example, some projects include images.  I
generally do not want a new version of an image displayed in the
buffer, I want it saved to the project tree.  But when I'm sending
mail to a local users' group of the last meeting with pix of
somebody's system, I often do want it inlined.  I've been asked how I
do that by non-Emacs users on several occasions, so I know that there
are readers out there that do respect this header.

Patches are another example.  Sometimes patches are intended to be
reviewed, but discouraging cut and paste from mail buffers (of
non-Emacs MUAs) is a good idea since they often munge the text of both
patches and 

Sure, the user can (if they're lucky or wilful enough to be using a
good MUA like Gnus) toggle the display or save an inlined attachment
to a file if they want.  But it takes me ~0.2 seconds (1 keystroke) to
accept the default 80% of the time when it really doesn't matter, ~1
second (1 keystroke) to accept the default when it matters, and ~2
seconds (2 keystrokes with completion) to change it.

I think that's a small cost to advertise this feature, and give the
expert user the option by default.

I realize that there are users with disabilities etc such that the
cost is much higher.  However, I suggest they may be better served by
a feature that evaluates the quality of the default offered, and short
circuits the question when the program is "pretty sure" the default is
correct.  Eg, I don't think anybody really would want tar.gz displayed
inline by default.  Ditto large PDFs.

It would also be possible to specify a customizable alist of MIME
types with values 'attachment or 'inline, allowing the user to specify
ones that should automatically be given a particular disposition.
Something like that must already be part of MML, although if it's
customizable I didn't find it.

This may be way more complex than you would like, of course.

Thing is, that complexity is going to pop up at every turn as you
develop these features.