Sending attachments

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

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

[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

[Bastien-7]

Stefan Monnier <monnier@...> 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

[Chong Yidong]

Bastien <bastienguerry@...> 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.

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

[Kevin Ryde]

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