Sending attachments

[Eli Zaretskii]

> From: Stefan Monnier <monnier@...>
> Cc: Miles Bader <miles@...>,  cyd@...,  rms@...,  emacs-devel@...
> Date: Sat, 11 Jul 2009 14:50:59 -0400
>
> > My gray hair says there ain't no such thing.  If it's more powerful
> > and sophisticated, there's some price to pay.
>
> So your argument is hypothetical, rather than based on concrete
> problems.

Not hypothetical, based on experience.

> To me that counts as "one vote to make mail-mode obsolete".

Yes, I used to hold such naive ideas as well: that an argument isn't
valid unless it is based on provable facts.  I'm much better now,
thank you.

[leon-9]

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

[Lennart Borgman (gmail)]

On Sun, Jul 12, 2009 at 5:05 AM, Leo<sdl.web@...> 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.

[Richard Stallman]

    Why not?  More specifically, what do you think would break if we did
    something along the lines of:

       (define-obsolete-function-alias 'mail-mode 'message-mode)

I may need to maintain Emacs again; past history shows other
maintainers come and go.  If that happens, I want to have Mail mode,
not depend on something that is part of Gnus.

Please don't mess this up.


I am considering moving some code (including mml) outside Gnus so that
Gnus will not be an issue for its future maintenance.  (I've done that
to other packages before.)

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

[Stefan Monnier]

>     Why not?  More specifically, what do you think would break if we did
>     something along the lines of:
>        (define-obsolete-function-alias 'mail-mode 'message-mode)
> I may need to maintain Emacs again; past history shows other
> maintainers come and go.  If that happens, I want to have Mail mode,
> not depend on something that is part of Gnus.

Please explain why you consider "part of Gnus" to be a negative attribute.

> I am considering moving some code (including mml) outside Gnus so that
> Gnus will not be an issue for its future maintenance.  (I've done that
> to other packages before.)

As I said, making message-mode (and related libraries) more generic
is good.  I fully support it, and I think the Gnus maintainers would
not oppose it either.


        Stefan

[Richard Stallman]

    > I may need to maintain Emacs again; past history shows other
    > maintainers come and go.  If that happens, I want to have Mail mode,
    > not depend on something that is part of Gnus.

    Please explain why you consider "part of Gnus" to be a negative attribute.

There are two reasons.  First, its primary source is maintained
outside of Emacs.  Second, the people who work on it do not hesitate
to add dependencies between one part and another, with results that
one quickly sees on studying files from Gnus.

Another problem with Gnus maintenance is that, whenever they see the
need for some other feature, they add it to Gnus, without discussing
it with the Emacs maintainer, and without attempting to make the
package independent of Gnus.

Another problem is that a lot of the code is ugly and hard to
understand.  While this CAN happen to any code, I think the separate
maintenance of Gnus encourages it, since it discourages other people
than the Gnus developers from working on the code at all.

I decided to make rfc2047.el work outside Gnus.  Most of the
dependence on other Gnus files existed for no good reason at all.
However, a couple of functions in mm-util do real work that seems
important.  They are a specialized facility in the same file with lots
of low-level XEmacs compatibility functions used in Gnus.  Perhaps I
will just split that file.

[leon-9]

On 2009-07-14 11:44 +0100, Richard Stallman wrote:

> There are two reasons. First, its primary source is maintained outside
> of Emacs. Second, the people who work on it do not hesitate to add
> dependencies between one part and another, with results that one
> quickly sees on studying files from Gnus.
>
> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.
>
> Another problem is that a lot of the code is ugly and hard to
> understand. While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.
>
> I decided to make rfc2047.el work outside Gnus. Most of the dependence
> on other Gnus files existed for no good reason at all. However, a
> couple of functions in mm-util do real work that seems important. They
> are a specialized facility in the same file with lots of low-level
> XEmacs compatibility functions used in Gnus. Perhaps I will just split
> that file.

What Richard has said makes a lot of sense. There are different
standards on the quality of code that can be included in Emacs.
Unfortunately many think that 'it works' is the standard. Also many libs
stop developing because they have been included. We shouldn't be afraid
to recycle them if that's where they belong.

--
Leo's Emacs uptime: 33 days, 23 hours, 24 minutes, 49 seconds

[Stephen J. Turnbull-2]

Richard Stallman writes:

 > There are two reasons.  First, its primary source is maintained
 > outside of Emacs.

I don't see how that's a reason not to use the perfectly good Message
mode that is a part of Emacs.  If you can't persuade them to go along
with your refactorings, you still will be starting from a much more
featureful MUA, one which is well-debugged and highly conformant.

 > Another problem is that a lot of the code is ugly and hard to
 > understand.  While this CAN happen to any code, I think the
 > separate maintenance of Gnus encourages it, since it discourages
 > other people than the Gnus developers from working on the code at
 > all.

That's certainly not my experience.  I'd say about half of the hackers
closest to me over the last 10 years have been at least occasional
contributors to Gnus.  And they've been really good citizens in
general even though their main interests are rather different from
"core" Emacs developers.

It seems to me that both Gnus and Emacs would benefit from you
pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
integration, and make the points about refactoring and maintainability
to them.  Ask them to represent your needs (ie, only the basic
features, more emphasis on refactoring and maintainability in Message
mode).  It's worth trying to avoid the duplication, for Message mode,
at least.

