Re: It is time for a feature freeze (it is NOW or never).

Re: It is time for a feature freeze (it is NOW or never).

[David PONCE]

Hi Stefan and Kim,

>>>>Let's make USE_LSB_TAG the default for now, and if the bug you
>>>>have not found does not get fixed, we can back it out later.
>>>
>>>I have now made it the default on systems where I know it should work.
>>
>>I have installed a fix to mark_kboards to avoid marking x and y members
>>of an input_event when it is overloaded by a selection_input_event.
> 
> 
> Eww.... I didn't know about this overloading.  Pretty ugly.
> Thanks for figuring it out.  I strongly suspect that it is the problem that
> David Ponce had and that I couldn't reproduce (his backtraces always passed
> through mark_kboards).

It looks you're right.  Without Kim's fix I experienced again the crash
with USE_LSB_TAG enabled, and the backtrace passed through
mark_kboards.

Since I applied Kim's fix, Emacs no more crashed :-)
Thank you very much Kim!

David

Compilation to native

[Matthew Mundell]

>From etc/TODO:

    * Investigate using GNU Lightning or similar system for incremental
      compilation of selected bytecode functions to subrs.  Converting CCL
      programs to native code is probably the first thing to try, though.

Is there any work towards this?

Re: Compilation to native

[Matthew Mundell]

Matthew Mundell <matt@mundell.ukfsn.org> writes:

> >From etc/TODO:
>
>     * Investigate using GNU Lightning or similar system for incremental
>       compilation of selected bytecode functions to subrs.  Converting CCL
>       programs to native code is probably the first thing to try, though.
>
> Is there any work towards this?

Well, I have a start at generating native code from byte code at run
time, and invoking the code produced.  It uses the GNU Lightning
macros.  The generation is done in a modified copy of Fbyte_code,
called Fnative_compile_byte_code, by generating the code for each byte
code operation instead of performing the operation.

Enough is implemented to run the example function from the "Speed of
Byte-Code" node in the Elisp manual.  The function is:

(defun silly-loop (n)
  "Return time before and after N iterations of a loop."
  (let ((t1 (current-time-string)))
    (while (> (setq n (1- n))
			  0))
	(list t1 (current-time-string))))

Here is a set of results:

(silly-loop 100000000)
=> ("Sat Feb 28 10:04:39 2004" "Sat Feb 28 10:05:30 2004")     ; 51 secs

