Major update just committed

Major update just committed

[Kim F. Storm]

As I told you last week, I was about to commit a major set of changes
to the src directory.  That has just happened (see the Changelog for
details).

Since these changes are pretty intrusive, I have created
two tags in CVS before and after the commit:
        kfs_20030524_pre and kfs_20030524_post.

as usual, I cannot test the MAC, W32, and MSDOS ports, only the X
version on GNU/Linux, so don't hesitate to report any problems with
the patches (unless you can fix them yourself).

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

Re: Major update just committed

[Juanma Barranquero]

On 25 May 2003 02:48:49 +0200, storm@cua.dk (Kim F. Storm) wrote:

> as usual, I cannot test the MAC, W32, and MSDOS ports

It bootstraps fine on XP.

                                                           /L/e/k/t/u

Re: Major update just committed

[David Ponce]

> It bootstraps fine on XP.

It bootstraps fine on NT4 too (compiled with latest MingW toolkit).

David

Re: Major update just committed

[Miles Bader]

I now see a approx. two-column wide strip of emacs' frame not being
redraw when a emacs window is raised over a window previously obscuring
part of the emacs X window.  It only seems to happen on the _right_
side of the exposed area.

E.g., if I have this:

    +----------------------+
    |                      |
    |      Emacs           |
    |                      |
    |   +--------------+   |
    |   |              |   |
    |   |  Other X app |   |
    |   |              |   |
    +---|              |---+
        |              |
        +--------------+

and raise the Emacs frame, I'll get this:

    +----------------------+
    |                      |
    |      Emacs           |
    |                      |
    |                 XX   |
    |                 XX   |
    |                 XX   |
    |                 XX   |
    +----------------------+
        |              |
        +--------------+

