RE: Release update

[Drew Adams]

> Also, what about bug #970?  I don't think we can release Emacs that
> messes up the tty display like that.

If we're reminding about specific bugs and talking about possible release, the
following two bugs are very long-standing. They are regressions specific to
Emacs 23.

#117 -

* Fringe (on first frame only), when no-fringe was specified.

* Tool bar, when no-tool-bar was specified.

* Duplicate and contradictory frame parameters.

* Frames not redisplayed until manual C-l. Frame goes blank
  when another frame or window-mgr window is dragged over it
  or otherwise obscures it - and frame stays blank until C-l.

#1562 aka #119 -

* modify-frame-parameters, given a `font' parameter argument ending
  with "-iso8859-1" changes the `font' frame parameter to a font
  name that ends with "-fontset-auto1" (where `1' seems to be an
  index of the number of such calls, so the second uses `auto2'...).

In both cases, I sent code to reproduce the problem.

Those bugs are, to me, quite major - they (esp. #117) make Emacs 23 unusable for
me, sad to say. And there are of course other open bugs.

Another noticeable problem is the time it takes Emacs to start up. I know that
people have tried to improve this, but for me this startup time has not changed,
as of this build:

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-12-19 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'

Whether I use my own setup of a standalone minibuffer frame and one other,
principal frame or I use emacs -Q, the startup time is about the same. And
that's true whether I start by editing a file or Dired or just start with
*scratch*.

With my own setup, it takes on average 15-20 seconds for the initial frame to
appear, and another 10 seconds for my two-frame setup to finish. emacs -Q takes
15-20 seconds on average for the frame to appear. The command I use is this:
runemacs.exe -Q --debug-init. This is on a 1-year-old laptop with 2G RAM and
pretty good processors.

The startup time is variable, for some reason. Sometimes it is much less (as if
something were cached), sometimes it is a little more. Usually it is about 15-20
sec.

To compare: for my two-frame setup, Emacs 22.3 takes about 4 sec total, and
Emacs 22.3 -Q takes less than a second. (These are all wall-clock durations.)

Personally, the long startup time does not prevent me from using Emacs 23. The
bugs do.

I don't know whether this kind of performance and these kinds of bugs are normal
for a pretest. Perhaps pretesting will lead to fixes. But I hope Emacs 23 will
not be released with these problems.