(byte-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:06:37 2004" "Sat Feb 28 10:06:53 2004")     ; 16 secs

(native-compile 'silly-loop)
(silly-loop 100000000)
=> ("Sat Feb 28 10:17:13 2004" "Sat Feb 28 10:17:22 2004")     ; 9 secs


The changes come to more than 25000 characters, so they're here:
    http://www.mundell.ukfsn.org/native/bytecode.c.diff
    http://www.mundell.ukfsn.org/native/eval.c.diff
    http://www.mundell.ukfsn.org/native/lisp.h.diff
Alternatively, the full files are available:
    http://www.mundell.ukfsn.org/native/bytecode.c
    http://www.mundell.ukfsn.org/native/eval.c
    http://www.mundell.ukfsn.org/native/lisp.h
Either way, this file is also required:
    http://www.mundell.ukfsn.org/native/native.el

The changes require NO_UNION_TYPE to be set, USE_LSB_TAG to be clear,
and EMACS_INT to be an int.  For now a fixed amount of memory is
allocated for the generated code.


Is this effort good enough to continue?

Re: Compilation to native

[Richard Stallman]

    (byte-compile 'silly-loop)
    (silly-loop 100000000)
    => ("Sat Feb 28 10:06:37 2004" "Sat Feb 28 10:06:53 2004")     ; 16 secs

    (native-compile 'silly-loop)
    (silly-loop 100000000)
    => ("Sat Feb 28 10:17:13 2004" "Sat Feb 28 10:17:22 2004")     ; 9 secs

I don't think that a speedup of less than a factor of 2 would be worth
installing something that might take substantial maintenance effort.

However, it could be that this test is a bad test and doesn't really
show the benefit of compilation.  Maybe this loop spends most of the
time inside current-time-string.  How about trying something purely
computational?

    The changes require NO_UNION_TYPE to be set, USE_LSB_TAG to be clear,
    and EMACS_INT to be an int.

It will be necessary to remove these restrictions to make it ready to
install.  However, there's no harm working initially on this case
and handling other cases later.

Re: Compilation to native

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> I don't think that a speedup of less than a factor of 2 would be worth
> installing something that might take substantial maintenance effort.

Hmm, I expected more speedup given that it compiles to machine code.

Anyhow, while jit compilation of Emacs bytecode to native code would
be a far-reaching goal, the most urgent issue is with CCL programs.
Currently, CCL programs are unbearable slow.  For example, opening
a 10MB UTF-8 file on a fast machine takes 5 min, while opening it
without conversion is performed instantly.

I thought about a different approach: predefined CCL programs
could be statically converted into C code and compiled by a C
compiler into Emacs core.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Compilation to native

[Richard Stallman]

    I thought about a different approach: predefined CCL programs
    could be statically converted into C code and compiled by a C
    compiler into Emacs core.

It is worth a try.  On the other hand, I have to wonder
if the CCL interpreter could be faster.

Re: Compilation to native

[Kenichi Handa]

In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     I thought about a different approach: predefined CCL programs
>     could be statically converted into C code and compiled by a C
>     compiler into Emacs core.

> It is worth a try.  On the other hand, I have to wonder
> if the CCL interpreter could be faster.

I think there's not much room of improvement in the CCL
interpreter (i.e. the function ccl_driver).

In addtion, in emacs-unicode, CCL is, by default, used only
for Ethiopic font encoding, and it can easily be changed not
to use CCL.

So, I think it's not that worth working on CCL interpreter.

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

Re: Compilation to native

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> 
> >     I thought about a different approach: predefined CCL programs
> >     could be statically converted into C code and compiled by a C
> >     compiler into Emacs core.
> 
> > It is worth a try.  On the other hand, I have to wonder
> > if the CCL interpreter could be faster.
> 
> I think there's not much room of improvement in the CCL
> interpreter (i.e. the function ccl_driver).
> 
> In addtion, in emacs-unicode, CCL is, by default, used only
> for Ethiopic font encoding, and it can easily be changed not
> to use CCL.
> 
> So, I think it's not that worth working on CCL interpreter.

If we have a development plan to switch to emacs-unicode soon.  We
really need to get a grip about what should be in the next feature
release.

If the unicode and bidi branches are considerable usable, what are we
waiting for?

We are in the situation that currently for many purposes one has to
tell people "try using CVS".  People get more and more to rely on it
for daily work.  This situation is unhealthy.  If things like
emacs-unicode and emacs-bidi are expected to cause longer-lasting
trouble, then we should crank out something like a full-featured 21.5
or so just before merging them.  If the merge phase leads to longer
problems, we at least have a somewhat stable release to refer people
to while we are sorting the problems out.

If, on the other hand, users and developers of the unicode and bidi
branches are confident enough that under _normal_ use (i.e., if one
does not use bidi texts) stability should not be affected much, then
I'd say "what the heck, give it to us".  Maintaining separate branches
for longer always leads to merging headaches.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Compilation to native

[Kenichi Handa]

In article <x5lll8554h.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>  In article <E1B5q0C-00039m-FD@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>>  
>>  >     I thought about a different approach: predefined CCL programs
>>  >     could be statically converted into C code and compiled by a C
>>  >     compiler into Emacs core.
>>  
>>  > It is worth a try.  On the other hand, I have to wonder
>>  > if the CCL interpreter could be faster.
>>  
>>  I think there's not much room of improvement in the CCL
>>  interpreter (i.e. the function ccl_driver).
>>  
>>  In addtion, in emacs-unicode, CCL is, by default, used only
>>  for Ethiopic font encoding, and it can easily be changed not
>>  to use CCL.
>>  
>>  So, I think it's not that worth working on CCL interpreter.

> If we have a development plan to switch to emacs-unicode soon.  We
> really need to get a grip about what should be in the next feature
> release.

> If the unicode and bidi branches are considerable usable, what are we
> waiting for?

I think Unicode branch is fairly usable in normal use.  At
least it's stable enough for my daily work.  But if it is
used with third party packages, I think some of them must be
adjusted for emacs-unicode.

Bidi branch is far from usable.  I created that branch
mainly for that the other people can contribute.  It's very
difficult to find a time to work on it for me.

> We are in the situation that currently for many purposes one has to
> tell people "try using CVS".  People get more and more to rely on it
> for daily work.  This situation is unhealthy.  If things like
> emacs-unicode and emacs-bidi are expected to cause longer-lasting
> trouble, then we should crank out something like a full-featured 21.5
> or so just before merging them.  If the merge phase leads to longer
> problems, we at least have a somewhat stable release to refer people
> to while we are sorting the problems out.

> If, on the other hand, users and developers of the unicode and bidi
> branches are confident enough that under _normal_ use (i.e., if one
> does not use bidi texts) stability should not be affected much, then
> I'd say "what the heck, give it to us".  Maintaining separate branches
> for longer always leads to merging headaches.

I fully agree.

When I synchronized emacs-unicode branch to HEAD a half year
ago, it took about 10 days concentrated work.  I think it
will need the same amount of work to merge emacs-unicode to
HEAD.  If Richard says "go ahead", I'll manage to make that
time.

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

Re: Compilation to native

[Alex Schroeder]

Kenichi Handa <handa@m17n.org> writes:

> I think Unicode branch is fairly usable in normal use.  At
> least it's stable enough for my daily work.  But if it is
> used with third party packages, I think some of them must be
> adjusted for emacs-unicode.

I used HEAD for several months, and have since switched to the unicode
branch for several months.  I still experience a crash or two a month,
which is bad, but I cannot say I noticed any difference between the
two.

As for third party packages, I'm using the unicode branch with Gnus
and ERC (IRC client) for heavy duty work every day, so clearly I think
the Unicode branch is ready for merging, feature freeze, testing, and
release as soon as possible.

I must confess, however, that I have hoped all this time that the bidi
branch would be merged into the unicode branch, and that we'd release
the stuff as Emacs 22...  Even fickle Arabic and Hebrew support is
better than no support at all...  And for all it's worth, I've used
the bidi branch for IRC as well!  :)

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fourth law:
OOO  None of your friends and coworkers share your taste in music.

It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Alex Schroeder <alex@emacswiki.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> 
> > I think Unicode branch is fairly usable in normal use.  At
> > least it's stable enough for my daily work.  But if it is
> > used with third party packages, I think some of them must be
> > adjusted for emacs-unicode.
> 
> I used HEAD for several months, and have since switched to the unicode
> branch for several months.  I still experience a crash or two a month,
> which is bad, but I cannot say I noticed any difference between the
> two.
> 
> I must confess, however, that I have hoped all this time that the bidi
> branch would be merged into the unicode branch, and that we'd release
> the stuff as Emacs 22...  Even fickle Arabic and Hebrew support is
> better than no support at all...  And for all it's worth, I've used
> the bidi branch for IRC as well!  :)

I also think that unicode and bidi belongs in 22.1 => which is why
they should NOT be merged at this time.

I suggest that we make a complete feature freeze on HEAD for 21.4 NOW !!!

Thus, we allow just bug fixes, and minor adjustments to new features
(in case current interface/implementation is sub-optimal or unclean).

Eg. if there are still some issues with the new compile.el, do 
whatever is necessary to fix them.

New packages that we have already decided to add may also still go in.

And of course, we should get the remaining documentation tasks done
(getting new stuff in NEWS into the manuals).

Besides that, our efforts should concentrate on ironing out the (few?)
remaning unsolved reports about crashes in CVS head.

We should aim at doing the first pre-test in approx. 1 month (no later
than June 1st).

WHY?

Current HEAD is rock-solid for normal use, and I don't think it will
can be much better in that respect (but we should try!).  I suppose we
have all used it in our daily work for [too] many months already, and
so have numerous anonymous users who need - or just like - the new
features of 21.4.

Also, people (notably Luc) have spent quite some time proof-reading
the current documentation on HEAD, so docs are also in a pretty
consistent state.


Consequently, we should be able to have an expedited pre-test phase,
as many parts of the code has already received extensive testing by a
much broader audience than any previous pre-test versions of emacs.


If we don't do it now, and start merging unicode and bidi to HEAD, I
fear that a 22.1 release is at least 1 year further into the future --
and that CVS HEAD will go through a phase of lesser stable code than
we have been used to for quite some time (I'm not judging the quality
of the code on those branches, it's just that it hasn't been tested to
the same extent as HEAD, so we should expect problems).


It's time!!!

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

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <m3lll7b3j0.fsf_-_@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> I suggest that we make a complete feature freeze on HEAD for 21.4 NOW !!!

I have thought that we are going to take the following
schedule.

(1) Release the current RC branch as 21.4.
(2) Feature freeze on HEAD.
(3) Merge HEAD into RC branch, and make it 21.4.50.
(4) Merge Unicode branch into HEAD, and make it 22.0.0.
(5) Start pretest of 21.5 based on RC.
(6) Release RC branch as 21.5.
...
(7) Feature freeze on HEAD (i.e. Unicode version)
(8) Merge HEAD into RC branch, and make it 22.0.50.

Do you intend to skip (1)?  Perhaps, that will be better
because we can avoid disappointing users who exepect new
features in the release of this long delay.

> If we don't do it now, and start merging unicode and bidi to HEAD, I
> fear that a 22.1 release is at least 1 year further into the future --
> and that CVS HEAD will go through a phase of lesser stable code than
> we have been used to for quite some time (I'm not judging the quality
> of the code on those branches, it's just that it hasn't been tested to
> the same extent as HEAD, so we should expect problems).

I agree.  But, I think bug-fixing work for 21.5 (or 21.4)
must be done on RC branch so that (4) can be done promptly
and we can have more users of Unicode version, which boosts
the release of 22.1.

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

Re: It is time for a feature freeze (it is NOW or never).

[John Wiegley]

Kenichi Handa <handa@m17n.org> writes:

> I have thought that we are going to take the following schedule.
>
> (1) Release the current RC branch as 21.4.

I would note too that I'm currently trying to identify a frequent
crash that occurs on Mac OS/X (1-4 times daily).  This is a new
breakage, as earlier versions of Emacs were quite stable.

I'm still watching for another crash, to find if it's all the same
source.  The last one was at:

  SetupOffscreenGDevice()
  PortToNQDPixMap()
  PortToNQDPixMap()
  StdText()
  XDrawString (display=0xbfffd6a4, w=0xffffffff, gc=0xbfffd69c, x=1, y=-1441792, buf=0xffea0000 <Address 0xffea0000 out of bounds>, nchars=25559642) at macterm.c:779
  779       mac_draw_string_common (display, w, gc, x, y, buf, nchars, srcOr, 1);

It seems to happen more frequently if I have more than one frame open.

John

Re: It is time for a feature freeze (it is NOW or never).

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 Apr 2004 20:13:04 -0700, John Wiegley <johnw@gnu.org> said:

> I would note too that I'm currently trying to identify a frequent
> crash that occurs on Mac OS/X (1-4 times daily).  This is a new
> breakage, as earlier versions of Emacs were quite stable.

I guess some of them are related to repeated C-g.  Is that right?  I
think mac_check_for_quit_char (in macterm.c) needs some changes so
that it reflects the recent changes on kbd_buffer_store_event_hold (in
keyboard.c).

> I'm still watching for another crash, to find if it's all the same
> source.  The last one was at:

>  XDrawString (display=0xbfffd6a4, w=0xffffffff, gc=0xbfffd69c, x=1, y=-1441792, buf=0xffea0000 <Address 0xffea0000 out of bounds>, nchars=25559642) at macterm.c:779
>  779       mac_draw_string_common (display, w, gc, x, y, buf, nchars, srcOr, 1);

Seems like you compiled with `-O2 -g'.  In my experience, gdb in Mac
OS X sometimes shows wrong values about function arguments if emacs is
compiled with optimization options.  Maybe you can obtain more correct
information if compiled without `-O2'.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: It is time for a feature freeze (it is NOW or never).

[John Wiegley]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I guess some of them are related to repeated C-g.  Is that right?  I
> think mac_check_for_quit_char (in macterm.c) needs some changes so
> that it reflects the recent changes on kbd_buffer_store_event_hold (in
> keyboard.c).

No C-g pressing, I don't recall...  I think it happened after waking
up the screen.  Hasn't recurred today, although somebody on #emacs
triggered the same bug.  He thought it might be a font issue.

John

Re: It is time for a feature freeze (it is NOW or never).

[Piet van Oostrum]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

>>>>> On Wed, 07 Apr 2004 20:13:04 -0700, John Wiegley <johnw@gnu.org> said:
>> I would note too that I'm currently trying to identify a frequent
>> crash that occurs on Mac OS/X (1-4 times daily).  This is a new
>> breakage, as earlier versions of Emacs were quite stable.

YM> I guess some of them are related to repeated C-g.  Is that right?  I
YM> think mac_check_for_quit_char (in macterm.c) needs some changes so
YM> that it reflects the recent changes on kbd_buffer_store_event_hold (in
YM> keyboard.c).

The crashes on my machine are (almost) invariably tied to the following
sequence:

I am reading news/mail with gnus.
I switch a couple of times between emacs and other applications
I go back to gnus and continue reading or request new news with the 'g'
command in *Groups*.
Emacs hangs
I try to get it out of the hang by hitting C-g once or several times.
Crash.

These crashes happen sometimes several times a day.

It was my impression that it could be related to something like screen
redrawing or redrawing the menu, that corrupts some memory or doesn't
cooperate properly with GC.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: It is time for a feature freeze (it is NOW or never).

[Jason Rumney]

Kenichi Handa wrote:

> I have thought that we are going to take the following
> schedule.
> 
> (1) Release the current RC branch as 21.4.

That was discussed some weeks ago, but no pretest has begun yet, so 
maybe it is better to skip this if it is going to take a long time anyway.

> (2) Feature freeze on HEAD.
> (3) Merge HEAD into RC branch, and make it 21.4.50.

I think making a new branch would be easier than merging. I doubt there 
are important bugfixes in the RC branch that are not already in HEAD.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> 
> > I have thought that we are going to take the following
> > schedule.
> > (1) Release the current RC branch as 21.4.
> 
> That was discussed some weeks ago, but no pretest has begun yet, so
> maybe it is better to skip this if it is going to take a long time
> anyway.

I would say that depends on how long we expect the 21.5 pretest to take.
If THAT takes a long time, let's go for a 21.4 pretest now, and release
quickly if the pretest doesn't reveal anything major (compared to 21.3).

> 
> > (2) Feature freeze on HEAD.
> > (3) Merge HEAD into RC branch, and make it 21.4.50.
> 
> I think making a new branch would be easier than merging. I doubt
> there are important bugfixes in the RC branch that are not already in
> HEAD.

I agree that we should leave the old RC branch as is (ending with 21.4)
and create a new RC branch for 21.5 _asap_!!.

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

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> In article <m3lll7b3j0.fsf_-_@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> > I suggest that we make a complete feature freeze on HEAD for 21.4 NOW !!!
> 
> I have thought that we are going to take the following
> schedule.
> 
> (1) Release the current RC branch as 21.4.

I have no opinion on this.

> (2) Feature freeze on HEAD.

Yes.

> (3) Merge HEAD into RC branch, and make it 21.4.50.

There is no need to merge to the existing RC branch.

We just create a new RC branch from HEAD for 21.5 named EMACS_21_5_RC.

> (4) Merge Unicode branch into HEAD, and make it 22.0.0.

Yes.

I suggest we also merge the multi-tty branch to HEAD quickly.


> (5) Start pretest of 21.5 based on RC.

(With RC = 21_5_RC):

Fix all 21.4 => 21.5 references on RC.
Then start pretest from RC.

> (6) Release RC branch as 21.5.

Yes.

> ...
> (7) Feature freeze on HEAD (i.e. Unicode version)

I suppose that bidi support is not mature enough for 22.1 --

actually IMO, bidi support would warrent another major number,
i.e. 23.1.

> (8) Merge HEAD into RC branch, and make it 22.0.50.

No, again just make a 22_1_RC branch from HEAD.

> 
> Do you intend to skip (1)?  Perhaps, that will be better
> because we can avoid disappointing users who exepect new
> features in the release of this long delay.

Since there is some confusion as to what 21.4 is or would be, I
suggest we aim for using 21.5 as the version for the release from
the new RC branch.   If things take too long, we still have the option
to release 21.4 from the old RC branch.


> 
> > If we don't do it now, and start merging unicode and bidi to HEAD, I
> > fear that a 22.1 release is at least 1 year further into the future --
> > and that CVS HEAD will go through a phase of lesser stable code than
> > we have been used to for quite some time (I'm not judging the quality
> > of the code on those branches, it's just that it hasn't been tested to
> > the same extent as HEAD, so we should expect problems).
> 
> I agree.  But, I think bug-fixing work for 21.5 (or 21.4)
> must be done on RC branch so that (4) can be done promptly
> and we can have more users of Unicode version, which boosts
> the release of 22.1.

Yes, lets branch now for 21.5 and fix bugs on the RC branch.

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

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

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

> Kenichi Handa <handa@m17n.org> writes:
> 
> > In article <m3lll7b3j0.fsf_-_@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> > > I suggest that we make a complete feature freeze on HEAD for 21.4 NOW !!!
> > 
> > I have thought that we are going to take the following
> > schedule.
> > 
> > (1) Release the current RC branch as 21.4.
> 
> I have no opinion on this.

I also don't know how important that is.  I don't know the fixes as
opposed to 21.3.

But it _is_ important that we get the four years of development since
21.0 feature freeze out of the door sometimes.  People increasingly
switch to Emacs CVS since that is the only sane option to do, and that
means that they have to use something with a stability completely
based on timing and good luck.  If we don't release from HEAD before
potentially large merges, they will be screwed without an alternative.

> > (2) Feature freeze on HEAD.
> 
> Yes.
> 
> > (3) Merge HEAD into RC branch, and make it 21.4.50.
> 
> There is no need to merge to the existing RC branch.

Right.

> We just create a new RC branch from HEAD for 21.5 named
> EMACS_21_5_RC.
> 
> > (4) Merge Unicode branch into HEAD, and make it 22.0.0.
> 
> Yes.

Whatever.

> I suggest we also merge the multi-tty branch to HEAD quickly.

After 21_5_RC has been split off.  If it turns out that post-release
changes leave HEAD stable enough, we can still surprise the world by
following up with 22.0 on short notice.  But at the current point of
time, the tester base for the branches is not so large that we should
take the risk.

> > (7) Feature freeze on HEAD (i.e. Unicode version)
> 
> I suppose that bidi support is not mature enough for 22.1 --
> 
> actually IMO, bidi support would warrent another major number,
> i.e. 23.1.

Actually, I'd want to see both.  Anyhow, after the unicode merge, the
bidi branch will need to synch up, and one can then see how it fares.

Unicode makes somewhat more sense with bidi (and I want to be able to
offer Emacs at one time for creation of philological texts, and
vocalized Hebrew is not exactly irrelevant in that respect).  But if
it is apparent that 22.0 would be help up by it considerably, I'd say
to go without it.

> Since there is some confusion as to what 21.4 is or would be, I
> suggest we aim for using 21.5 as the version for the release from
> the new RC branch.  If things take too long, we still have the
> option to release 21.4 from the old RC branch.

Sounds reasonable.  Also, if we happen to skip a number, people will
notice that there is some larger change.

> > I agree.  But, I think bug-fixing work for 21.5 (or 21.4)
> > must be done on RC branch so that (4) can be done promptly
> > and we can have more users of Unicode version, which boosts
> > the release of 22.1.
> 
> Yes, lets branch now for 21.5 and fix bugs on the RC branch.

Sounds reasonable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> (1) Release the current RC branch as 21.4.

I don't consider it very useful, but if people want to spend their time on
it I can't stop them.

> (2) Feature freeze on HEAD.
> (3) Merge HEAD into RC branch, and make it 21.4.50.
> (4) Merge Unicode branch into HEAD, and make it 22.0.0.
> (5) Start pretest of 21.5 based on RC.
> (6) Release RC branch as 21.5.
> ...
> (7) Feature freeze on HEAD (i.e. Unicode version)
> (8) Merge HEAD into RC branch, and make it 22.0.50.

I'd offer a very slightly different schedule:
(2) Feature freeze on the trunk NOW
(3) Start pretest from the trunk (maybe after fixing known bugs, but there
    doesn't seem to be many of those, so it seems unnecessary).
(4) When bug-fixing starts to slow down such that some developers feel bored,
    make a new RC branch and move the bug-fixing and pretesting there.
    Those people who are bored can start playing on the trunk again.
(5a) Finish bug-fixing RC and finally Release.
(5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the
    trunk.  Branches basically don't get any testing and waste too much of
    our energy with merging, so we should only keep them for code that's
    really unstable or that we don't know whether we'll ever include.
    E.g. if bidi only crashed when you set enable-bidi-display, then it's
    ready for inclusion.
    I'd also like to see the emacs-xft (anti-aliasing) merged in, but AFAIK
    it's not ready yet.
(6) Almost immediately after that: goto number (2).

Note that the plan above tries to reduce the amount of "parallel
development" for two reasons:
- we need to make sure people focus on fixing bugs during the pretest.
- we don't have the manpower to work and test many branches at the same time,
  let alone keep them uptodate w.r.t the trunk.

> Do you intend to skip (1)?  Perhaps, that will be better
> because we can avoid disappointing users who exepect new
> features in the release of this long delay.

Agreed.

> I agree.  But, I think bug-fixing work for 21.5 (or 21.4)
> must be done on RC branch so that (4) can be done promptly
> and we can have more users of Unicode version, which boosts
> the release of 22.1.

You have a point but I think we should only do it when the bug-fixing
frenzy slows down (hopefully this will happen very quickly).
But of course, as soon as the bugs left over are "none of your business",
you'd better start merging rather than twiddle your thumbs.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> (5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the
>     trunk.

I'd like to (post-release) merge my tiling branch too; I don't seen any
particularly good reason to keep it separate.  I think the only probable
conflict is with multi-tty (at the least because of RIF changes).

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > (5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the
> >     trunk.
> 
> I'd like to (post-release) merge my tiling branch too; I don't seen any
> particularly good reason to keep it separate.  I think the only probable
> conflict is with multi-tty (at the least because of RIF changes).

That is ok with me -- IMO, it would be nice to get all feature
branches merged to the trunk soon after branching for 21.5 so we can
get everything (and everybody) synchronized.

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

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Sat, Apr 10, 2004 at 01:43:32AM +0200, Kim F. Storm wrote:
> IMO, it would be nice to get all feature branches merged to the trunk soon
> after branching for 21.5 so we can get everything (and everybody)
> synchronized.

There's also the `lexbind' branch

It seems to work OK in normal use (i.e. it doesn't seem to adversely affect
the normal case of dynamic binding), but until recently I haven't used it for
everyday use; I'm now running the "miles" branch which is the sum of the
tiling and lexbind branches, so hopefully if there are any problems I'll see
them.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

I wrote:
> I'd like to (post-release) merge my tiling branch too; I don't seen any
> particularly good reason to keep it separate.  I think the only probable
> conflict is with multi-tty (at the least because of RIF changes).

I did a test merge of multi-tty with tiling, and there are actually very few
patch conflicts, though the RIF changes probably do mean there are few
semantic errors in the result.

I'd love see the multi-tty changes go in -- not just because it's a great
feature (and it is), but because I like the code cleanup.  Compared to the
current "everything global all the time" code, it should make things a bit
easier to understand, which is no small thing given the confusingness of the
redisplay code.

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> I wrote:
> > I'd like to (post-release) merge my tiling branch too; I don't seen any
> > particularly good reason to keep it separate.  I think the only probable
> > conflict is with multi-tty (at the least because of RIF changes).
> 
> I did a test merge of multi-tty with tiling, and there are actually very few
> patch conflicts, though the RIF changes probably do mean there are few
> semantic errors in the result.
> 
> I'd love see the multi-tty changes go in -- not just because it's a great
> feature (and it is), but because I like the code cleanup.  Compared to the
> current "everything global all the time" code, it should make things a bit
> easier to understand, which is no small thing given the confusingness of the
> redisplay code.

Yes, I also look forward to the RIF cleanup from the multi-tty patch.
I had plans to do this cleanup myself sometime, but Romain beat me to it.

It should definitely go in soon after 21.5 is branched from trunk.

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

Re: It is time for a feature freeze (it is NOW or never).

[Romain Francoise]

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

> Yes, I also look forward to the RIF cleanup from the multi-tty patch.
> I had plans to do this cleanup myself sometime, but Romain beat me to it.

Just to give credit where it's due, the person behind the multi-tty
branch is Károly Lorentey, not myself.  I'm just a convinced and
sometimes vocal user.

-- 
Romain Francoise <romain@orebokech.com> | It was fourteen degrees below
it's a miracle -- http://orebokech.com/ | on a screeching march 23.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Romain Francoise <romain@orebokech.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Yes, I also look forward to the RIF cleanup from the multi-tty patch.
> > I had plans to do this cleanup myself sometime, but Romain beat me to it.
> 
> Just to give credit where it's due, the person behind the multi-tty
> branch is Károly Lorentey, not myself.  I'm just a convinced and
> sometimes vocal user.

Sorry for the mixup.  So it was Károly who beat me to it :-)

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

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <m365c7vg5v.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

>>  I did a test merge of multi-tty with tiling, and there are actually very few
>>  patch conflicts, though the RIF changes probably do mean there are few
>>  semantic errors in the result.
>>  
>>  I'd love see the multi-tty changes go in -- not just because it's a great
>>  feature (and it is), but because I like the code cleanup.  Compared to the
>>  current "everything global all the time" code, it should make things a bit
>>  easier to understand, which is no small thing given the confusingness of the
>>  redisplay code.

> Yes, I also look forward to the RIF cleanup from the multi-tty patch.
> I had plans to do this cleanup myself sometime, but Romain beat me to it.

> It should definitely go in soon after 21.5 is branched from trunk.

I don't object to it, but if it changes some internal
interfaces, I'd like to ask to merge it after emacs-unicode
merge is done.  At least emacs-unicode doesn't change RIF.

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

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <m365c7vg5v.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> 
> >>  I did a test merge of multi-tty with tiling, and there are
> >>  actually very few patch conflicts, though the RIF changes
> >>  probably do mean there are few semantic errors in the result.
> >>  
> >>  I'd love see the multi-tty changes go in -- not just because
> >>  it's a great feature (and it is), but because I like the code
> >>  cleanup.  Compared to the current "everything global all the
> >>  time" code, it should make things a bit easier to understand,
> >>  which is no small thing given the confusingness of the redisplay
> >>  code.
> 
> > Yes, I also look forward to the RIF cleanup from the multi-tty
> > patch.  I had plans to do this cleanup myself sometime, but Romain
> > beat me to it.
> 
> > It should definitely go in soon after 21.5 is branched from trunk.
> 
> I don't object to it, but if it changes some internal interfaces,
> I'd like to ask to merge it after emacs-unicode merge is done.  At
> least emacs-unicode doesn't change RIF.

In my opinion, we should first merge the unicode branch into the
trunk.  Once unicode is merged, multi-tty can merge the current
trunk.  Once this is done, one can judge the respective stabilities.

If it turns out that the unicode branch merge left us with a rather
stable system on the trunk, we should aim for releasing 22.1 as fast
as possible.  This means that multi-tty should only be merged if its
HEAD (after merge in of the trunk's HEAD) seems similarly stable.

Since we can't just right now judge how the stability is affected
with the combined branches, I would postpone the decision of when to
merge multi-tty until we have the actual merge candidates.

When in doubt, there is no harm in releasing 22.0, noticing
afterwards that the multi-head branch leaves us with a quite stable
Emacs, too, and release 22.1 soon after that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Lőrentey Károly]

Kenichi Handa <handa@m17n.org> writes:
> In article <m365c7vg5v.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
>>>  I did a test merge of multi-tty with tiling, and there are actually very few
>>>  patch conflicts, though the RIF changes probably do mean there are few
>>>  semantic errors in the result.
>>>  
>>>  I'd love see the multi-tty changes go in -- not just because it's a great
>>>  feature (and it is), but because I like the code cleanup.  Compared to the
>>>  current "everything global all the time" code, it should make things a bit
>>>  easier to understand, which is no small thing given the confusingness of the
>>>  redisplay code.
>
>> Yes, I also look forward to the RIF cleanup from the multi-tty patch.
>> I had plans to do this cleanup myself sometime, but Romain beat me to it.
>
>> It should definitely go in soon after 21.5 is branched from trunk.
>
> I don't object to it, but if it changes some internal
> interfaces, I'd like to ask to merge it after emacs-unicode
> merge is done.  At least emacs-unicode doesn't change RIF.

That's OK with me; my branch follows HEAD, and I will happily merge in
the unicode changes as soon as they appear there.  (I looked at the
unicode branch a few months ago and it seemed the merge could be done
without too much work.)

-- 
Károly

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    I'd like to (post-release) merge my tiling branch too; I don't seen any
    particularly good reason to keep it separate.

I seem to recall that code had serious flaws and that it was not clear
whether they could be fixed at all.  I don't remember the details
after all this time, but we cannot schedule installation ofn this code.

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Sat, Apr 10, 2004 at 10:34:55PM -0400, Richard Stallman wrote:
>     I'd like to (post-release) merge my tiling branch too; I don't seen any
>     particularly good reason to keep it separate.
> 
> I seem to recall that code had serious flaws and that it was not clear
> whether they could be fixed at all.

If so, nobody told _me_ about them...

-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: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Sun, Apr 11, 2004 at 05:06:05AM -0400, Miles Bader wrote:
> On Sat, Apr 10, 2004 at 10:34:55PM -0400, Richard Stallman wrote:
> >     I'd like to (post-release) merge my tiling branch too; I don't seen any
> >     particularly good reason to keep it separate.
> > 
> > I seem to recall that code had serious flaws and that it was not clear
> > whether they could be fixed at all.
> 
> If so, nobody told _me_ about them...

To restate that in a less glib manner, to the best of my knowledge, my tiling
changes have never been reviewed by anybody, and such discussion as has
occurred has mostly been off on various tangents, not about the core
functionality.

For instance Dave Love commented that would nice if a background image could
be synchronized with the text (so it acted like "paper"), as that's what web
browsers do, and the ensuing discussion was mostly about why it was hard to
do that in emacs -- but I don't think that detracts from the basic
functionality, it's just an interesting possible feature.

Are you sure you're not thinking of some other patch?

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Sun, Apr 11, 2004 at 05:06:05AM -0400, Miles Bader wrote:
> > On Sat, Apr 10, 2004 at 10:34:55PM -0400, Richard Stallman wrote:
> > >     I'd like to (post-release) merge my tiling branch too; I don't seen any
> > >     particularly good reason to keep it separate.
> > > 
> > > I seem to recall that code had serious flaws and that it was not clear
> > > whether they could be fixed at all.
> > 
> > If so, nobody told _me_ about them...

IIRC, it was yourself who said that my various consolidation changes
broke your tiling patches.  I'm pleased to hear that it wasn't the
case after all (or that you managed to recover from my "de-messing"
efforts :-)

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

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Mon, Apr 12, 2004 at 11:10:48PM +0200, Kim F. Storm wrote:
> IIRC, it was yourself who said that my various consolidation changes
> broke your tiling patches.  I'm pleased to hear that it wasn't the
> case after all (or that you managed to recover from my "de-messing"
> efforts :-)

No, in fact though I've been a bit scared everytime you re-arrange redisplay,
merging's never been a real problem even then.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    > > I seem to recall that code had serious flaws and that it was not clear
    > > whether they could be fixed at all.
    > 
    > If so, nobody told _me_ about them...

    To restate that in a less glib manner, to the best of my knowledge, my tiling
    changes have never been reviewed by anybody, and such discussion as has
    occurred has mostly been off on various tangents, not about the core
    functionality.

I think we had a discussion about this right when you wrote it.
They were conceptual-level issues, not little bugs.

But my memory is vague.  I don't remember what the tiling patch does,
I only have an associated memory that there was some problem which
wasn't obvious how to fix.  It is possible I'm confusing this with
some other patch.

Can you tell me the range of dates where I could find the first discussion
of the tiling patch?

Re: It is time for a feature freeze (it is NOW or never).

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I'd offer a very slightly different schedule:

I think this is the best plan for Emacs users and for Emacs developers.
I have only a few comments.

> (2) Feature freeze on the trunk NOW

Please announce a day for feature freeze ~1-2 weeks from now,
to give a chance to submit latest features.

> (3) Start pretest from the trunk (maybe after fixing known bugs, but there
>     doesn't seem to be many of those, so it seems unnecessary).

This shouldn't take too long given the fact that CVS Emacs is already
under constant testing.

> (4) When bug-fixing starts to slow down such that some developers feel bored,
>     make a new RC branch and move the bug-fixing and pretesting there.
>     Those people who are bored can start playing on the trunk again.
> (5a) Finish bug-fixing RC and finally Release.
> (5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the
>     trunk.  Branches basically don't get any testing and waste too much of
>     our energy with merging, so we should only keep them for code that's
>     really unstable or that we don't know whether we'll ever include.
>     E.g. if bidi only crashed when you set enable-bidi-display, then it's
>     ready for inclusion.
>     I'd also like to see the emacs-xft (anti-aliasing) merged in, but AFAIK
>     it's not ready yet.
> (6) Almost immediately after that: goto number (2).

After merging unicode, multi-tty, and bidi, when most developers will
start to use them, new bugs will be discovered and new related features
will be proposed, so most probably the next release will be postponed
for more than a half-year.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Thu, Apr 08, 2004 at 04:35:15AM +0200, Kim F. Storm wrote:
> Current HEAD is rock-solid for normal use, and I don't think it will
> can be much better in that respect (but we should try!).

This may be a false warning for HEAD (I run my own branch which has a fair
number of redisplay changes), but just in case:

I've had several crashes recently related to i-search faces, and haven't been
able to track down the cause; it appears that the face cache ids are being
used even after the face cache has been cleared.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <20040408020537.GA22508@fencepost>, Miles Bader <miles@gnu.org> writes:

> On Thu, Apr 08, 2004 at 04:35:15AM +0200, Kim F. Storm wrote:
>>  Current HEAD is rock-solid for normal use, and I don't think it will
>>  can be much better in that respect (but we should try!).

> This may be a false warning for HEAD (I run my own branch which has a fair
> number of redisplay changes), but just in case:

> I've had several crashes recently related to i-search faces, and haven't been
> able to track down the cause; it appears that the face cache ids are being
> used even after the face cache has been cleared.

In emacs-unicode, I also met the similar bug.  Emacs crashed
at the end of get_glyph_face_and_encoding.  In this
function, FACE_FROM_ID (f, glyph->face_id) returned NULL,
thus, the macro call PREPARE_FACE_FOR_DISPLAY at the end led
to the crash.  Though, this happens very very rarely.

As emacs-unicode-2 was branched after a big change in
display code, it's possible that we are seeing the same bug.

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

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> In emacs-unicode, I also met the similar bug.  Emacs crashed at the
> end of get_glyph_face_and_encoding.  In this function, FACE_FROM_ID
> (f, glyph->face_id) returned NULL, thus, the macro call
> PREPARE_FACE_FOR_DISPLAY at the end led to the crash.  Though, this
> happens very very rarely.

Yes that sounds like the same symptoms I saw.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: It is time for a feature freeze (it is NOW or never).

[Romain Francoise]

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

> I suggest that we make a complete feature freeze on HEAD for 21.4 NOW
> !!!

Please consider merging the multi-tty branch.  It brings a set of _very_
useful features, and postponing the merge until Emacs 22 sounds like a
real waste.  I have been using this branch for some months as my main
Emacs environment for heavy usage and it's very solid.  The only
show-stopper is that Mac, Windows and DOS support is missing, but maybe
this could be left aside temporarily...

<URL: http://lorentey.web.elte.hu/project/emacs.html.en>

-- 
Romain Francoise <romain@orebokech.com> | They're nothing but scared
it's a miracle -- http://orebokech.com/ | little mice.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Romain Francoise <romain@orebokech.com> writes:

> Please consider merging the multi-tty branch.  It brings a set of _very_
> useful features, and postponing the merge until Emacs 22 sounds like a
> real waste.  

IMHO, postponing currently available features that have already
been in HEAD for years any further would be an even bigger waste.

>              I have been using this branch for some months as my main
> Emacs environment for heavy usage and it's very solid.  

One or a few user's impression here doesn't convince me that it can be
merged without hazzle.

I have looked briefly at the multi-tty pathces, and although it looks
very sensible and systematic in its approach, it touches on many files
and interfaces!  

Since it probably hasn't received much attention (yet) from the core
developers, I would think that there are still some issues which need
to be ironed out.  For example , what is the value of window-system
variable if you have both a window frame and a non-window frame open
at the same time (I haven't looked, so I don't know how this issue has
been resolved, but there could be other issues like it).

Also, is the documentation on the multi-tty branch updated to reflect
changes in interfaces etc. (where it matters).

I would fear that even minor issues with it would inhibit a 21.5
release in 2004, and no matter how useful it is, I think it will have
to wait.  

Others may (and will) disagree of course...

>                                                         The only
> show-stopper is that Mac, Windows and DOS support is missing, but maybe
> this could be left aside temporarily...
> 

We are talking about a major new release here, so I don't like to have
"temporary show-stoppers" that will generate noise in the pretest.

There are enough new features for people to test already...

But I also think that as soon as we have branched from HEAD for 21.5,
it would be a good time to merge the multi-tty stuff to HEAD (with the
unicode branch).

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

Re: It is time for a feature freeze (it is NOW or never).

[Romain Francoise]

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

> IMHO, postponing currently available features that have already
> been in HEAD for years any further would be an even bigger waste.

True.

> I have looked briefly at the multi-tty pathces, and although it looks
> very sensible and systematic in its approach, it touches on many files
> and interfaces!  

Yes; it is quite intrusive.

> For example , what is the value of window-system variable if you have
> both a window frame and a non-window frame open at the same time (I
> haven't looked, so I don't know how this issue has been resolved, but
> there could be other issues like it).

It's what it's supposed to be: if you eval it in an X frame, you get 'x,
in a console frame you get nil.

> Also, is the documentation on the multi-tty branch updated to reflect
> changes in interfaces etc. (where it matters).

I don't know about that, but it doesn't look like it.

> I would fear that even minor issues with it would inhibit a 21.5
> release in 2004, and no matter how useful it is, I think it will have
> to wait.  

You're right, apparently a large amount of work is needed before this
branch can go in HEAD, your plan for an immediate release is the most
reasonable course of action.  I will have to wait some more before
seeing these features in mainline Emacs...

Cheers,

-- 
Romain Francoise <romain@orebokech.com> | It was fourteen degrees below
it's a miracle -- http://orebokech.com/ | on a screeching march 23.

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

I agree that we should not include the multi-tty code in the next HEAD
release.  However, it sounds like maybe the unicode branch is ready to
install now.  If so, maybe we should install that as soon as
practical, then start pretesting from HEAD, and skip making another
release from RC.

However, we need to remove the files that relate specifically to
encryption.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I agree that we should not include the multi-tty code in the next HEAD
> release.  However, it sounds like maybe the unicode branch is ready to
> install now.  

I still think this is a bad idea -- it cannot be done without potentially
destabilizing the trunk which is currently in a very stable state, and
thus in a pretty unique state of "readiness for release".

>               If so, maybe we should install that as soon as
> practical, then start pretesting from HEAD, and skip making another
> release from RC.
> 
> However, we need to remove the files that relate specifically to
> encryption.

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

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <m3smfcbol5.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>>  I agree that we should not include the multi-tty code in the next HEAD
>>  release.  However, it sounds like maybe the unicode branch is ready to
>>  install now.  

> I still think this is a bad idea -- it cannot be done without potentially
> destabilizing the trunk which is currently in a very stable state, and
> thus in a pretty unique state of "readiness for release".

I agree with Kim.  Unicode branch is stable for me, but I
think we'll meet various problems when used more widely.  In
addition, we must work on mule-related manuals.  I dared not
work on manuals in Unicode branch to avoid conflict with
frequent changes in HEAD.

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

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

      In
    addition, we must work on mule-related manuals.  I dared not
    work on manuals in Unicode branch to avoid conflict with
    frequent changes in HEAD.

In that case, I guess we should aim for a release without the unicode
branch.  And certainly without the multi-tty branch.  (As for the
tiling and lexical branches, I am not convinced I want to make those
changes.)

However, this reminds me that we need to update the Emacs Manual.  I
updated the Emacs Lisp manual myself some 6 months ago, but aside from
Luc Teirlink who has done a lot of work, most of you have not helped
me check it.  Now it is out of print.  But I don't know if I can
update the Emacs Manual.  I can barely keep up with my work, and I am
injured.

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       In
>     addition, we must work on mule-related manuals.  I dared not
>     work on manuals in Unicode branch to avoid conflict with
>     frequent changes in HEAD.
> 
> In that case, I guess we should aim for a release without the unicode
> branch.  And certainly without the multi-tty branch.  (As for the
> tiling and lexical branches, I am not convinced I want to make those
> changes.)

So when do we declare "feature freeze" ?  May 1st ?


> 
> However, this reminds me that we need to update the Emacs Manual.  I
> updated the Emacs Lisp manual myself some 6 months ago, but aside from
> Luc Teirlink who has done a lot of work, most of you have not helped
> me check it.  Now it is out of print.  But I don't know if I can
> update the Emacs Manual.  I can barely keep up with my work, and I am
> injured.

Once we have "feature freeze", it will be a good time for everyone to
update the manuals to reflect their additions (hopefully documented in
etc/NEWS).

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>> In that case, I guess we should aim for a release without the unicode
>> branch.  And certainly without the multi-tty branch.  (As for the
>> tiling and lexical branches, I am not convinced I want to make those
>> changes.)

> So when do we declare "feature freeze" ?  May 1st ?

May 1st sounds very good to me,


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

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

> >> In that case, I guess we should aim for a release without the unicode
> >> branch.  And certainly without the multi-tty branch.  (As for the
> >> tiling and lexical branches, I am not convinced I want to make those
> >> changes.)
> 
> > So when do we declare "feature freeze" ?  May 1st ?
> 
> May 1st sounds very good to me,

Too good to be true ?

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

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Sat, May 01, 2004 at 10:16:25PM +0200, Kim F. Storm wrote:
> > > So when do we declare "feature freeze" ?  May 1st ?
> > 
> > May 1st sounds very good to me,
> 
> Too good to be true ?

Um, as you seem to be adding many of the new features these days, why don't
you tell us?

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Sat, May 01, 2004 at 10:16:25PM +0200, Kim F. Storm wrote:
> > > > So when do we declare "feature freeze" ?  May 1st ?
> > > 
> > > May 1st sounds very good to me,
> > 
> > Too good to be true ?
> 
> Um, as you seem to be adding many of the new features these days, why don't
> you tell us?

I was busy doing it before May 1st :-)

I'll concentrate on bug-fixing + documentation from now on !!

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

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> On Sat, May 01, 2004 at 10:16:25PM +0200, Kim F. Storm wrote:
> > > > So when do we declare "feature freeze" ?  May 1st ?
> > > 
> > > May 1st sounds very good to me,
> > 
> > Too good to be true ?
> 
> Um, as you seem to be adding many of the new features these days,
> why don't you tell us?

Hey, that was _before_ May 1, to get a nice feature set to iron out.
One that will make people happy for the next three years we need to
get a feature release out.

Ok, the image stuff seemingly has a few discussions with possible
interface changes pending, but the features themselves were in before
the feature freeze.  And that's the point of a freeze: gather things
that really should get it before that all at once, so that one can
the solidify on everything afterwards.

With regard to solidification, I think that many of Emacs' scrolling
functions should get more comfortable with large-height glyphs.  While
we should avoid last-minute before-release changes (which might
introduce deadlocks and similar), quite a bit of changes in that area
would qualify not as "features" but as bug fixes.  The feature is tall
lines, and it needs work to be considered close to proper.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>> > > So when do we declare "feature freeze" ?  May 1st ?
>> > May 1st sounds very good to me,
>> Too good to be true ?
> Um, as you seem to be adding many of the new features these days, why don't
> you tell us?

As a perpertrator of "last minute feature addition", I can't complain.
But in any case I think people should from now on concentrate on bug-fixing
(which might include some interface-changes, admittedly).


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Nick Roberts]

 > >> > > So when do we declare "feature freeze" ?  May 1st ?
 > >> > May 1st sounds very good to me,
 > >> Too good to be true ?
 > > Um, as you seem to be adding many of the new features these days, why don't
 > > you tell us?
 > 
 > As a perpertrator of "last minute feature addition", I can't complain.
 > But in any case I think people should from now on concentrate on bug-fixing
 > (which might include some interface-changes, admittedly).

IMHO, any feature freeze is only meaningful if it is accompanied by a branch.
Otherwise new features will have no place to go and will quite likely get
bundled in with bug-fixes.

Also, from the mailing list archives, I see that a year elapsed between the
first pretest and the release of Emacs 21.1. So I would like to see a target
date for the release so that the "freeze" doesn't drag on indefinitely.

Well, one can only hope.

Nick

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Nick Roberts <nick@nick.uklinux.net> writes:

>  > >> > > So when do we declare "feature freeze" ?  May 1st ?
>  > >> > May 1st sounds very good to me,
>  > >> Too good to be true ?

>  > > Um, as you seem to be adding many of the new features these
>  > > days, why don't you tell us?
>  > 
>  > As a perpertrator of "last minute feature addition", I can't
>  > complain.  But in any case I think people should from now on
>  > concentrate on bug-fixing (which might include some
>  > interface-changes, admittedly).
> 
> IMHO, any feature freeze is only meaningful if it is accompanied by
> a branch.

No.

> Otherwise new features will have no place to go and will quite
> likely get bundled in with bug-fixes.

New features can go into branches if really necessary.  And we already
_have_ some things like lexical, bidi, multi-tty, unicode and so on in
branches.  So it is not that this is a novelty.  But developers should
get their head wrapped around getting Emacs into releasable state
rather than bothering with new features now, if possible.

> Also, from the mailing list archives, I see that a year elapsed
> between the first pretest and the release of Emacs 21.1. So I would
> like to see a target date for the release so that the "freeze"
> doesn't drag on indefinitely.

Nope.  There is no point in releasing it before it is ready.  And
there is no sense in delaying further once it is ready.  And there is
no point in telling a lot of voluntary that they have to deliver on a
certain date or lose their non-job.

> Well, one can only hope.

And work.  Proofreading the manual is something that needs not be
restricted to core developers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Nick Roberts]

 > > Otherwise new features will have no place to go and will quite
 > > likely get bundled in with bug-fixes.
 > 
 > New features can go into branches if really necessary.

By new features, I just mean patches that might break functionality. They
might be too small to justify a separate branch.

 > > Also, from the mailing list archives, I see that a year elapsed
 > > between the first pretest and the release of Emacs 21.1. So I would
 > > like to see a target date for the release so that the "freeze"
 > > doesn't drag on indefinitely.
 >
 > Nope.  There is no point in releasing it before it is ready.  And
 > there is no sense in delaying further once it is ready.

Well, Confucius might say something like that. If there was a nominal date,
developers like Kai, could make a judgement as to whether or not there was
enough time to merge new features of Tramp.

 >                                                         And there is
 > no point in telling a lot of voluntary that they have to deliver on a
 > certain date or lose their non-job.

It would just be something to aim for. I don't remember talking about penalty
clauses. Currently, for all I know, features of GDB needed by gdb-ui.el may
be obsolete before the next Emacs release.

Nick

Re: It is time for a feature freeze (it is NOW or never).

[Jason Rumney]

Nick Roberts <nick@nick.uklinux.net> writes:

>  > > Otherwise new features will have no place to go and will quite
>  > > likely get bundled in with bug-fixes.
>  > 
>  > New features can go into branches if really necessary.
> 
> By new features, I just mean patches that might break functionality. They
> might be too small to justify a separate branch.

Put them into the unicode branch, since that is the target of the
next feature release after this one.

If we branch now, everyone will continue to work on HEAD, and we will
never get a release out. We need to concentrate on the release now,
and worry about branching for bugfixes after we have made a release.

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    New features can go into branches if really necessary.  And we already
    _have_ some things like lexical, bidi, multi-tty, unicode and so on in
    branches.  So it is not that this is a novelty.  But developers should
    get their head wrapped around getting Emacs into releasable state
    rather than bothering with new features now, if possible.

I agree--it is little use having a "freeze" in the trunk if most
developers turn their attention away from it.  To aim for a release,
we should focus on the work that needs to be done for a release.

The biggest separate jobs remaining are updating and checking the
manuals.

Re: It is time for a feature freeze (it is NOW or never).

[Jan D.]

>
> The biggest separate jobs remaining are updating and checking the
> manuals.

Should the icons for the toolbar be updated for this release?  When 
running
on Gnome, it would be an advantage if Emacs used the same icons as other
Gnome/GTK applications.  I think Emacs now use GTK 1.2 icons.
We could just convert the GTK 2.x icons to xpm.  Alternative I have a
patch to use GTK stock icons for Emacs compiled with GTK.  It involves
setting the property :stock on tool bar items.  It is just for GTK
though, so it is not general.

	Jan D.

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    Should the icons for the toolbar be updated for this release?  When 
    running
    on Gnome, it would be an advantage if Emacs used the same icons as other
    Gnome/GTK applications.  I think Emacs now use GTK 1.2 icons.
    We could just convert the GTK 2.x icons to xpm.

I think that someone drew us new icons for Emacs, but I don't
remember if they ever got installed, nor where to find them now.

Re: It is time for a feature freeze (it is NOW or never).

[Jan D.]

>     Should the icons for the toolbar be updated for this release?  When
>     running
>     on Gnome, it would be an advantage if Emacs used the same icons as 
> other
>     Gnome/GTK applications.  I think Emacs now use GTK 1.2 icons.
>     We could just convert the GTK 2.x icons to xpm.
>
> I think that someone drew us new icons for Emacs, but I don't
> remember if they ever got installed, nor where to find them now.

I've put up some pictures at http://mywebpage.netscape.com/jhdns/ so
you can view them easily.  There where two suggestions, Daniel Pfeiffer 
made
changes to the speedbar icons, and someone whos name escapes me (jefbed)
made Gnome icons in xpm formats.  None of these are installed in CVS.

The speedbar icons where marginally preferred by me and Miles Bader, I 
don't
think there where any other comments.  The Gnome icons where not 
commented
much either.

I slightly prefer the new icons, but it is not that much of a 
difference.
I do think we should change though.

	Jan D.

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> >     Should the icons for the toolbar be updated for this release?
> >     When running on Gnome, it would be an advantage if Emacs used
> >     the same icons as other Gnome/GTK applications.  I think Emacs
> >     now use GTK 1.2 icons.  We could just convert the GTK 2.x
> >     icons to xpm.
> >
> > I think that someone drew us new icons for Emacs, but I don't
> > remember if they ever got installed, nor where to find them now.
> 
> I've put up some pictures at http://mywebpage.netscape.com/jhdns/ so
> you can view them easily.  There where two suggestions, Daniel
> Pfeiffer made changes to the speedbar icons, and someone whos name
> escapes me (jefbed) made Gnome icons in xpm formats.  None of these
> are installed in CVS.
> 
> The speedbar icons where marginally preferred by me and Miles Bader,
> I don't think there where any other comments.  The Gnome icons where
> not commented much either.

The speedbar icon changes are marginal, mainly being less glaring
(which is not the worst idea, considering that they are merely
indicators beside the main text).

With the other icons, the changes are more significant: one thing
that is apparent is that they are done with much more focus on
getting them to rasterize well.  With the exception of the scissor, I
consider them a definite improvement.

I am not sure the "help" icon is an improvement.  The "?" icon is
just that, iconic, whereas the life-saver ring looks like a pretty
toy at first sight.

But in general, I don't think it worth the trouble to do an Emacs-only
policy for single icons: such details should rather be discussed
upstream; they are not Emacs-specific.

> I slightly prefer the new icons, but it is not that much of a
> difference.  I do think we should change though.

Agreed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

We can use the GMOME icons on the same basis that we use things
such as oldxlib: saying that they are not part of Emacs, but
used by Emacs and distributed with Emacs.

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> IMHO, any feature freeze is only meaningful if it is accompanied by a branch.
> Otherwise new features will have no place to go and will quite likely get
> bundled in with bug-fixes.

No, we want people to stop working on features and work on
bugfixing instead.  When we create the branch is when we say "alright
people, if you're bored of bugfixing you can add features again".

> Also, from the mailing list archives, I see that a year elapsed between the
> first pretest and the release of Emacs 21.1. So I would like to see a target
> date for the release so that the "freeze" doesn't drag on indefinitely.

It just depends on how much time it takes before the stream of bug-reports
slows down enough that the code can be considered "stable".


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 02 May 2004 15:16:56 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> No, we want people to stop working on features and work on
> bugfixing instead.

I've been trying to finish the help-highlight-argument stuff in time to
install it before the freeze. It's tiny and it can be removed easily if
some problem arises.

I'd like an OK or three before install it, though.

                                                           /L/e/k/t/u

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Juanma Barranquero <lektu@mi.madritel.es> writes:

> On 02 May 2004 15:16:56 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > No, we want people to stop working on features and work on
> > bugfixing instead.
> 
> I've been trying to finish the help-highlight-argument stuff in time to
> install it before the freeze. It's tiny and it can be removed easily if
> some problem arises.
> 
> I'd like an OK or three before install it, though.

In my book "feature freeze" does not completely exclude tiny
enhancements (like this one) going in; rather it is a "state of mind"
on the developers concentrating on _finalizing_ what's already there
rather than _adding_ new stuff.

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

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 03 May 2004 07:44:18 +0200
storm@cua.dk (Kim F. Storm) wrote:

> In my book "feature freeze" does not completely exclude tiny
> enhancements (like this one) going in; rather it is a "state of mind"
> on the developers concentrating on _finalizing_ what's already there
> rather than _adding_ new stuff.

I agree, but I'd rather ask than step on somebody's toes.

Thanks,

                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

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

> >> In that case, I guess we should aim for a release without the unicode
> >> branch.  And certainly without the multi-tty branch.  (As for the
> >> tiling and lexical branches, I am not convinced I want to make those
> >> changes.)
> 
> > So when do we declare "feature freeze" ?  May 1st ?
> 
> May 1st sounds very good to me,

BTW, what about USE_LSB_TAG ?  

Should we make it the default on some platforms?  Which ones?

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> BTW, what about USE_LSB_TAG ?  
> Should we make it the default on some platforms?  Which ones?

The USE_LSB_TAG code is ready in the sense that it should work just as
well as the default (or as USE_LISP_UNION_TYPE).  Even .gdbinit has been
updated to automatically know how to do xbacktrace and stuff with it.

So we could make it the default on some platforms (I've used it extensively
on MacOSX and GNU/Linux).

Note that there is still an open bug (by David Ponce) that I have not been
able to track down.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

Let's make USE_LSB_TAG the default for now, and if the bug you
have not found does not get fixed, we can back it out later.

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> Let's make USE_LSB_TAG the default for now, and if the bug you
> have not found does not get fixed, we can back it out later.

I have now made it the default on systems where I know it should work.
I.e. it checks that it is compiled with gcc and it also checks that the
malloc library is either the one that comes with glibc or macosx's
libc, or is doug lea's malloc or gnu_malloc.
I don't know if that covers *BSD systems.

You'll need to rm src/*.o before rebuilding, since the required
dependencies on lisp.h are missing from src/Makefile.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

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

> > Let's make USE_LSB_TAG the default for now, and if the bug you
> > have not found does not get fixed, we can back it out later.
> 
> I have now made it the default on systems where I know it should work.

I have installed a fix to mark_kboards to avoid marking x and y members
of an input_event when it is overloaded by a selection_input_event.

Without USE_LSB_TAG, it didn't really matter as x and y were still
just integers, but with USE_LSB_TAG, they become random objects when
overloaded.

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>> > Let's make USE_LSB_TAG the default for now, and if the bug you
>> > have not found does not get fixed, we can back it out later.
>> I have now made it the default on systems where I know it should work.
> I have installed a fix to mark_kboards to avoid marking x and y members
> of an input_event when it is overloaded by a selection_input_event.

Eww.... I didn't know about this overloading.  Pretty ugly.
Thanks for figuring it out.  I strongly suspect that it is the problem that
David Ponce had and that I couldn't reproduce (his backtraces always passed
through mark_kboards).


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[YAMAMOTO Mitsuharu]

>>>>> On 13 May 2004 13:14:14 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> Let's make USE_LSB_TAG the default for now, and if the bug you have
>> not found does not get fixed, we can back it out later.

> I have now made it the default on systems where I know it should
> work.

Fccl_execute_on_string fails to set the values to the status vector.
The following change should fix that.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

*** src/ccl.c.~1.84.~	Mon Nov 17 01:17:09 2003
--- src/ccl.c	Fri May 14 20:57:30 2004
***************
*** 2196,2202 ****
    produced = ccl_driver (&ccl, SDATA (str), outbuf,
  			 SBYTES (str), outbufsize, (int *) 0);
    for (i = 0; i < 8; i++)
!     XSET (AREF (status, i), Lisp_Int, ccl.reg[i]);
    XSETINT (AREF (status, 8), ccl.ic);
    UNGCPRO;
  
--- 2196,2202 ----
    produced = ccl_driver (&ccl, SDATA (str), outbuf,
  			 SBYTES (str), outbufsize, (int *) 0);
    for (i = 0; i < 8; i++)
!     XSETINT (AREF (status, i), ccl.reg[i]);
    XSETINT (AREF (status, 8), ccl.ic);
    UNGCPRO;

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <wlekpnxkv3.wl@church.math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>  I have now made it the default on systems where I know
>> it should work.

> Fccl_execute_on_string fails to set the values to the
> status vector.  The following change should fix that.

Thank you.  I've just installed this slightly different fix.

Index: ccl.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/ccl.c,v
retrieving revision 1.84
retrieving revision 1.85
diff -u -c -r1.84 -r1.85
cvs server: conflicting specifications of output style
*** ccl.c	16 Nov 2003 16:17:09 -0000	1.84
--- ccl.c	14 May 2004 12:41:32 -0000	1.85
***************
*** 2196,2203 ****
    produced = ccl_driver (&ccl, SDATA (str), outbuf,
  			 SBYTES (str), outbufsize, (int *) 0);
    for (i = 0; i < 8; i++)
!     XSET (AREF (status, i), Lisp_Int, ccl.reg[i]);
!   XSETINT (AREF (status, 8), ccl.ic);
    UNGCPRO;
  
    if (NILP (unibyte_p))
--- 2196,2203 ----
    produced = ccl_driver (&ccl, SDATA (str), outbuf,
  			 SBYTES (str), outbufsize, (int *) 0);
    for (i = 0; i < 8; i++)
!     ASET (status, i, make_number (ccl.reg[i]));
!   ASET (status, 8, make_number (ccl.ic));
    UNGCPRO;
  
    if (NILP (unibyte_p))

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

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

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

> >> In that case, I guess we should aim for a release without the unicode
> >> branch.  And certainly without the multi-tty branch.  (As for the
> >> tiling and lexical branches, I am not convinced I want to make those
> >> changes.)
> 
> > So when do we declare "feature freeze" ?  May 1st ?
> 
> May 1st sounds very good to me,


Did we decide on naming the next release 21.5 ?  

It's simpler just to stick with 21.4 and do some real work, but if we
must change it, who will make an effort to change 21.4 -> 21.5
throughout the sources.

To speed up things even further, should we make a pretest now?

We could announce to the pretesters that it is an early pre-test, but
believed to be stable and ask the pretesters to actively start using
it so we can get feedback asap.

I suggest that we set the USE_LSB_TAG for GNU/Linux and Mac/OS for the
first pretest; we can then enable it for more ports in the next
pretest.

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

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > >> In that case, I guess we should aim for a release without the
> > >> unicode branch.  And certainly without the multi-tty branch.
> > >> (As for the tiling and lexical branches, I am not convinced I
> > >> want to make those changes.)
> > 
> > > So when do we declare "feature freeze" ?  May 1st ?
> > 
> > May 1st sounds very good to me,
> 
> 
> Did we decide on naming the next release 21.5 ?
> 
> It's simpler just to stick with 21.4 and do some real work, but if we
> must change it, who will make an effort to change 21.4 -> 21.5
> throughout the sources.

I think that 21.4 has been mentioned frequently as probably another
bug fix release, and 21.5 is "half-way" to 22.0.

Since we will need quite some time of consolidation before we can
hope to get out the new feature release, reserving 21.4 for a
possible bug fix release in case something horrible turns up that
needs immediate fixing during that time might not do harm.

And if we don't need to release a 21.4 in the mean time, the version
number jump will then perhaps be somewhat of an indicator that there
was a larger change.

It's annoying if you write things like "will be available in version
21.4 and later" in some manual and then have to admit that you were
lying.  And 21.4 has already been earmarked as a non-trunk release in
some announcements or comments.

So if we skip this bugfix release, let us also skip the number.

> To speed up things even further, should we make a pretest now?
> 
> We could announce to the pretesters that it is an early pre-test,
> but believed to be stable and ask the pretesters to actively start
> using it so we can get feedback asap.

Believed to be stable?  With several unresolved lockups and display
problems and last-minute additions?  I think that would be unfair.
"Workable" and "worth it" would be more like it.

> I suggest that we set the USE_LSB_TAG for GNU/Linux and Mac/OS for
> the first pretest; we can then enable it for more ports in the next
> pretest.

I suggest that before doing a formal pretest release, we let the last
changes shake down a few weeks among developers.

Well, at least till Mother's Day.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 04 May 2004 09:14:26 +0200
David Kastrup <dak@gnu.org> wrote:

> So if we skip this bugfix release, let us also skip the number.

I fully agree...

> reserving 21.4 for a
> possible bug fix release in case something horrible turns up that
> needs immediate fixing during that time might not do harm.

...but this doesn't seem very sensible. Getting out a 21.5 and
*afterwards* a bug-fix 21.4 would be confusing, to say the least. If
we're afraid it can really happen, we would be best served by bumping up
21.5 to 22.0 so 21.X, X > 3 can be presented as "new releases of the
stable 21.1 series".

But in fact I think that if something horrible happens after 21.5, the
thing to do would be to fix it as quickly as posible, and meanwhile
recommend users to stand with the stable 21.3.

                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 04 May 2004 09:14:26 +0200
> David Kastrup <dak@gnu.org> wrote:
> 
> > So if we skip this bugfix release, let us also skip the number.
> 
> I fully agree...
> 
> > reserving 21.4 for a
> > possible bug fix release in case something horrible turns up that
> > needs immediate fixing during that time might not do harm.
> 
> ...but this doesn't seem very sensible. Getting out a 21.5 and
> *afterwards* a bug-fix 21.4 would be confusing, to say the least.

No, no.  The 21.4 was supposed to be reserved as a bug fix release to
21.3.  Once 21.5 is out, 21.4 should not appear: then people have to
jump the gun and help us get the bug out from 21.5 instead.

I just wanted to take 21.4 as a reserve when we know that 21.5 can't
be out soon, but we would very much need a particular bug fix to 21.3
to be out before that.

> But in fact I think that if something horrible happens after 21.5,
> the thing to do would be to fix it as quickly as posible, and
> meanwhile recommend users to stand with the stable 21.3.

Right.  I was talking about reserving 21.4 for _before_ 21.5 is
released.  Once we consider the trunk stable enough for an 21.5
release to be imminent, expending work on an in-between bug fix
release would be inappropriate.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> > > So if we skip this bugfix release, let us also skip the number.
> > 
> > I fully agree...

I agree too -- so who will take on the task of changing 21.4 -> 21.5 ?

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

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 04 May 2004 08:34:31 +0200
storm@cua.dk (Kim F. Storm) wrote:

> I agree too -- so who will take on the task of changing 21.4 -> 21.5 ?

I'll do tonight (in about ten hours).


                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>> I agree too -- so who will take on the task of changing 21.4 -> 21.5 ?
> I'll do tonight (in about ten hours).

Please don't.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 04 May 2004 09:45:02 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Please don't.

Ok, but why?  Are you disagreeing with releasing 21.5, or just have many
uncommited changes right now?


                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 04 May 2004 10:17:49 +0200
David Kastrup <dak@gnu.org> wrote:

> No, no.  The 21.4 was supposed to be reserved as a bug fix release to
> 21.3.  Once 21.5 is out, 21.4 should not appear: then people have to
> jump the gun and help us get the bug out from 21.5 instead.

Sorry, I misunderstood you.

I agree with your plan.


                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> I think that 21.4 has been mentioned frequently as probably another
> bug fix release, and 21.5 is "half-way" to 22.0.

Huh?  I think it's been much more mentioned as "the next big thing".
As in "will only be included in 21.4".

And all the code currently refersw to 21.4.

So I suggest we don't change anything for now (i.e. aim for 21.4).
If something bad happens we can always release a 21.4 bugfix and go through
the CVS code to fix the refs from 21.4 to 21.5.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Juanma Barranquero]

On 04 May 2004 09:44:36 -0400
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> So I suggest we don't change anything for now (i.e. aim for 21.4).

We'll have to change the places where 21.5 is already mentioned:

  lisp/cus-start.el
  lisp/descr-text.el
  lisp/log-edit.el
  lisp/international/latin1-disp.el
  lispref/modes.texi

(At least.)

                                                                Juanma

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

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

> > I think that 21.4 has been mentioned frequently as probably another
> > bug fix release, and 21.5 is "half-way" to 22.0.
> 
> Huh?  I think it's been much more mentioned as "the next big thing".
> As in "will only be included in 21.4".

That was once.  And then there was a time where it was "21.4 will
likely be another bug fix release".

There was once talk to have another RC_1 branch release, before we
decided to bite the bullet and go directly for a trunk release next.

> And all the code currently refersw to 21.4.
> 
> So I suggest we don't change anything for now (i.e. aim for 21.4).
> If something bad happens we can always release a 21.4 bugfix and go through
> the CVS code to fix the refs from 21.4 to 21.5.

The problem is that I saw quite a few announcements of the "will be
fixed/available in 21.4 or 21.5" by now.  Since talk was made about
another RC_1 release, people have amended the lines that once talked
about the feature being in 21.2, 21.3 and 21.4 in succession.

And if indeed people expect 21.4 to be the next great thing,
releasing as 21.5 will do no harm.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

I think we may as well skip making another release from RC.  The
question is whether we should call the next release 21.4 or 22.0.

There has been so much change that maybe the next release should be
22.0.

I don't think we are ready for a pretest now.

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I think we may as well skip making another release from RC.  The
> question is whether we should call the next release 21.4 or 22.0.
> 
> There has been so much change that maybe the next release should be
> 22.0.

While there have been lots of small to medium changes and lots of
additions across the board, I don't think that there have been really
fundamental changes as compared to 21.0.  So the problem is not as
much that we have a big change warranting 22.0, but that we have
missed out on releasing anything between 21.4 and 21.20.

>From what we have planned right now, immediately after getting the
next release out, the Unicode branch will get merged and
consolidated, and the multi tty branch merged as well, if feasible.
Those are fundamental changes.  The Unicode branch is believed to be
in pretty good shape, but we want to have a consolidated _released_
version to merge it into.

Unicode, in particular with multi tty, will definitely warrant a
changed major release number.  It would appear awkward to change to
22.0, and right in the next step (after at most 22.1) to 23.0.
Merging the bidi branch, in contrast, will probably not warrant a
major release step, even though it will mean major work.

So in order to avoid version overkill, I think that we would stay at
21.x as long as we have "merely" extensive, but not fundamental
changes.

> I don't think we are ready for a pretest now.

Same here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > I think we may as well skip making another release from RC.  The
> > question is whether we should call the next release 21.4 or 22.0.
> > 
> > There has been so much change that maybe the next release should be
> > 22.0.
> 
> So in order to avoid version overkill, I think that we would stay at
> 21.x as long as we have "merely" extensive, but not fundamental
> changes.

Well, there are SOME fundamental changes from 21.3 to "this" release:

** Leim is now part of the Emacs distribution.
** The Emacs Lisp Reference Manual is now part of the distribution.
** The max size of buffers and integers has been doubled.
** GTK support

Besides, a lot of external lisp packages are now included with emacs
(tramp, ses, cua, ...)

If you look at NEWS, 3500 lines have been added since 21.3.

Compare this to 4800 lines describing the changes from 20.7 to 21.3

But I don't really case if we call this 21.4, 21.5, or 22.0 --
as long as we release something in 2004 !!

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

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
> 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> > > I think we may as well skip making another release from RC.  The
> > > question is whether we should call the next release 21.4 or 22.0.
> > > 
> > > There has been so much change that maybe the next release should be
> > > 22.0.
> > 
> > So in order to avoid version overkill, I think that we would stay at
> > 21.x as long as we have "merely" extensive, but not fundamental
> > changes.
> 
> Well, there are SOME fundamental changes from 21.3 to "this" release:
> 
> ** Leim is now part of the Emacs distribution.

A difference in packaging is not fundamental.

> ** The Emacs Lisp Reference Manual is now part of the distribution.

A difference in packaging is not fundamental.

> ** The max size of buffers and integers has been doubled.

This is just a minor detail for the user.

> ** GTK support

Probably more relevant.  Also image support has been extended to Mac
and Windows, but I consider this more a bugfix than a feature
enhancement: image support never was intended to be X-only.  It was
just a tolerated shortcoming in order to get something out.

> Besides, a lot of external lisp packages are now included with emacs
> (tramp, ses, cua, ...)

A difference in packaging...  but I repeat myself.  It is convenient,
but not fundamental.

> But I don't really case if we call this 21.4, 21.5, or 22.0 -- as
> long as we release something in 2004 !!

Yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Luc Teirlinck]

