Rmail mbox-format branch

Rmail mbox-format branch

[Richard Stallman]

I would like the Rmail changes to use mbox format to be installed
before the release.  Is anyone testing that yet?

Re: Rmail mbox-format branch

[Stefan]

> I would like the Rmail changes to use mbox format to be installed
> before the release.  Is anyone testing that yet?

Let's move it on the trunk.  As long as it's on a branch, it won't get much
testing if any.


        Stefan

Re: Rmail mbox-format branch

[Paul Michael Reilly]

Stefan wrote:
>>I would like the Rmail changes to use mbox format to be installed
>>before the release.  Is anyone testing that yet?
> 
> 
> Let's move it on the trunk.  As long as it's on a branch, it won't get much
> testing if any.

I agree that it won't get much testing on the branch.  However, I am 
leery that it got hardly any testing on the branch, so if a release is 
planned any time soon, then I'd be inclined to move it to the trunk 
AFTER the release is cut and put it out with the next release.  That 
would insure that it got plenty of testing.

-pmr

Re: Rmail mbox-format branch

[Stefan]

> I agree that it won't get much testing on the branch.  However, I am leery
> that it got hardly any testing on the branch, so if a release is planned any
> time soon, then I'd be inclined to move it to the trunk AFTER the release is
> cut and put it out with the next release.  That would insure that it got
> plenty of testing.

We haven't even started beta-testing yet.


        Stefan

Re: Rmail mbox-format branch

[Eli Zaretskii]

> Date: Thu, 09 Sep 2004 10:44:22 -0400
> From: Paul Michael Reilly <pmr@pajato.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> I agree that it won't get much testing on the branch.  However, I am 
> leery that it got hardly any testing on the branch, so if a release is 
> planned any time soon, then I'd be inclined to move it to the trunk 
> AFTER the release is cut and put it out with the next release.

Yours are valid concerns, but all things considered, I tend to agree
with Stefan.  That's because the release process will not be short,
probably a couple of months at the least, so we will have enough time
to fix any bugs.

OTOH, if we don't do this now, it will need to wait until a very
distant next release.

Re: Rmail mbox-format branch

[Miles Bader]

On Thu, Sep 09, 2004 at 09:56:16PM +0300, Eli Zaretskii wrote:
> OTOH, if we don't do this now, it will need to wait until a very
> distant next release.

Will the next release (after 21.4) be distant?

I was envisioning just moving the unicode branch to the trunk about 5 minutes
after 21.4 is released, and immediately going into testing for version 22.

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

Re: Rmail mbox-format branch

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Thu, Sep 09, 2004 at 09:56:16PM +0300, Eli Zaretskii wrote:
>> OTOH, if we don't do this now, it will need to wait until a very
>> distant next release.
>
> Will the next release (after 21.4) be distant?
>
> I was envisioning just moving the unicode branch to the trunk about 5 minutes
> after 21.4 is released, and immediately going into testing for version 22.

That was my understanding too.


I don't really see why we cannot wait with rmail/mbox until 22.1.
rmail has done fine with BABYL for MANY years -- can't it do one more?

Considering that the new code is said to be mostly UNTESTED (contrary
to Gnus 5.10 which was very well tested), merging it now will
_definitely_ delay the release of 21.4.

If we hope for a 21.4 release in 2004 (rather than 2104), we should
probably NOT do that.

Compare these two schedules (if testing rmail adds 2 months delay):

Release:                When
21.4 without rmail      End 2004
22.1 with rmail         Mid 2005


Release:                When
21.4 with rmail         Mar 2005
22.1                    Nov 2005  (include holiday season)


