Emacs 22 branch created.

Emacs 22 branch created.

[Chong Yidong]

I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
(I'm not sure of the reason for shouting, but it seems to be
traditional.)

Note that you need to use "-r EMACS_22_BASE" to apply your changes to
the branch.  If you want to work in the branch, I believe the easiest
way is to do

cvs up -r EMACS_22_BASE

in your working directory, which will move it to the branch;
subsequent commits will then apply to the branch.

Since the python.el issue doesn't seem likely to be resolved in the
near future, I will go ahead and remove it from the branch.  Then I
will roll the 22.0.99 pretest; it should come online in a couple of
hours.

Thanks.

Re: Emacs 22 branch created.

[Eric Lilja]

Chong Yidong wrote:
> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
> (I'm not sure of the reason for shouting, but it seems to be
> traditional.)

How do I perform a checkout from this branch? I used to do:
cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs

but I guess that would give me mainline sources now... I know little 
about cvs.

> 
> Note that you need to use "-r EMACS_22_BASE" to apply your changes to
> the branch.  If you want to work in the branch, I believe the easiest
> way is to do
> 
> cvs up -r EMACS_22_BASE
> 
> in your working directory, which will move it to the branch;
> subsequent commits will then apply to the branch.
> 
> Since the python.el issue doesn't seem likely to be resolved in the
> near future, I will go ahead and remove it from the branch.  Then I
> will roll the 22.0.99 pretest; it should come online in a couple of
> hours.
> 
> Thanks.

- Eric

Re: Emacs 22 branch created.

[Andreas Schwab]

Eric Lilja <mindcooler@gmail.com> writes:

> Chong Yidong wrote:
>> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
>> (I'm not sure of the reason for shouting, but it seems to be
>> traditional.)
>
> How do I perform a checkout from this branch? I used to do:
> cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs
>
> but I guess that would give me mainline sources now... I know little about
> cvs.

Just add -r EMACS_22_BASE after co.  See (cvs)checkout.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 22 branch created.

[Eric Lilja]

Andreas Schwab wrote:
> Eric Lilja <mindcooler@gmail.com> writes:
> 
>> Chong Yidong wrote:
>>> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
>>> (I'm not sure of the reason for shouting, but it seems to be
>>> traditional.)
>> How do I perform a checkout from this branch? I used to do:
>> cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs
>>
>> but I guess that would give me mainline sources now... I know little about
>> cvs.
> 
> Just add -r EMACS_22_BASE after co.  See (cvs)checkout.

Thanks for the quick reply, Mr Schwab! Seems to work just fine, 
performing checkout as I'm writing this and I'm eager to try out this 
new prerelease!

> 
> Andreas.
> 

- Eric

Re: Emacs 22 branch created.

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
> (I'm not sure of the reason for shouting, but it seems to be
> traditional.)
> 
> Note that you need to use "-r EMACS_22_BASE" to apply your changes to
> the branch.  If you want to work in the branch, I believe the easiest
> way is to do
> 
> cvs up -r EMACS_22_BASE
> 
> in your working directory, which will move it to the branch;
> subsequent commits will then apply to the branch.
> 
> Since the python.el issue doesn't seem likely to be resolved in the
> near future, I will go ahead and remove it from the branch.  Then I
> will roll the 22.0.99 pretest; it should come online in a couple of
> hours.


Thanks for this. Since I do not know anything about CVS branching I have 
to ask if the instructions on

   http://savannah.gnu.org/cvs/?group=emacs

still are correct. If I do "cvs up -r EMACS_22_BASE" how should I then 
continue fetching updates from the CVS? Is this ok then? :

   cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs

On one line. This is what is on the web page above now.

Re: Emacs 22 branch created.

[Leo]

----- Lennart Borgman (gmail) (2007-04-24) wrote:-----

> If I do "cvs up -r EMACS_22_BASE" how should I then
> continue fetching updates from the CVS? Is this ok then? :

I would also like to know.

>
>   cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co
>emacs

This will create another brand-new checkout, I guess.

>
> On one line. This is what is on the web page above now.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Emacs 22 branch created.

[Jason Rumney]

Leo wrote:
>> If I do "cvs up -r EMACS_22_BASE" how should I then
>> continue fetching updates from the CVS? Is this ok then? :
>>     
>
> I would also like to know.
>   

"cvs up" is sufficient to keep the working copy up to date. The -r 
option is "sticky", which means that once you've used it once, it is 
automatically assumed in future on that working copy.

Re: Emacs 22 branch created.

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Leo wrote:
>>> If I do "cvs up -r EMACS_22_BASE" how should I then
>>> continue fetching updates from the CVS? Is this ok then? :
>>>     
>>
>> I would also like to know.
>>   
> 
> "cvs up" is sufficient to keep the working copy up to date. The -r 
> option is "sticky", which means that once you've used it once, it is 
> automatically assumed in future on that working copy.


Thanks for your very clear answer, Jason.

Re: Emacs 22 branch created.

[Leo]

----- Jason Rumney (2007-04-24) wrote:-----

>> I would also like to know.
>>   
>
> "cvs up" is sufficient to keep the working copy up to date. The -r 
> option is "sticky", which means that once you've used it once, it is
> automatically assumed in future on that working copy.

But if I am in the EMACS_22_BASE tree and want to change to HEAD, which
command to run?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Emacs 22 branch created.

[Lennart Borgman (gmail)]

Leo wrote:
> ----- Lennart Borgman (gmail) (2007-04-24) wrote:-----
> 
>> If I do "cvs up -r EMACS_22_BASE" how should I then
>> continue fetching updates from the CVS? Is this ok then? :
> 
> I would also like to know.
> 
>>   cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co
>> emacs
> 
> This will create another brand-new checkout, I guess.

It will update if you have already done a checkout.

Re: Emacs 22 branch created.

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> ----- Lennart Borgman (gmail) (2007-04-24) wrote:-----
>
>> If I do "cvs up -r EMACS_22_BASE" how should I then
>> continue fetching updates from the CVS? Is this ok then? :
>
> I would also like to know.

Just continue to use cvs up.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 22 branch created.

[Nick Roberts]

 > But if I am in the EMACS_22_BASE tree and want to change to HEAD, which
 > command to run?

cvs up -A

But I really think all these questions should be answered by reading the CVS
manual and not by asking on the mailing list.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22 branch created.

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> But if I am in the EMACS_22_BASE tree and want to change to HEAD, which
> command to run?

(cvs)update options:

`-A'
     Reset any sticky tags, dates, or `-k' options.  See *Note Sticky
     tags::, for more information on sticky tags/dates.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 23 Apr 2007 21:51:52 -0400
> 
> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.

Thanks.

Please also bump the version on HEAD to 22.1.50, to avoid confusion.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Tue, 24 Apr 2007 12:51:57 +0100
> 
> But if I am in the EMACS_22_BASE tree and want to change to HEAD, which
> command to run?

I don't recommend switching the same tree between head and the branch,
because each such switch will potentially change many files.

It is much better to have two separate trees.

Re: Emacs 22 branch created.

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Mon, 23 Apr 2007 21:51:52 -0400
>> 
>> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
>
> Thanks.
>
> Please also bump the version on HEAD to 22.1.50, to avoid confusion.

Shouldn't this be 23.0.50?  I thought the plan was to merge the
Unicode branch into the trunk.

Re: Emacs 22 branch created.

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Chong Yidong <cyd@stupidchicken.com>
>>> Date: Mon, 23 Apr 2007 21:51:52 -0400
>>> 
>>> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
>>
>> Thanks.
>>
>> Please also bump the version on HEAD to 22.1.50, to avoid confusion.
>
> Shouldn't this be 23.0.50?  I thought the plan was to merge the
> Unicode branch into the trunk.

I think we should wait with bumping to 23.x until the branch is actually
merged.  The only important thing is that the trunk has a higher version
than the release branch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 22 branch created.

[Stefan Monnier]

>>> cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co
>>> emacs
>> 
>> This will create another brand-new checkout, I guess.

> It will update if you have already done a checkout.

Yes, sadly, it does.  Please consider it as a misfeature not to be used.
"checkout" is to fetch a new tree, and "update" is to ...well... update
a tree.


        Stefan

RE: Emacs 22 branch created.

[Drew Adams]

> > Shouldn't this be 23.0.50?  I thought the plan was to merge the
> > Unicode branch into the trunk.
> 
> I think we should wait with bumping to 23.x until the branch is actually
> merged.  The only important thing is that the trunk has a higher version
> than the release branch.

