emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: rfc2047.el dependencies on mm-util.el
Date: Sun, 19 Jul 2009 01:30:58 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]