So 22.1 would be 21.4 with unicode, multi-tty, plus rmail/mbox.
And I don't see why we shouldn't be able to release that in 2005
(which considering the time span between 21.1 and 21.4 isn't distant).


BTW, what happened with the face-remapping for 21.4 ?

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

Re: Rmail mbox-format branch

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 10 Sep 2004 09:36:20 +0200
> Cc: Paul Michael Reilly <pmr@pajato.com>, Eli Zaretskii <eliz@gnu.org>,
> 	emacs-devel@gnu.org
> 
> Miles Bader <miles@gnu.org> writes:
> 
> > On Thu, Sep 09, 2004 at 09:56:16PM +0300, Eli Zaretskii wrote:
> >> OTOH, if we don't do this now, it will need to wait until a very
> >> distant next release.
> >
> > Will the next release (after 21.4) be distant?
> >
> > I was envisioning just moving the unicode branch to the trunk about 5 minutes
> > after 21.4 is released, and immediately going into testing for version 22.
> 
> That was my understanding too.

I don't think it's reasonable to hope for that.  Experience shows that
21.4 will most probably be followed by a bugfix release 21.5, a month
or two after 21.4 is out; if that happens, we cannot move 22.1 into a
pretest before the bugfix release is out.  Since we cannot know
whether 21.4 will need a bugfix release, we will wait at least a month
or so before we decide, which again doesn't allow 22.1 to start a
pretest immediately.

Experience also shows that a pretest of a major new release takes
several months.  21.1 took more than 6 months, IIRC, and it was used
by more people before the pretest than the Unicode branch is now.

So I don't think 22.1 could be released before the end of next year,
even with the most favorable assumptions.

> If we hope for a 21.4 release in 2004 (rather than 2104), we should
> probably NOT do that.

One can hope, but I personally don't believe 21.4 will be out in 2004,
again based on past experience.  Perhaps it would be educational to
compile and publish some representative statistics of how long it
takes to get a release through a pretest.

Re: Rmail mbox-format branch

[Miles Bader]

"Eli Zaretskii" <eliz@gnu.org> writes:
> Experience shows that 21.4 will most probably be followed by a bugfix
> release 21.5, a month or two after 21.4 is out; if that happens, we
> cannot move 22.1 into a pretest before the bugfix release is out.
> Since we cannot know whether 21.4 will need a bugfix release, we will
> wait at least a month or so before we decide, which again doesn't
> allow 22.1 to start a pretest immediately.

What's wrong with using a branch for bugfixes in 21.4?

The point of keeping a pending release on the trunk is to make sure it
gets a lot of testing.  If 21.4 is released, then it's gonna be
reasonably solid, so there seems little point to having it hang around
on the trunk Just In Case; using a branch to fix those bugs that creep
into the release (and which are deemed serious enough to warrant another
minor release) seems quite reasonable.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Rmail mbox-format branch

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> "Eli Zaretskii" <eliz@gnu.org> writes:
>> Experience shows that 21.4 will most probably be followed by a bugfix
>> release 21.5, a month or two after 21.4 is out; if that happens, we
>> cannot move 22.1 into a pretest before the bugfix release is out.
>> Since we cannot know whether 21.4 will need a bugfix release, we will
>> wait at least a month or so before we decide, which again doesn't
>> allow 22.1 to start a pretest immediately.
>
> What's wrong with using a branch for bugfixes in 21.4?

I don't know if Eli argued against branching for 21.4 bug fixes.

But I think the point was that we should not run two pre-tests (21.5
and 22.1) at the same time.

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

Re: Rmail mbox-format branch

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 10 Sep 2004 12:41:39 +0200
> Cc: pmr@pajato.com, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> But I think the point was that we should not run two pre-tests (21.5
> and 22.1) at the same time.

Exactly.

Re: Rmail mbox-format branch

[Eli Zaretskii]

> Cc: storm@cua.dk, pmr@pajato.com, emacs-devel@gnu.org
> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: Fri, 10 Sep 2004 18:38:50 +0900
> 
> What's wrong with using a branch for bugfixes in 21.4?

Nothing.  What I meant was that we cannot run 2 pretests at the same
time, so if 21.4 is immediately followed by another bugfix release
from the same branch, we cannot start pretesting 22.1 until 21.5 is
out.

Re: Rmail mbox-format branch

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

> I don't think it's reasonable to hope for that.  Experience shows that
> 21.4 will most probably be followed by a bugfix release 21.5, a month
> or two after 21.4 is out; if that happens, we cannot move 22.1 into a
> pretest before the bugfix release is out.  

It will probably take a month or two for the emacs developers
to fix bugs in the unicode branch before starting pretest on 22.1 --

in the meantime, we can run a pretest for 21.5 bug-fix release if
necessary.

>
> Experience also shows that a pretest of a major new release takes
> several months.  21.1 took more than 6 months, IIRC, and it was used
> by more people before the pretest than the Unicode branch is now.

21.1 was developed within a "closed group".  21.4 has been developed
in a wide open forum since day 1, and I think that CVS emacs is used
by MANY users everyday already -- and as such has got more pre-testing
already than 21.1 ever got!

So I'm pretty optimistic re. the length of the 21.4 pretest.

But if we merge the rmail/mbox branch to trunk now, I'm much less
optimistic :-(

> So I don't think 22.1 could be released before the end of next year,
> even with the most favorable assumptions.

Could be...

Personally I don't think that's too bad if we get 21.4 out in 2004.

I think rmail can use BABYL until end 2005 -- why not ??

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

Re: Rmail mbox-format branch

[Eli Zaretskii]

> Cc: pmr@pajato.com,  emacs-devel@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 10 Sep 2004 12:39:37 +0200
> 
> It will probably take a month or two for the emacs developers
> to fix bugs in the unicode branch before starting pretest on 22.1 --
> 
> in the meantime, we can run a pretest for 21.5 bug-fix release if
> necessary.

Okay, but that means we cannot ``immediately'' start pretesting 22.1.

> > Experience also shows that a pretest of a major new release takes
> > several months.  21.1 took more than 6 months, IIRC, and it was used
> > by more people before the pretest than the Unicode branch is now.
> 
> 21.1 was developed within a "closed group".  21.4 has been developed
> in a wide open forum since day 1, and I think that CVS emacs is used
> by MANY users everyday already -- and as such has got more pre-testing
> already than 21.1 ever got!
> 
> So I'm pretty optimistic re. the length of the 21.4 pretest.

I was talking about the length of the pretest of 22.1, not of 21.4.
The unicode branch is developed by a small group as well, I think it's
even smaller than the one who used 21.1 during its development.

> But if we merge the rmail/mbox branch to trunk now, I'm much less
> optimistic :-(

I don't understand why.  Most Emacs suers don't use RMAIL anyway, so
please explain the reasons for your pessimism.

Re: Rmail mbox-format branch

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> But if we merge the rmail/mbox branch to trunk now, I'm much less
>> optimistic :-(
>
> I don't understand why.  Most Emacs suers don't use RMAIL anyway, so
> please explain the reasons for your pessimism.

Because "most emacs users don't use RMAIL" (i.e. only a few of the
pretesters will actually test it) it will inevitably take some time
for the more subtle bugs (which suddenly delete somebody's mailbox) to
surface.

And why delay 21.4 to include somethings which "most users don't use" ??

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

Re: Rmail mbox-format branch

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Fri, 10 Sep 2004 14:38:32 +0200
> Cc: pmr@pajato.com, emacs-devel@gnu.org
> 
> And why delay 21.4 to include somethings which "most users don't use" ??

This goes both ways, you know: if "most users don't use" it, you won't
have to delay the release.

Re: Rmail mbox-format branch

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: storm@cua.dk (Kim F. Storm)
>> Date: Fri, 10 Sep 2004 14:38:32 +0200
>> Cc: pmr@pajato.com, emacs-devel@gnu.org
>> 
>> And why delay 21.4 to include somethings which "most users don't use" ??
>
> This goes both ways, you know: if "most users don't use" it, you won't
> have to delay the release.

If you have many users, bugs in the code will (most likely) be detected sooner,
i.e. well before the release date.

If you have few users, bugs may go undetected longer, and may either
be detected "just before the release", thus delaying the release, or
worse, still be present in the released software.

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

Re: Rmail mbox-format branch

[Richard Stallman]

Rmail is the primary Emacs mail-reader.  I don't know how many people
currently use it, but I will ignore any suggestion to treat it as
unimportant.

Re: Rmail mbox-format branch

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, pmr@pajato.com, emacs-devel@gnu.org
> Date: Sat, 11 Sep 2004 06:52:00 -0400
> 
> Rmail is the primary Emacs mail-reader.  I don't know how many people
> currently use it, but I will ignore any suggestion to treat it as
> unimportant.

If something that I said somehow implied that RMAIL is to be
considered unimportant, then please disregard that something.  I
couldn't have possibly meant anything like that, since I'm one of the
few people who use RMAIL (and _only_ RMAIL) to read my mail.

Re: Rmail mbox-format branch

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Rmail is the primary Emacs mail-reader.  I don't know how many people
> currently use it, but I will ignore any suggestion to treat it as
> unimportant.

I didn't imply that I think RMAIL is unimportant -- quite the contrary.

If we don't have enough users test the mbox branch, we _risk_ breaking
RMAIL support in 21.4.  So if we are not confident RMAIL with mbox
will be fully tested in 21.4, we better delay it to 22.1

But if you say we should have the new rmail in 21.4, we should merge
it now, so it can receive maximum testing.

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

Re: Rmail mbox-format branch

[Luc Teirlinck]

Kim Storm wrote:

   Compare these two schedules (if testing rmail adds 2 months delay):

   Release:                When
   21.4 without rmail      End 2004
   22.1 with rmail         Mid 2005


   Release:                When
   21.4 with rmail         Mar 2005
   22.1                    Nov 2005  (include holiday season)

That first schedule is completely unrealistic.  There is no way that
we will have all manuals checked, and all problems that come to light
while checking the manuals fixed, before the end of the year.  At the
present rate, even end March is rather optimistic.

Sincerely,

Luc.

Proof-reading manuals (was Re: Rmail mbox-format branch)

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    Compare these two schedules (if testing rmail adds 2 months delay):
>
>    Release:                When
>    21.4 without rmail      End 2004
>    22.1 with rmail         Mid 2005
>
>
>    Release:                When
>    21.4 with rmail         Mar 2005
>    22.1                    Nov 2005  (include holiday season)
>
> That first schedule is completely unrealistic.  There is no way that
> we will have all manuals checked, and all problems that come to light
> while checking the manuals fixed, before the end of the year.  At the
> present rate, even end March is rather optimistic.
>

Luc,

IMO you are doing a tremendous (and probably unprecedented) job at
proof-reading the manuals in minute details.  As a result you find
quite a number of problems, some of which are new, but others which I
bet have existed for several releases.

The question is what level of "correctness" and "completeness" we
require before we can make the 21.4 release.

Of course we should strive for 100%, but personally I would rather
make a release in 2004 with a few errors and omissions in the
documentation than wait several more months "just" because
proof-reading of the manuals is not complete or has revealed
inconsistencies.

That said, proof-reading the manuals definitely deserves more attention,
and I hope to have some time soon to help with the process.

To help organize the process, I have added a list of all the
relevant texi files in admin/FOR-RELEASE like this:

DONE	SECTION
---------------------------------------------
	man/abbrevs.texi

If you would update the list according to your current progress,
I hope others will jump in and start proof-reading some of
the "open" sections.

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

Re: Proof-reading manuals (was Re: Rmail mbox-format branch)

[Luc Teirlinck]

Kim Storm wrote:

   To help organize the process, I have added a list of all the
   relevant texi files in admin/FOR-RELEASE like this:

   DONE	SECTION
   ---------------------------------------------
	   man/abbrevs.texi

For lispref this way of organizing things may be reasonable, but for
man it makes no sense.  It might be nice to have things like
man/cl.texi updated, but such things are a luxury right now.  What we
worry about now is the Emacs and Elisp manual and info.texi.

I proofread all of the Elisp manual except the chapters (if you do
`C-h i elisp'):

Advising Functions
Debugging
Customization
Modes
Text
Processes
Display
Calendar

I did also not check or update:

Antinews
GNU Free Documentation License 
GPL
Standard Buffer-Local Variables
Standard Keymaps
Standard Hooks
New Symbols

However, I have read Text up to and including `(elisp)Maintaining Undo'.

I _will_ read Customization because there still is some unfinished
business there.

I still need to go over some details in some of the sections I read,
due to developments after I read them.

For the Emacs manual, I read everything up to and including (in Info
order), Info Chapter 29, Commands for Human Languages.  (The "29" only
makes sense if you are using texinfo 4.7.)

However, I skipped `(emacs)HTML Mode' and `(emacs)Nroff Mode', because
I never use the material in those sections (I do not know HTML, SGML,
XML nor NROFF).

I will still have to take a closer look at some sections I already
read.

Of course, the original aim was to have everything proofread by at
least two persons, but that seems unrealistic now.

Note that the reason why all of this takes time is not just the
proofreading and correcting of the documentation.  All kinds of bugs
come to light during proofreading and they have to be corrected. 

Sincerely,

Luc.

Re: Proof-reading manuals (was Re: Rmail mbox-format branch)

[Richard Stallman]

    For lispref this way of organizing things may be reasonable, but for
    man it makes no sense.  It might be nice to have things like
    man/cl.texi updated, but such things are a luxury right now.  What we
    worry about now is the Emacs and Elisp manual and info.texi.

I agree.  Could you remove the other files from the `man' list, keeping
only info.texi and those that are part of the Emacs manual?
Also, remove gfdl.texi and gpl.texi if they are included.

    I proofread all of the Elisp manual except the chapters (if you do
    `C-h i elisp'):

    Advising Functions
    Debugging
    Customization
    Modes
    Text
    Processes
    Display
    Calendar

Nearly all the work that has been done, has been done by you,
and you are doing a very good job of it.

I am pretty sure there has been little change in the advice system.
If you could read the others of those sections, it would be very
useful.

    I did also not check or update:

    Antinews
    GNU Free Documentation License 
    GPL
    Standard Buffer-Local Variables
    Standard Keymaps
    Standard Hooks
    New Symbols

The file lispref/anti.texi is for the Emacs 20 to 21 transition.
This file needs to be rewritten from zero, based on what's in
etc/NEWS since 21.1.

There is no need to review the GFDL and GPL sections.
Checking those four appendixes only needs to be done once,
if someone can do them in a careful way.

Re: Proof-reading manuals (was Re: Rmail mbox-format branch)

[Luc Teirlinck]

Richard Stallman wrote:

       For lispref this way of organizing things may be reasonable, but for
       man it makes no sense.  It might be nice to have things like
       man/cl.texi updated, but such things are a luxury right now.  What we
       worry about now is the Emacs and Elisp manual and info.texi.

   I agree.  Could you remove the other files from the `man' list, keeping
   only info.texi and those that are part of the Emacs manual?
   Also, remove gfdl.texi and gpl.texi if they are included.

Done.

I removed man/faq.texi, because it has nothing to do with the Emacs manual.
Should we add man/faq.texi as something that should be updated?

I removed man/ack.texi, because it is already listed separately.

I still have to take care of some problems in some of the chapters I
read and marked with LT.  I have not yet sent my suggested changes for
man/text.texi.

The original aim was to have everything proofread by at
least two persons.  For the Elisp manual, that seems unrealistic now.

For the Emacs manual, it might be better if we kept that standard, if
possible.  For instance, I did read man/mule.texi, but I am not a
heavy user of that stuff.  Thus it might be better if somebody using
it more heavily would double check it.  There are other instances like
that.

The Emacs manual could easily be checked by somebody not knowing
Texinfo.  The way we have organized things now (referring to the .texi
files) might not be very understandable to such a person.

Sincerely,

Luc.

Re: Proof-reading manuals (was Re: Rmail mbox-format branch)

[Richard Stallman]

    The original aim was to have everything proofread by at
    least two persons.  For the Elisp manual, that seems unrealistic now.

Everything should be proofread by at least two.  This is perfectly
easy if people participate, so please do not suggest to people
that the goal has changed.

Re: Proof-reading manuals

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The original aim was to have everything proofread by at
>     least two persons.  For the Elisp manual, that seems unrealistic now.
>
> Everything should be proofread by at least two.  This is perfectly
> easy if people participate, so please do not suggest to people
> that the goal has changed.

I have added a second "DONE2" column to the lists in FOR-RELEASE -- so we can
keep track of which sections have been reviewed (at least) twice.

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

Re: Rmail mbox-format branch

[Richard Stallman]

I think we need at least one or two people to try the mbox-format code
before we install it in the trunk.  Can a couple of people try it now?

Re: Rmail mbox-format branch

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: pmr@pajato.com, emacs-devel@gnu.org
> Date: Sat, 11 Sep 2004 06:50:56 -0400
> 
> I think we need at least one or two people to try the mbox-format code
> before we install it in the trunk.  Can a couple of people try it now?

Trying things on a branch pose a difficulty for me, since I have only
a few hours per week to work on Emacs, and checking out and
bootstrapping a tree takes a large portion of that time.  That is why
I asked to merge that branch with the trunk.

Re: Rmail mbox-format branch

[Stefan]

>> I think we need at least one or two people to try the mbox-format code
>> before we install it in the trunk.  Can a couple of people try it now?

> Trying things on a branch pose a difficulty for me, since I have only
> a few hours per week to work on Emacs, and checking out and
> bootstrapping a tree takes a large portion of that time.  That is why
> I asked to merge that branch with the trunk.

100% agreement,


        Stefan

Re: Rmail mbox-format branch

[Richard Stallman]

    Trying things on a branch pose a difficulty for me, since I have only
    a few hours per week to work on Emacs, and checking out and
    bootstrapping a tree takes a large portion of that time.  That is why
    I asked to merge that branch with the trunk.

That would be useful, but we need it to be tried by a few people
first.

Re: Rmail mbox-format branch

[Thien-Thi Nguyen]

Richard Stallman <rms@gnu.org> writes:

       Trying things on a branch pose a difficulty for me, since I have
       only a few hours per week to work on Emacs, and checking out and
       bootstrapping a tree takes a large portion of that time.  That is
       why I asked to merge that branch with the trunk.

   That would be useful, but we need it to be tried by a few people
   first.

if the people who are willing to try it (myself included) prefer the
instability of merging the branch to the trunk to the inconvenience of
building a separate tree, it seems like a good idea to do the merge now.
both instability and inconvenience are temporary, but the latter doesn't
preclude the former anyway, so choosing it is not a win.

thi

Re: Rmail mbox-format branch

[Robert J. Chassell]

   I think we need at least one or two people to try the mbox-format code
   before we install it in the trunk.  Can a couple of people try it now?

I just tried the rmail-mbox-branch on an mbox text file.

`rmail-activate-urls' is erroneously called which prevents Emacs from
reading the mbox file.  The *Messages* buffer says
`Symbol's function definition is void: browse-url-activate-urls'.

When I comment out the `(rmail-activate-urls)' line in the function
definition for `rmail-show-message' in the mbox-format branch of
rmail.el, I am able to read the email.

`rmail-activate-urls' does not exist in the `rmail-format' (main)
branch of the /usr/local/src/emacs/lisp/mail/ directory.


Here is what I did:

    ## in a shell
    ## cd <to-the-CVS-repository-on-my-machine> 
    cd /usr/local/src/emacs/lisp/mail

    ## discover the name of the branch
    cvs status -v rmail.el

    ## convert all files to that branch 
    ##     time is: Sat, 2004 Sep 11  12:56 UTC
    cvs update -r rmail-mbox-branch

        # Run a `plain vanilla' Emacs using the mbox branch:
        #     /usr/local/src/emacs/src/emacs -Q
        # #### and look at an mbox file:
        # 
        #     C-u M-x rmail RET mbox-foo RET 
        # 
        # ## In *Messages* buffer, see:
        # 
        # Processing new messages...done (55)
        # save-excursion: Symbol's function definition is void:
        #  browse-url-activate-urls

        # Comment out the `(rmail-activate-urls)' line in the function
        # definition for `rmail-show-message' in the mbox-format branch of
        # rmail.el and evaluate the rmail.el buffer.
        # Now able to read email in mbox-foo.

    ## update to previous version, using `-A' to reset
    cvs update -A

        # Run a `plain vanilla' Emacs using the previous branch:
        #     /usr/local/src/emacs/src/emacs -Q
        # #### and look at the same mbox file:
        # 
        #     C-u M-x rmail RET mbox-foo RET 
        # 
        # ## In *Messages* buffer, see:
        #         Converting to Babyl format...done
        # ## Also able to read email from same mbox file.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Rmail mbox-format branch

[Richard Stallman]

    `rmail-activate-urls' is erroneously called which prevents Emacs from
    reading the mbox file.  The *Messages* buffer says
    `Symbol's function definition is void: browse-url-activate-urls'.

Does this fix that bug?  (You'd need to do update-file-autoloads then
rebuild Emacs.)

*** browse-url.el	15 Feb 2003 13:03:27 -0500	1.27.2.1
--- browse-url.el	13 Sep 2004 16:28:04 -0400	
***************
*** 1303,1308 ****
--- 1303,1309 ----
  (defvar browse-url-activation-alist nil
    "A per buffer cache of overlays that mark URLs in the buffer.")
  
+ ;;;###autoload
  (defun browse-url-activate-urls (start end &optional face visited-face mouse-face keymap)
    "Activate the URLs in the region of the current buffer bracketed by START and END.
  This creates an overlay on each URL in the region. FACE, if provided,

Re: Rmail mbox-format branch

[Richard Stallman]

I think it needs to be tested at least a little before we put it in
the trunk.  I don't know if anyone has actually used it yet.

Re: Rmail mbox-format branch

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> I think it needs to be tested at least a little before we put it in
> the trunk.  I don't know if anyone has actually used it yet.

Our problem is that many people use Gnus for their mail.  On #emacs,
most people recommend to use Gnus when newbies ask for mail within
Emacs.  Can we look specifically for RMAIL users willing to help us
test?  We could ask on the newsgroups, for example.  I will ask on
#emacs...

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: Rmail mbox-format branch

[Richard Stallman]

    Our problem is that many people use Gnus for their mail.  On #emacs,
    most people recommend to use Gnus when newbies ask for mail within
    Emacs.

The one time I tried to start Gnus (to read news), it was so much
hassle when starting up that I killed it.  I recommend use of Rmail to
read mail.

    Can we look specifically for RMAIL users willing to help us
    test?  We could ask on the newsgroups, for example.  I will ask on
    #emacs...

Thank you.