Is the intention to merge the Unicode branch right away?

Re: Emacs 22 branch created.

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
> (I'm not sure of the reason for shouting, but it seems to be
> traditional.)

Unfortunately, you got it a bit wrong!

You should have tagged the HEAD with EMACS_22_BASE as a normal
tag, and then created a EMACS_22_RC branch from the base tag.

Then we could have done things like

cvs diff -r EMACS_22_BASE -r EMACS_22_RC

to see what changes have been applied to the branch.

And (in a trunk checkout) we could have done

cvs diff -r EMACS_22_BASE

to see what have been committed to the trunk since the branch.

I'm not sure how to clean this up (or create the missing base tag).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 branch created.

[Kim F. Storm]

Also, can we somehow make the emacs-diffs mailing list show commits to
the EMACS_22 branch?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 branch created.

[Jason Rumney]

Kim F. Storm wrote:
> I'm not sure how to clean this up (or create the missing base tag).

cvs -d ... co -D "2007-04-24 02:51"
cvs diff -r EMACS_22_BASE

manually fix up any differences by checking out the right revision of 
the file from the trunk (don't use -r EMACS_22_BASE!).

cvs tag EMACS_22_BRANCHPOINT

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 24 Apr 2007 18:59:23 +0200
> Cc: emacs-devel@gnu.org
> 
> Also, can we somehow make the emacs-diffs mailing list show commits to
> the EMACS_22 branch?

AFAIK, it should do that already.  If it does not, please holler to
GNU sysadmins.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 24 Apr 2007 18:39:51 +0200
> Cc: emacs-devel@gnu.org
> 
> Chong Yidong <cyd@stupidchicken.com> writes:
> 
> > I've created the Emacs 22 branch, which has CVS tag EMACS_22_BASE.
> > (I'm not sure of the reason for shouting, but it seems to be
> > traditional.)
> 
> Unfortunately, you got it a bit wrong!
> 
> You should have tagged the HEAD with EMACS_22_BASE as a normal
> tag, and then created a EMACS_22_RC branch from the base tag.

Perhaps the exact instructions to do this right should be added to
admin/make-tarball.txt.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Tue, 24 Apr 2007 16:25:51 +0200
> 
> >> Please also bump the version on HEAD to 22.1.50, to avoid confusion.
> >
> > Shouldn't this be 23.0.50?  I thought the plan was to merge the
> > Unicode branch into the trunk.
> 
> I think we should wait with bumping to 23.x until the branch is actually
> merged.  The only important thing is that the trunk has a higher version
> than the release branch.

100% agreement.

Re: Emacs 22 branch created.

[Stefan Monnier]

> Unfortunately, you got it a bit wrong!

Yes, I've been disappointed as well.  I specifically sent sample commands on
this list a few weeks ago to make sure we were not going to make this kind
of mistake again.


        Stefan

Re: Emacs 22 branch created.

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: storm@cua.dk (Kim F. Storm)
>> Date: Tue, 24 Apr 2007 18:59:23 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Also, can we somehow make the emacs-diffs mailing list show commits to
>> the EMACS_22 branch?
>
> AFAIK, it should do that already.  If it does not, please holler to
> GNU sysadmins.

I don't see any.

I don't see the emacs-unicode-2 commits either ... the last
such entry is from Dec. 9, 2004.


Maybe this thread is related:

http://www.mail-archive.com/savannah-hackers@gnu.org/msg02595.html

Maybe the log_accum script was lost when the cvs server was re-organized.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 branch created.

[Jason Rumney]

Jason Rumney wrote:
> Kim F. Storm wrote:
>> I'm not sure how to clean this up (or create the missing base tag).
>
> cvs -d ... co -D "2007-04-24 02:51"
> cvs diff -r EMACS_22_BASE
>
> manually fix up any differences by checking out the right revision of 
> the file from the trunk (don't use -r EMACS_22_BASE!).
>
> cvs tag EMACS_22_BRANCHPOINT

I've created the tag EMACS_22_BRANCHPOINT. Due to python.el and version 
number changes on the branch, I did the diff one hour forwards and 
backwards from the time above - which is the time Chong sent the 
announcement, to ensure I had the correct revisions. The only changes in 
that timeframe were to src/xdisp.c and src/Changelog by Chong before the 
branch, so I am pretty sure -D "2007-04-24 02:51" gives the correct 
revisions for all files.

It may be possible to rename EMACS_22_BASE to EMACS_22_RC using cvs tag 
-A, depending on how that is implemented - if it creates a new tag 
pointing to the same versions then it should work, but if it creates a 
real alias, as the name suggests, then it could have disasterous 
consequences when we change EMACS_22_BASE to replace 
EMACS_22_BRANCHPOINT (the latter is easily done).

Re: Emacs 22 branch created.

[Eli Zaretskii]

> Cc: cyd@stupidchicken.com,  emacs-devel@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 24 Apr 2007 19:56:00 +0200
> 
> >> Also, can we somehow make the emacs-diffs mailing list show commits to
> >> the EMACS_22 branch?
> >
> > AFAIK, it should do that already.  If it does not, please holler to
> > GNU sysadmins.
> 
> I don't see any.
> 
> I don't see the emacs-unicode-2 commits either ... the last
> such entry is from Dec. 9, 2004.

Please report this to savannah-hackers.

Re: Emacs 22 branch created.

[Stefan Monnier]

> I've created the tag EMACS_22_BRANCHPOINT. Due to python.el and version
> number changes on the branch, I did the diff one hour forwards and backwards
> from the time above - which is the time Chong sent the announcement, to
> ensure I had the correct revisions. The only changes in that timeframe were
> to src/xdisp.c and src/Changelog by Chong before the branch, so I am pretty
> sure -D "2007-04-24 02:51" gives the correct revisions for all files.

Thank you.

> It may be possible to rename EMACS_22_BASE to EMACS_22_RC using cvs tag -A,
> depending on how that is implemented - if it creates a new tag pointing to
> the same versions then it should work, but if it creates a real alias, as
> the name suggests, then it could have disasterous consequences when we
> change EMACS_22_BASE to replace EMACS_22_BRANCHPOINT (the latter is easily
> done).

I don't know the -A flag to tag (could it be a cvsnt-ism?), so maybe this is
doing the right thing, but otherwise I think there's no clean way to rename
a branch in CVS.

The best I've found so far is:

    cvs admin -N <newname>:<oldname>
    cvs admin -n <oldname>

the first may be equivalent to

    cvs admin -n <newname>:<oldname>

and the second may be equivalent to

    cvs tag -B -d <oldname>

I've just tried it on emacs/admin/notes/toto and it seems to work.


        Stefan

Re: Emacs 22 branch created.

[Jason Rumney]

Stefan Monnier wrote:
> I don't know the -A flag to tag (could it be a cvsnt-ism?)

That probably explains why I can't find any documentation for what it 
actually does.

> The best I've found so far is:
>
>     cvs admin -N <newname>:<oldname>
>     cvs admin -n <oldname>
>
> the first may be equivalent to
>
>     cvs admin -n <newname>:<oldname>
>
> and the second may be equivalent to
>
>     cvs tag -B -d <oldname>
>
> I've just tried it on emacs/admin/notes/toto and it seems to work.
>   

I've found mention on the web that it won't DTRT for files in the Attic. 
Since we've deleted python.el from the branch, it might be too much of a 
risk to change the tag names now.

Re: Emacs 22 branch created.

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
>>> Please also bump the version on HEAD to 22.1.50, to avoid confusion.
>>
>> Shouldn't this be 23.0.50?  I thought the plan was to merge the
>> Unicode branch into the trunk.
>
> I think we should wait with bumping to 23.x until the branch is actually
> merged.  The only important thing is that the trunk has a higher version
> than the release branch.

Yeah, we can wait a few minutes before merging 23... :-)

-Miles

-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Emacs 22 branch created.

[Richard Stallman]

    Since the python.el issue doesn't seem likely to be resolved in the
    near future, I will go ahead and remove it from the branch.

I have not decided to remove this file from the release.
Please do not do such drastic things without asking.
Until I decide whether to take it out, please put it back in.

Re: Emacs 22 branch created.

[Leo]

----- Miles Bader (2007-04-24) wrote:-----

> Yeah, we can wait a few minutes before merging 23... :-)
>
> -Miles

Which will be merged first, MultiTTY or Unicode2?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Emacs 22 branch created.

[Jason Rumney]

