Re: Sending attachments

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Could you please post a list of the features you had in mind, so that
> the effort could be estimated?

Important things:

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

  3. The ability to handle the various quirks of sending netnews as
     opposed to email (they're similar in many ways, but obviously not
     all).

     [This presumes that we're looking at _replacing_ the current
     duplicated infrastructure with something new/better -- if the
     non-trivial effort is to be spent to make mail-mode really do email
     correctly, it would be dumb to retain message-mode just for
     handling netnews!]

Of course, message-mode already does all this properly.

My observation has been that there are lot of corner cases, and a lot of
software screws them up.

It would be very very useful to have some of the guys that actually work
on message-mode involved in this conversation, because they probably
know this stuff in much more detail -- I only know what I use as a user,
and have had problems with in the past.

-Miles


p.s. A probably unrelated problem, which made testing a bit annoying:
I can't actually send _any_ mail with mail-mode, because my ISP's
mail-forwarder rejects any messages generated with it!  I'm not quite
sure what extra headers or whatever message-mode adds, but I have no
problems with mail sent using message-mode...

-- 
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Chad Brown <yandros@MIT.EDU>, Katsumi Yamaoka <yamaoka@jpl.org>,
>     emacs-devel@gnu.org, ding@gnus.org
> Date: Sun, 05 Jul 2009 11:39:59 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Could you please post a list of the features you had in mind, so that
> > the effort could be estimated?
> 
> Important things:

Thanks.

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

I think this is not really related to attaching files.

>   3. The ability to handle the various quirks of sending netnews as
>      opposed to email (they're similar in many ways, but obviously not
>      all).

And this is out of scope for mail-mode, which (AFAIK) does not support
news.

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

If you find out why that happens and post the info here, perhaps
someone could fix the problems causing it.  FWIW, I use mail-mode for
many years with many different ISPs with no problems at all.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> I think this is not really related to attaching files.
...
> And this is out of scope for mail-mode, which (AFAIK) does not support
> news.

What exactly is the plan here?

Do we want to address the duplication between mail-mode and message-mode
or not?  Isn't this duplication a bad thing?  I think it is -- it
confuses users and adds maintenance burden.  Is adding layers and layers
of poorly integrated leaky bandaids to mail-mode really the path we want
to follow?  Are you just saying "let's add this one function now and
deal with the real problem later"?

-Miles

-- 
Hers, pron. His.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: yamaoka@jpl.org,  yandros@MIT.EDU,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Sun, 05 Jul 2009 12:44:00 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > I think this is not really related to attaching files.
> ...
> > 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.

> Do we want to address the duplication between mail-mode and message-mode
> or not?

I don't know about ``we'', but _I_ don't.  I simply don't have enough
time for such cleanups, and don't think I know enough about Gnus and
message-mode to be a good candidate for the job anyway.

> Isn't this duplication a bad thing?

Probably, but we have lived with that since when Gnus was merged with
Emacs.

> 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''.
I didn't even say I'm going to write any code, let alone ``leaky''.
And I don't think I ever added to Emacs such low-quality code that
would justify you making such assumptions, should I decide to write
some code.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> 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?

> I have no idea why you thought I was about to add ``leaky bandaids''.
> I didn't even say I'm going to write any code, let alone ``leaky''.
> And I don't think I ever added to Emacs such low-quality code that
> would justify you making such assumptions, should I decide to write
> some code.

I was not saying anything about your code (I wasn't even thinking you'd
write the code), and thus was making no assumptions about it.

The point was that real support for mime (as message-mode has today)
can't be done piecemeal, and that while adding "a little bit" of support
to mail-mode may be a _temporary_ fix for some people's perceived
problem, it isn't a good long-term solution -- and even in the
short-term it actually makes the duplication problem _worse_, so it
seems worth thinking about whether even that is actually desirable.

-Miles

-- 
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: yamaoka@jpl.org,  yandros@MIT.EDU,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Mon, 06 Jul 2009 05:44:51 +0900
> 
> Eli Zaretskii <eliz@gnu.org> 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.

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> 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.

Re: Sending attachments