[Jonathan Rockway]

* On Tue, Jul 14 2009, Richard Stallman wrote:

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.

I think they want something that works first.  Once the code works, it
can be refactored to be generic.

Some people don't want to discuss every minute detail of the code before
they implement it.  The bike shed can be painted after it's built.

(Look at how long this thread is.  Did all this discussion actually
accomplish anything, or was it mostly a waste of time?)

Anyway, I think the solution is to cleanup the Gnus code as needed
rather than completely rewrite it from scratch and call it something
else.  I can't speak for the Gnus developers, but I'm sure they would
appreciate the help.  The point of free software is that the users can
improve the code; so that it works better, or so that it can be used
somewhere else more generically.  Right?

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

[Bastien-7]

Richard Stallman <rms@...> writes:

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.
>
> Another problem is that a lot of the code is ugly and hard to
> understand.  While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.

Would Gnus maintainers strongly resist to the idea of maintaining Gnus
within Emacs?  

--
 Bastien

[Stefan Monnier]

>> I may need to maintain Emacs again; past history shows other
>> maintainers come and go.  If that happens, I want to have Mail mode,
>> not depend on something that is part of Gnus.

>     Please explain why you consider "part of Gnus" to be
>     a negative attribute.

> There are two reasons.  First, its primary source is maintained
> outside of Emacs.  Second, the people who work on it do not hesitate
> to add dependencies between one part and another, with results that
> one quickly sees on studying files from Gnus.

I'm sure they'll appreciate help in reducing dependencies between modules.

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.

Actually, they originally did make a specific effort to make
message-mode independent from Gnus so that it can replace mail-mode.
And then mail-mode stayed and so message-mode evolved under the pressure
of nothing else than Gnus.

> Another problem is that a lot of the code is ugly and hard to
> understand.  While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.

I don't know about you, but I'm a lot more afraid of CC-mode's code than
of Gnus's.  If you agree with that and following your reasoning, we
should have kept the old c-mode.el.


        Stefan

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

[Richard Riley-4]

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

[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

[Ted Zlatanov]

On Tue, 14 Jul 2009 11:17:33 -0500 Jonathan Rockway <jon@...> wrote:

JR> * On Tue, Jul 14 2009, Richard Stallman wrote:

>> Another problem with Gnus maintenance is that, whenever they see the
>> need for some other feature, they add it to Gnus, without discussing
>> it with the Emacs maintainer, and without attempting to make the
>> package independent of Gnus.

JR> Anyway, I think the solution is to cleanup the Gnus code as needed
JR> rather than completely rewrite it from scratch and call it something
JR> else.  I can't speak for the Gnus developers, but I'm sure they would
JR> appreciate the help.  The point of free software is that the users can
JR> improve the code; so that it works better, or so that it can be used
JR> somewhere else more generically.  Right?

(speaking as a Gnus and Emacs contributor)

Right.  I have not seen anything concrete about what needs to be fixed,
refactored, etc. in Gnus.  There aren't many developers actively
contributing to Gnus, either, so making major changes will take a long
time and needs to be well-justified.  Gnus welcomes new developers with
open hooves...er...arms, but the code complexity is probably
intimidating to most.

Pulling code out of Gnus has the downside that it then needs to be
inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
long as I can remember) been a Gnus goal.  How should Gnus and Emacs
deal with this?  I hope "drop XEmacs support" is not an option.

Ted

[Frank Schmitt]

Ted Zlatanov <tzz@...> writes:

> Pulling code out of Gnus has the downside that it then needs to be
> inside Emacs, but XEmacs may not have it.  XEmacs compatibility has (as
> long as I can remember) been a Gnus goal.  How should Gnus and Emacs
> deal with this?  I hope "drop XEmacs support" is not an option.

Is XEmacs compatibility really worth the trouble? How many XEmacs users
are still out there?

--
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

[Stefan Monnier]

> Pulling code out of Gnus has the downside that it then needs to be
> inside Emacs, but XEmacs may not have it.

Don't worry about this part: the changes (supposedly) needed don't
intend to remove any code, just better modularize it (e.g. so that
message-mode can be self-standing without importing (transitively)
gnus-*.el packages).


        Stefan

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

[Richard Stallman]

     > There are two reasons.  First, its primary source is maintained
     > outside of Emacs.

    I don't see how that's a reason not to use the perfectly good Message
    mode that is a part of Emacs.

Someone asked me why I see this as a problem, and I explained why.
You may not see it as a problem, but the point is that I do.

    It seems to me that both Gnus and Emacs would benefit from you
    pow-wowing with Miles Bader and anybody else who works on Gnus-Emacs
    integration, and make the points about refactoring and maintainability
    to them.

I would like to see progress in this direction, and I am willing to do
a certain amount of work to help it.  However, at present I have
nothing to specific suggest, because I know very little about the code
of Gnus.  Its complexity has discouraged me from looking at it except
in cases of need.

On a few occasions I have looked at part of Gnus.  Each time what I
encountered was daunting complexity, each part interacting with many
other parts.  I tried my best to reduce the amount of code I had to
look at.

I don't know how many other parts of Gnus are comparable to rfc2047.el
in that they are useful general facilities and ought to be made
separate and modular.  If Gnus developers are interested in doing work
to make these files modular, I'm interested in looking for candidates.