Where the `XX' area is not redrawn properly (it ends up blank).

The fact that the problem area is about two columns wide make me think
that it's somehow related to the fringe calculations.

-Miles
--
Occam's razor split hairs so well, I bought the whole argument!

Re: Major update just committed

[Kim F. Storm]

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

> I now see a approx. two-column wide strip of emacs' frame not being
> redraw when a emacs window is raised over a window previously obscuring
> part of the emacs X window.  It only seems to happen on the _right_
> side of the exposed area.
> ...
> The fact that the problem area is about two columns wide make me think
> that it's somehow related to the fringe calculations.

I see that too -- but only when scroll-bars are on the left, so
I think it is related to the width of the scroll bars.

I'll investigate and fix asap.

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

Re: Major update just committed

[Kenichi Handa]

In article <5x3cj3x34e.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> As I told you last week, I was about to commit a major set
> of changes to the src directory.  That has just happened
> (see the Changelog for details).

Are there any other big changes scheduled?  If not, I'll
start the work of synchronizing emacs-unicode to HEAD next
week.

---
Ken'ichi HANDA
handa@m17n.org

Re: Major update just committed

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> In article <5x3cj3x34e.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> > As I told you last week, I was about to commit a major set
> > of changes to the src directory.  That has just happened
> > (see the Changelog for details).
> 
> Are there any other big changes scheduled?  

Not on my part at least :-)

>                                             If not, I'll
> start the work of synchronizing emacs-unicode to HEAD next
> week.

Great news!

So it's about time to change the CVS version number to 22.0.50 (or
better introduce the new version numbers we talked about some time
ago).


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

Re: Major update just committed

[Stefan Monnier]

> > > As I told you last week, I was about to commit a major set
> > > of changes to the src directory.  That has just happened
> > > (see the Changelog for details).
> > 
> > Are there any other big changes scheduled?  
> 
> Not on my part at least :-)
> 
> >                                             If not, I'll
> > start the work of synchronizing emacs-unicode to HEAD next
> > week.
> 
> Great news!
> 
> So it's about time to change the CVS version number to 22.0.50 (or
> better introduce the new version numbers we talked about some time
> ago).

How 'bout creating a EMACS_21_4_RC branch instead if you catch my drift ?

Also, looking at the RC branch, I see that there hasn't been too
many changes committed since 21.3.  Are we really planning on
releasing a bug-fix 21.4 ?


	Stefan

Re: Major update just committed

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Tue, 27 May 2003 18:39:02 -0400
> 
> Also, looking at the RC branch, I see that there hasn't been too
> many changes committed since 21.3.  Are we really planning on
> releasing a bug-fix 21.4 ?

I think we should, since 21.3 broke a few things that are quite
annoying.  I'd suggest to release 21.4 ASAP, with minimal pretest and
no changes except those which fix the bugs introduced by 21.3.

Re: Major update just committed

[Richard Stallman]

    I think we should, since 21.3 broke a few things that are quite
    annoying.  I'd suggest to release 21.4 ASAP, with minimal pretest and
    no changes except those which fix the bugs introduced by 21.3.

That is basically a good idea, though we can fix a few other bugs too
(we already have).

Re: Major update just committed

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Reply-to: rms@gnu.org
> 
>     I think we should, since 21.3 broke a few things that are quite
>     annoying.  I'd suggest to release 21.4 ASAP, with minimal pretest and
>     no changes except those which fix the bugs introduced by 21.3.
> 
> That is basically a good idea, though we can fix a few other bugs too
> (we already have).

IMHO, this is The Mother of All Foobars.  We are tempted to fix a few
more bugs, and in the process introduce a new bug.  Then the pretest
becomes longer, we fix yet more bugs during that (if the release is
delayed, why not make it better, right?).  And then a couple of real
bugs creap in, and we release Emacs with them.

If we continue like that, we won't have a stable version before 21.34,
and the current CVS code that has so many useful improvements will not
be released before year 2035.  If we want to do better, we should use
will power to resist the temptation to fix non-critical bugs.

(Sorry for being in such a grumpy mood so early in the morning.)

Re: Major update just committed

[Stefan Monnier]

> >     I think we should, since 21.3 broke a few things that are quite
> >     annoying.  I'd suggest to release 21.4 ASAP, with minimal pretest and
> >     no changes except those which fix the bugs introduced by 21.3.
> > 
> > That is basically a good idea, though we can fix a few other bugs too
> > (we already have).
> 
> IMHO, this is The Mother of All Foobars.  We are tempted to fix a few

aol-mode


	Stefan

Re: Major update just committed

[Juanma Barranquero]

On Thu, 29 May 2003 06:46:44 +0300, "Eli Zaretskii" <eliz@elta.co.il> wrote:

> If we continue like that, we won't have a stable version before 21.34,
> and the current CVS code that has so many useful improvements will not
> be released before year 2035.  If we want to do better, we should use
> will power to resist the temptation to fix non-critical bugs.
> 
> (Sorry for being in such a grumpy mood so early in the morning.)

Grumpy or not, some of us fully agree with you :)

What's wrong with:

 - branching now (or at least soonish) for a "new features" 21.5

 - releasing ASAP (for S ~ 0) the current RC branch as the last of the 21.[234]
bugfix releases

 - joining the emacs_unicode branch into the trunk so developers can
start to test it more thoroughly

The more we wait, the harder will be to bring emacs_unicode back in sync
with the trunk.


                                                           /L/e/k/t/u

Re: Major update just committed

[Stefan Monnier]

> What's wrong with:
> 
>  - branching now (or at least soonish) for a "new features" 21.5
> 
>  - releasing ASAP (for S ~ 0) the current RC branch as the last of the 21.[234]
> bugfix releases
> 
>  - joining the emacs_unicode branch into the trunk so developers can
> start to test it more thoroughly
> 
> The more we wait, the harder will be to bring emacs_unicode back in sync
> with the trunk.

100% agreed,


	Stefan

Re: Major update just committed

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > What's wrong with:
> > 
> >  - branching now (or at least soonish) for a "new features" 21.5
> > 
> >  - releasing ASAP (for S ~ 0) the current RC branch as the last of the 21.[234]
> > bugfix releases
> > 
> >  - joining the emacs_unicode branch into the trunk so developers can
> > start to test it more thoroughly
> > 
> > The more we wait, the harder will be to bring emacs_unicode back in sync
> > with the trunk.
> 
> 100% agreed,

Me too.

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

Re: Major update just committed

[Richard Stallman]

     - branching now (or at least soonish) for a "new features" 21.5

I think we are waiting for a new Gnus and a new CC-mode
to be installed.

Re: Major update just committed

[Juanma Barranquero]

On Thu, 29 May 2003 20:48:56 -0400
Richard Stallman <rms@gnu.org> wrote:

> I think we are waiting for a new Gnus and a new CC-mode
> to be installed.

Glad to hear, if that means we *will* branch for 21.5 after Gnus and
CC-mode are here.


                                                                Juanma

Re: Major update just committed

[Richard Stallman]

    Glad to hear, if that means we *will* branch for 21.5 after Gnus and
    CC-mode are here.

I don't think we should make a branch for the next non-bug-fix
release.  We should think of what will be the next non-bug-fix release
as the main focus of work, so it should be in the trunk.  It will need
a considerable amount of work to become reliable, I expect.  Some
smaller features can still be installed during that time.

Rather, people should start putting major changes into other branches.

Re: Major update just committed

[Stefan Monnier]

>     Glad to hear, if that means we *will* branch for 21.5 after Gnus and
>     CC-mode are here.
> 
> I don't think we should make a branch for the next non-bug-fix
> release.  We should think of what will be the next non-bug-fix release
> as the main focus of work, so it should be in the trunk.  It will need
> a considerable amount of work to become reliable, I expect.  Some
> smaller features can still be installed during that time.
> 
> Rather, people should start putting major changes into other branches.

If we have another branch (other than unicode) for major changes,
then we will not really focus on the trunk, methinks.

So I think we should do like we did for 21.1 and like most projects
do AFAIK, which is to say "freeze", spend some months debugging
and then (and only then) make a new branch (which is the release branch).

During the debugging phase people should just refrain from any "major work"
which would distract them from debugging.  When this "refraining" because
too difficult, it's a sign that there isn't enough debugging to do any more,
so it's a good time to branch.

As you said, it will probably take time to debug this beast, so we
should start the freeze as soon as possible.


	Stefan

Re: Major update just committed

[Jason Rumney]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> If we have another branch (other than unicode) for major changes,
> then we will not really focus on the trunk, methinks.

I am more worried that the opposite will happen. Casual users will
only ever look at the trunk, so if we branch for a 21.5 release, it
will not get much attention.

> So I think we should do like we did for 21.1 and like most projects
> do AFAIK, which is to say "freeze", spend some months debugging
> and then (and only then) make a new branch (which is the release branch).

> During the debugging phase people should just refrain from any "major work"
> which would distract them from debugging.  When this "refraining" because
> too difficult, it's a sign that there isn't enough debugging to do any more,
> so it's a good time to branch.

We have the unicode branch already. If people cannot resist making
major changes, they can use that.

Re: Major update just committed

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Sat, 31 May 2003 16:33:37 -0400
> 
> If we have another branch (other than unicode) for major changes,
> then we will not really focus on the trunk, methinks.

I agree that this danger would become very real.

> So I think we should do like we did for 21.1 and like most projects
> do AFAIK, which is to say "freeze", spend some months debugging
> and then (and only then) make a new branch (which is the release branch).

Agreed: feature-freeze of the next release should be something we do
soon.

Re: Major update just committed

[Richard Stallman]

    During the debugging phase people should just refrain from any "major work"
    which would distract them from debugging.  When this "refraining" because
    too difficult, it's a sign that there isn't enough debugging to do any more,
    so it's a good time to branch.

That seems like a good standard.  However, we could still install
new versions of self-contained packages such as Gnus.

Re: Major update just committed

[Juanma Barranquero]

On Sat, 31 May 2003 15:52:12 -0400, Richard Stallman <rms@gnu.org> wrote:

> We should think of what will be the next non-bug-fix release
> as the main focus of work, so it should be in the trunk.  It will need
> a considerable amount of work to become reliable, I expect.

That will mean that

 - either big new features are commited against the emacs-unicode branch

 - or (at least) one new branch is created for big new features

In the first case, the gap between the emacs-unicode branch and the
trunk will widen still more; the joining back it's going to be painful,
I think.

In the second one, two or more branches with posibly big changes will
have to be integrated back to the trunk in the future. Not pretty either.

Anyway, if that's what we're going to do, OK. But then, as Stefan and
Jason say, I think the trunk should be mostly frozen. Every "smaller
feature" commited against it puts the release farther and farther away.

My .02€, of course.

                                                           /L/e/k/t/u

Re: Major update just committed

[Jason Rumney]

Juanma Barranquero <lektu@terra.es> writes:

> In the first case, the gap between the emacs-unicode branch and the
> trunk will widen still more; the joining back it's going to be painful,
> I think.

Changes from HEAD should be merged into unicode at frequent intervals
(for some definition of frequent that does not usually produce a large
number of conflicts).

Re: Major update just committed

[Eli Zaretskii]

> Date: Thu, 29 May 2003 19:15:24 +0200
> From: Juanma Barranquero <lektu@terra.es>
> 
> What's wrong with:
> 
>  - branching now (or at least soonish) for a "new features" 21.5

Yes.

>  - releasing ASAP (for S ~ 0) the current RC branch as the last of the 21.[234]
> bugfix releases

YES!!

>  - joining the emacs_unicode branch into the trunk so developers can
> start to test it more thoroughly

I think this one should wait, as I understand the unicode branch is
not yet stable enough.  However, I don't myself use the unicode
branch, so perhaps my understanding is incorrect (in which case I
agree with you).

Re: Major update just committed

[Juanma Barranquero]

On Sun, 01 Jun 2003 18:49:31 +0300, "Eli Zaretskii" <eliz@elta.co.il> wrote:

> >  - joining the emacs_unicode branch into the trunk so developers can
> > start to test it more thoroughly
> 
> I think this one should wait, as I understand the unicode branch is
> not yet stable enough.

If we were to release 21.5 from a branch, as I suggested, merging
emacs-unicode with the trunk would make sense (the trunk would
accumulate all important changes and would be the basis for 22).

Richard wants to release a new-features Emacs from the trunk, so in this
case there's no point in merging emacs-unicode until after 21.5.

                                                           /L/e/k/t/u

Re: Major update just committed

[Juanma Barranquero]

On 28 May 2003 02:16:35 +0200, storm@cua.dk (Kim F. Storm) wrote:

> So it's about time to change the CVS version number to 22.0.50 (or
> better introduce the new version numbers we talked about some time
> ago).

Hear, hear!!

                                                           /L/e/k/t/u

Re: Major update just committed

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

> So it's about time to change the CVS version number to 22.0.50 (or
> better introduce the new version numbers we talked about some time
> ago).

Only on the unicode branch I should think.

Re: Major update just committed

[Kenichi Handa]

In article <5xllwsudr0.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
>>                                              If not, I'll
>> start the work of synchronizing emacs-unicode to HEAD
>> next week.

> Great news!

> So it's about time to change the CVS version number to
> 22.0.50 (or better introduce the new version numbers we
> talked about some time ago).

No.  For the moment, I'll just modify emacs-unicode branch
so that it become easier to actually integrate emacs-unicode
into HEAD in the near feature.

---
Ken'ichi HANDA
handa@m17n.org