[Miles Bader]

Miles Bader <miles@gnu.org> 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.

Re: Sending attachments

[Eli Zaretskii]

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

Re: Sending attachments

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> 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

Re: Sending attachments

[Kenichi Handa]

In article <87y6r1san7.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> 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@m17n.org

Re: Sending attachments

[Alfred M. Szmidt]

That is really neat, thank you.

Re: Sending attachments

[Richard Stallman]

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

Re: Sending attachments

[Stefan Monnier]

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

Feel free to install it.  Note that it brings mail-mode closer to
message-mode, relying on the same MIME code, so I'm very favorable
to it.  I'd go even further and implement all the remaining missing
features.  It can be done with even less code (just a defalias).


        Stefan

Re: Sending attachments

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

Re: Sending attachments

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> 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.

Re: Sending attachments

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: eliz@gnu.org, yandros@MIT.EDU, yamaoka@jpl.org, ding@gnus.org,
>         emacs-devel@gnu.org
> 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).

Re: Sending attachments

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> 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.

Re: Sending attachments

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Miles Bader <miles@gnu.org>, eliz@gnu.org, yandros@MIT.EDU,
>         yamaoka@jpl.org, ding@gnus.org, emacs-devel@gnu.org
> Date: Mon, 06 Jul 2009 10:13:51 -0400
> 
> "Alfred M. Szmidt" <ams@gnu.org> 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''.

Re: Sending attachments

[Giorgos Keramidas]

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

Re: Sending attachments

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

Re: Sending attachments

[Stefan Monnier]

> The real issue that I raised is sending attachments with Mail mode.

Actually, not really.  I think "the real issue" if sending attachments
(and non-ASCII text, including in headers) in "the default
mail-composition interface".  *Very* few users actually choose
mail-mode.

> Installing Etach will deal with that.  This actually does not involve
> a change in sendmail.el, since Etach is modular.

A simpler change is to make message-mode the default UI.
This thread seems to show that noone knows of any actual difference that
users would notice (other than being able to attach files and stuff, of
course).

So I think the first step should be to change mail-user-agent to
default to message-user-agent.
The next step will then be to make Rmail use message-mode as well
(which may require some changes to message-mode, of course).


        Stefan

Re: Sending attachments

[Alfred M. Szmidt]

   So I think the first step should be to change mail-user-agent to
   default to message-user-agent.  The next step will then be to make
   Rmail use message-mode as well (which may require some changes to
   message-mode, of course).

PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
that they prefer it over message-mode, please respect that!

Re: Sending attachments

[Leo]

On 2009-07-11 20:41 +0100, Alfred M. Szmidt wrote:
>    So I think the first step should be to change mail-user-agent to
>    default to message-user-agent.  The next step will then be to make
>    Rmail use message-mode as well (which may require some changes to
>    message-mode, of course).
>
> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
> that they prefer it over message-mode, please respect that!

Don't worry.
We can put it in emacswiki so that it will be available for good.

-- 
Leo's Emacs uptime: 31 days, 13 hours, 21 minutes, 13 seconds

Re: Sending attachments

[Lennart Borgman]

On Sun, Jul 12, 2009 at 5:05 AM, Leo<sdl.web@gmail.com> wrote:
> On 2009-07-11 20:41 +0100, Alfred M. Szmidt wrote:
>>    So I think the first step should be to change mail-user-agent to
>>    default to message-user-agent.  The next step will then be to make
>>    Rmail use message-mode as well (which may require some changes to
>>    message-mode, of course).
>>
>> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
>> that they prefer it over message-mode, please respect that!
>
> Don't worry.
> We can put it in emacswiki so that it will be available for good.

I think you are misunderstanding. The code will still be distributed
with Emacs but will not be used by default.

If you think something is missing in message-mode then please consider
contributing code for what you miss.

Re: Sending attachments

[Stefan Monnier]

>    So I think the first step should be to change mail-user-agent to
>    default to message-user-agent.  The next step will then be to make
>    Rmail use message-mode as well (which may require some changes to
>    message-mode, of course).

