Sending attachments

[Chong Yidong]

Richard Stallman <rms@...> writes:

> What I want to do is install Etach.  Specifically, the part of Etach
> that creates mime attachments.  This would provide the facility of
> sending attachments in Mail mode, but without any actual change to
> sendmail.el.

Since there is existing, actively-maintained code in Emacs for sending
attachments, it's incorrect to add yet another library for this.
Assuming the status quo, with mail-mode and message-mode separate,
adding mime functionality to mail-mode should involve calling this
existing code.

> message.el forces the loading of many other packages (I sent the list
> before).  So its effective complexity includes all of them.  It is
> tied in with Gnus, and can't be maintained on its own.

Message mode is actively maintained by the Gnus maintainers, so this
point is irrelevant.  And there is no other salient objection to message
mode, as far as I can tell.

[Chong Yidong]

"Alfred M. Szmidt" <ams@...> writes:

> Please, lets drop this discussion.  Richard volunteered to maintain
> mail-mode, so do I, and Eli I suspect will be more than happy to do it
> as well.

The problem is that further development of mail-mode will likely involve
adding code that directly duplicates the existing code used in message
mode, with inferior results (e.g. mml vs etach).

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: cyd@..., rms@..., emacs-devel@...
> Date: Tue, 07 Jul 2009 13:54:25 +0900
>
> Eli Zaretskii <eliz@...> writes:
> >> How, exactly, is message-mode an "imposition" on "people who are happy
> >> with simple modes"?
> >
> > If you insist on everyone switching to message-mode and making
> > mail-mode obsolete, you are imposing message-mode on them.
>
> "imposition" is pejorative

So is ``leaky bandaids''.

> > This old fart simply doesn't want to learn a new mode unless it's
> > absolutely necessary.  Is this so hard to understand?
>
> What if the new mode is effectively indistinguishable from the old mode?

My gray hair says there ain't no such thing.  If it's more powerful
and sophisticated, there's some price to pay.

[Richard Stallman]

    > message.el forces the loading of many other packages (I sent the list
    > before).  So its effective complexity includes all of them.  It is
    > tied in with Gnus, and can't be maintained on its own.

    Message mode is actively maintained by the Gnus maintainers, so this
    point is irrelevant.

It is not a good thing that message mode can only be maintained by the
Gnus maintainers.

[Richard Stallman]

    > Etach has a convenient interface M-x attach which attaches a file in
    > the message in the current buffer.

    As does MML (mml-attach-file).

It isn't in the emacs-mime manual so I did not know about it.  I tried
it just now.  It asked me a lot of questions and then inserted this
text.

<#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
<#/part>

I suppose this is MML and needs to get converted later.
However, when I sent the message with C-c C-c, it did not convert.
I don't see that it set up any hook to do so.

After a lot of searching thru that manual I found the function
mml-to-mime.

If mml-to-mime were put on a hook so that C-c C-c would call it, this
feature would be usable.  A suitable front-end to mml-attach-file
could avoid asking all the annoying questions.  It would only be
necessary to document it.

However, that hook could also cause trouble, since it might
trigger by accident when users did not intend it.

Another drawback, compared with etach-detach, is that you don't see
what is really going to appear in the message.

[Richard Stallman]

I can adapt and install Handa's code.  Before I do,
does anyone see a problem with the change he proposes?

[Andreas Schwab-2]

Richard Stallman <rms@...> writes:

> Another drawback, compared with etach-detach, is that you don't see
> what is really going to appear in the message.

That's what mml-preview is for.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Jason Rumney-4]

Richard Stallman wrote:
> <#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
> <#/part>
>  

> A suitable front-end to mml-attach-file
> could avoid asking all the annoying questions.

It is probably reasonable to use a type of application/octet-stream,
disposition of attachment and have no description for simple
attachments.  So the only absolutely necessary question is the
filename.  We could have another command for attaching inline images and
text files if that is a goal also, and such a function could determine
the type automatically from the file type (which seems to be done now,
but the user is prompted to change it), always have a disposition of
inline, and again not use description.

[Miles Bader-2]

Jason Rumney <jasonr@...> writes:
> always have a disposition of inline, and again not use description.

Hmm, I think disposition=inline is often (usually?) wrong...
My impression is that most people, when they attach something, want it
attached as a separate downloadable thingie.

-Miles

--
Brain, n. An apparatus with which we think we think.

[Teemu Likonen-2]

On 2009-07-08 22:41 (+0900), Miles Bader wrote:

> Jason Rumney <jasonr@...> writes:
>> always have a disposition of inline, and again not use description.
>
> Hmm, I think disposition=inline is often (usually?) wrong...
> My impression is that most people, when they attach something, want it
> attached as a separate downloadable thingie.

