Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Date: Mon, 06 Jul 2009 13:54:03 +0900
> Cc: ding@...
>
>                              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.

Did you actually try that?  Mail mode will not let you send such
messages, it will prompt for a proper encoding.

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: eliz@..., yandros@..., yamaoka@..., ding@...,
>         emacs-devel@...
> Date: Mon, 06 Jul 2009 16:47:22 +0900
>
> does mail-mode support any non-8-bit transfer encodings?

Yes.

> Does it work if the message encoding isn't utf-8, and the user uses
> multiple languages?

No.  It supports only a single encoding for the whole body (and will
insist on getting one, before it sends).

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Cc: Miles Bader <miles@...>, yamaoka@..., yandros@...,
>         ding@..., emacs-devel@...
> Date: Sun, 05 Jul 2009 18:56:04 -0400
>
> 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.

Even if I would agree with your point, it's still a far cry from leaky
bandaids.

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Date: Sun, 05 Jul 2009 10:47:32 -0400
> Cc: emacs-devel@..., miles@...
>
> As has been pointed out, message-mode has more features than mail-mode.

Yes.  And Gnus has much more features than Rmail.  So what?  We all do
agree that much more features means more complexity in setting things
up.  Why impose that on people who are happy with simple modes?

> Even if we wanted to bring mail-mode up to par

No one suggested that.

> that would turn it into something just as complex, or more (since,
> as you noted, message-mode already relies on other libraries to much
> of its functionality).

Encoding a file uses only core Emacs features (base64-encode-region),
so no libraries should be involved.

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Cc: Miles Bader <miles@...>, eliz@..., yandros@...,
>         yamaoka@..., ding@..., emacs-devel@...
> Date: Mon, 06 Jul 2009 10:13:51 -0400
>
> "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.

For some value of ``maintained''.  Cursory scan of the logs shows that
it gets one simple change every 3 months or so, sometimes even less
(modulo doc fixes).  So much for a ``burden''.

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
>> 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.
>
> Did you actually try that?  Mail mode will not let you send such
> messages, it will prompt for a proper encoding.

You may be thinking of a different case.

I did test sending a message with non-ASCII text in the header, which
mail-mode sent incorrectly, without any prompting or warning (you can't
just encode header text using the body's encoding, you need to use the
special "?=" encoding stuff).

-Miles

--
We have met the enemy, and he is us.  -- Pogo

[Kenichi Handa]

In article <87y6r1san7.fsf@...>, Miles Bader <miles@...> writes:

> Eli Zaretskii <eliz@...> writes:
>>> 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.
> >
> > Did you actually try that?  Mail mode will not let you send such
> > messages, it will prompt for a proper encoding.

> You may be thinking of a different case.

> I did test sending a message with non-ASCII text in the header, which
> mail-mode sent incorrectly, without any prompting or warning (you can't
> just encode header text using the body's encoding, you need to use the
> special "?=" encoding stuff).

I've been believed that mail-mode (and the new rmail code)
supports non-ASCII Subject: correctly, but it was not.  I've
just noticed that I'm using these setups in my .emacs.  The
similar codes should be installed (of course, not as hooks).

