Sending attachments

[Stefan Monnier]

> You should set the variable `mail-header-separator' to ""; message-mode
> also pays attention to this variable.

Still, message-mode needs to be fixed so this is not necessary.


        Stefan

[Stefan Monnier]

>    I object strenuously to the idea of replacing the very simple Mail
>    mode with something complex from Gnus.
> As a user of mail-mode, I agree fully.

Could you give actual concrete arguments why you think so?


        Stefan

[Stefan Monnier]

> Etach looks like just what I had in mind.
> (The parts that interact with Rmail need updating.)

Adding etach to Emacs means adding complexity and the only benefit will
be to add to mail-mode a subset of the features offered by
message-mode, AFAICT.
So for mail-mode it may be a good idea, but not for Emacs as a whole.

As far as I'm concerned, mail-mode should be moved to the
`obsolete' directory.


        Stefan

[Alfred M. Szmidt]

   Etach looks like just what I had in mind.

I'll see if I can wip up something that we can included in Emacs, that
replaces mail-attach-file in mail-mode so that it will use MIME
instead.

   (The parts that interact with Rmail need updating.)

Indeed they do, rmail already has some hooks for MIME.  But the
rmailmime mode that I saw was quite complex, and I can no longer find
it, the URL that is listed in rmail.el doesn't work..

Does anyone have a copy of rmailmime.el?

[Chong Yidong]

Eli Zaretskii <eliz@...> writes:

>> Is adding layers and layers of poorly integrated leaky bandaids to
>> mail-mode really the path we want to follow?
>
> I have no idea why you thought I was about to add ``leaky bandaids''.

RMS has suggested adding simple attachment functionality to mail-mode,
e.g. via etach.  I haven't had time to look at the code of etach, but I
suspect that all this will accomplish is an incremental and incomplete
extension of mail-mode's feature set---not enough to catch up with
message-mode, but adding more code duplication.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@...>
> Date: Sun, 05 Jul 2009 23:52:03 +0200
> Cc: ams@..., emacs-devel@...
>
> As far as I'm concerned, mail-mode should be moved to the
> `obsolete' directory.

I hope that's a joke.  Especially since there's no mail-mode.el to
move.

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: yamaoka@...,  yandros@...,  ding@...,  emacs-devel@...
> Date: Mon, 06 Jul 2009 05:44:51 +0900
>
> Eli Zaretskii <eliz@...> writes:
> >> > And this is out of scope for mail-mode, which (AFAIK) does not support
> >> > news.
> >>
> >> What exactly is the plan here?
> >
> > There is no plan (yet).  I was just trying to estimate the effort
> > needed for adding simple attachment facility to mail-mode.  Plans, if
> > there will be such, will come later.
>
> So that would be the "let's add this one function now and
> deal with the real problem later" answer, yes?

Maybe, or maybe it will be a "let's do nothing" answer.

> The point was that real support for mime (as message-mode has today)
> can't be done piecemeal

I don't think anybody was talking about ``real support for MIME''.
People who managed to get away without MIME at all till this day
probably don't need more than a simple way of attaching non-text
files.

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
> I don't think anybody was talking about ``real support for MIME''.
> People who managed to get away without MIME at all till this day
> probably don't need more than a simple way of attaching non-text
> files.

It's not what rms asked about, but it's certainly relevant to the
discussion.  Even if rms and ams would be satisfied with mail-mode +
simple-attach, it's natural to step back and think about the wider
implications of doing that.

In particular, the objections to simply adopting message-mode are still
unclear to me (other than the obvious one, that rms continues to be
annoyed because it was merged [apparently] without asking him).  Roughly
these objections seem to be something along the lines of "mail-mode is
simpler", but unless I've missed it, there's been little discussion of
exactly what the benefits of that are.

Some random points that come to mind:

  (1) We must still maintain message-mode as well, so mail-mode's
      "simplicity" yields no obvious code maintenance Benefit.

      Indeed, it's obviously more of a _burden_ to maintain both modes
      than it is to maintain message-mode alone (in the case that we got
      rid of mail-mode).  This burden goes up, of course, if mail-mode
      starts getting more features, like the suggested attachments.

  (2) I've used both modes over the years, and from my viewpoint as a
      user, both modes seem pretty much the same form a UI standpoint --
      message-mode has more bindings to support its additional
      functionality, but they do not get in the way as far as I can see.

      So as far as I can tell, mail-mode does not have an obviously
      simpler UI for the average user.

So... what exactly _is_ the "simplicity advantage" that's been alluded to?

[The "duplicated code disadvantage", on the other hand is pretty obvious...]

Thanks,

-Miles

--
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

[Miles Bader-2]

Miles Bader <miles@...> writes:
> Some random points that come to mind:
>
>   (1) We must still maintain message-mode as well, so mail-mode's
>       "simplicity" yields no obvious code maintenance Benefit.
>
>   (2) I've used both modes over the years, and from my viewpoint as a
>       user, both modes seem pretty much the same form a UI standpoint

Oh, also:

  (3) Having both modes present presents a user burden, especially
      because the default is mail-mode -- there are many cases where
      a new user may need the extra features (even if he doesn't
      realize this, e.g., if he is sending non-ASCII characters in a
      way that isn't handled properly by mail-mode), but will still
      be using the default settings.

      Not only must the documentation be written to consider this
      and guide users, but in many cases, the user won't look at the
      documentation, or won't look in the proper place, and so will
      simply decide that Emacs mail handling doesn't support the
      desired feature.  In the case non-ASCII character case
      mentioned above, he may not even _know_ that he needs to do
      anything or look at any documentation -- he'll just send
      incorrect mail.

Thanks,

-Miles

--
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

[Alfred M. Szmidt]

     (1) We must still maintain message-mode as well, so mail-mode's
         "simplicity" yields no obvious code maintenance Benefit.

Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
vs. mh (which each has their own mail sending mode!), viper
vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.
You already have people who prefer it, and are more than happy to fix
any bugs it has.  Maintaince is clear not the issue here.

         Indeed, it's obviously more of a _burden_ to maintain both
         modes than it is to maintain message-mode alone (in the case
         that we got rid of mail-mode).  This burden goes up, of
         course, if mail-mode starts getting more features, like the
         suggested attachments.

For such a feature to be properly implmented they wouldn't be in
mail-mode (or any such mode), but in a seperate mode that handles MIME
attachment exclusivly.  If message-mode handles this itself, then it
is a sign that it was not properly thought through.

  (3) Having both modes present presents a user burden, especially
      because the default is mail-mode -- there are many cases where a
      new user may need the extra features (even if he doesn't realize
      this, e.g., if he is sending non-ASCII characters in a way that
      isn't handled properly by mail-mode), but will still be using
      the default settings.

I use it every day for non-ASCII text, and mail-mode has not had any
problems with that.

[Reiner Steib]

On Sun, Jul 05 2009, Stefan Monnier wrote:
> Miles Bader wrote:
>> Teemu Likonen <tlikonen@...> writes:
>>> Context-sensitive commands are good but in message-mode they seem to
>>> require that the "--text follows this line--" separator line exists.
[...]
>> You should set the variable `mail-header-separator' to ""; message-mode
>> also pays attention to this variable.
>
> Still, message-mode needs to be fixed so this is not necessary.