I personally believe that the most logical thing would be to call the
next release "21.4".  The NEWS has always described all changes as to
be made in 21.4.  Skipping a number like "21.5" might confuse people
and make them believe that there was a "21.4" which they somehow
"missed".  If a sysadmin updates to 21.5, I am sure plenty of people
are going to believe there was a 21.4, which just never got updated
to, especially given the large amount of elapsed time.  "22.0" might
be OK, but there is the lack of a really super-significant individual
change.

   > But I don't really case if we call this 21.4, 21.5, or 22.0 -- as
   > long as we release something in 2004 !!

   Yes.

Of course, I would not really mind if it were called "21.5" either,
even though that would be my least favorite choice of the three.

Sincerely,

Luc.

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

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

> I personally believe that the most logical thing would be to call the
> next release "21.4".  The NEWS has always described all changes as to
> be made in 21.4.

The NEWS in CVS is read by developers.  Nobody ever claimed that it
was a realiable document before the release.

> Skipping a number like "21.5" might confuse people and make them
> believe that there was a "21.4" which they somehow "missed".  If a
> sysadmin updates to 21.5, I am sure plenty of people are going to
> believe there was a 21.4, which just never got updated to,

Well, if they believe that, where is the problem?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Wed, May 05, 2004 at 12:21:18AM +0200, David Kastrup wrote:
> So in order to avoid version overkill, I think that we would stay at
> 21.x as long as we have "merely" extensive, but not fundamental
> changes.