Leo wrote:
> Which will be merged first, MultiTTY or Unicode2?
>   
 
Last time I looked, MultiTTY was not even in CVS yet. We need to get it 
into CVS on a branch first, and check that it at least compiles and runs 
on all platforms that Emacs supports before merging it to HEAD.

Re: Emacs 22 branch created.

[Nick Roberts]

 > >> I'm not sure how to clean this up (or create the missing base tag).
 > >
 > > cvs -d ... co -D "2007-04-24 02:51"
 > > cvs diff -r EMACS_22_BASE
 > >
 > > manually fix up any differences by checking out the right revision of 
 > > the file from the trunk (don't use -r EMACS_22_BASE!).
 > >
 > > cvs tag EMACS_22_BRANCHPOINT

EMACS_PRETEST_22_0_99 seems to have been made on the trunk.  Wouldn't that
have given you what you wanted?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22 branch created.

[Nick Roberts]

 > > Unfortunately, you got it a bit wrong!
 > 
 > Yes, I've been disappointed as well.  I specifically sent sample commands on
 > this list a few weeks ago to make sure we were not going to make this kind
 > of mistake again.

Everyone is quick to point out mistakes, but I think Chong should be praised
for his Herculean effort to get us this far at all.

I've added a note in make-tarball.txt, as Eli suggested, along the lines, but
not exactly as, you suggested.  If you think it's wrong, please correct it
rather than just moan about it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22 branch created.

[Richard Stallman]

    > Also, can we somehow make the emacs-diffs mailing list show commits to
    > the EMACS_22 branch?

    AFAIK, it should do that already.

I had it set up to show only the trunk.

Re: Emacs 22 branch created.

[Richard Stallman]

    Perhaps the exact instructions to do this right should be added to
    admin/make-tarball.txt.

Yes, would someone please do that?

Re: Emacs 22 branch created.

[Richard Stallman]

    http://www.mail-archive.com/savannah-hackers@gnu.org/msg02595.html

    Maybe the log_accum script was lost when the cvs server was re-organized.

I don't think it was lost (unless it was replaced with another
implementation).  It appears to be in use, and working.

Re: Emacs 22 branch created.

[Richard Stallman]

    I've found mention on the web that it won't DTRT for files in the Attic. 
    Since we've deleted python.el from the branch, it might be too much of a 
    risk to change the tag names now.

Maybe just ADD the desired name ..._RC
without removing the undesired name ..._BASE.

Re: Emacs 22 branch created.

[Glenn Morris]

Nick Roberts wrote:

> I think Chong should be praised for his Herculean effort to get us
> this far at all.

Hear, hear.

Re: Emacs 22 branch created.

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> Maybe just ADD the desired name ..._RC
> without removing the undesired name ..._BASE.

The problem is that the "undesired name" is quite misleading; I wouldn't
be surprised if just leaving it as an alias would cause further grief
later...

>     I've found mention on the web that it won't DTRT for files in the Attic. 
>     Since we've deleted python.el from the branch, it might be too much of a 
>     risk to change the tag names now.

If just one file is problematic, it could probably be fixed up by hand.