Please elaborate.

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

[Miles Bader-2]

"Alfred M. Szmidt" <ams@...> writes:
>      (1) We must still maintain message-mode as well, so mail-mode's
> "simplicity" yields no obvious code maintenance Benefit.
>
> Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> vs. mh (which each has their own mail sending mode!), viper
> vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.

For all of the above, the duplication _does_ cause additional
maintenance burden, and more user confusion.

However, for many such packages the UIs of the various alternative modes
are quite different, so it's much easier to argue that the alternatives
are all "necessary" (in some cases that may not be true -- e.g., I'm not
sure if vi-mode is still really necessary), and that the burden is
justified.

mail-mode vs. message-mode is a particular funny case because the
message-mode UI seems to be pretty much a superset of mail-mode's UI
(if it isn't, please give details).

ERC vs. rcirc is a case where ERC is more functional, but has a very
different feel to the user.  My vague sense is that maybe people are
saying they feel the same is true of mail-mode vs. message-mode, but in
my own experience, such a difference was not at all obvious.

> You already have people who prefer it, and are more than happy to fix
> any bugs it has.

So, tell me, in concrete terms, _why_ do they prefer it?   Well, OK, you
may not want to speak for others, so just tell me why _you_ prefer it?
How would you be adversely affected if one day, someone snuck up and
replaced mail-mode with message-mode?

To help you get started, here are a general categories:

 (1) UI differences (AFAICT, they're very very similar, but I'm sure
     there are some differences that annoy people -- though in some
     cases these are probably bugs...)

 (2) Customization/hook differences -- maybe mail-mode has some great
     hooks or settings that message-mode doesn't.

 (3) Behavioral differences -- does mail-mode work with some systems
     where message-mode doesn't (as I mentioned earlier, mail-mode fails
     to send for some reason on one of my machines)?

Remember, be concrete, and be detailed -- we've all argued enough that
people's basic position is clear enough, and I don't see how it's
possible to advance this discussion without some actual details...

The reason why I sound a bit incredulous is that I've used both, and
other than message-mode's extra functionality -- which seemed pretty
much invisible to me unless I needed it -- they seemed more or less
identical.  [Well there are some things, like the fill prefix when
filling a header line is different...]

> Maintenance is clearly not the issue here.

Both modes seem fairly mature, so it's not the problem it might be, but
any bugs need to be checked for in both modes, and any new features may
need to be thought about in the context of both.  Documentation needs to
consider both, and worry about making the difference clear to users.
But I agree, it's probably not the main issue (though in the abstract
it's Not Good to have duplicate code bases).