I agree with this; I think unicode should be 22.0, at least nominally.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: It is time for a feature freeze (it is NOW or never).

[Robert J. Chassell]

   >From what we have planned right now, immediately after getting the
   next release out, the Unicode branch will get merged and
   consolidated, and the multi tty branch merged as well, if feasible.
   Those are fundamental changes.  

Right.  I think the release that includes these should be called 22.

Anything before that, such as the one currently planned, should stay
in 21.

David Kastrup is right when he says:

   ...  in order to avoid version overkill, I think that we would stay
   at 21.x as long as we have "merely" extensive, but not fundamental
   changes.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    As I slowly update it,                     bob@rattlesnake.com
        I rewrite a "What's New" segment for   http://www.rattlesnake.com

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    I still think this is a bad idea -- it cannot be done without potentially
    destabilizing the trunk which is currently in a very stable state, and
    thus in a pretty unique state of "readiness for release".

We could urge all the pretesters to try out the unicode branch now.
That way we would get a picture of how far it is from readiness.

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Sun, Apr 11, 2004 at 11:50:57PM -0400, Richard Stallman wrote:
> We could urge all the pretesters to try out the unicode branch now.
> That way we would get a picture of how far it is from readiness.

I was under the impression that the unicode-2 branch was fairly old (I looked
at a few files, and it seems to have last been updated from the trunk around
last summer), which might make such testing a bit questionable.