[What's the "risk", anyway?]

-Miles

-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: Emacs 22 branch created.

[Nick Roberts]

Richard Stallman writes:
 >     Perhaps the exact instructions to do this right should be added to
 >     admin/make-tarball.txt.
 > 
 > Yes, would someone please do that?

Already done (it might be wirth checking for accuracy though).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22 branch created.

[Stefan Monnier]

>     I've found mention on the web that it won't DTRT for files in the Attic. 
>     Since we've deleted python.el from the branch, it might be too much of a 
>     risk to change the tag names now.

> Maybe just ADD the desired name ..._RC

Actually, even adding isn't necessarily as easy as it sounds.

> without removing the undesired name ..._BASE.

A simpler solution is to re-create a new branch and forget about the
old one.  We can then safely remove the ..._BASE tags: it'll leave the
undesired branch in an unusable state, but it's not like we care.


        Stefan

Re: Emacs 22 branch created.

[Stefan Monnier]

>> > Unfortunately, you got it a bit wrong!
>> Yes, I've been disappointed as well.  I specifically sent sample commands on
>> this list a few weeks ago to make sure we were not going to make this kind
>> of mistake again.
> Everyone is quick to point out mistakes, but I think Chong should be praised
> for his Herculean effort to get us this far at all.

Of course.


        Stefan

Re: Emacs 22 branch created.

[Jason Rumney]

Nick Roberts wrote:
> EMACS_PRETEST_22_0_99 seems to have been made on the trunk.  Wouldn't that
> have given you what you wanted?
>   

EMACS_PRETEST_22_0_99 is on the branch. Most files have not changed, so 
you need to look at the history of one like lisp/version.el to see that.

Re: Emacs 22 branch created.

[Leo]

----- Jason Rumney (2007-04-24) wrote:-----

> Leo wrote:
>> Which will be merged first, MultiTTY or Unicode2?
>>   
>
> Last time I looked, MultiTTY was not even in CVS yet. We need to get
> it into CVS on a branch first, and check that it at least compiles and
> runs on all platforms that Emacs supports before merging it to HEAD.

But from the author's page:
,----
|  I use Bazaar 1 for the revision control of the multi-tty branch. Use
|  the following commands to download the source:
| 
|    baz grab http://lorentey.hu/grab/multi-tty
`----

Does this suffice?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Emacs 22 branch created.

[David Kastrup]

Leo <sdl.web@gmail.com> writes:

> ----- Jason Rumney (2007-04-24) wrote:-----
>
>> Leo wrote:
>>> Which will be merged first, MultiTTY or Unicode2?
>>>   
>>
>> Last time I looked, MultiTTY was not even in CVS yet. We need to get
>> it into CVS on a branch first, and check that it at least compiles and
>> runs on all platforms that Emacs supports before merging it to HEAD.
>
> But from the author's page:
> ,----
> |  I use Bazaar 1 for the revision control of the multi-tty branch. Use
> |  the following commands to download the source:
> | 
> |    baz grab http://lorentey.hu/grab/multi-tty
> `----
>
> Does this suffice?

Would probably still require to be put in a branch first for first
access.  I think this should be done (and merged) before merging
unicode-2.

-- 
David Kastrup

Re: Emacs 22 branch created.

[Jason Rumney]

Leo wrote:
> But from the author's page:
> ,----
> |  I use Bazaar 1 for the revision control of the multi-tty branch. Use
> |  the following commands to download the source:
> | 
> |    baz grab http://lorentey.hu/grab/multi-tty
> `----
>
> Does this suffice?
>   


Not really. I don't have all manner of bizarre source control systems 
installed, nor do I want them. Many are only available for limited 
platforms.

Re: Emacs 22 branch created.

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Leo wrote:
>> But from the author's page:
>> ,----
>> |  I use Bazaar 1 for the revision control of the multi-tty branch. Use
>> |  the following commands to download the source:
>> | |    baz grab http://lorentey.hu/grab/multi-tty
>> `----
>>
>> Does this suffice?
>>   
>
>
> Not really. I don't have all manner of bizarre source control systems
> installed, nor do I want them. Many are only available for limited
> platforms.

Maybe someone with access to both baz and CVS on GNU/Linux could check
whether the "tailor" program makes it possible to migrate the change
set with full information.

-- 
David Kastrup

Re: Emacs 22 branch created.

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Maybe someone with access to both baz and CVS on GNU/Linux could check
> whether the "tailor" program makes it possible to migrate the change
> set with full information.

Baz 1 is essentially arch.  I don't see much sense in trying to preserve
the individual changesets.

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Emacs 22 branch created.

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> Maybe someone with access to both baz and CVS on GNU/Linux could check
>> whether the "tailor" program makes it possible to migrate the change
>> set with full information.
>
> Baz 1 is essentially arch.  I don't see much sense in trying to preserve
> the individual changesets.

Miles, you have considerable experience with arch and merging stuff
into branches.  Could you possibly import the multitty stuff into a
CVS branch in case that Károly is not available for that?  It seems
however from the multi-tty commit mailing list that Károly still keeps
the archive synchronized with HEAD, so it would probably make sense to
wait with the branch import until we are in the position where we can
go through with the merge (probably some weeks after the release) and
deal with the consequences.

-- 
David Kastrup

Re: Emacs 22 branch created.

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> Everyone is quick to point out mistakes, but I think Chong should be praised
> for his Herculean effort to get us this far at all.

Definitely.  Thanks Chong!!

And thanks to Jason for creating the missing base tag.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 branch created.

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> Nick Roberts <nickrob@snap.net.nz> writes:
> 
>> Everyone is quick to point out mistakes, but I think Chong should be praised
>> for his Herculean effort to get us this far at all.
> 
> Definitely.  Thanks Chong!!

Yes, thanks Chong. And the old "the only way to avoid mistakes is to do 
nothing" is as valid as always.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 25 Apr 2007 10:37:49 +0200
> Cc: emacs-devel@gnu.org
> 
> Miles, you have considerable experience with arch and merging stuff
> into branches.  Could you possibly import the multitty stuff into a
> CVS branch in case that Károly is not available for that?

I'd also like to remind us the rmail-mbox branch, which we also wanted
to merge post-22.1.

Re: Emacs 22 branch created.

[Henrik Enberg]

Eli Zaretskii <eliz@gnu.org> writes:
> > From: David Kastrup <dak@gnu.org>
> > Date: Wed, 25 Apr 2007 10:37:49 +0200
> > Cc: emacs-devel@gnu.org
> > 
> > Miles, you have considerable experience with arch and merging stuff
> > into branches.  Could you possibly import the multitty stuff into a
> > CVS branch in case that Károly is not available for that?
> 
> I'd also like to remind us the rmail-mbox branch, which we also wanted
> to merge post-22.1.

I'm not sure it is suitable for immediate merging, there are still some
issues:

  * At the moment, it is slightly worse than current Rmail when it comes
    to non-ascii support.  One of the major points of moving to the mbox
    format is to be compatible with external tools, and that rules out
    storing mailboxes in emacs-mule form, which old Rmail does.  I'm
    still not sure what the best approach here would be here.  UTF-8?
    Raw text?

  * Gnus BABYL support will break.  Since the new Rmail no longer knows
    how to decode BABYL, neither will Gnus.  This is unfortunate, but
    more or less unavoidable, given the way Rmail is designed.

  * The mime support is _very_ basic, but I guess that's not really a
    change from old Rmail.

Re: Emacs 22 branch created.

[Stefan Monnier]

>   * At the moment, it is slightly worse than current Rmail when it comes
>     to non-ascii support.  One of the major points of moving to the mbox
>     format is to be compatible with external tools, and that rules out
>     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
>     still not sure what the best approach here would be here.  UTF-8?
>     Raw text?

The mailbox should not be decoded, most likely.
The decoding should only happen when displaying a message.


        Stefan

Re: Emacs 22 branch created.

[Andreas Schwab]

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

>>   * At the moment, it is slightly worse than current Rmail when it comes
>>     to non-ascii support.  One of the major points of moving to the mbox
>>     format is to be compatible with external tools, and that rules out
>>     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
>>     still not sure what the best approach here would be here.  UTF-8?
>>     Raw text?
>
> The mailbox should not be decoded, most likely.
> The decoding should only happen when displaying a message.

FWIW, this is also what Gnus is doing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 22 branch created.

[Henrik Enberg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >   * At the moment, it is slightly worse than current Rmail when it comes
> >     to non-ascii support.  One of the major points of moving to the mbox
> >     format is to be compatible with external tools, and that rules out
> >     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
> >     still not sure what the best approach here would be here.  UTF-8?
> >     Raw text?
> 
> The mailbox should not be decoded, most likely.
> The decoding should only happen when displaying a message.

Yes, that's what it does, but we need to write messages to the mailbox
too.

Re: Emacs 22 branch created.

[Leo]

----- David Kastrup (2007-04-25) wrote:-----

>>> Maybe someone with access to both baz and CVS on GNU/Linux could
>>> check whether the "tailor" program makes it possible to migrate the
>>> change set with full information.
>>
>> Baz 1 is essentially arch.  I don't see much sense in trying to
>> preserve the individual changesets.
>
> Miles, you have considerable experience with arch and merging stuff
> into branches.  Could you possibly import the multitty stuff into a
> CVS branch in case that Károly is not available for that?  It seems
> however from the multi-tty commit mailing list that Károly still keeps
> the archive synchronized with HEAD, so it would probably make sense to
> wait with the branch import until we are in the position where we can
> go through with the merge (probably some weeks after the release) and
> deal with the consequences.

I wonder, would it be simpler merge it into Unicode2 branch first?

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Emacs 22 branch created.

[Eli Zaretskii]

> Date: Wed, 25 Apr 2007 21:50:26 +0200
> From: Henrik Enberg <henrik.enberg@telia.com>
> Cc: emacs-devel@gnu.org
> 
> > I'd also like to remind us the rmail-mbox branch, which we also wanted
> > to merge post-22.1.
> 
> I'm not sure it is suitable for immediate merging

IMO, if it's not merged now, it will be another long wait.  So we had
better merge it now and fix all that needs fixing, while most people
are using the pretest branch.

>   * At the moment, it is slightly worse than current Rmail when it comes
>     to non-ascii support.  One of the major points of moving to the mbox
>     format is to be compatible with external tools, and that rules out
>     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
>     still not sure what the best approach here would be here.  UTF-8?
>     Raw text?

Neither.  I think you should encode it and store it encoded, like it
would be when it comes from the wire.

>   * Gnus BABYL support will break.  Since the new Rmail no longer knows
>     how to decode BABYL, neither will Gnus.

Why cannot we retain the BABYL support?  It won't hurt leaving it
alone: e.g., all my email archives are in BABYL format, and I'd like
to be able to read them, even if only thru unrmail or b2m.

>   * The mime support is _very_ basic, but I guess that's not really a
>     change from old Rmail.

Yes, that is not a problem, since the current Rmail doesn't support
MIME at all.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> Date: Wed, 25 Apr 2007 22:12:45 +0200
> From: Henrik Enberg <henrik.enberg@telia.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > >   * At the moment, it is slightly worse than current Rmail when it comes
> > >     to non-ascii support.  One of the major points of moving to the mbox
> > >     format is to be compatible with external tools, and that rules out
> > >     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
> > >     still not sure what the best approach here would be here.  UTF-8?
> > >     Raw text?
> > 
> > The mailbox should not be decoded, most likely.
> > The decoding should only happen when displaying a message.
> 
> Yes, that's what it does, but we need to write messages to the mailbox
> too.

Then encode it and make it look like mbox.  E.g., a message in French
would be encoded to Latin-1 or Latin-9.

Re: Emacs 22 branch created.

[Henrik Enberg]

Eli Zaretskii <eliz@gnu.org> writes:
> > Date: Wed, 25 Apr 2007 21:50:26 +0200
> > From: Henrik Enberg <henrik.enberg@telia.com>
> > Cc: emacs-devel@gnu.org
> > 
> > > I'd also like to remind us the rmail-mbox branch, which we also wanted
> > > to merge post-22.1.
> > 
> > I'm not sure it is suitable for immediate merging
> 
> IMO, if it's not merged now, it will be another long wait.  So we had
> better merge it now and fix all that needs fixing, while most people
> are using the pretest branch.

I guess people who use the bleeding edge can live with some regression
while the details are being hammered out.

> >   * At the moment, it is slightly worse than current Rmail when it comes
> >     to non-ascii support.  One of the major points of moving to the mbox
> >     format is to be compatible with external tools, and that rules out
> >     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
> >     still not sure what the best approach here would be here.  UTF-8?
> >     Raw text?
> 
> Neither.  I think you should encode it and store it encoded, like it
> would be when it comes from the wire.
>
> >   * Gnus BABYL support will break.  Since the new Rmail no longer knows
> >     how to decode BABYL, neither will Gnus.
> 
> Why cannot we retain the BABYL support?  It won't hurt leaving it
> alone: e.g., all my email archives are in BABYL format, and I'd like
> to be able to read them, even if only thru unrmail or b2m.

It's not quite that drastic.  A BABYL box will be converted to mbox
format on the fly if you load it.  

I'm talking about the ability to browse and save BABYL boxes.  The
BABYL-support bits are so permeated through Rmail that you'd end up
having to specialcase half the functions in there, creating a complete
mess.  It would likely have been easier to write a whole new mailreader
than try to do it like that.

Re: Emacs 22 branch created.

[Kenichi Handa]

In article <jwvhcr4nrvp.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >   * At the moment, it is slightly worse than current Rmail when it comes
> >     to non-ascii support.  One of the major points of moving to the mbox
> >     format is to be compatible with external tools, and that rules out
> >     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
> >     still not sure what the best approach here would be here.  UTF-8?
> >     Raw text?

> The mailbox should not be decoded, most likely.
> The decoding should only happen when displaying a message.

I agree.  As Gnus, the decoded message should be shown in
the different buffer than RMAIL buffer.

---
Kenichi Handa
handa@m17n.org

Re: Emacs 22 branch created.

[Glenn Morris]

Eli Zaretskii wrote:

> Please also bump the version on HEAD to 22.1.50, to avoid confusion.

done

Re: Emacs 22 branch created.

[Glenn Morris]

Richard Stallman wrote:

> Until I decide whether to take it out, please put it back in.

I tried, but I don't know how to restore a file from the trunk onto
a branch and preserve the CVS history. I'm sure someone on this list
does though...

Re: Emacs 22 branch created.

[Richard Stallman]

    A simpler solution is to re-create a new branch and forget about the
    old one.

If you know how to do it, please do it.

Re: Emacs 22 branch created.

[Nick Roberts]

 > > Until I decide whether to take it out, please put it back in.
 > 
 > I tried, but I don't know how to restore a file from the trunk onto
 > a branch and preserve the CVS history. I'm sure someone on this list
 > does though...

If we cut the branch again (as Stefan suggested to cure the earlier problem)
this would presumably restore it (assuming there have been no changes made
on the trunk only).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs 22 branch created.

[Francesco Potorti`]

>  * At the moment, it is slightly worse than current Rmail when it comes
>    to non-ascii support.  

Last time I asked, I was told that I wouldn't be able to read mail
arriving in different codings, such as I normally receive.  Is that the
case?

>			    One of the major points of moving to the mbox
>    format is to be compatible with external tools, and that rules out
>    storing mailboxes in emacs-mule form, which old Rmail does.  I'm
>    still not sure what the best approach here would be here.  UTF-8?
>    Raw text?

I think it should be stored as other tools do, which I suppose it means
just as they arrive from the wire.

>  * Gnus BABYL support will break.  Since the new Rmail no longer knows
>    how to decode BABYL, neither will Gnus.  This is unfortunate, but
>    more or less unavoidable, given the way Rmail is designed.

If Rmail decodes babyl and writes it back in mbox format, maybe Gnus
could do the same.

>  * The mime support is _very_ basic, but I guess that's not really a
>    change from old Rmail.

I use the very old rmime.el.  Its most important feature is that it
decodes base64 and quoted-printable for me.  Additionally, it collapses
attachments to a single line each and allows me to save them on disk by
hitting C-cC-c on that line.  Such a very basic support would be enough
for a start.

Re: Emacs 22 branch created.

[Henrik Enberg]

> Date: Thu, 26 Apr 2007 12:52:09 +0200
> From: Francesco Potorti` <pot@gnu.org>
> 
> >  * At the moment, it is slightly worse than current Rmail when it comes
> >    to non-ascii support.  
> 
> Last time I asked, I was told that I wouldn't be able to read mail
> arriving in different codings, such as I normally receive.  Is that the
> case?

Well, you can read them, but you'll have to put up with the occasional
\NNN escape showing up in the buffer.  It is usable as a mailreader
though.

This is a pretty high-priority item to fix though, me being Swedish and
all.  I haven't worked on rmail much this year due to other commitments,
but I hope to get active again soonish.


> >			    One of the major points of moving to the mbox
> >    format is to be compatible with external tools, and that rules out
> >    storing mailboxes in emacs-mule form, which old Rmail does.  I'm
> >    still not sure what the best approach here would be here.  UTF-8?
> >    Raw text?
> 
> I think it should be stored as other tools do, which I suppose it means
> just as they arrive from the wire.
>
> >  * Gnus BABYL support will break.  Since the new Rmail no longer knows
> >    how to decode BABYL, neither will Gnus.  This is unfortunate, but
> >    more or less unavoidable, given the way Rmail is designed.
> 
> If Rmail decodes babyl and writes it back in mbox format, maybe Gnus
> could do the same.

I guess, but that will require changes to Gnus, so a heads-up to the
Gnus developers is probably in order before installing the changes.

> >  * The mime support is _very_ basic, but I guess that's not really a
> >    change from old Rmail.
> 
> I use the very old rmime.el.  Its most important feature is that it
> decodes base64 and quoted-printable for me.  Additionally, it collapses
> attachments to a single line each and allows me to save them on disk by
> hitting C-cC-c on that line.  Such a very basic support would be enough
> for a start.

I doubt rmime.el will work out the box, but some basic mime code has
been committed (in rmailmm.el) and It should be fairly easy to get QP
and base64 support working.  I haven't really been working on that part
of the code though, so I can't say for sure.

Re: Emacs 22 branch created.

[Glenn Morris]

Glenn Morris wrote:

> Richard Stallman wrote:
>
>> Until I decide whether to take it out, please put it back in.
>
> I tried, but I don't know how to restore a file from the trunk onto
> a branch and preserve the CVS history. I'm sure someone on this list
> does though...

I figured it out and restored it to the branch. I was just being dumb.
The procedure was exactly the same as normal, only I was persistently
putting the cvs arguments in the wrong order for some reason.

cvs up -j 1.58.2.1 -j 1.58 python.el

Re: Emacs 22 branch created.

[Richard Stallman]

      * Gnus BABYL support will break.  Since the new Rmail no longer knows
	how to decode BABYL, neither will Gnus.  This is unfortunate, but
	more or less unavoidable, given the way Rmail is designed.

Gnus should covert Babyl files into mailbox files.  (So should Rmail,
I guess.)  The unrmail command, plus the old code for reading Babyl files,
ought to suffice for this.

That is the only kind of support for Babyl files that we can retain
in the Rmail-inbox code.  It would be too much of a pain to try to
support actually editing both formats.

Re: Emacs 22 branch created.

[Richard Stallman]

    >   * At the moment, it is slightly worse than current Rmail when it comes
    >     to non-ascii support.  One of the major points of moving to the mbox
    >     format is to be compatible with external tools, and that rules out
    >     storing mailboxes in emacs-mule form, which old Rmail does.  I'm
    >     still not sure what the best approach here would be here.  UTF-8?
    >     Raw text?

    The mailbox should not be decoded, most likely.
    The decoding should only happen when displaying a message.

That would mean decoding each message when you move to it,
and reencoding it when you move away from it.  And I presume
it would have to reencode the current message to save it.
Not good!

Or it would mean decoding it in a separate buffer, which has
its own big inconveniences.

I think it should decode a message when it is first visited (and the
extra header that Rmail saves data in is constructed).

(I don't recall whether I implemented that already in Rmail-inbox.)

I think the issue of decoding needs to be dealt with before
the Rmail-inbox branch is merged in.

Re: Emacs 22 branch created.

[Richard Stallman]

    I agree.  As Gnus, the decoded message should be shown in
    the different buffer than RMAIL buffer.

No thanks.  That would be inconvenient in various ways.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: henrik.enberg@telia.com, eliz@gnu.org, emacs-devel@gnu.org
> Date: Fri, 27 Apr 2007 01:59:02 -0400
> 
>     The mailbox should not be decoded, most likely.
>     The decoding should only happen when displaying a message.
> 
> That would mean decoding each message when you move to it,

That's what Rmail does now in v22.1, at least the first time you
display the message.  I don't find it inconvenient; do you?

> and reencoding it when you move away from it.

No, that won't be needed if you don't touch the original mbox-format
message, but instead display the results of decoding in a separate
buffer.

> And I presume it would have to reencode the current message to save
> it.

Only if you edit the message (which doesn't happen frequently).

> Or it would mean decoding it in a separate buffer, which has
> its own big inconveniences.

What are they?  Gnus works like that since time immemoriam, and I
don't think anyone complained.

> I think it should decode a message when it is first visited (and the
> extra header that Rmail saves data in is constructed).

And then what? how do you store the decoded message so that it is
still in mbox format?

Re: Emacs 22 branch created.

[Henrik Enberg]

> 
>       * Gnus BABYL support will break.  Since the new Rmail no longer knows
> 	how to decode BABYL, neither will Gnus.  This is unfortunate, but
> 	more or less unavoidable, given the way Rmail is designed.
> 
> Gnus should covert Babyl files into mailbox files.  (So should Rmail,
> I guess.)  The unrmail command, plus the old code for reading Babyl files,
> ought to suffice for this.

This is what the mbox branch does.  When you read in a file, it will
check the format, and if is BABYL, it automatically converts it to
mailbox with unrmail.  It should be pretty easy for Gnus to do something
similar.

> That is the only kind of support for Babyl files that we can retain
> in the Rmail-inbox code.  It would be too much of a pain to try to
> support actually editing both formats.

Indeed.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Henrik Enberg <henrik.enberg@telia.com>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> Date: Fri, 27 Apr 2007 15:38:32 +0200 (CEST)
> 
> > 
> >       * Gnus BABYL support will break.  Since the new Rmail no longer knows
> > 	how to decode BABYL, neither will Gnus.  This is unfortunate, but
> > 	more or less unavoidable, given the way Rmail is designed.
> > 
> > Gnus should covert Babyl files into mailbox files.  (So should Rmail,
> > I guess.)  The unrmail command, plus the old code for reading Babyl files,
> > ought to suffice for this.
> 
> This is what the mbox branch does.  When you read in a file, it will
> check the format, and if is BABYL, it automatically converts it to
> mailbox with unrmail.  It should be pretty easy for Gnus to do something
> similar.

Then I think there's no real issue with BABYL support in this branch.

The only other controversy seems to be the encoding stuff.  I don't
really understand Richard's objections to what people suggested (i.e.,
store the messages undecoded).  I think this is the way to go; it was
discussed several times in the past, and the conclusion was always the
same: that decoding should happen at display time.

Re: Emacs 22 branch created.

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

> The only other controversy seems to be the encoding stuff.  I don't
> really understand Richard's objections to what people suggested ...

I guess it is part of a secret plan to delay Emacs 23 indefinitely
(delaying Emacs 22 indefinitely is part of that plan).

 :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs 22 branch created.

[Richard Stallman]

    > Or it would mean decoding it in a separate buffer, which has
    > its own big inconveniences.

    What are they?

C-x b RMAIL RET stops working, for one thing.
That in itself is a pain in the neck.

    > I think it should decode a message when it is first visited (and the
    > extra header that Rmail saves data in is constructed).

    And then what? how do you store the decoded message so that it is
    still in mbox format?

I do not see the issue.  The file is always in mbox format.  Decoding
the message contents doesn't alter the overall file format.

Re: Emacs 22 branch created.

[Richard Stallman]

    The only other controversy seems to be the encoding stuff.  I don't
    really understand Richard's objections to what people suggested (i.e.,
    store the messages undecoded). 

It would require either (1) displaying messages in a separate buffer
or (2) reencoding the text when you move away to display another
message or save the file.

#1 is intolerable because it means C-x b RMAIL RET won't take you
to the current message.

#2 is quite a pain to implement.

				    I think this is the way to go; it was
    discussed several times in the past, and the conclusion was always the
    same: that decoding should happen at display time.

I do not know who participated in these discussions, or what reasons
they cited, or how they proposed to deal with the painful dilemma
stated above, so this does not convince me of anything.

Re: Emacs 22 branch created.

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Sat, 28 Apr 2007 00:06:58 -0400

       The only other controversy seems to be the encoding stuff.  I
       don't really understand Richard's objections to what people
       suggested (i.e., store the messages undecoded).

   It would require either (1) displaying messages in a separate buffer
   or (2) reencoding the text when you move away to display another
   message or save the file.

   #1 is intolerable because it means C-x b RMAIL RET won't take you to
   the current message.

   #2 is quite a pain to implement.

it seems to me the two design criteria are to maintain the same buffer
and to maintain the same (undecoded, mbox format) text on disk.  so how
about displaying the decoded message in the current buffer as an overlay
of the (undecoded) text?  overlays do not get saved, normally, and can
be made to show the decoded message.  this satisfies the criteria.

thi

Re: Emacs 22 branch created.

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  henrik.enberg@telia.com,
> 	  emacs-devel@gnu.org
> From: Thien-Thi Nguyen <ttn@gnuvola.org>
> Date: Sat, 28 Apr 2007 09:21:55 +0200
> 
> how about displaying the decoded message in the current buffer as an
> overlay of the (undecoded) text?  overlays do not get saved,
> normally, and can be made to show the decoded message.

I expect such a bizarre design to have unintended consequences.  For
starters, Emacs doesn't behave well when there are lots of overlays
(because overlays disable many display optimizations, so redisplay
becomes intolerably slow).

Also, what will the normal kill/yank operations do when the text you
want to copy to the kill ring is in an overlay?

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: henrik.enberg@telia.com, emacs-devel@gnu.org
> Date: Sat, 28 Apr 2007 00:06:58 -0400
> 
>     The only other controversy seems to be the encoding stuff.  I don't
>     really understand Richard's objections to what people suggested (i.e.,
>     store the messages undecoded). 
> 
> It would require either (1) displaying messages in a separate buffer
> or (2) reencoding the text when you move away to display another
> message or save the file.

I was thinking about #1.  This is what Gnus does.

> #1 is intolerable because it means C-x b RMAIL RET won't take you
> to the current message.

Why not?  We could arrange for RMAIL to be that separate buffer where
we display decoded message text.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, henrik.enberg@telia.com,
> 	emacs-devel@gnu.org
> Date: Sat, 28 Apr 2007 00:06:46 -0400
> 
>     > I think it should decode a message when it is first visited (and the
>     > extra header that Rmail saves data in is constructed).
> 
>     And then what? how do you store the decoded message so that it is
>     still in mbox format?
> 
> I do not see the issue.  The file is always in mbox format.  Decoding
> the message contents doesn't alter the overall file format.

Decoding creates the internal Emacs representation of characters in
memory.  By contrast, the file where messages are stored is a disk
file, and the question I was asking is how to store the decoded
characters in that file, if you don't want to decode them each time
you look at that message.  Are you suggesting to store them, after
decoding, in the internal Emacs format (i.e. emacs-mule)?  That would
mean that only Emacs will be able to read the resulting mbox file.

Perhaps we need to step back and consider the larger perspective: what
is the main purposes of switching to mbox, if not to maintain the
messages in the format that any other MUA can read and display
correctly?  Writing our internal representation of non-ASCII
characters there would defeat that purpose.

Re: Emacs 22 branch created.

[Richard Stallman]

    so how
    about displaying the decoded message in the current buffer as an overlay
    of the (undecoded) text?

That won't work for editing the text of the message, which is something
I often do.  It won't even work for citing parts of the message text
in outgoing mail.

Re: Emacs 22 branch created.

[Richard Stallman]

    > #1 is intolerable because it means C-x b RMAIL RET won't take you
    > to the current message.

    Why not?  We could arrange for RMAIL to be that separate buffer where
    we display decoded message text.

Normally the buffer named RMAIL is the one that visits the file RMAIL.
If we break that correspondence it is likely to cause a lot of
trouble.  And what would we do for other mail files?

    file, and the question I was asking is how to store the decoded
    characters in that file, if you don't want to decode them each time
    you look at that message.  Are you suggesting to store them, after
    decoding, in the internal Emacs format (i.e. emacs-mule)?  That would
    mean that only Emacs will be able to read the resulting mbox file.

That is a valid point.

A new idea just occurred to me.  Moving to a message could copy that
message in the buffer, decode the copy, and display that copy using
narrowing instead of the original message.  If you edit the message,
exiting the editing mode will reencode it and put that in place
of the original message.

We could have a new feature to omit part of the buffer when saving the
file.  Rmail could use it so that this copy is not saved.  This
feature should not affect auto-saving.

As an optimization, if there are attachments, don't copy them.  Just
copy and decode the main text of the message.  (Attachments don't need
character set decoding, since they are in ASCII.)  Put the copy after
the original, and the attachments will effecvtively become part of it.

Does anyone see a flaw in this?

Re: Emacs 22 branch created.

[Henrik Enberg]

>     The only other controversy seems to be the encoding stuff.  I don't
>     really understand Richard's objections to what people suggested (i.e.,
>     store the messages undecoded). 
> 
> It would require either (1) displaying messages in a separate buffer
> or (2) reencoding the text when you move away to display another
> message or save the file.
> 
> #1 is intolerable because it means C-x b RMAIL RET won't take you
> to the current message.

Would it be acceptable to do like Eli suggested, name the display buffer
e.g. RMAIL and keep the actual mailbox file in another, possibly hidden
buffer.

An upshot of this would be that we could do pretty fancy things such as
replacing the text of stuff like HTML-only message bodies with the
output of "lynx -dump" without ruining the original mail.

> #2 is quite a pain to implement.

It would require work, yes.  But trying to get many differently encoded
messages to live in a single file, while still not encoding it in an
Emacs-specific way is painful too.

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: henrik.enberg@telia.com, emacs-devel@gnu.org
> Date: Sat, 28 Apr 2007 14:35:18 -0400
> 
>     > #1 is intolerable because it means C-x b RMAIL RET won't take you
>     > to the current message.
> 
>     Why not?  We could arrange for RMAIL to be that separate buffer where
>     we display decoded message text.
> 
> Normally the buffer named RMAIL is the one that visits the file RMAIL.
> If we break that correspondence it is likely to cause a lot of
> trouble.  And what would we do for other mail files?

Perhaps I'm missing something, because I don't see a problem.  When
the user visits an Rmail file FOO, we could _always_ hold the current
message from that file in the buffer named FOO and arrange for its
visited file name to be FOO.  The actual contents of FOO the file
would be in another buffer.  We could arrange for save-file and other
similar commands to save FOO's contents from the buffer where we keep
its actual contents, instead of saving the buffer FOO.

Do you see any problem with this approach?

Re: Emacs 22 branch created.

[Richard Stallman]

    Would it be acceptable to do like Eli suggested, name the display buffer
    e.g. RMAIL and keep the actual mailbox file in another, possibly hidden
    buffer.

The results might be acceptable if this were made to work smoothly,
but I think that would be likely to be a lot of work.

Re: Emacs 22 branch created.

[Stefan Monnier]

> A new idea just occurred to me.  Moving to a message could copy that
> message in the buffer, decode the copy, and display that copy using
> narrowing instead of the original message.  If you edit the message,
> exiting the editing mode will reencode it and put that in place
> of the original message.

The non-decoded part of the buffer should be in unibyte mode.
The decoded part of the buffer has to be in multibyte mode.
I.e. it'll get ugly.
And of course very inefficient when you'll constantly be editing a very
large rmail buffer.

> We could have a new feature to omit part of the buffer when saving the
> file.  Rmail could use it so that this copy is not saved.  This
> feature should not affect auto-saving.

If you need such a low-level hack, I think it's a good indication that
you're headed for a bad solution.

> As an optimization, if there are attachments, don't copy them.  Just
> copy and decode the main text of the message.  (Attachments don't need
> character set decoding, since they are in ASCII.)  Put the copy after
> the original, and the attachments will effecvtively become part of it.

> Does anyone see a flaw in this?

See above.  Some more flaws:
- you assume that a MIME message has only one "main text".  It may have
  several, with "inlined attachments" in-between (e.g. images).  Some of the
  attachments may contain text which you may want to display as well.
  All solvable of course, just an indication that your optimization will
  work less often and will be a potential source of more bugs.
- you will not be able to reuse the Gnus code.  I.e. you'll end up
  reinventing the wheel yet again once more.

In any case, I don't use Rmail, don't intend to, and don't intend to work
on its code either, so do as you please.  


        Stefan

Re: Emacs 22 branch created.

[Richard Stallman]

    The non-decoded part of the buffer should be in unibyte mode.

Why does it have to be in unibyte mode?
Decoding can be done in a multibyte buffer.

    And of course very inefficient when you'll constantly be editing a very
    large rmail buffer.

Not really, because the gap makes such operations efficient.

    > We could have a new feature to omit part of the buffer when saving the
    > file.  Rmail could use it so that this copy is not saved.  This
    > feature should not affect auto-saving.

    If you need such a low-level hack, I think it's a good indication that
    you're headed for a bad solution.

The other approach also needs peculiar changes in lower-level features
to work right.  Various operations on the message buffer would have to
operate on the file buffer as well.  These include set-buffer-file-name,
rename-buffer, as well as saving.

    - you assume that a MIME message has only one "main text".  It may have
      several, with "inlined attachments" in-between (e.g. images).  Some of the
      attachments may contain text which you may want to display as well.
      All solvable of course, just an indication that your optimization will
      work less often and will be a potential source of more bugs.

This has no effect on the validity of this optimization.
Rmail does not handle attachments now.

We might want to implement support for displaying attachments, but if
we display them in separate buffers, the optimization won't interfere.

If we wanted to make Rmail decode text attachments in the same buffer,
that too can work easily enough together with this optimization.

So I think there is no difficulty, really.

Re: Emacs 22 branch created.

[Stefan Monnier]

>     The non-decoded part of the buffer should be in unibyte mode.
> Why does it have to be in unibyte mode?

I didn't say it has to, just that it should: for efficiency, for clarity,
etc...

> Decoding can be done in a multibyte buffer.

Yes, binary data stored in a multibyte buffer works, but has to be handled
with more care.  Experience shows it's more likely to lead to bugs which
ultimately result in things like \NNN escapes shown to the user instead of
accented chars.

>     And of course very inefficient when you'll constantly be editing a very
>     large rmail buffer.
> Not really, because the gap makes such operations efficient.

It just reduces the inefficiency.

> The other approach also needs peculiar changes in lower-level features
> to work right.  Various operations on the message buffer would have to
> operate on the file buffer as well.  These include set-buffer-file-name,
> rename-buffer, as well as saving.

Those other features can all be done at the UI-level, where they belong, not
at a low level.  At the very least, it's all done in elisp, without any need
to fiddle with C code.


        Stefan

Re: Emacs 22 branch created.

[Richard Stallman]

    >     And of course very inefficient when you'll constantly be editing a very
    >     large rmail buffer.
    > Not really, because the gap makes such operations efficient.

    It just reduces the inefficiency.

It makes them plenty efficient enough.  Remember, the same issue
arises in Rmail, and it isn't a problem.

    > The other approach also needs peculiar changes in lower-level features
    > to work right.  Various operations on the message buffer would have to
    > operate on the file buffer as well.  These include set-buffer-file-name,
    > rename-buffer, as well as saving.

    Those other features can all be done at the UI-level, where they belong, not
    at a low level.  At the very least, it's all done in elisp, without any need
    to fiddle with C code.

I don't think that is true.  Changes in set-buffer-file-name and rename-buffer
would have to be done at the C level.  And I expect we would find other
low-level facilities that would need such changing.

With my approach, we can be sure that only the operating of writing a file
needs changing.

Re: Emacs 22 branch created.

[Kenichi Handa]

In article <E1HhrlO-0001R5-A2@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> #1 is intolerable because it means C-x b RMAIL RET won't take you
> to the current message.

>     Why not?  We could arrange for RMAIL to be that separate buffer where
>     we display decoded message text.

> Normally the buffer named RMAIL is the one that visits the file RMAIL.
> If we break that correspondence it is likely to cause a lot of
> trouble.  And what would we do for other mail files?

I've long used the rmail-mime package which uses different
buffer than the RMAIL file buffer for displaying a decoded
message, and it doesn't have a serious problem.  The only
problem I feel is the somewhat slowness of
rmail-search-forward/backward.  As rmail.el already has
various *-function variables
(e.g. rmail-show-mime-function), what rmail-mime does is
just setting proper functions to those variables.  I'll
attach the core file (rmail-mime.el) of that package so that
you can see how it works.

Unfortunately, rmail-mime package provides various its own
functions for handling mime features that conflicts with the
current Gnus, and is not maintained now.  So it seems very
difficult to include it in Emacs.  But, I think it's
possible to utilze Gnus' mime facilities in the similar way.

>     file, and the question I was asking is how to store the decoded
>     characters in that file, if you don't want to decode them each time
>     you look at that message.  Are you suggesting to store them, after
>     decoding, in the internal Emacs format (i.e. emacs-mule)?  That would
>     mean that only Emacs will be able to read the resulting mbox file.

> That is a valid point.

> A new idea just occurred to me.  Moving to a message could copy that
> message in the buffer, decode the copy, and display that copy using
> narrowing instead of the original message.  If you edit the message,
> exiting the editing mode will reencode it and put that in place
> of the original message.

> We could have a new feature to omit part of the buffer when saving the
> file.  Rmail could use it so that this copy is not saved.  This
> feature should not affect auto-saving.

> As an optimization, if there are attachments, don't copy them.  Just
> copy and decode the main text of the message.  (Attachments don't need
> character set decoding, since they are in ASCII.)  Put the copy after
> the original, and the attachments will effecvtively become part of it.

> Does anyone see a flaw in this?

One disadvantage of that method compared to using a
different buffer is that, RMAIL file must be read into a
multibyte buffer, which requires decoding all 8-bit bytes
into multibyte 8-bit characters.  I think the percentage of
8-bit bytes is small, but the decoding process move memories
many times.  If we use a different buffer for decoding, that
process becomes unnecessary.  RMAIL file tends to become
very big (especially for novice users).

---
Kenichi Handa
handa@m17n.org

----------------------------------------------------------------------
;;; rmail-mime.el --- Add MIME handling facility to RMAIL

;; Copyright (C) 2001 Free Software Foundation, Inc.

;; Author: MORIOKA Tomohiko <tomo@m17n.org>
;; Keywords: mail, news, MIME, multimedia, multilingual, encoded-word

;; This file is part of SEMI (Setting for Emacs MIME Interfaces).

;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 2, or (at
;; your option) any later version.

;; This program is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Code:

(require 'mime-view)

(defun rmail-decode-header (decoded-buffer original-buffer start end)
  (set-buffer (get-buffer-create decoded-buffer))
  (erase-buffer)
  (insert-buffer-substring original-buffer start end)
  (mime-decode-header-in-buffer rmail-enable-mime))

(defun rmail-decode-mime-message (decoded-buffer original-buffer msg)
  (save-excursion
    (set-buffer original-buffer)
    (save-restriction
      (narrow-to-region (rmail-msgbeg msg)
			(rmail-msgend msg))
      (setq mime-message-structure
	    (mime-open-entity 'babyl original-buffer))
      (mime-display-message mime-message-structure decoded-buffer)))
  (set-buffer decoded-buffer))

(defun rmail-view-kill-rmail-buffer ()
  (if rmail-buffer (kill-buffer rmail-buffer)))

(defvar rmail-view-mode-map nil)

(defun rmail-show-mime-message ()
  (let ((abuf (current-buffer))
	(buf-name (concat (buffer-name) "-view"))
	buf win)
    (narrow-to-region (rmail-msgbeg rmail-current-message)
		      (rmail-msgend rmail-current-message))
    (setq mime-message-structure
	  (mime-open-entity 'babyl abuf))
    (set-buffer (mime-display-message mime-message-structure
				      buf-name nil
				      nil nil rmail-view-mode-map))
    (setq buf (current-buffer))
    (make-local-variable 'font-lock-defaults)
    (setq font-lock-defaults
	  '(rmail-font-lock-keywords
	    t nil nil nil
	    (font-lock-maximum-size . nil)
	    (font-lock-fontify-buffer-function
	     . rmail-fontify-buffer-function)
	    (font-lock-unfontify-buffer-function
	     . rmail-unfontify-buffer-function)
	    (font-lock-inhibit-thing-lock
	     . (lazy-lock-mode fast-lock-mode))))
    (make-local-variable 'rmail-buffer)
    (setq rmail-buffer abuf)
    (make-local-variable 'rmail-view-buffer)
    (setq rmail-view-buffer (current-buffer))
    (make-local-variable 'rmail-summary-buffer)
    (setq rmail-summary-buffer
	  (with-current-buffer rmail-buffer
	    rmail-summary-buffer))
    (make-local-variable 'rmail-current-message)
    (setq rmail-current-message
	  (with-current-buffer rmail-buffer
	    rmail-current-message))
    (make-local-variable 'kill-buffer-hook)
    (add-hook 'kill-buffer-hook 'rmail-view-kill-rmail-buffer)
    (let ((mode-line
	   (with-current-buffer abuf
	     (setq rmail-view-buffer buf)
	     mode-line-process)))
      (setq mode-line-process mode-line))
    (if (and (setq win (get-buffer-window abuf))
	     buf)
	(set-window-buffer win buf))
    (bury-buffer rmail-buffer)
    (run-hooks 'rmail-show-mime-message-hook)))

(defun rmail-insert-mime-forwarded-message (forward-buffer)
  (insert (mime-make-tag "message" "rfc822"))
  (insert "\n")
  (mime-insert-entity (with-current-buffer forward-buffer
			mime-message-structure)))

(defun rmail-insert-mime-resent-message (forward-buffer)
  (mime-insert-entity (with-current-buffer forward-buffer
			mime-message-structure)))

(defun rmail-enable-mime ()
  (interactive)
  (setq rmail-enable-mime t)
  (rmail-show-message))

(defun rmail-disable-mime ()
  (interactive)
  (let ((buf rmail-buffer))
    (when rmail-enable-mime
      (remove-hook 'kill-buffer-hook 'rmail-view-kill-rmail-buffer)
      (set-window-buffer (selected-window) buf)
      (kill-buffer rmail-view-buffer))
    (set-buffer buf))
  (setq rmail-enable-mime nil
	rmail-view-buffer (current-buffer))
  (rmail-show-message))

(defun rmail-search-mime-message (msg regexp)
  "Search the message of number MSG for REGEXP.
If the search succeeds, return non-nil.  Otherwise, return nil."
  (save-excursion
    (rmail-decode-mime-message " *RMAIL-temp-VIEW*" (current-buffer) msg)
    (goto-char (point-min))
    (prog1 (re-search-forward regexp nil t)
      (kill-buffer " *RMAIL-temp-VIEW*"))))

(defun rmail-search-mime-header (msg regexp limit)
  "Search the message header of number MSG for REGEXP.
The current point is the beginninf of header,
and LIMIT is the end position of header.
If the search succeeds, return non-nil.  Otherwise, return nil."
  (save-excursion
    (rmail-decode-header " *RMAIL-temp-VIEW*" (current-buffer) (point) limit)
    (goto-char (point-min))
    (prog1 (re-search-forward regexp nil t)
      (kill-buffer " *RMAIL-temp-VIEW*"))))

(set-alist 'mime-raw-representation-type-alist 'rmail-mode
	   (if rmail-enable-mime
	       'binary
	     'cooked))

(set-alist 'mime-preview-over-to-previous-method-alist
	   'rmail-mode
	   (function
	    (lambda ()
	      (message "Beginning of buffer")
	      ;; (rmail-previous-undeleted-message 1)
	      )))

(set-alist 'mime-preview-over-to-next-method-alist
	   'rmail-mode
	   (function
	    (lambda ()
	      (message "End of buffer")
	      ;; (rmail-next-undeleted-message 1)
	      )))

(set-alist 'mime-preview-quitting-method-alist 'rmail-mode #'rmail-quit)

;; Override values defined in rmail.
(eval-after-load "rmail"
  '(progn
     (define-key rmail-mode-map "v" 'rmail-enable-mime)
     (setq rmail-show-mime-function
	   (function rmail-show-mime-message)
	   rmail-insert-mime-forwarded-message-function
	   (function rmail-insert-mime-forwarded-message)
	   rmail-insert-mime-resent-message-function
	   (function rmail-insert-mime-resent-message)
	   rmail-search-mime-message-function
	   (function rmail-search-mime-message)
	   rmail-search-mime-header-function
	   (function rmail-search-mime-header))
     (unless rmail-view-mode-map
       (setq rmail-view-mode-map (mime-view-define-keymap rmail-mode-map))
       (define-key rmail-view-mode-map
	 "p" (function rmail-previous-undeleted-message))
       (define-key rmail-view-mode-map
	 "n" (function rmail-next-undeleted-message))
       (define-key rmail-view-mode-map
	 "u" (function rmail-undelete-previous-message))
       (define-key rmail-view-mode-map
	 "a" (function rmail-add-label))
       (define-key rmail-view-mode-map
	 "\C-c\C-c" (function rmail-disable-mime)))))

;; Override values defined in rmailsum.
(eval-after-load "rmailsum"
  '(setq rmail-summary-line-decoder
	 (function
	  (lambda (string)
	    (eword-decode-string
	     (decode-coding-string string 'undecided))))))

;; Override values defined in sendmail.
(eval-after-load "sendmail"
  '(progn
     (add-hook 'mail-setup-hook 'turn-on-mime-edit)
     (add-hook 'mail-send-hook 'mime-edit-maybe-translate)))

(provide 'rmail-mime)

Re: Emacs 22 branch created.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, henrik.enberg@telia.com, emacs-devel@gnu.org
> Date: Tue, 01 May 2007 20:13:28 -0400
> 
>     > The other approach also needs peculiar changes in lower-level features
>     > to work right.  Various operations on the message buffer would have to
>     > operate on the file buffer as well.  These include set-buffer-file-name,
>     > rename-buffer, as well as saving.
> 
>     Those other features can all be done at the UI-level, where they belong, not
>     at a low level.  At the very least, it's all done in elisp, without any need
>     to fiddle with C code.
> 
> I don't think that is true.  Changes in set-buffer-file-name and rename-buffer
> would have to be done at the C level.

I think we have enough hook variables to do this in Lisp.