I think, however, that the user burden of the duplication is very real.
People do not know, in general, that to get certain functionality they
have to use a different mail-sending mode.

> Indeed, it's obviously more of a _burden_ to maintain both
> modes than it is to maintain message-mode alone (in the case
> that we got rid of mail-mode).  This burden goes up, of
> course, if mail-mode starts getting more features, like the
> suggested attachments.
>
> For such a feature to be properly implmented they wouldn't be in
> mail-mode (or any such mode), but in a seperate mode that handles MIME
> attachment exclusivly.  If message-mode handles this itself, then it
> is a sign that it was not properly thought through.

That is not at all clear -- AFAIK, much of the actual MIME stuff is a
separate library, but MIME covers a lot of aspects of mail encoding, not
just attachments, and all of that it's going to need to be hooked into
the top-level mode.

In any case, I can't defend the quality of the message-mode code.  The
general code quality or design of mail-mode may well be higher.

However, if mail-mode doesn't have the requisite functionality (which
certainly seems to be the case), then we could

 (a) Keep both, and suffer the problems of having both (maintenance
     burden and user confusion).

 (b) Fix any bugs / functional inadequacies in in message-mode, and
     trash mail-mode.  Since message-mode largely seems to be a superset
     from the user's point of view, this option seems to have a fairly
     small cost.  If message-mode's code is bad, then that's a shame,
     but having message-mode alone is certainly less of a problem than
     message-mode plus something else.

 (c) Add the required functionality to mail-mode, fix any other problems
     with it, and trash message-mode.  As mail-mode is missing a lot of
     functionality, this would seem to have a far higher cost than
     option (b), but the end result might be better.

If mail-mode has better code than message-mode, then ideally we'd choose
(c), but in practice, the implementation cost (and associated extra
maintenance burden of new code) may make (b) the better choice.

> I use it every day for non-ASCII text, and mail-mode has not had any
> problems with that.

The most obvious problem with mail-mode's handling of non-ASCII text is
that it doesn't seem to encode headers correctly (headers in email are
annoying, you need to use a whole separate system for encoding them).

[and does mail-mode support any non-8-bit transfer encodings?  Does it
work if the message encoding isn't utf-8, and the user uses multiple
languages?]

Thanks,

-Miles

--
Erudition, n. Dust shaken out of a book into an empty skull.

[Chong Yidong]

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

> Seeing that we have already rcirc vs. erc, rmail vs. gnus vs. vm
> vs. mh (which each has their own mail sending mode!), viper
> vs. vi-mode vs. vile; a small _derived_ mode can't be the problem.
> You already have people who prefer it, and are more than happy to fix
> any bugs it has.  Maintaince is clear not the issue here.

Apart from Miles' reply to this (with which I fully agree), it should be
noted that rcirc/erc/gnus/mh have dedicated maintainers, while mail-mode
is maintained in-tree.

[Richard Stallman]

    As far as I'm concerned, mail-mode should be moved to the
    `obsolete' directory.

Please don't do that!

[Richard Stallman]

    I'll see if I can wip up something that we can included in Emacs, that
    replaces mail-attach-file in mail-mode so that it will use MIME
    instead.

Other than some simplifications, because it would not need to work
in old Emacs versions, why is any change needed?

[Richard Stallman]

    So that would be the "let's add this one function now and
    deal with the real problem later" answer, yes?

The real issue that I raised is sending attachments with Mail mode.
Installing Etach will deal with that.  This actually does not involve
a change in sendmail.el, since Etach is modular.

[Richard Stallman]

      1. Proper handling of non-ascii text. For instance:

          a. Proper encoding of non-ascii headers (using "=?" notation)
          b. Ability to use other transfer encodings besides 8-bit
          c. Ability to automatically choose different character encodings
             depending on the language/context/whatever (e.g., for many
             cases, the "standard" isn't utf-8).

      2. Ability to have both text and binary attachments (both are very
         important), and that these work together with the language support
         in part (1).

The features I would like to see are probably a subset of this.  I am
not sure it needs to be as automatic and complete as this would have
it.

Etach seems to do the job that I want done.

[Richard Stallman]

I can maintain and extend Mail mode.  I cannot maintain Message mode;
it is too hairy and depends on too much.

Etach, once documented in the Emacs manual
(which is very simple to do),
will show Emacs users how to send attachments.

Etach also decodes Mime.  I have not tried that yet
but I will soon.

[Chong Yidong]

Richard Stallman <rms@...> writes:

> Etach, once documented in the Emacs manual (which is very simple to
> do), will show Emacs users how to send attachments.
>
> Etach also decodes Mime.  I have not tried that yet but I will soon.

We should not add yet another mime library to Emacs, when we already
have one (mml.el).

[Glenn Morris-3]

Richard Stallman wrote:

> Etach also decodes Mime. I have not tried that yet but I will soon.

Have you looked at rmailmm.el, which is part of Emacs?

;;; rmailmm.el --- MIME decoding and display stuff for RMAIL