I think a merge one direction or another should take place.

BTW, I wonder if it might be a slightly easier to use arch to manage the
unicode branch, at least the merging duties.  I keep my branches up-to-date
by merging regularly from the trunk, and it's quite painless in general (some
of this is that I now have a fair amount of experience with arch, of course
-- but I was pretty good with CVS too, and it was always a pain).

Since unicode-2 was branched before I added taglines, it would take a bit of
preparation, but once done it would be simple for me to keep the unicode
branch synchronized between CVS and arch as I do with the trunk, and the
unicode hackers could continue to use CVS for daily hacking if they wished,
with arch used to keep the unicode branch updated with respect to the CVS
trunk (this latter is probably best done by a unicode hacker, as they would
know how to best resolve merge conflicts).

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

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    BTW, I wonder if it might be a slightly easier to use arch to manage the
    unicode branch, at least the merging duties.

Handa is the main developer of that branch, so let's do this whatever
way he prefers.

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <20040412041506.GA31211@fencepost>, Miles Bader <miles@gnu.org> writes:

> On Sun, Apr 11, 2004 at 11:50:57PM -0400, Richard Stallman wrote:
>>  We could urge all the pretesters to try out the unicode branch now.
>>  That way we would get a picture of how far it is from readiness.

> I was under the impression that the unicode-2 branch was fairly old (I looked
> at a few files, and it seems to have last been updated from the trunk around
> last summer), which might make such testing a bit questionable.