> PLEASE DO NOT DO THIS!  People using mail-mode have already expressed
> that they prefer it over message-mode,

Most of the people who use mail-mode have not expressed any opinion.
The vast majority of them have no idea they're using mail-mode and that
they have a choice to use something else.

> please respect that!

The very few users who have expressed a preference for mail-mode have
not given any concrete argument for why.  Some developers/maintainers of
mail-mode have expressed their preference for it, indeed, but that's
a different issue.


        Stefan


PS: And to reply to Lennart, when I say "obsolete" that means I have the
intention to get rid of the corresponding code as well, tho as we know
such things take time, and even more so in cases like this one where the
maintainers are emotionally atached to their code and happen to be some
of the most important Emacs developers.

Re: Sending attachments

[Alfred M. Szmidt]

Nobody (atleast I do not) has no issues with setting mail-user-agent
to message-user-agent; since that allows people who prefer mail-mode
to continue to use it.  And can be easily reverted at a later date.

But your insistance to remove a perfectly usable mode that people
actually prefer, and wish to continue to use _and_ maintain, is not
productive.


There are far more important things to work on in Emacs.  Org mode has
many modes that already exist in Emacs which are not very popular.  I
am in particular thinking of table-mode and footnote-mode, which are
very useful modes, but Org mode has similar modes that are better.

Re: Sending attachments

[Richard Riley]

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

> Nobody (atleast I do not) has no issues with setting mail-user-agent
> to message-user-agent; since that allows people who prefer mail-mode
> to continue to use it.  And can be easily reverted at a later date.
>
> But your insistance to remove a perfectly usable mode that people
> actually prefer, and wish to continue to use _and_ maintain, is not
> productive.

As an observer this argument you keep putting up is very weak.

Not one person has offered a reason why they can not use the subset of
message-mode which encompasses mail-mode.

It appears, from the outside, simply ludicrous to maintain TWO suites of
SW one of which is a *poorer* and less meticulous subset of the other
purely because, well,  - actually there have been zero usability reasons
put forwards - only "because I said so" foot stomping reasons.

Re: Sending attachments

[Stefan Monnier]

> Nobody (atleast I do not) has no issues with setting mail-user-agent
> to message-user-agent;

Which is wy I did it.

> But your insistance to remove a perfectly usable mode that people
> actually prefer, and wish to continue to use _and_ maintain, is not
> productive.

Where did I insist to remove it?  It's still there, isn't it?
I do indeed want to obsolete it.  I also want to make strings and
defconst immutable, and let be lexically scoped, and ...
Some of those will hopefully happen within my lifetime, others not.

Obsoleting mail-mode actually requires some amount of technical work,
and I have better things to do, so don't expect it to happen any time
soon, especially since it would require an enormous amount of
social-work along side.

But I do oppose very strongly the addition of etach: if someone wants to
add MIME features to mail-mode, it should be by bringing mail-mode and
message-mode closer to each other.


        Stefan

Re: Sending attachments

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> 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.

Re: Sending attachments

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Miles Bader <miles@gnu.org>, yamaoka@jpl.org, yandros@MIT.EDU,
>         ding@gnus.org, emacs-devel@gnu.org
> Date: Sun, 05 Jul 2009 18:56:04 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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.

Re: Sending attachments

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> p.s. A probably unrelated problem, which made testing a bit annoying:
> I can't actually send _any_ mail with mail-mode, because my ISP's
> mail-forwarder rejects any messages generated with it!  I'm not quite
> sure what extra headers or whatever message-mode adds, but I have no
> problems with mail sent using message-mode...

Perhaps it's the wrong envelope sender.

Andreas.

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

Re: Sending attachments

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
>> p.s. A probably unrelated problem, which made testing a bit annoying:
>> I can't actually send _any_ mail with mail-mode, because my ISP's
>> mail-forwarder rejects any messages generated with it!  I'm not quite
>> sure what extra headers or whatever message-mode adds, but I have no
>> problems with mail sent using message-mode...
>
> Perhaps it's the wrong envelope sender.

I think that's it, but somehow, message-mode manages to set it correctly
(or perhaps not set it incorrectly), whereas mail-mode fails to do so.

