Re: [rmail-mbox-branch]: mail-utils

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 01:34:49AM +0200, Alexander Pohoyda wrote:
> > The mm- stuff seems not to be intended to be gnus-specific, but rather
> > general-purpose code for handling mime that happens to be developed as part
> > of gnus.
> 
> Yes, I understand the intention.
> 
> 
> > There are probably a few dependencies on gnus that have crept in, but I
> > presume these could be excised.
> 
> Some mm-*.el files use quite often functions or constants with gnus-
> prefix.

Can you be more specific?  I did a grep, and the dependencies seem pretty
much restricted to a few files (e.g., mm-view.el); the most general mime
functionality seems pretty clean at first glance.

Note that some places the mm- stuff has code of the form:

  (if (or (eq foo ...) (eq foo ...) (eq foo 'gnus-magic-constant))
     ...)

But this sort of thing is perfectly fine -- it's not really a dependency at
all, because all it does is tweak the behavior specially for gnus in some
way.

> I would like to have a clean MIME library first.

Sure, and the mm- stuff seems like the right to start from.  It would
completely silly to reimplement all of it when mm- is pretty close to what
you want anyway.

Maybe I'm wrong, but if so, please give details, don't just assert it.

Thanks,

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

Miles Bader <miles@gnu.org> writes:

> On Sat, Oct 09, 2004 at 01:34:49AM +0200, Alexander Pohoyda wrote:
> > > The mm- stuff seems not to be intended to be gnus-specific, but rather
> > > general-purpose code for handling mime that happens to be developed as part
> > > of gnus.
> > 
> > Yes, I understand the intention.
> > 
> > 
> > > There are probably a few dependencies on gnus that have crept in, but I
> > > presume these could be excised.
> > 
> > Some mm-*.el files use quite often functions or constants with gnus-
> > prefix.
> 
> Can you be more specific?  I did a grep, and the dependencies seem pretty
> much restricted to a few files (e.g., mm-view.el);

Yes, there are only very few cases:

mm-partial.el:(require 'gnus-sum)
mm-partial.el:             (set-buffer gnus-summary-buffer)
mm-partial.el:    (gnus-request-article-this-buffer (aref header 0)
mm-partial.el:                     (gnus-summary-article-number))))
mm-partial.el:      (setq gnus-article-mime-handles
mm-partial.el:      (append (if (listp (car gnus-article-mime-handles))
mm-partial.el:                  gnus-article-mime-handles
mm-partial.el:                (list gnus-article-mime-handles))
mm-partial.el:      (run-hooks 'gnus-article-decode-hook)
mm-partial.el:      (gnus-article-prepare-display)

mm-uu.el:  :group 'gnus-article-mime)

mm-view.el:  (autoload 'gnus-article-prepare-display "gnus-art")
mm-view.el:       (run-hooks 'gnus-article-decode-hook)


My primary concern, however, is that mm- stuff is rather a MIME
parser (viewer), while rfc*.el files implement basic functions.
Wouldn't it be good to have these two things clearly separated?

If we don't separate mm- and basic MIME functions, and if we don't
move them out of gnus directory, people will continue to re-implement
basic functions.

Do you know of any good reason to have the mm-* stuff used in rfc*
files?

Anyway, we need MIME support in Rmail.  Would it be correct to make
Rmail depend on file from Gnus directory?  My idea is to move MIME
stuff into lisp/mail(/mime?) directory.  Both Gnus and Rmail could use
these basic functions.  All I propose to move, are few files:
    lisp/gnus/rfc2045.el
    lisp/gnus/rfc2047.el
    lisp/gnus/rfc2231.el
leaving mm-* files intact.  What exactly do you disagree with?

> > I would like to have a clean MIME library first.
> 
> Sure, and the mm- stuff seems like the right to start from.

By "MIME library" I mean functions like
    rfc2045-qp-decode-string,
    rfc2231-decode-string,
    rfc2047-decode-region
but not
    mm-inline-partial,
    mm-inline-image-xemacs,
    mm-setup-w3, 
    mm-inline-message

> would completely silly to reimplement all of it when mm- is pretty
> close to what you want anyway.

People may have their own ideas how to use MIME, let's not force them
to use mm- as a bonus.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Stefan]

> My primary concern, however, is that mm- stuff is rather a MIME
> parser (viewer), while rfc*.el files implement basic functions.
> Wouldn't it be good to have these two things clearly separated?

I guess I'd agree with the following:
- changes that remove dependencies from rfc* to mm*
- changes that remove dependencies from mm* to gnus*
- moving rfc* and mm* files from gnus/ to mail/

I don't see a strong need to create a mime-only subdirectory (of course
mail/mime is even worse since we currently only support one level of
subdirectory).


        Stefan

Re: [rmail-mbox-branch]: mail-utils

[Alexander Pohoyda]

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

> > My primary concern, however, is that mm- stuff is rather a MIME
> > parser (viewer), while rfc*.el files implement basic functions.
> > Wouldn't it be good to have these two things clearly separated?
> 
> I guess I'd agree with the following:
> - changes that remove dependencies from rfc* to mm*

Great!  I'll work out the patch.

> - changes that remove dependencies from mm* to gnus*

That would be another step, OK?

> - moving rfc* and mm* files from gnus/ to mail/

Good.  I'm only interested in rfc* files, so that's what I'm advocating.


> I don't see a strong need to create a mime-only subdirectory (of course
> mail/mime is even worse since we currently only support one level of
> subdirectory).

OK, no problems, I agree to what you say.

Just for my education, what's the problem with two level directories? 


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 08:15:40PM +0200, Alexander Pohoyda wrote:
> > - changes that remove dependencies from rfc* to mm*
> 
> Great!  I'll work out the patch.

Please CC your patch to the ding list <ding@gnus.org>.

Thanks,

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sat, Oct 09, 2004 at 11:02:03PM +0200, Alexander Pohoyda wrote:
> > > Great!  I'll work out the patch.
> > 
> > Please CC your patch to the ding list <ding@gnus.org>.
> 
> Will do.  Does this mean that you agree with the separation now?

I have no objection to moving files around, or to removing unnecessary
dependencies.  The hierarchy (gnus -> mm -> rfc*) is reasonable.

Some care should be taken to not step on Gnus' toes -- e.g., if some rfc*.el
file uses a mm- function for a good reason, instead of just removing the
functionality, it should be replaced with something like a callback or
something.

Anyway, it's easier to talk with a patch.

Thanks,

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

I wrote:
> I have no objection to moving files around, or to removing unnecessary
> dependencies.  The hierarchy (gnus -> mm -> rfc*) is reasonable.

Oh, BTW, of course the files should probably stay in their current location
in the Gnus distribution -- the renaming will only effect their location
within the Emacs source tree.

-Miles
-- 
Would you like fries with that?

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    Oh, BTW, of course the files should probably stay in their current location
    in the Gnus distribution -- the renaming will only effect their location
    within the Emacs source tree.

If some files from Gnus are moved out of the gnus subdirectory, that
means we will maintain them as ordinary parts of Emacs.

It is fine if Gnus developers copy changes from these files, and
contribute changes to them.  But they can't just install new
versions of them as they do with the Gnus files.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

On Sun, Oct 10, 2004 at 11:15:51AM -0400, Richard Stallman wrote:
>     Oh, BTW, of course the files should probably stay in their current
>     location in the Gnus distribution -- the renaming will only effect
>     their location within the Emacs source tree.
> 
> If some files from Gnus are moved out of the gnus subdirectory, that
> means we will maintain them as ordinary parts of Emacs.
> 
> It is fine if Gnus developers copy changes from these files, and
> contribute changes to them.  But they can't just install new
> versions of them as they do with the Gnus files.

I'm not sure what the difference between "contribute new changes" and
"install new versions" is.  Do you mean that a patch from a gnus maintainer
would have to be posted to the mailing list to be put into emacs (unlike Gnus
changes)?

I don't like such a distinction in principle, as it has the potential be
extremely annoying for me (as the person who is currently dealing with
interfacing Gnus and Emacs).  However I'm not if it's would be a problem in
practice, because the Gnus branch Emacs is using is relatively slowly
changing: I would likely implement such a restriction simply by giving any
Gnus changes to "non-Gnus" files a more thorough examination -- and expect
that mostly they would be perfectly fine (minor bugfixes and the like) and
apply them.

I'll it up to the Gnus maintainers to comment on Alexander's (forthcoming)
patch in light of this.  If these files are mature enough that they should
rarely be changed, there may be no problem.

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

Re: [rmail-mbox-branch]: mail-utils

[Richard Stallman]

    I'm not sure what the difference between "contribute new changes" and
    "install new versions" is.

In the gnus directory, the Gnus developers occasionally copy in new
versions of the files.  (They look first for changes on our side that
ought not to be lost.)  But they should not do this for files
outside the gnus directory.

    Do you mean that a patch from a gnus maintainer would have to be
    posted to the mailing list to be put into emacs (unlike Gnus
    changes)?

I mean they should treat these files the same way they treat all the
other Lisp files that are not part of Gnus.  That does not mean ALL
changes have to be discussed.  They can install local uncontroversial
bug fixes without discussion, just as any of us would.  However,
beyond that, they ought to post on this list.

Re: [rmail-mbox-branch]: mail-utils

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Do you mean that a patch from a gnus maintainer would have to be
>     posted to the mailing list to be put into emacs (unlike Gnus
>     changes)?
>
> I mean they should treat these files the same way they treat all the
> other Lisp files that are not part of Gnus.  That does not mean ALL
> changes have to be discussed.  They can install local uncontroversial
> bug fixes without discussion, just as any of us would.  However,
> beyond that, they ought to post on this list.

Ok, that sounds reasonable, and workable in practice for my Gnus-syncing.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Syncing Gnus with Emacs and back (was: [rmail-mbox-branch]: mail-utils)

[Reiner Steib]

On Tue, Oct 12 2004, Miles Bader wrote:

> On Tue, Oct 12, 2004 at 05:42:38PM +0300, Juri Linkov wrote:
[...]
>> There are other Gnus files in Emacs outside the gnus directory:
>> gnus.texi, gnus-faq.texi, message.texi + some other texi files in the
>> emacs/man directory.
>> 
>> Miles, are changes made in these files in Emacs CVS synced automagically
>> with the Gnus CVS repository?
>
> Yes; these files are clearly part of Gnus, so it would be absurd to
> not do so.

I saw that you have synced my recent changes from Gnus to Emacs, but
Juri's recent changes in emacs/man/gnus.texi haven't made it from
Emacs to Gnus (v5-10 and trunk).

There are also some changes in v5-10/texi/ that are not yet synced to
the Gnus trunk and to emacs/man.  (Sorry to bother you in case you are
already aware of it.)

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

Re: Syncing Gnus with Emacs and back

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> I saw that you have synced my recent changes from Gnus to Emacs, but
> Juri's recent changes in emacs/man/gnus.texi haven't made it from
> Emacs to Gnus (v5-10 and trunk).

I do Emacs->Gnus less often (than Gnus->Emacs) because it tends to
require more manual work.

By default I sync about once a week.  I also try to follow any Gnus
threads on the mailing lists and make sure any changes being discussed
are kept more up-to-date (so say 1-2 days delay for "topical" changes).

> There are also some changes in v5-10/texi/ that are not yet synced to
> the Gnus trunk and to emacs/man.  (Sorry to bother you in case you are
> already aware of it.)

Ok, I've synced up everything I know about.  If there's anything still
missing, let me know (that would probably mean I messed up resolving a
conflict or something).

Thanks,

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Syncing Gnus with Emacs and back

[Reiner Steib]

On Wed, Oct 13 2004, Miles Bader wrote:

> I do Emacs->Gnus less often (than Gnus->Emacs) because it tends to
> require more manual work.
>
> By default I sync about once a week.  I also try to follow any Gnus
> threads on the mailing lists and make sure any changes being discussed
> are kept more up-to-date (so say 1-2 days delay for "topical" changes).

Sounds good.  Thanks for the explanation.

> Ok, I've synced up everything I know about.  If there's anything still
> missing, let me know (that would probably mean I messed up resolving a
> conflict or something).

One change in gnus-faq.texi needs to be synced from v5-10 to
emacs/man: revision 6.19.2.5 (Gnus CVS) is missing.  I think this
corresponds to miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-46.

BTW, a disadvantage of the arch syncing is that e.g. in the cvs log of
texi/gnus-faq.texi we get the following:

,----[1]
| revision 7.5
| date: 2004/10/13 01:27:08;  author: miles;  state: Exp;  lines: +7 -4
| Revision: miles@gnu.org--gnu-2004/gnus--devo--0--patch-145
| 
| Merge from gnus--rel--5.10
| 
| Patches applied:
| 
|  * miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-46
|    Update from CVS
`----

The original commit had the following log message:

,----[2]
| revision 6.19.2.5
| date: 2004/10/12 15:54:46;  author: rsteib;  state: Exp;  lines: +7 -4
| ([5.9]): Improve code for reply-in-news.
`----

In [1], there is no indication what this changes is about.  People
need to find and read the ChangeLog entry to find out what has been
changed.  It would be nice if the original log message could be
included.

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

Re: Syncing Gnus with Emacs and back

[Miles Bader]

On Wed, Oct 13, 2004 at 10:21:42PM +0200, Reiner Steib wrote:
> BTW, a disadvantage of the arch syncing is that e.g. in the cvs log of
> texi/gnus-faq.texi we get the following:
...
> It would be nice if the original log message could be included.

A pretty basic constraint though is that all the files have to have the same
log message (it's a changeset log, not a file change log).  Furthermore it's
probably not practical to base this on CVS log messages[*].

However I've had pretty good success using "ChangeLog-changes" for this
purpose when generating log messages for emacs.  ChangeLog-changes are the
additions to all ChangeLogs, i.e., do a diff of all ChangeLogs, look for "+"
lines, and tweak them to be prettier -- it basically ends up looking like a
big ChangeLog entry for all files in the changeset.

[*] Several reasons: (1) CVS makes it quite difficult to retrieve the precise
log messages corresponding to an update, and (2) The CVS log messages for all
changed files would have to be combined, and getting a usable (not ugly and
bloated) result from this doesn't look at all easy given the typically
inconsistent log messages people use.

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Syncing Gnus with Emacs and back

[Miles Bader]

Ok, I've implemented something so that future merges into Gnus, and into
the Emacs trunk[*] will have log messages like:

   Merge from $MERGE_VERSION

   $MERGE_LOG

   $CHANGELOG

Where $MERGE_LOG is the same sort of log that has been used up until
now, and $CHANGELOG is an aggregation of any new ChangeLog entries
present in the merge.

[*] Merges into Emacs branches will _not_ use this style; I thought they
might be too verbose, as such merges tend to contain large numbers of
changes, so such an aggregate changelog is less useful.

-Miles
-- 
We live, as we dream -- alone....

Re: [rmail-mbox-branch]: mail-utils

[Stefan]

>> I don't see a strong need to create a mime-only subdirectory (of course
>> mail/mime is even worse since we currently only support one level of
>> subdirectory).

> OK, no problems, I agree to what you say.

I'm just yet-another-emacs-maintainer.  Only Richard can make final decisions.

> Just for my education, what's the problem with two level directories? 

Nothing serious.  It's just that the curent code doesn't support them.


        Stefan

Re: [rmail-mbox-branch]: mail-utils

[Simon Josefsson]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Wouldn't it be good to have these two things clearly separated?

I support this.  Although I don't know whether using mm is all that
problematic.  I don't think the user need to use mm just because
rfc*.el uses it.  Modularizing files from Gnus is generally a good
thing.

As an aside, Lars once said, on the topic of rfc*.el, that "RFCs
wither and die, lisp is forever", arguing against rfc*.el as the name
of lisp files.  Instead, the RFC 2047 functionality could be moved
into qp.el, RFC 2231 could be moved into (say) encoded-word.el, etc.
One reason is that RFC numbers are obsoleted once in a while.