> I think a merge one direction or another should take place.

I've just synchronized emacs-unicode-2 branch to the trunk,
i.e, I've done something like this:

% cd .../emacs-trunk
% cvs tag handa-temp-tag
% cd .../emacs-unicode-2
% cvs update -j emcas-unicode-2-base -j handa-temp-tag
% cvs commit -m 'Sync to HEAD'
% cd .../emacs-trunk
% cvs tag -F -r handa-temp-tag emacs-unicode-2

> Since unicode-2 was branched before I added taglines, it would take a bit of
> preparation, but once done it would be simple for me to keep the unicode
> branch synchronized between CVS and arch as I do with the trunk, and the
> unicode hackers could continue to use CVS for daily hacking if they wished,
> with arch used to keep the unicode branch updated with respect to the CVS
> trunk (this latter is probably best done by a unicode hacker, as they would
> know how to best resolve merge conflicts).

So, now all files in emacs-unicode-2 branch have arch tags.
But, I've never used arch.  Could you tell me the exact
procedure to use arch for synchronizing?  Is it surely
easier than the above procedure for CVS?

By the way, the last step above aborted as below.

[...]
T src/s/vms4-4.h
T src/s/vms5-5.h
T src/s/windows95.h
T src/s/xenix.h
cvs server: Tagging vms
T vms/README
T vms/make-mms-derivative.el
cvs [server aborted]: "tag" requires write access to the repository