(require 'rfc2047)

(defun rmail-decode-header ()
  (save-excursion
    (goto-char (point-min))
    (search-forward "\n\n")
    (if (re-search-backward "^subject:" nil t)
        (let ((buffer-read-only nil)
              (pos (match-end 0)))
          (forward-line 1)
          (while (looking-at "[ \t]")
            (forward-line 1))
          (rfc2047-decode-region pos (1- (point)))))))

(add-hook 'rmail-show-message-hook 'rmail-decode-header)

(require 'rmailsum)

(defun mail-decode-summary-line (line)
  (rfc2047-decode-string line))

(setq rmail-summary-line-decoder 'mail-decode-summary-line)

(require 'sendmail)

(defun mail-encode-header ()
  (save-excursion
    (goto-char (point-min))
    (search-forward mail-header-separator nil 'move)
    (let ((case-fold-search t)
          pos)
      (when (re-search-backward "^subject:" nil t)
        (setq pos (point))
        (forward-line 1)
        (while (looking-at "[ \t][^ \t\n]")
          (forward-line 1))
        (rfc2047-encode-region pos (1- (point)))))))

(add-hook 'mail-send-hook 'mail-encode-header)

(defun mail-decode-header ()
  (save-excursion
    (mail-position-on-field "Subject" t)
    (if (not (bobp))
        (let ((pos (point)))
          (beginning-of-line)
          (while (looking-at "[ \t]")
            (forward-line -1))
          (rfc2047-decode-region (point) pos)))))

(add-hook 'mail-setup-hook 'mail-decode-header)

---
Kenichi Handa
handa@...

[Miles Bader-2]

Eli Zaretskii <eliz@...> writes:
>> As has been pointed out, message-mode has more features than mail-mode.
>
> Yes.  And Gnus has much more features than Rmail.  So what?  We all do
> agree that much more features means more complexity in setting things
> up.  Why impose that on people who are happy with simple modes?

How, exactly, is message-mode an "imposition" on "people who are happy
with simple modes"?

  * Its user-interface?  [As far as I can tell, message-mode's UI
    _isn't_ complex, and indeed is pretty much exactly the same as
    mail-mode's (its additional functionality being largely invisible
    unless you use it).  I've used both many times over the years, and
    never noticed anything obviously different (there are random trivial
    differences like header-filling whitespace, etc, but those are not
    significant -- if they actually bother people, they can easily be
    changed).]

  * Its resource consumption?  [It doesn't seem any slower (which makes
    sense, as the great bulk of the extra functionality is only used
    with explicitly invoked).  It's more code, but doesn't seem horribly
    large by emacs standards, and additional memory used by its code
    seems small compared to the rest of emacs, and shouldn't be an issue
    on any modern system.]

  * Is it more buggy?  [Never noticed any obvious difference in this respect.]

  * Is it missing useful user-customization hooks or settings that
    mail-mode has?

  * Does it interface badly with some other Emacs code (e.g., rmail)?

Please, please, somebody who asserts that mail-mode is necessary, give
some concrete examples as to _why_.  The amount of hand-waving in this
thread is maddening...

-Miles

--
Future, n. That period of time in which our affairs prosper, our friends
are true and our happiness is assured.

[Eli Zaretskii]

> From: Miles Bader <miles@...>
> Cc: Chong Yidong <cyd@...>, rms@..., emacs-devel@...
> Date: Tue, 07 Jul 2009 10:12:57 +0900
>
> Eli Zaretskii <eliz@...> writes:
> >> As has been pointed out, message-mode has more features than mail-mode.
> >
> > Yes.  And Gnus has much more features than Rmail.  So what?  We all do
> > agree that much more features means more complexity in setting things
> > up.  Why impose that on people who are happy with simple modes?
>
> 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.

> Please, please, somebody who asserts that mail-mode is necessary, give
> some concrete examples as to _why_.

Maybe someone else will.  This old fart simply doesn't want to learn a
new mode unless it's absolutely necessary.  Is this so hard to
understand?

[Miles Bader-2]

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; it implies that the people being imposed
upon will suffer in some way.  Since I don't see any obvious negative
effect from switching to message-mode (counter-examples welcome!), using
a pejorative term doesn't really seem warranted.

>> Please, please, somebody who asserts that mail-mode is necessary, give
>> some concrete examples as to _why_.
>
> Maybe someone else will.  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?

See, _that's_ why I'm so confused -- message-mode is not some kind of
wacky new UI, it seems to me to be pretty much _the same_ as mail-mode
from the user's point of view.

If I'm wrong about this, I'd like to know.  I've used both, so I think I
have _some_ clue, but maybe I'm missing something.

Thanks,

-Miles

--
Consult, v.i. To seek another's disapproval of a course already decided on.

[Giorgos Keramidas]

On Mon, 06 Jul 2009 02:37:32 -0400, "Alfred M. Szmidt" <ams@...> wrote:
> 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.

It's a library already, IIRC.  The mml-* functions can parse a simple
meta-language from plain text buffers and generate MIME messages:

,---[ (emacs-mime)Top > Composing ----------------------------------
|
| 2 Composing
| ***********
|
| Creating a MIME message is boring and non-trivial.  Therefore, a
| library called `mml' has been defined that parses a language called MML
| (MIME Meta Language) and generates MIME messages.
|
`-----------------------------------------------------------------------

Perhaps mail-mode can be tweaked to use `mml-' functions too?

[Alfred M. Szmidt]

       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?

If etach is added to emacs, then I suppose it would be unneeded work.

[Alfred M. Szmidt]

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.

[Alfred M. Szmidt]

That is really neat, thank you.

[Richard Stallman]

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

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

Thanks for reminding me about this.

Etach has code for making attachments and for decoding attachments,
but they are separate in implementation.  If rmailmm is better for
decoding, we could install only the Etach encoding support.

I looked at, and tried, both rmailmm and Etach's mime decoding code.

I just tried rmailmm on a message which had a text part and an HTML
part.  It made a temporary buffer and showed both of them in it.  If I
changed it to put some separator between the two parts, it would be
usable.

etach-detach is more convenient because does one attachment at a time.
It also understands mime more.  For instance, it understands that the
text and HTLM are alternatives and you only want to see one.

I needed to make a few changes to get it to work with rmail-mbox, but
they were simplifications.  It now displays the textual attachments
right in the rmail view buffer.

I concluded that the etach-detach code is superior.  I think it should
replace rmailmm.  With a little more work I could give it a mode
of behavior similar to rmailmm, so as to make the replacement smoother.

[Richard Stallman]

    As has been pointed out, message-mode has more features than mail-mode.
    Even if we wanted to bring mail-mode up to par, that would turn it into
    something just as complex,

If "par" means all the same features, nobody wants to do that.  It is not
necessary or useful.

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.

There may be a few other features that it would be nice to provide in
Mail mode, and some of them might involve adding some code in that file.
But this would not involve anything like the complexity of Message mode.

Etach attachment is a modular feature which does not directly interact
with the code in sendmail.el.  Users could load it or not.

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.  Mail mode is nice
and simple, and I will maintain it myself if you don't want to.

[Richard Stallman]

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

Etach and mml both deal with puttimg mime into a message, but in very
different ways.  mml.el requires the user to write text in the MML
language and then convert it into mime.

Etach has a convenient interface M-x attach which attaches a file in
the message in the current buffer.  That is a simple feature and
easy to use.

Etach and MML are complementary, so it is better to have them both.

[Richard Riley-4]

"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.
>

Reading this discussion is quite interesting. I have to ask why you are
so keen to duplicate efforts when it seems relatively clear that
message-mode is a non intrusive superset of mail-mode. Getting more
familiar with emacs I have to say that its frequently an issue for new
adopters as well as seasoned users that there are too many versions of
effectively the same thing leading to duplicated efforts as well as
confusion in both code usage and documentation. In addition, quoting properly
might add more force to your argument. Miles has asked multiple times
for something that mail-mode provides that message mode does not, he has
pointed out how there is no real learning curve. I would be very
interested, from the developer point of view, to know why you seem to be
so dead set against retiring what is effectively a sub-set of a more
commonly used and better maintained mode like message-mode. Especially
in the context of adding things to mail-mode which are blatantly
unproven in this thread.

Excuse me my 3 seconds, but, well, the arguments for maintaining
mail-mode seem, to me who has no agenda, nothing more than "because I
say so".

[Andreas Schwab-2]

Richard Stallman <rms@...> writes:

>     We should not add yet another mime library to Emacs, when we already
>     have one (mml.el).
>
> Etach and mml both deal with puttimg mime into a message, but in very
> different ways.  mml.el requires the user to write text in the MML
> language and then convert it into mime.

It doesn't.  There are front-end functions that do all that for you.

> 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).

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:
> mml.el requires the user to write text in the MML
> language and then convert it into mime.
>  

Most users would use mml-attach-file, though some might find writing
text in MML faster if they are familiar with it. And the conversion to
MIME is the major part of what mml.el handles, as part of a send hook
(or maybe directly called by message-mode's send function).