I was kind of surprised because I thought both used the same backend
sending code in emacs....

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

Re: Sending attachments

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

Reducing Gnus dependencies in message.el (was: Sending attachments)

[Reiner Steib]

On Sat, Jul 04 2009, Richard Stallman wrote:

>     > I object strenuously to the idea of replacing the very simple Mail
>     > mode with something complex from Gnus.
>
>     It's a question of necessary complexity.
>
> I don't think so.  Look at all the libraries message.el loads.
>
>
>     (require 'hashcash)
>     (require 'canlock)

We can eliminate these by using autoloads.  canlock is used for news
postings in Gnus by default.  Hashcash is an optional feature for
mail.

>     (require 'mailheader)

[mailheader.el is not part of Gnus, but part of Emacs.]  Required to
insert correctly formated (quoting, folding, ...) headers into mail
message buffers.

;;; mailheader.el --- mail header parsing, merging, formatting
[...]
;;; Commentary:

;; This package provides an abstraction to RFC822-style messages, used in
;; mail, news, and some other systems.  The simple syntactic rules for such
;; headers, such as quoting and line folding, are routinely reimplemented
;; in many individual packages.  This package removes the need for this
;; redundancy [...]

>     (require 'gmm-utils)

;;; gmm-utils.el --- Utility functions for Gnus, Message and MML

... is an attempt to reduce Gnus dependencies from Message and MML
files.

>     (require 'nnheader)
>
>       That loads
> 	(require 'mail-utils)

[mailutils.el is not part of Gnus, but part of Emacs].  It provides
utility functions for mail handling.  Both, rmail.el and sendmail.el
use it.  I see no point in avoiding using it.

;;; mail-utils.el --- utility functions used both by rmail and rnews
[...]
;; Utility functions for mail and netnews handling.  These handle fine
;; points of header parsing.

> 	(require 'mm-util)

;;; mm-util.el --- Utility functions for Mule and low level things
... needed for MIME.

> 	(require 'gnus-util)

I will try to eliminate this dependency.

>     ;; This is apparently necessary even though things are autoloaded.
>     ;; Because we dynamically bind mail-abbrev-mode-regexp, we'd better
>     ;; require mailabbrev here.
>     (if (featurep 'xemacs)
> 	(require 'mail-abbrevs)
>       (require 'mailabbrev))

Handling expansions of mail aliases.

>     (require 'mail-parse)

For parsing and encoding headers and body correctly.

>     (require 'mml)

Required for MIME handling (e.g. sending attachments).

>     (require 'rfc822)

[rfc822.el is not part of Gnus, but part of Emacs.]  Uses to ensure that
address headers are RFC822-compliant.  Is also used in rmail.el.

>     (require 'ecomplete)

We can eliminate these by using autoloads.  ecomplete is optional.

> I don't want to replace the simple sendmail.el with this tremendous
> pile of complexity.
>
> message.el is also 8000 lines long, where sendmail.el is under 2000
> lines.  I expect that sending attachments won't require more than 200
> lines.

Doing all aspects of MIME mostly correct is not quite simple.  Many
MUAs (Mail User Agent) have severe bugs WRT this.  When reading about
non-trivial topics in the relevant newsgroups, most of the time only
mutt and Gnus do the right thing.

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

Re: message-mode / mail-mode

[Reiner Steib]

On Sun, Jul 05 2009, Stefan Monnier wrote:
> Miles Bader wrote:
>> Teemu Likonen <tlikonen@iki.fi> 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/

Re: message-mode / mail-mode

[Stefan Monnier]

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

message-mode should accept both the empty line and "--text follows this
line--" as a header-terminator.


        Stefan

rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Reiner Steib]

On Sat, Jul 18 2009, Richard Stallman wrote:

> rfc2047.el depends on some substantial code in mm-util.el:
> mm-charset-to-coding-system and mm-find-mime-charset-region.  I cannot
> understand that code, and I am not sure what it is trying to do.  I
> understand the doc strings, but they explain only in vague terms.

Please elaborate what is not clear...

,----[ <f1> f mm-find-mime-charset-region RET ]
| mm-find-mime-charset-region is a compiled Lisp function in `mm-util.el'.
| (mm-find-mime-charset-region B E &optional HACK-CHARSETS)
| 
| Return the MIME charsets needed to encode the region between B and E.
| nil means ASCII, a single-element list represents an appropriate MIME
| charset, and a longer list means no appropriate charset.
`----

,----[ <f1> f mm-charset-to-coding-system RET ]
| mm-charset-to-coding-system is a compiled Lisp function in `mm-util.el'.
| (mm-charset-to-coding-system CHARSET &optional LBT ALLOW-OVERRIDE SILENT)
| 
| Return coding-system corresponding to CHARSET.
| CHARSET is a symbol naming a MIME charset.  [...]
`----

MIME charsets are not the same as (Emacs) coding systems.  This
function does the mapping and also handles overrides (many MUAs
specify wrong charsets), invalid charsets, etc.

> Can you separate out that functionality into a file by itself, which
> does not depend on the rest of Gnus, and clean it up and/or add
> comments so that it is clear?

rfc2047.el implements (one of) the MIME standards.  mm-utils.el
contains utility functions for MIME.  I.e. they are closely related.
I'm not sure it is worth to separate out parts of it.

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

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Richard Stallman]

    > rfc2047.el depends on some substantial code in mm-util.el:
    > mm-charset-to-coding-system and mm-find-mime-charset-region.  I cannot
    > understand that code, and I am not sure what it is trying to do.  I
    > understand the doc strings, but they explain only in vague terms.

    Please elaborate what is not clear...

If only a piece of it were unclear, that would be a reasonable question.
However, the problem is that I can't even begin to understand most
of those functions.  The necessary info is not present.

    MIME charsets are not the same as (Emacs) coding systems.  This
    function does the mapping and also handles overrides (many MUAs
    specify wrong charsets), invalid charsets, etc.

That is just the beginning of the necessary explanation for
understanding what this code does.  To state the purpose in general
terms like this is not enough.

To make the code clear means explaining the specifics of what it does.
Each group of a few lines needs comments to explain why those lines
are there.  Lots of background information needs to be provided.

    rfc2047.el implements (one of) the MIME standards.  mm-utils.el
    contains utility functions for MIME.  I.e. they are closely related.

Only part of mm-utils.el is closely related to rfc2047.el.  That part
is what I am talking about here.  It consists of the two functions
mm-find-mime-charset-region and mm-charset-to-coding-system, and their
subroutines and data.

    I'm not sure it is worth to separate out parts of it.

I don't think you and I are talking about the same "it".  The things
you think I want to separate, actually I want to keep together.

I am going to move rfc20457.el outside Gnus to make it a regular part
of Emacs.

What I want to do is keep the two functions
mm-find-mime-charset-region and mm-charset-to-coding-system (and their
subroutines and data) together with rfc2047.el, making them too a
regular part of Emacs.  This requires separating them from the rest of
mm-utils.el which will remain inside Gnus.  It also requires making
them clean and understandable.

I am asking Gnus developers to help me by do this by splitting mm-utils
and cleaning up this part.

If I have to do this on my own, then since I can't understand all the
code of these functions, I will have to delete parts of the code until
I can understand what remains.  Some features will be lost, but at
least it will be clear and maintainable.  Whatever features I had to
discard could be re-added later if someone can write them cleanly.

However, if you help, maybe we can achieve a better outcome in which
we get clean code that implements all the existing features of
mm-charset-to-coding-system and mm-find-mime-charset-region, and thus
have no inconvenience for anyone.

Re: rfc2047.el dependencies on mm-util.el

[Stefan Monnier]

> If only a piece of it were unclear, that would be a reasonable question.
> However, the problem is that I can't even begin to understand most
> of those functions.  The necessary info is not present.

I'm not familar with those functions, but they don't look particularly
unclear to me.  So I don't know what "necessary info" you're looking for.

>     rfc2047.el implements (one of) the MIME standards.  mm-utils.el
>     contains utility functions for MIME.  I.e. they are closely related.

> Only part of mm-utils.el is closely related to rfc2047.el.  That part
> is what I am talking about here.  It consists of the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system, and their
> subroutines and data.

They're used in other places as well (basically to encode message
bodies), so they don't really belong to rfc2047.el.

> I am going to move rfc20457.el outside Gnus to make it a regular part
> of Emacs.

It's been part of Emacs since Emacs-21.  And I don't think you can
prevent the Gnus maintainers from distributing rfc2047.el along
with Gnus.

> What I want to do is keep the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system (and their
> subroutines and data) together with rfc2047.el, making them too
> a regular part of Emacs.  This requires separating them from the rest
> of mm-utils.el which will remain inside Gnus.  It also requires making
> them clean and understandable.

Rather than focus on code-ownership, I'd rather we focus on this latter
part: "clean and understandable".

> I am asking Gnus developers to help me by do this by splitting mm-utils
> and cleaning up this part.

Maybe one way to look at it is to split mm-utils.el into a part that
deals with compatibility between different Emacsen
(e.g. mm-string-to-multibyte) and the other that provides actual
functionality (e.g. mm-find-mime-charset-region).

I'm still wondering why someone would want to do that since it seems
pretty far from the goal of improving the user's experience.
IOW, another way to look at this problem would be: what changes would it
take to make Rmail use message-mode for composition?  I'm sure this will
take less time and make more people happier.


        Stefan

Re: rfc2047.el dependencies on mm-util.el

[Richard Stallman]

    I'm not familar with those functions, but they don't look particularly
    unclear to me.

If you can manage to understand them, can you please add comments explaining
their code clearly?

    > Only part of mm-utils.el is closely related to rfc2047.el.  That part
    > is what I am talking about here.  It consists of the two functions
    > mm-find-mime-charset-region and mm-charset-to-coding-system, and their
    > subroutines and data.

    They're used in other places as well (basically to encode message
    bodies), so they don't really belong to rfc2047.el.

I would not say they "belong to" it, but they are closely related to
it.

    > I am going to move rfc20457.el outside Gnus to make it a regular part
    > of Emacs.

    It's been part of Emacs since Emacs-21.

I am going to make it a regular part of Emacs -- no longer part of Gnus.

      And I don't think you can
    prevent the Gnus maintainers from distributing rfc2047.el along
    with Gnus.

I have no wish to stop them.  I'm concerned with what's in Emacs.  How
Gnus is distributed outside of Emacs is not the issue.

      This requires separating them from the rest
    > of mm-utils.el which will remain inside Gnus.  It also requires making
    > them clean and understandable.

    Rather than focus on code-ownership, I'd rather we focus on this latter
    part: "clean and understandable".

Part of making them clean and understandable is making the code not
depend on Gnus.

This won't stop Gnus from using these facilities.  It could use them
just as it uses any other Emacs facilities.

    Maybe one way to look at it is to split mm-utils.el into a part that
    deals with compatibility between different Emacsen
    (e.g. mm-string-to-multibyte) and the other that provides actual
    functionality (e.g. mm-find-mime-charset-region).

That could be the first step.  Then the next step is to make the
second part clear and independent of Gnus.

    I'm still wondering why someone would want to do that since it seems
    pretty far from the goal of improving the user's experience.

The goal is to move rfc2047.el outside of Gnus so that other parts
of Emacs can use it without using Gnus.

Re: rfc2047.el dependencies on mm-util.el

[Stefan Monnier]

>     I'm not familar with those functions, but they don't look particularly
>     unclear to me.

> If you can manage to understand them, can you please add comments explaining
> their code clearly?

Not really, because I don't know what's unclear about it.

>> I am going to move rfc20457.el outside Gnus to make it a regular part
>> of Emacs.
>     It's been part of Emacs since Emacs-21.
> I am going to make it a regular part of Emacs

I don't know what that means.

> -- no longer part of Gnus.

Isn't this out of your control?

>       And I don't think you can prevent the Gnus maintainers from
>     distributing rfc2047.el along with Gnus.
> I have no wish to stop them.  I'm concerned with what's in Emacs.  How
> Gnus is distributed outside of Emacs is not the issue.

Then I don't know what you mean by "no longer part of Gnus".

>     Rather than focus on code-ownership, I'd rather we focus on this latter
>     part: "clean and understandable".
> Part of making them clean and understandable is making the code not
> depend on Gnus.

What do you mean by "Gnus" in this context?  E.g., in my view,
mm-util.el is not part of Gnus (C-s gnus in this file shows it does
appear, but mostly in comments).

>     I'm still wondering why someone would want to do that since it seems
>     pretty far from the goal of improving the user's experience.
> The goal is to move rfc2047.el outside of Gnus so that other parts
> of Emacs can use it without using Gnus.

These words don't mean much to me since AFAICT rfc2047.el is already
independent from Gnus.


        Stefan

Re: rfc2047.el dependencies on mm-util.el

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I am going to make it a regular part of Emacs
>
> I don't know what that means.
>
>> -- no longer part of Gnus.
>
> Isn't this out of your control?

I think Richard is talking about moving the rfc2047.el file outside of
the gnus/ directory in Emacs.

-- 
 Bastien

Re: rfc2047.el dependencies on mm-util.el

[Chong Yidong]

Bastien <bastienguerry@googlemail.com> writes:

> I think Richard is talking about moving the rfc2047.el file outside of
> the gnus/ directory in Emacs.

If the Gnus maintainers are actively maintaining and developing the
rfc*.el files, it's not worthwhile to move those files from gnus/ into
net/, if that would make it harder for them to do thir job (due to the
repository synch issues etc.)  But if these files are more or less
"stable", then I don't see why not.

In the meantime, there's no reason to avoid `require'ing a package just
because that package happens to live in the gnus/ directory.

Re: rfc2047.el dependencies on mm-util.el

[Richard Stallman]

    In the meantime, there's no reason to avoid `require'ing a package just
    because that package happens to live in the gnus/ directory.

Indeed, the reason isn't tht it's in `gnus', but rather that it is
part of Gnus and dependent on lots of other parts of Gnus.

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 19 Jul 2009 00:36:49 -0400
> Cc: tzz@lifelogs.com, ding@gnus.org, emacs-devel@gnu.org
> 
> What I want to do is keep the two functions
> mm-find-mime-charset-region and mm-charset-to-coding-system (and their
> subroutines and data) together with rfc2047.el, making them too a
> regular part of Emacs.

Do we really need these two functions?  I think we have the necessary
infrastructure in Emacs:

  . find-charset-region

  . find-coding-systems-region

  . find-coding-systems-for-charsets

  . (coding-system-get FOO :mime-charset)

  . coding-system-list

  . sort-coding-systems

If these are not enough to write a much cleaner, leaner versions of
those two mm-utils functions, please tell what else is missing.

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Richard Stallman]

    > What I want to do is keep the two functions
    > mm-find-mime-charset-region and mm-charset-to-coding-system (and their
    > subroutines and data) together with rfc2047.el, making them too a
    > regular part of Emacs.

    Do we really need these two functions?  I think we have the necessary
    infrastructure in Emacs:

      . find-charset-region

      . find-coding-systems-region
    ...

I don't know whether they do 100% of the job.  I asked Handa basically
that question a week ago, but he has not answered yet.

I have been working on extracting the actually needed parts of mm-util.el.
That code often consists of wrappers around these standard functions.
But it does not have comments explaining why do something different,
or which cases  are intended to get different treatment, etc.

Re: rfc2047.el dependencies on mm-util.el (was: Sending attachments)

[Kevin Ryde]

Eli Zaretskii <eliz@gnu.org> writes:
>
> necessary infrastructure in Emacs:

And of course locale-charset-to-coding-system.  I've had some joy with
that on mime-ish names, doing the job of mm-charset-to-coding-system.

In bits of my code I've called locale- when available (emacs 22 up),
then try the mm-.  The mm- one has more variables to setup synonyms and
aliasing, but locale- might cover much of that already (and not need the
`codepage-setup' stuff for msdos any more at all).