Could someone tell me what it means?

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> % cd .../emacs-trunk
> % cvs tag handa-temp-tag
> % cd .../emacs-unicode-2
> % cvs update -j emcas-unicode-2-base -j handa-temp-tag
> % cvs commit -m 'Sync to HEAD'
> % cd .../emacs-trunk
> % cvs tag -F -r handa-temp-tag emacs-unicode-2

Seems right (except for the `emcas' typo and the fact that the last command
should set emacs-unicode-2-base rather than emacs-unicode-2, but I expect
these were copy-errors and you use the right commands ;-).

> So, now all files in emacs-unicode-2 branch have arch tags.
> But, I've never used arch.  Could you tell me the exact
> procedure to use arch for synchronizing?

Well, you'll have to create an Arch branch first.

> Is it surely easier than the above procedure for CVS?

Once the branch is setup, merging is much easier because the management of
emacs-unicode-2-base is basically all done for you.  You'll just do

   tla star-merge --three-way miles@gnu.org--gnu-2004/emacs--cvs-trunk--0

to merge in changes from the cvs-trunk.

> By the way, the last step above aborted as below.
> [...]
> T src/s/vms4-4.h
> T src/s/vms5-5.h
> T src/s/windows95.h
> T src/s/xenix.h
> cvs server: Tagging vms
> T vms/README
> T vms/make-mms-derivative.el
> cvs [server aborted]: "tag" requires write access to the repository
> Could someone tell me what it means?

No idea.  Can you try again?
Since `cvs tag handa-temp-tag' worked, I'd assume that it was just
a transient bug.  Otherwise, it means that some permissions are messed up,
which seems odd.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

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

>>  % cd .../emacs-trunk
>>  % cvs tag handa-temp-tag
>>  % cd .../emacs-unicode-2
>>  % cvs update -j emcas-unicode-2-base -j handa-temp-tag
>>  % cvs commit -m 'Sync to HEAD'
>>  % cd .../emacs-trunk
>>  % cvs tag -F -r handa-temp-tag emacs-unicode-2

> Seems right (except for the `emcas' typo and the fact that the last command
> should set emacs-unicode-2-base rather than emacs-unicode-2, but I expect
> these were copy-errors and you use the right commands ;-).

Ah, yes.  They are my typo (I manually typed above, not
copy&past).

>>  So, now all files in emacs-unicode-2 branch have arch tags.
>>  But, I've never used arch.  Could you tell me the exact
>>  procedure to use arch for synchronizing?

> Well, you'll have to create an Arch branch first.

>>  Is it surely easier than the above procedure for CVS?

> Once the branch is setup, merging is much easier because the management of
> emacs-unicode-2-base is basically all done for you.  You'll just do

>    tla star-merge --three-way miles@gnu.org--gnu-2004/emacs--cvs-trunk--0

> to merge in changes from the cvs-trunk.

Thank you.  I don't know what is "Arch branch", how to
create it.  In addition, I couldn't install "tla-1.2" on my
Debian.  I downloaded it from
http://ftp.gnu.org/gnu/gnu-arch/.

The configure script showed this error:
----------------------------------------------------------------------
% ../configure --prefix /usr/local/work/tmp

The configured versions of diff and diff3 do not handle files
not ending in newline correctly.

  configured diff = diff.
  configured diff3 = diff3.


Use config options
  --with-gnu-diff PROG
  --with-gnu-diff3 PROG

  NOTE: especially on BSD-derived systems, you will want
   to grab a recent version of GNU diff and compile it for use
   with those config options.   You don't need to replace
   the native diff tools on your system, but you do need to
   configure tla specially.   Sorry about that -- some BSDs
   have made a poor decision about their native diffs.

   (Example systems: some NetBSD, FreeBSD, and MacOS versions.)
----------------------------------------------------------------------

At least, as I found a manual in it, I'm reading it now.

>>  By the way, the last step above aborted as below.
>>  [...]
>>  T src/s/vms4-4.h
>>  T src/s/vms5-5.h
>>  T src/s/windows95.h
>>  T src/s/xenix.h
>>  cvs server: Tagging vms
>>  T vms/README
>>  T vms/make-mms-derivative.el
>>  cvs [server aborted]: "tag" requires write access to the repository
>>  Could someone tell me what it means?

> No idea.  Can you try again?
> Since `cvs tag handa-temp-tag' worked, I'd assume that it was just
> a transient bug.  Otherwise, it means that some permissions are messed up,
> which seems odd.

I found that "cvs tag handa-temp-tag" also showed this at
the tail.

[...]
T src/s/xenix.h
cvs server: Tagging vms
T vms/README
T vms/make-mms-derivative.el
cvs [server aborted]: "tag" requires write access to the repository

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

> Thank you.  I don't know what is "Arch branch", how to
> create it.  In addition, I couldn't install "tla-1.2" on my
> Debian.  I downloaded it from
> http://ftp.gnu.org/gnu/gnu-arch/.

Have you tried `apt-get install tla' ?  Worked for me (it's in testing,
not in stable).

> The configure script showed this error:
> ----------------------------------------------------------------------
> % ../configure --prefix /usr/local/work/tmp

> The configured versions of diff and diff3 do not handle files
> not ending in newline correctly.

>   configured diff = diff.
>   configured diff3 = diff3.

You need to upgrade your diff program.  GNU diff 2.7 (and non-GNU diffs)
have various bugs related to handling of files without terminating newline.

> I found that "cvs tag handa-temp-tag" also showed this at
> the tail.

> [...]
> T src/s/xenix.h
> cvs server: Tagging vms
> T vms/README
> T vms/make-mms-derivative.el
> cvs [server aborted]: "tag" requires write access to the repository

By any chance, do you have a CVS/Root file somewhere that points to
some other repository ?  Do a

        cat **/CVS/Root

in zsh (or eshell) or

        find . -type d -name CVS --exec cat {}/Root


-- Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <m165byy1p4.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>  Thank you.  I don't know what is "Arch branch", how to
>>  create it.  In addition, I couldn't install "tla-1.2" on my
>>  Debian.  I downloaded it from
>>  http://ftp.gnu.org/gnu/gnu-arch/.

> Have you tried `apt-get install tla' ?  Worked for me (it's in testing,
> not in stable).

It couldn't find the package "tla".  :-(

>>  The configure script showed this error:
>>  ----------------------------------------------------------------------
>>  % ../configure --prefix /usr/local/work/tmp

>>  The configured versions of diff and diff3 do not handle files
>>  not ending in newline correctly.

>>    configured diff = diff.
>>    configured diff3 = diff3.

> You need to upgrade your diff program.  GNU diff 2.7 (and non-GNU diffs)
> have various bugs related to handling of files without terminating newline.

Thank you for the info.

apt-get tells me that `diff' on my machine is the newest
version.  So, I installed diffutils-2.8.1 manually, then tla
was successfully built.

>>  I found that "cvs tag handa-temp-tag" also showed this at
>>  the tail.

>>  [...]
>>  T src/s/xenix.h
>>  cvs server: Tagging vms
>>  T vms/README
>>  T vms/make-mms-derivative.el
>>  cvs [server aborted]: "tag" requires write access to the repository

> By any chance, do you have a CVS/Root file somewhere that points to
> some other repository ?  Do a

>         cat **/CVS/Root

> in zsh (or eshell) or

>         find . -type d -name CVS --exec cat {}/Root

Bingo!  I recalled I built `gnulib' directory and checked
out regex.[ch] in it.  CVS/Root in it is:

:ext:anoncvs@subversions.gnu.org:/cvsroot/gnulib

I'm so sorry for bothering you.

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>>> Thank you.  I don't know what is "Arch branch", how to
>>> create it.  In addition, I couldn't install "tla-1.2" on my
>>> Debian.  I downloaded it from
>>> http://ftp.gnu.org/gnu/gnu-arch/.
>> Have you tried `apt-get install tla' ?  Worked for me (it's in testing,
>> not in stable).
> It couldn't find the package "tla".  :-(

Do you have `testing' or `unstable' in your sources.list?

> apt-get tells me that `diff' on my machine is the newest version.

That's because you're using `stable'.

   apt-get install diffutils/testing

should get you 2.8.1 or somesuch (provided you have `testing' in your
sources.list).

> So, I installed diffutils-2.8.1 manually, then tla
> was successfully built.

Good.


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <jwvr7uk6pnw.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>  Have you tried `apt-get install tla' ?  Worked for me (it's in testing,
>>>  not in stable).
>>  It couldn't find the package "tla".  :-(

> Do you have `testing' or `unstable' in your sources.list?

Ah! No.  But I'd like to avoid installing such versions by
apt-get.  I always install testing version in
/usr/local/... by getting source and compiling it.

Anyway, thank you for the tip.

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

Re: It is time for a feature freeze (it is NOW or never).

[Miles Bader]

On Tue, Apr 20, 2004 at 08:44:58AM +0900, Kenichi Handa wrote:
> > Do you have `testing' or `unstable' in your sources.list?
> 
> Ah! No.  But I'd like to avoid installing such versions by
> apt-get.  I always install testing version in
> /usr/local/... by getting source and compiling it.

I wouldn't worry too much about it -- "unstable" is actually quite reliable
generally (failures are almost always of the form "package won't upgrade",
which of course leaves you wait the old version still installed).

"testing" is even better: it's like unstable without the occasional problems
unstable has, albeit a tiny bit older.

My vague rules are:

  * For a personal machine with a fast net connection (so downloading fixes
    is fast), use "unstable" -- the frequent upgrades and quick bugfixes are
    more than worth the occasional (and usually minor) problem.

  * For a personal machine with a slow net connection, or where you don't
    want to do frequent updates, use "testing".  Weighing the (small)
    _potential_ for unstability in "testing" versus the rather old (and often
    buggy) software in "stable", testing almost always wins.

  * For a big department server, where changes can affect many people, maybe
    "stable" is justified -- but even here, you probably want to download
    both package lists, and install some packages from testing as well,
    where the stable version is simply too stupidly old.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <20040419235950.GA12584@fencepost>, Miles Bader <miles@gnu.org> writes:
> I wouldn't worry too much about it -- "unstable" is actually quite reliable
> generally (failures are almost always of the form "package won't upgrade",
> which of course leaves you wait the old version still installed).

> "testing" is even better: it's like unstable without the occasional problems
> unstable has, albeit a tiny bit older.

Thank you for the info.  It seems "testing" is good enough
for my purpose.

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

Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier]