It's very useful to have a choice. For small textual file the "inline"
type is good because it can be seen and read without further action. An
example:

    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3437#10

Inline MIME part is better than putting the content to the message body
because it is protected from possible word-wrapping of the editor or
mail client. Inline parts can be saved to disk too.

Real attachment is obviously better for binary files and large textual
files. It would waste too much space if a large textual attachment was
an "inline".

In my opinion mml-attach-file does not ask "annoying question". Other
than choosing the file user can just press Enter to all the questions.

[Miles Bader-2]

Teemu Likonen <tlikonen@...> writes:
>>> always have a disposition of inline, and again not use description.
>>
>> Hmm, I think disposition=inline is often (usually?) wrong...
>> My impression is that most people, when they attach something, want it
>> attached as a separate downloadable thingie.
>
> It's very useful to have a choice. For small textual file the "inline"
> type is good because it can be seen and read without further action.

Sure, I agree there are times when inline can be useful -- my objection
was to the (apparent) idea of having inline be the default without
prompting (I think _if_ people want to avoid prompting, inline is the
wrong default).

-Miles

--
自らを空にして、心を開く時、道は開かれる

[Teemu Likonen-2]

On 2009-07-08 23:27 (+0900), Miles Bader wrote:

> Teemu Likonen <tlikonen@...> writes:
>> It's very useful to have a choice. For small textual file the
>> "inline" type is good because it can be seen and read without further
>> action.
>
> Sure, I agree there are times when inline can be useful -- my
> objection was to the (apparent) idea of having inline be the default
> without prompting (I think _if_ people want to avoid prompting, inline
> is the wrong default).

Oh yes, I agree very much, inline would be wrong default if the question
was totally hidden. I wanted to point out that those "annoying
questions" (according to Richard) are _useful_ questions to me.

[Jason Rumney-4]

I wrote:

    It is probably reasonable to use a type of application/octet-stream,
    disposition of attachment and have no description for simple
    attachments.
    ....
    We could have another command for attaching inline images and text
    files if that is a goal also, and such a function could ....


Miles Bader quoted:
>>>> always have a disposition of inline, and again not use description.
>>>>        
> Sure, I agree there are times when inline can be useful -- my objection
> was to the (apparent) idea of having inline be the default without
> prompting (I think _if_ people want to avoid prompting, inline is the
> wrong default).
>  


It seems you only read the last bit of what I wrote.

[Richard Stallman]

    That's what mml-preview is for.

It isn't mentioned in the Emacs-Mime manual.  Its doc string seems to
say it displays the message with Gnus, which is not what I want to do.

I did manage to preview the mime text by executing (mml-to-mime).
(That interface is not satisfactory.)  But now, after looking at the
code of mml-preview, I wonder whether that is enough.  The code of
mml-preview does things I do not understand the purpose of.

Here's what the code does, leading up to the call to mml-to-mime.
Why is this needed?  What does this do?

      (mml-preview-insert-mail-followup-to)
      (let ((message-deletable-headers (if (message-news-p)
                                           nil
                                         message-deletable-headers)))
        (message-generate-headers
         (copy-sequence (if (message-news-p)
                            message-required-news-headers
                          message-required-mail-headers))))
      (if (re-search-forward
           (concat "^" (regexp-quote mail-header-separator) "\n") nil t)
          (replace-match "\n"))
      (let ((mail-header-separator ""));; mail-header-separator is removed.
        (message-sort-headers)
        (mml-to-mime))

[Reiner Steib]

On Wed, Jul 08 2009, Jason Rumney wrote:

> Richard Stallman wrote:
[...]
>> A suitable front-end to mml-attach-file could avoid asking all the
>> annoying questions.
>
> It is probably reasonable to use a type of application/octet-stream,

Please don't follow the bad behavior of MS Outlook.  mml-attach-file
figures out the suitable default by consulting the MIME type / Mailcap
files.  application/octet-stream is more or less a fallback for
arbitrary binary data, see RFC 2046
<http://tools.ietf.org/html/rfc2046#section-4.5.1>.

> disposition of attachment and have no description for simple
> attachments.  So the only absolutely necessary question is the
> filename.

We could add an option as we do when using drag and drop to attach a
file:

,----[ <f1> v mml-dnd-attach-options RET ]
| mml-dnd-attach-options is a variable defined in `mml.el'.
| Its value is nil
|
| Documentation:
| Which options should be queried when attaching a file via drag and drop.
|
| If it is a list, valid members are `type', `description' and
| `disposition'.  `disposition' implies `type'.  If it is nil,
| don't ask for options.  If it is t, ask the user whether or not
| to specify options.
|
| You can customize this variable.
`----

Bye, Reiner.
--
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

[Reiner Steib]

On Wed, Jul 08 2009, Richard Stallman wrote:

>     As does MML (mml-attach-file).
>
> It isn't in the emacs-mime manual so I did not know about it.  

It is documented in the Message manual:

,----[ (info "(message)MIME") ]
|    The most typical thing users want to use the multipart things in
| MIME for is to add "attachments" to mail they send out.  This can be
| done with the `C-c C-a' command (`M-x mml-attach-file'), which will
| prompt for a file name and a MIME type.
|
|    If your Emacs supports drag and drop, you can also drop the file in
| the Message buffer.  [...]
`----

> I tried it just now.  It asked me a lot of questions and then
> inserted this text.
>
> <#part type="text/x-sh" filename="~/foo.sh" disposition=inline description=foo>
> <#/part>
>
> I suppose this is MML and needs to get converted later.
> However, when I sent the message with C-c C-c, it did not convert.
> I don't see that it set up any hook to do so.

message-mode does the conversion automatically

,----[ (info "(message)MIME") ]
| Message is a MIME-compliant posting agent.  The user generally doesn't
| have to do anything to make the MIME happen--Message will automatically
| add the `Content-Type' and `Content-Transfer-Encoding' headers.
`----

> After a lot of searching thru that manual I found the function
> mml-to-mime.

Well, it under Composing -> Conversion, which seem quite suitable to
me.  

,----[ (info "(emacs-mime)Conversion") ]
|    An MML message can be converted back to MIME by the `mml-to-mime'
| function.
`----

message-mode uses mml-generate-mime, though:

,----[ (info "(emacs-mime)Composing") ]
|    The main interface function is `mml-generate-mime'.  It will examine
| the contents of the current (narrowed-to) buffer and return a string
| containing the MIME message.
`----

> If mml-to-mime were put on a hook so that C-c C-c would call it, this
> feature would be usable.  A suitable front-end to mml-attach-file
> could avoid asking all the annoying questions.  

mml-attach-file is the front-end used in message-mode for many years.
I quite often adjust type and disposition (inline vs. attachment).  I
don't recall any complains about the questions from our users.  Just
hit RET if you are happy with.

> It would only be necessary to document it.
>
> However, that hook could also cause trouble, since it might
> trigger by accident when users did not intend it.

It quite unlikely that users insert MML markup by accident.  When
writing about it, there is `mml-quote-region'.

> Another drawback, compared with etach-detach, is that you don't see
> what is really going to appear in the message.

C-u M-x mml-preview RET, M-x mml-preview RET

,----[ <f1> f mml-preview RET ]
| mml-preview is an interactive compiled Lisp function in `mml.el'.
| It is bound to <menu-bar> <Attachments> <Preview>, C-c RET P.
| (mml-preview &optional RAW)
|
| Display current buffer with Gnus, in a new buffer.
| If RAW, display a raw encoded MIME message.
`----

Bye, Reiner.
--
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

[Reiner Steib]

On Wed, Jul 08 2009, Richard Stallman wrote:

> I did manage to preview the mime text by executing (mml-to-mime).
> (That interface is not satisfactory.)  But now, after looking at the
> code of mml-preview, I wonder whether that is enough.  The code of
> mml-preview does things I do not understand the purpose of.
>
> Here's what the code does, leading up to the call to mml-to-mime.
> Why is this needed?  

The purpose is to display the mail message more like it would be sent.

> What does this do?

Removing/adding suitable headers, stripping mail-header-separator,
sorting headers.

Bye, Reiner.
--
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

[Miles Bader-2]

Jason Rumney <jasonr@...> writes:
> It seems you only read the last bit of what I wrote.

Whatever....  If people want to waste their time duplicating code and
making Emacs harder to use and understand for silly reasons, it's their
business, but I'm not going spend any more effort on it.

So, I'm going to plonk this thread.

If at some point real issues start to be addressed (for instance,
actually figuring out a coherent plan for making mail/news sending in
Emacs better for everybody, not just rms and ams), could someone give me
a ping, so I can start paying attention again?

Thanks,

-Miles

--
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

[Richard Stallman]

    The purpose is to display the mail message more like it would be sent.

    > What does this do?

    Removing/adding suitable headers, stripping mail-header-separator,
    sorting headers.

I see that that is true as regards mail-header-separator.
However, the rest seems not to be right for Mail mode.
It looks like this code is written only for use in Gnus.

[Richard Stallman]

    It is probably reasonable to use a type of application/octet-stream,
    disposition of attachment and have no description for simple
    attachments.

For most files, the type can be determined from the file name and
contents.  The simple interface should be able to do everything
automatically.  Maybe just accepting mml's default type would
do the right job.  If not, the code to do this is available in Etach.