>     I still think this is a bad idea -- it cannot be done without potentially
>     destabilizing the trunk which is currently in a very stable state, and
>     thus in a pretty unique state of "readiness for release".

> We could urge all the pretesters to try out the unicode branch now.
> That way we would get a picture of how far it is from readiness.

What's the problem with releasing from the current trunk ASAP instead?
Based on feedback from the few non-latin-only users I know, the trunk's
unicode support is "good enough" and is a major improvement over
Emacs-21.3.

There's no shortage of improvements in the current trunk.  Trying to merge
the unicode branch before the next release would just delay the release of
those improvements.  Maybe it would end up releasing the unicode-branch
a bit earlier, but I'm wondering why the unicode branch should be
considered so much more important than all those other features.
What concrete improvement does it bring to the user that's so valuable
compared to all the rest that's already in the trunk (i.e. utf-8 CJK
support, customizable fringes, many new packages, extra bundled manuals,
the list in NEWS is already much too long).


        Stefan

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I still think this is a bad idea -- it cannot be done without potentially
>     destabilizing the trunk which is currently in a very stable state, and
>     thus in a pretty unique state of "readiness for release".
> 
> We could urge all the pretesters to try out the unicode branch now.
> That way we would get a picture of how far it is from readiness.

But the unicode branch is not synchronized with the trunk, so it wouldn't
really tell us anything.

Even Handa-san says he is in favour of not merging unicode before we
have made a major release from trunk.

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

Re: It is time for a feature freeze (it is NOW or never).

[Kenichi Handa]

In article <m3r7usnbad.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>>      I still think this is a bad idea -- it cannot be done without potentially
>>      destabilizing the trunk which is currently in a very stable state, and
>>      thus in a pretty unique state of "readiness for release".
>>  
>>  We could urge all the pretesters to try out the unicode branch now.
>>  That way we would get a picture of how far it is from readiness.

> But the unicode branch is not synchronized with the trunk, so it wouldn't
> really tell us anything.

I'm gradually synchronizing unicode branch with the trunk by
the method Stephen taught me (i.e. moving
emacs-unicode-2-base tag), but the progress is slow.

> Even Handa-san says he is in favour of not merging unicode before we
> have made a major release from trunk.

Yes, but, what do you mean by "major release"?  I thought
releasing from the trunk with the version number 21.5 (or
21.4) is a "minor release" because it changes only the minor
version.

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

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> > Even Handa-san says he is in favour of not merging unicode before we
> > have made a major release from trunk.
> 
> Yes, but, what do you mean by "major release"?  I thought
> releasing from the trunk with the version number 21.5 (or
> 21.4) is a "minor release" because it changes only the minor
> version.

IMO a release from trunk _is_ a major release -- even if we only
increment the minor number...

Sorry to be imprecise.

-- 
Kim F. Storm  http://www.cua.dk

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Lőrentey Károly writes:

> The multi-tty branch changes some internal interfaces which break
> non-UN*X ports of Emacs.  The changes are not complex at all, but I
> can not fix the broken ports without help from Mac/Windows/DOS gurus.
> Because of this, the multi-tty branch is certainly not yet ready for
> merging.

Do you know that the ports are broken with your changes (have you made
the changes to those ports?), or do you just suspect they are broken
because you haven't been able to test your changes.

I usually manage to change this sort of thing (primarily textual,
rather than functional changes) on the W32/DOS/MAC ports even though I
don't use (or even compile on) them myself.

I just make the changes (very carefully), commit my changes, and then
leave it to the maintainers of those ports to verify my changes.  So
far, this procedure hasn't caused much trouble.

> > I have looked briefly at the multi-tty pathces, and although it looks
> > very sensible and systematic in its approach, it touches on many files
> > and interfaces!  
> >
> > Since it probably hasn't received much attention (yet) from the core
> > developers, I would think that there are still some issues which need
> > to be ironed out.  For example , what is the value of window-system
> > variable if you have both a window frame and a non-window frame open
> > at the same time (I haven't looked, so I don't know how this issue has
> > been resolved, but there could be other issues like it).
> 
> The window-system variable is frame-local in the multi-tty branch.
> Actually, I think this is the most important change on Lisp level;
> multi-tty support is otherwise mostly transparent to Lisp code.

Indeed.  

Still, one problem with that variable is that it is no longer safe to
base other (global) settings on the value of that variable.  I think
some defcustoms test this variable to select the default setting.

But I suppose it works ok in practice.

> Of course, the Lisp-level display/frame initialization code has
> changed quite a bit, and a few libraries (first and foremost
> server.el) have been enhanced for multi-tty support.
> 
> > Also, is the documentation on the multi-tty branch updated to reflect
> > changes in interfaces etc. (where it matters).
> 
> I think it matters surprisingly little.  Most of the things I changed
> are (unfortunately) :-) undocumented.  

That is good.

>                                        That said, a few nodes in the
> Emacs manuals need to be updated to reflect the changes.

Have you identified the sections of the emacs and elisp
manuals that need to be changed?

> 
> I think it would be useful if Emacs had display-local variables, and a
> display type that is accessible from Lisp code.  The Elisp manual will
> have to be updated when (if) these features are implemented.

That sounds useful, especially with multi-tty support.

Richard -- is this something we should add?

> I agree that the next release should be from the current HEAD,
> without multi-tty.
> 
> -- 
> Károly
> 
> 

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

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    > I think it would be useful if Emacs had display-local variables, and a
    > display type that is accessible from Lisp code.  The Elisp manual will
    > have to be updated when (if) these features are implemented.

    That sounds useful, especially with multi-tty support.

    Richard -- is this something we should add?

If it is necessary, we could add it with the multi-tty support.
However, if we can do without it, let's do without it.  These would
surely not be used very often.  It could be a feature not worth the
effort it costs.

When would you use it?

Re: It is time for a feature freeze (it is NOW or never).

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > I think it would be useful if Emacs had display-local variables, and a
>     > display type that is accessible from Lisp code.  The Elisp manual will
>     > have to be updated when (if) these features are implemented.
> 
>     That sounds useful, especially with multi-tty support.
> 
>     Richard -- is this something we should add?
> 
> If it is necessary, we could add it with the multi-tty support.
> However, if we can do without it, let's do without it.  These would
> surely not be used very often.  It could be a feature not worth the
> effort it costs.
> 
> When would you use it?

I like to have a menu-bar on a window system, but don't like it on
a terminal.  Maybe a display-local variable could do that.

There could also be a need for different keymaps to co-exist.

Some modes may also initialize things differently based on the display
type, e.g. depending on whether images are supported or not.

-- 
Kim F. Storm  http://www.cua.dk

Re: It is time for a feature freeze (it is NOW or never).

[Lőrentey Károly]

Kim F. Storm <storm@cua.dk> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>>     > I think it would be useful if Emacs had display-local variables, and a
>>     > display type that is accessible from Lisp code.  The Elisp manual will
>>     > have to be updated when (if) these features are implemented.
>> 
>>     That sounds useful, especially with multi-tty support.
>> 
>>     Richard -- is this something we should add?
>> 
>> If it is necessary, we could add it with the multi-tty support.
>> However, if we can do without it, let's do without it.  These would
>> surely not be used very often.  It could be a feature not worth the
>> effort it costs.
>> 
>> When would you use it?
>
> I like to have a menu-bar on a window system, but don't like it on
> a terminal.  Maybe a display-local variable could do that.
>
> There could also be a need for different keymaps to co-exist.

There are a few special display-local variables even in the current
Emacs CVS trunk:

	File: elisp,  Node: Multiple Displays
        [...]
	   A few Lisp variables are "terminal-local"; that is, they have a
	separate binding for each terminal.  The binding in effect at any time
	is the one for the terminal that the currently selected frame belongs
	to.  These variables include `default-minibuffer-frame',
	`defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
	are always terminal-local, and can never be buffer-local (*note
	Buffer-Local Variables::) or frame-local.

(The implementation involves calculating offsets into struct kboard,
and other such fun; see defvar_kboard in lread.c and the DEFVAR_KBOARD
macro.)

My other proposal, making a primitive Lisp type for displays would
greatly simplify a few things, for example implementing support for
two separate Emacs displays on the same device.  I know that sounds
like a stupid thing to do, but I (and judging from the bug reports,
others) frequently want to run more than one separate emacsclient tty
sessions on the same terminal.  (Think classical UNIX shell-centric
vi-style: you start editing a file by `emacsclient foo', remember
something, so you press C-z to get back to the shell.  A few commands
later you need to make a quick edit in another file, so naturally you
type `emacsclient bar', only to find that it fails because Lisp code
can not currently distinguish between two separate displays on the
same device.  It's annoying.)

> Some modes may also initialize things differently based on the display
> type, e.g. depending on whether images are supported or not.

I think that is not a good idea to do in new Lisp code, as the same
buffer may later be displayed on another device, possibly even
simultaneously.

-- 
Károly

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    I like to have a menu-bar on a window system, but don't like it on
    a terminal.  Maybe a display-local variable could do that.

It would be just as easy to do this job with frame-local variables
(i.e. frame parameters), and they already exist.

    There could also be a need for different keymaps to co-exist.

I don't want to add a feature like this just because maybe
someone could use it sometimes.  Emacs is already quite complex;
let's not add more complexity to its basic mechanisms
unless that is really important.

    Some modes may also initialize things differently based on the display
    type, e.g. depending on whether images are supported or not.

On the contrary-- when the same Emacs can display on both ttys and
graphic displays, it is clearly better to set up the buffer in a way
that can work ok on both kinds of displays.

Re: It is time for a feature freeze (it is NOW or never).

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I like to have a menu-bar on a window system, but don't like it on
>     a terminal.  Maybe a display-local variable could do that.
> 
> It would be just as easy to do this job with frame-local variables
> (i.e. frame parameters), and they already exist.

I don't see how.  After all, we are not talking about the
_possibility_ of having a menu-bar or not (that's trivial), but about
the default for creation of new frames.  And as far as I can tell,
you can't set different defaults for different displays.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: It is time for a feature freeze (it is NOW or never).

[Richard Stallman]

    I don't see how.  After all, we are not talking about the
    _possibility_ of having a menu-bar or not (that's trivial), but about
    the default for creation of new frames.

I guess I don't understand your idea--I don't see how display-local
variables would have anything to do with this.

Re: It is time for a feature freeze (it is NOW or never).

[Lőrentey Károly]

[Resend to list]
Kim F. Storm <storm@cua.dk> writes:
> Lőrentey Károly writes:
>> The multi-tty branch changes some internal interfaces which break
>> non-UN*X ports of Emacs.  The changes are not complex at all, but I
>> can not fix the broken ports without help from Mac/Windows/DOS gurus.
>> Because of this, the multi-tty branch is certainly not yet ready for
>> merging.
>
> Do you know that the ports are broken with your changes (have you made
> the changes to those ports?), or do you just suspect they are broken
> because you haven't been able to test your changes.

I am positive they are broken, and won't even compile.  I did not even
attempt to update them while working, because the branch was initially
very unstable (source reorganization, variable renamings, second
thoughts etc.), and it would have been impossible to keep the ports
that I can not compile in shape.  I decided to update them all in one
go, after the base code stabilized a bit.  The branch is quite stable
now, so I think it is time for me to begin that update.

> I usually manage to change this sort of thing (primarily textual,
> rather than functional changes) on the W32/DOS/MAC ports even though I
> don't use (or even compile on) them myself.
>
> I just make the changes (very carefully), commit my changes, and then
> leave it to the maintainers of those ports to verify my changes.  So
> far, this procedure hasn't caused much trouble.

I am planning to do exactly that. :-)

>> > Since it probably hasn't received much attention (yet) from the core
>> > developers, I would think that there are still some issues which need
>> > to be ironed out.  For example , what is the value of window-system
>> > variable if you have both a window frame and a non-window frame open
>> > at the same time (I haven't looked, so I don't know how this issue has
>> > been resolved, but there could be other issues like it).
>> 
>> The window-system variable is frame-local in the multi-tty branch.
>> Actually, I think this is the most important change on Lisp level;
>> multi-tty support is otherwise mostly transparent to Lisp code.
>
> Indeed.  
>
> Still, one problem with that variable is that it is no longer safe to
> base other (global) settings on the value of that variable.  I think
> some defcustoms test this variable to select the default setting.
>
> But I suppose it works ok in practice.

Yes; in theory, Elisp packages that refer to window-system need to be
updated for multi-tty support, but I found that in practice most of
them work fine without any changes.  Emacs behaves the same way as it
used to until the user actually creates simultaneous tty and X frames,
so the degradation (if any) is graceful.

>>                                        That said, a few nodes in the
>> Emacs manuals need to be updated to reflect the changes.
>
> Have you identified the sections of the emacs and elisp
> manuals that need to be changed?

Not yet.  I will leaf through the manuals sometime and take notes.

-- 
Károly