Next release

Next release

[Nick Roberts]

Apart from a massive commit for org-mode, development has pretty much died off
on the EMACS_22_BASE branch.  Unless a security release is needed, I hope that
the next release, no matter how long it takes, comes from the trunk as that's
where most people (including myself) appear to be putting most bug-fixes now.
In this respect even billing a release from EMACS_22_BASE as a bug-fix release
can only create a bad impression.

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

Re: Next release

[Jason Rumney]

Nick Roberts wrote:
> Apart from a massive commit for org-mode, development has pretty much died off
> on the EMACS_22_BASE branch.  Unless a security release is needed, I hope that
> the next release, no matter how long it takes, comes from the trunk as that's
> where most people (including myself) appear to be putting most bug-fixes now.
> In this respect even billing a release from EMACS_22_BASE as a bug-fix release
> can only create a bad impression.
>   

If bugs are present in EMACS_22_BASE, they should be fixed there. Why 
would releasing 22.3 create a bad impression, especially if Emacs 23 
ends up taking 5 years or more again?

Re: Next release

[Nick Roberts]

 > If bugs are present in EMACS_22_BASE, they should be fixed there. 

They should but the reality is that they aren't.  It's more work to commit
changes to two separate branches and there's the complication of the
automatic/manual merging process.  Since there might not even be a release from
EMACS_22_BASE, I suspect people make a value judgement on their time.

 >                                                                    Why 
 > would releasing 22.3 create a bad impression, especially if Emacs 23 
 > ends up taking 5 years or more again?

It was the same with 21.3.  It looks like there has been less development on
Emacs than is actually the case and, in some ways, at the time of the release,
the trunk will be less buggy.

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

Re: Next release

[Jason Rumney]

Nick Roberts wrote:
>  > If bugs are present in EMACS_22_BASE, they should be fixed there. 
>
> They should but the reality is that they aren't.  It's more work to commit
> changes to two separate branches

So just commit them to the EMACS_22_BASE branch, and let the automated 
merge take care of them.  If the code has diverged enough to upset the 
automated merge, then it probably isn't worth the effort of fixing in 
Emacs 22 unless the bug is serious, but for most bugs the merge should 
take care of things.

Re: Next release

[Glenn Morris]

Nick Roberts wrote:

> Apart from a massive commit for org-mode, development has pretty
> much died off on the EMACS_22_BASE branch. Unless a security release
> is needed, I hope that the next release, no matter how long it
> takes, comes from the trunk as that's where most people (including
> myself) appear to be putting most bug-fixes now. In this respect
> even billing a release from EMACS_22_BASE as a bug-fix release can
> only create a bad impression.

I haven't installed anything on EMACS_22_BASE since 22.2, because I
hope 23.1 will be released soon enough to make 22.3 unnecessary. But I
will install things on EMACS_22_BASE if there is going to be, or is
likely to be, a 22.3 release.

Is there an official answer?

Re: Next release

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Nick Roberts wrote:
>
>> Apart from a massive commit for org-mode, development has pretty
>> much died off on the EMACS_22_BASE branch. Unless a security release
>> is needed, I hope that the next release, no matter how long it
>> takes, comes from the trunk as that's where most people (including
>> myself) appear to be putting most bug-fixes now. In this respect
>> even billing a release from EMACS_22_BASE as a bug-fix release can
>> only create a bad impression.
>
> I haven't installed anything on EMACS_22_BASE since 22.2, because I
> hope 23.1 will be released soon enough to make 22.3 unnecessary.

Not realistic.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Next release

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Nick Roberts wrote:
>
>> Apart from a massive commit for org-mode, development has pretty
>> much died off on the EMACS_22_BASE branch. Unless a security release
>> is needed, I hope that the next release, no matter how long it
>> takes, comes from the trunk as that's where most people (including
>> myself) appear to be putting most bug-fixes now. In this respect
>> even billing a release from EMACS_22_BASE as a bug-fix release can
>> only create a bad impression.
>
> I haven't installed anything on EMACS_22_BASE since 22.2, because I
> hope 23.1 will be released soon enough to make 22.3 unnecessary. But I
> will install things on EMACS_22_BASE if there is going to be, or is
> likely to be, a 22.3 release.
>
> Is there an official answer?

If all goes well, the Emacs 23 freeze will begin sometime in late June,
depending on how long Handa's font-backend branch and (hopefully) ECB
take to merge into the trunk.  From that point, I'm hoping for around
six months of testing until the 23.1 release.  With this time frame, I
don't think we will release 22.3 , unless a security hole appears that
we need to fix.

In other words, go ahead and check in minor fixed to the branch if you
like, but it's not necessary.  Major fixes definitely should *not* go
into the branch, since there will be no time to do extensive testing if
a security release is needed.

Re: Next release

[Glenn Morris]

Chong Yidong wrote:

> If all goes well, the Emacs 23 freeze will begin sometime in late June,

Great - I was hoping for something like this.

Re: Next release

[CHENG Gao]

*On Thu, 01 May 2008 16:30:35 -0400
* Also sprach Chong Yidong <cyd@stupidchicken.com>:

> If all goes well, the Emacs 23 freeze will begin sometime in late June,
> depending on how long Handa's font-backend branch and (hopefully) ECB
> take to merge into the trunk.  From that point, I'm hoping for around
> six months of testing until the 23.1 release.  With this time frame, I
> don't think we will release 22.3 , unless a security hole appears that
> we need to fix.
Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
this freeze? Since Carbon port is dead, if Cocoa not merged, there will
be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
10.5).

emacs-app is now an *official?* branch at Savannah and it builds and
works. And building with freetype fails and I reported this.

My build (I am using it to post this) is done as below:

,----
| ./configure --with-ns --without-x --enable-ns-app --prefix=/usr/local --without-freetype
| make -j4 bootstrap
| sudo make install
`----

Hope this is of some help.

CG

Re: Next release

[Bob]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Fri, May 2, 2008 at 12:48 AM, CHENG Gao <chenggao@gmail.com> wrote:

> *On Thu, 01 May 2008 16:30:35 -0400
> * Also sprach Chong Yidong <cyd@stupidchicken.com>:
>
> > If all goes well, the Emacs 23 freeze will begin sometime in late June,
> > depending on how long Handa's font-backend branch and (hopefully) ECB
> > take to merge into the trunk.  From that point, I'm hoping for around
> > six months of testing until the 23.1 release.  With this time frame, I
> > don't think we will release 22.3 , unless a security hole appears that
> > we need to fix.
> Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
> this freeze? Since Carbon port is dead, if Cocoa not merged, there will
> be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
> 10.5).


I got the trunk to compile on Mac OS X 10.4 using X, gtk, and freetype just
a few weeks ago (I did have to manually edit the Makefiles but it was not
too hard and I'm sure the configure could be fixed).  I see no reason it
won't work on 10.5 (which I will be switching to soon).  I really would like
to continue using the X backend since it gives me "focus follows mouse"
between X programs (and thus emacs frames), among other reasons.  Are there
plans to discontinue support for emacs using X and Mac OS X?

Bob

[-- Attachment #2: Type: text/html, Size: 1790 bytes --]

Re: Next release

[Richard M Stallman]

    Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
    this freeze? Since Carbon port is dead, if Cocoa not merged, there will
    be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
    10.5).

I seem to recall that the Cocoa port also works with GNUstep.
Is that correct?

Re: Next release

[CHENG Gao]

*On Sat, 03 May 2008 04:09:13 -0400
* Also sprach Richard M Stallman <rms@gnu.org>:

>     Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
>     this freeze? Since Carbon port is dead, if Cocoa not merged, there will
>     be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
>     10.5).
>
> I seem to recall that the Cocoa port also works with GNUstep.
> Is that correct?
Sure as said in its home site (http://emacs-app.sf.net):

,----
| NeXT/OpenStep Emacs for GNUstep and OS X
| 
| This is a port of the latest GNU Emacs source to the OpenStep (or
| NeXTstep) APIs, as implemented by Cocoa on OS X as well as the GNUstep
| open source project. 
`----

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 03 May 2008 17:22:40 +0800, CHENG Gao <chenggao@gmail.com> said:

> *On Sat, 03 May 2008 04:09:13 -0400
> * Also sprach Richard M Stallman <rms@gnu.org>:

>> Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
>> this freeze? Since Carbon port is dead, if Cocoa not merged, there will
>> be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
>> 10.5).
>> 
>> I seem to recall that the Cocoa port also works with GNUstep.
>> Is that correct?
> Sure as said in its home site (http://emacs-app.sf.net):

> ,----
> | NeXT/OpenStep Emacs for GNUstep and OS X
> | 
> | This is a port of the latest GNU Emacs source to the OpenStep (or
> | NeXTstep) APIs, as implemented by Cocoa on OS X as well as the GNUstep
> | open source project. 
> `----

GNUstep is currently one of CANNOT_DUMP platforms, and we have to make
sure if Emacs 23 works on such platforms.  Especially, preloading of
term/*-win.el, which was introduced by multi-tty, might cause some
problem on such platforms if it was changed by necessity.  Otherwise,
the preloading was actually unnecessary for multi-tty and it was
slipped into the unrelated multi-tty merger.

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

Re: Next release

[Stefan Monnier]

>>> Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk for
>>> this freeze? Since Carbon port is dead, if Cocoa not merged, there will
>>> be no support of MacOSX 10.5 in trunk (IIRC trunk cannot build with X on
>>> 10.5).
>>> 
>>> I seem to recall that the Cocoa port also works with GNUstep.
>>> Is that correct?
>> Sure as said in its home site (http://emacs-app.sf.net):

>> ,----
>> | NeXT/OpenStep Emacs for GNUstep and OS X
>> | 
>> | This is a port of the latest GNU Emacs source to the OpenStep (or
>> | NeXTstep) APIs, as implemented by Cocoa on OS X as well as the GNUstep
>> | open source project. 
>> `----

> GNUstep is currently one of CANNOT_DUMP platforms, and we have to make
> sure if Emacs 23 works on such platforms.  Especially, preloading of
> term/*-win.el, which was introduced by multi-tty, might cause some
> problem on such platforms if it was changed by necessity.  Otherwise,
> the preloading was actually unnecessary for multi-tty and it was
> slipped into the unrelated multi-tty merger.

I haven't been able to run the GNUstep version yet myself (it compiles
by crashes at the very first call to ObjC code), but supposedly someone
did get it to run on a Debian machine (mine's also Debian, for what
it's worth).

This said, we need to figure out how to do the dump for GNUstep in any
case.  As for the multi-tty preloading of win-*, I don't think it's
a problem for CANNOT_DUMP: IIUC the reason for this change is that those
win-* files prefer to be loaded "early" (e.g. before the .emacs file).


        Stefan

Re: Next release

[Glenn Morris]

Stefan Monnier wrote:

> This said, we need to figure out how to do the dump for GNUstep in any
> case.  As for the multi-tty preloading of win-*, I don't think it's
> a problem for CANNOT_DUMP: IIUC the reason for this change is that those
> win-* files prefer to be loaded "early" (e.g. before the .emacs file).

I know nothing about this, but just in case it's been overlooked, some
CANNOT_DUMP patches were submitted in March.

Patches for CANNOT_DUMP on 23.0.60
http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00015.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00010.html

Re: Next release

[Stefan Monnier]

>> This said, we need to figure out how to do the dump for GNUstep in any
>> case.  As for the multi-tty preloading of win-*, I don't think it's
>> a problem for CANNOT_DUMP: IIUC the reason for this change is that those
>> win-* files prefer to be loaded "early" (e.g. before the .emacs file).

> I know nothing about this, but just in case it's been overlooked, some
> CANNOT_DUMP patches were submitted in March.

> Patches for CANNOT_DUMP on 23.0.60
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00015.html
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-03/msg00010.html

Yes, they're still in http://emacsbugs.donarmstrong.com/emacs waiting
for someont to take care of them.


        Stefan

Re: Next release

[Richard M Stallman]

    > GNUstep is currently one of CANNOT_DUMP platforms,

Reloading everything at each start is a nuisance,
so can someone fix dumping with GNUstep?

Re: Next release

[Richard M Stallman]

    > I seem to recall that the Cocoa port also works with GNUstep.
    > Is that correct?
    Sure as said in its home site (http://emacs-app.sf.net):

So we should get it into Emacs 23.

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 05 May 2008 01:48:44 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> Then that would be the solution to the problem that the X11 build
>> does not bootstrap on Darwin.

> Doesn't it?  I have missed the corresponding discussion, sorry.  Is
> there some detailed info about it somewhere?

This one.

http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg02165.html

One of the messages in this thread also mentioned that:

>>>>> On Fri, 02 May 2008 14:48:26 +0800, CHENG Gao <chenggao@gmail.com> said:

> Is it planned to merge Cocoa port (emacs-app.sf.net) into the trunk
> for this freeze? Since Carbon port is dead, if Cocoa not merged,
> there will be no support of MacOSX 10.5 in trunk (IIRC trunk cannot
> build with X on 10.5).


>>>>> On Mon, 05 May 2008 01:48:44 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> If delaying the load of x-win.el resolves this problem, then maybe
> it's a good solution.  It would be good to try and figure out what's
> the root cause of the problem, tho, of course.

>> It would also reduce the required STATIC_HEAP_SIZE in sheap.c for
>> Cygwin.

> Does preloading x-win.el make a large difference here?  If so, does
> anybody know why?

I guess .el requires more resources in preloading than .elc.  I think
it's a good idea not to preload unnecessary .el at this stage.

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

Problems preloading x-win.el (was: Next release)

[Stefan Monnier]

>>> Then that would be the solution to the problem that the X11 build
>>> does not bootstrap on Darwin.
>> Doesn't it?  I have missed the corresponding discussion, sorry.  Is
>> there some detailed info about it somewhere?

> This one.
> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg02165.html

I must be missing something: this message seems to give the solution
(i.e. "increase the room for load commands").

>> If delaying the load of x-win.el resolves this problem, then maybe
>> it's a good solution.  It would be good to try and figure out what's
>> the root cause of the problem, tho, of course.
>>> It would also reduce the required STATIC_HEAP_SIZE in sheap.c for
>>> Cygwin.
>> Does preloading x-win.el make a large difference here?  If so, does
>> anybody know why?

Maybe because x-win.el causes a lot of memory allocation?

> I guess .el requires more resources in preloading than .elc.

No, the two kinds of files are pretty much identical.  But maybe
x-win.el for some reason requires a lot of resources.

> I think it's a good idea not to preload unnecessary .el at this stage.

But if x-win.el requires a lot of resources, than not preloading it will
just move those resources around, it won't actually solve the
corresponding problem.  The only way to solve the problem would be to
either not load x-win.el at all (obviously not an option if you use
X11), or to try and figure out why x-win.el uses up so much memory.


        Stefan

Re: Problems preloading x-win.el (was: Next release)

[Dan Nicolaescu]

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

  > >>> Then that would be the solution to the problem that the X11 build
  > >>> does not bootstrap on Darwin.
  > >> Doesn't it?  I have missed the corresponding discussion, sorry.  Is
  > >> there some detailed info about it somewhere?
  > 
  > > This one.
  > > http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg02165.html
  > 
  > I must be missing something: this message seems to give the solution
  > (i.e. "increase the room for load commands").
  > 
  > >> If delaying the load of x-win.el resolves this problem, then maybe
  > >> it's a good solution.  It would be good to try and figure out what's
  > >> the root cause of the problem, tho, of course.
  > >>> It would also reduce the required STATIC_HEAP_SIZE in sheap.c for
  > >>> Cygwin.
  > >> Does preloading x-win.el make a large difference here?  If so, does
  > >> anybody know why?
  > 
  > Maybe because x-win.el causes a lot of memory allocation?

Is there any evidence of that?
"pure bytes used" on GNU/Linux when preloading term/x-win:
1209573 pure bytes used

when not preloading term/x-win:
1194741 pure bytes used

~16KB does not seem excessive.

Re: Problems preloading x-win.el

[Stefan Monnier]

>> >>> Then that would be the solution to the problem that the X11 build
>> >>> does not bootstrap on Darwin.
>> >> Doesn't it?  I have missed the corresponding discussion, sorry.  Is
>> >> there some detailed info about it somewhere?
>> 
>> > This one.
>> > http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg02165.html
>> 
>> I must be missing something: this message seems to give the solution
>> (i.e. "increase the room for load commands").
>> 
>> >> If delaying the load of x-win.el resolves this problem, then maybe
>> >> it's a good solution.  It would be good to try and figure out what's
>> >> the root cause of the problem, tho, of course.
>> >>> It would also reduce the required STATIC_HEAP_SIZE in sheap.c for
>> >>> Cygwin.
>> >> Does preloading x-win.el make a large difference here?  If so, does
>> >> anybody know why?
>> 
>> Maybe because x-win.el causes a lot of memory allocation?

> Is there any evidence of that?

No.


        Stefan

Re: Problems preloading x-win.el (was: Next release)

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 23 May 2008 16:18:39 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>>> Then that would be the solution to the problem that the X11 build
>>>> does not bootstrap on Darwin.
>>> Doesn't it?  I have missed the corresponding discussion, sorry.
>>> Is there some detailed info about it somewhere?

>> This one.
>> http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg02165.html

> I must be missing something: this message seems to give the solution
> (i.e. "increase the room for load commands").

The room was sufficient for the final dump even with preloading
x-win.elc.  Another dump to create bootstrap-emacs needed some extra
room but that could be avoided by not preloading x-win.el at this
stage.

>> I guess .el requires more resources in preloading than .elc.

> No, the two kinds of files are pretty much identical.  But maybe
> x-win.el for some reason requires a lot of resources.

I think they are quite different in allocation of code.  The former
allocates it as (mostly) cons cells, but the latter does it as byte
codes in the pure storage.  This difference would also affect the
sizes/numbers of spaces that have been requested to the system.

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

Re: Next release

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Glenn Morris <rgm@gnu.org> writes:
  > 
  > > Nick Roberts wrote:
  > >
  > > I haven't installed anything on EMACS_22_BASE since 22.2, because I
  > > hope 23.1 will be released soon enough to make 22.3 unnecessary. But I
  > > will install things on EMACS_22_BASE if there is going to be, or is
  > > likely to be, a 22.3 release.
  > >
  > > Is there an official answer?
  > 
  > If all goes well, the Emacs 23 freeze will begin sometime in late June,
  > depending on how long Handa's font-backend branch and (hopefully) ECB
  > take to merge into the trunk.  From that point, I'm hoping for around
  > six months of testing until the 23.1 release.  With this time frame, I
  > don't think we will release 22.3 , unless a security hole appears that
  > we need to fix.
  > 
  > In other words, go ahead and check in minor fixed to the branch if you
  > like, but it's not necessary.  Major fixes definitely should *not* go
                                                           ^^^^^^^^^^^^^^   
  > into the branch, since there will be no time to do extensive testing if
  > a security release is needed.

Does the above apply to all platforms?  Looking at src/ChangeLog there
are pages after pages of changes for the Mac, which don't look at all
like minor changes...

Re: Next release

[Jason Rumney]

Dan Nicolaescu wrote:
> Does the above apply to all platforms?  Looking at src/ChangeLog there
> are pages after pages of changes for the Mac, which don't look at all
> like minor changes...
>   

I don't think major changes for the Mac can be avoided, as my 
understanding is that Apple have dropped support (or announced they will 
for the next OS X release) for the graphics API we were using.

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 02 May 2008 06:31:34 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> Looking at src/ChangeLog there are pages after pages of changes for
> the Mac, which don't look at all like minor changes...

You're seeing the changes that have been accumulated for a
relatively long period because I restricted the changes between
22.1 and 22.2 to strict bug fixes.

Don't worry.  They don't break the Carbon port of Emacs 22 unlike
the minimally-tested multi-tty support you've done for the Carbon
port of Emacs 23.

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

Re: Next release

[Dan Nicolaescu]

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

  > >>>>> On Fri, 02 May 2008 06:31:34 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > Looking at src/ChangeLog there are pages after pages of changes for
  > > the Mac, which don't look at all like minor changes...
  > 
  > You're seeing the changes that have been accumulated for a
  > relatively long period because I restricted the changes between
  > 22.1 and 22.2 to strict bug fixes.

Yidong said "minor changes", not "strict bug fixes".


  > Don't worry.  They don't break the Carbon port of Emacs 22 unlike
  > the minimally-tested multi-tty support you've done for the Carbon
  > port of Emacs 23.

Thank you, this is a great way to thank someone that is not a user of
Carbon, does not have experience on that platform, but volunteered his
time to get it from not even compiling to the point where it can start
up. And that was the only effort since to get this working.  Again,
thank you very much for your appreciation.

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 02 May 2008 09:10:43 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> >>>>> On Fri, 02 May 2008 06:31:34 -0700, Dan Nicolaescu
>> <dann@ics.uci.edu> said:
>> 
>> > Looking at src/ChangeLog there are pages after pages of changes
>> for > the Mac, which don't look at all like minor changes...
>> 
>> You're seeing the changes that have been accumulated for a
>> relatively long period because I restricted the changes between
>> 22.1 and 22.2 to strict bug fixes.

Correction: not "between 22.1 and 22.2", but "between 22.0.90 and
22.2".  That's why the recent changes include those as of
before-merge-multi-tty-to-trunk.

> Yidong said "minor changes", not "strict bug fixes".

Because Emacs 22.1 was the first official major version for Mac OS X,
and the Carbon port was relatively young compared with other ports, we
had to be really careful about its stability.  That's why I put such
restriction, i.e., "strict bug fixes" rather than "minor changes",
myself on that period.

On the other hand, some progress (*1) has been made locally between
22.0.90 and 22.2.  As the Carbon port is likely to become Emacs 22
only, such progress has no appropriate destination other than
EMACS_22_BASE.

*1: http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00249.html

>> Don't worry.  They don't break the Carbon port of Emacs 22 unlike
>> the minimally-tested multi-tty support you've done for the Carbon
>> port of Emacs 23.

> Thank you, this is a great way to thank someone that is not a user
> of Carbon, does not have experience on that platform, but
> volunteered his time to get it from not even compiling to the point
> where it can start up. And that was the only effort since to get
> this working.  Again, thank you very much for your appreciation.

What was the motivation to do that then?  If you were familiar with
either Carbon or multi-tty, I could understand that.  Did you want to
pretend as if multi-tty was ready to get merged to the trunk?

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

Re: Next release

[Stefan Monnier]

> 22.0.90 and 22.2.  As the Carbon port is likely to become Emacs 22
> only, such progress has no appropriate destination other than
> EMACS_22_BASE.

How much work would be needed to make the Carbon code on the trunk
work well?  IIUC it only suffers from 1 problem which is the timely
handling of input.  It looks like a fairly small problem: maybe not easy
to fix, but if someone who knows the code were to take it seriously, it
should not require much work.  That would be very welcome and we could
then keep the Carbon port (probably complemented by your AppKit changes)
for Emacs-23.


        Stefan

Re: Next release

[Dan Nicolaescu]

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

  > >>>>> On Fri, 02 May 2008 09:10:43 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
  > >> >>>>> On Fri, 02 May 2008 06:31:34 -0700, Dan Nicolaescu
  > >> <dann@ics.uci.edu> said:
  > >> 
  > >> > Looking at src/ChangeLog there are pages after pages of changes
  > >> for > the Mac, which don't look at all like minor changes...
  > >> 
  > >> You're seeing the changes that have been accumulated for a
  > >> relatively long period because I restricted the changes between
  > >> 22.1 and 22.2 to strict bug fixes.
  > 
  > Correction: not "between 22.1 and 22.2", but "between 22.0.90 and
  > 22.2".  That's why the recent changes include those as of
  > before-merge-multi-tty-to-trunk.

Which is fundamentally different from the stated policy for the branch,
unless the mac platform got a special dispense.  If it did, it wasn't
posted explicitly on the list.

Yidong, does this work OK with the goals for the 22 branch?  
Allow development for the Mac, and only minor bug fixes for the other
platforms?  
Will a quick security fix release work in this scenario?


  > >> Don't worry.  They don't break the Carbon port of Emacs 22 unlike
  > >> the minimally-tested multi-tty support you've done for the Carbon
  > >> port of Emacs 23.
  > 
  > > Thank you, this is a great way to thank someone that is not a user
  > > of Carbon, does not have experience on that platform, but
  > > volunteered his time to get it from not even compiling to the point
  > > where it can start up. And that was the only effort since to get
  > > this working.  Again, thank you very much for your appreciation.
  > 
  > What was the motivation to do that then?  If you were familiar with
  > either Carbon or multi-tty, I could understand that.  Did you want to
  > pretend as if multi-tty was ready to get merged to the trunk?

Thanks again, questioning a gift and bashing the giver is indeed the
ideal way to treat the giver.  No good deed should ever go unpunished!

Congratulation on the great strategy employed here: it is so much better
to spend time to periodically whine on the mailing list about the
multi-tty merge, and now, out of the blue, abuse _again_ the only person
that actually did _anything_ to get Carbon working with multi-tty, when
it would be would be much less effort to actually fix the minor bugs
left.  Outstanding job!

This excellent attitude, good manners towards contributors and great
interest in the multi-tty work is even more admirable when seen in
context:


   From: YAMAMOTO Mitsuharu
   Subject: Re: Reordering etc/NEWS
   Date: Thu, 10 May 2007 19:28:55 +0900

>>>>> On Thu, 10 May 2007 08:24:57 +0100, Jason Rumney <address@hidden> said:

> That is extremely optimistic. Has anyone even tried the multitty branch
> on Mac and Windows yet? I know there is still significant work required
> for emacs-unicode-2 on Windows, though it at least basically works.

As for Mac, I'm planning to quit the development of the Carbon port
for Emacs 23, as the Cocoa/GNUstep port will replace it on that
version.  So, personally I don't care if multitty is incompatible with
the current Carbon code as long as it is not for Emacs 22.x (x > 1).

                                     YAMAMOTO Mitsuharu

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 03 May 2008 17:56:03 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> Yidong, does this work OK with the goals for the 22 branch?  Allow
> development for the Mac, and only minor bug fixes for the other
> platforms?  Will a quick security fix release work in this scenario?

Of course, these changes have been made in a way that the branch is
always ready to a sudden release.

>> What was the motivation to do that then?  If you were familiar with
>> either Carbon or multi-tty, I could understand that.  Did you want
>> to pretend as if multi-tty was ready to get merged to the trunk?

> Thanks again, questioning a gift and bashing the giver is indeed the
> ideal way to treat the giver.  No good deed should ever go
> unpunished!

It seemed to me that you just superficially removed compilation
errors, with minimal test (you said that it was minimally-tested).
Just like you literally replaced `next-line' with `forward-line' to
remove byte-compiler warnings without considering their meanings.

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

Re: Next release

[Stefan Monnier]

>> Thanks again, questioning a gift and bashing the giver is indeed the
>> ideal way to treat the giver.  No good deed should ever go
>> unpunished!

> It seemed to me that you just superficially removed compilation
> errors, with minimal test (you said that it was minimally-tested).

That sounds like a good thing.  When I took care of some of the
multi-tty merge, I fixed some of the Carbon port to the best of my
knowledge without even trying to compile the code.  IIRC Dan then fixed
my rough-draft enough that the code compiled and didn't crash right
away.  We're still waiting for someone to actually finish the merge
w.r.t the Carbon port.  This can only be done by someone who understand
enough of the Carbon port.  You seem like our best hope here.

I do not know why you seem to be so offended by the multi-tty code.
Maybe if you explained it, we could work it through.  Its being
non-working and without anybody willing to fix it is basically the main
reason why we started to look into the Emacs.app code.  It is a pity to
throw away this code.

> Just like you literally replaced `next-line' with `forward-line' to
> remove byte-compiler warnings without considering their meanings.

Everybody makes mistakes.  Now, can we go back to improving Emacs
instead of bitching at each other?


        Stefan

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 03 May 2008 21:40:38 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> We're still waiting for someone to actually finish the merge w.r.t
> the Carbon port.  This can only be done by someone who understand
> enough of the Carbon port.  You seem like our best hope here.

As I said in
http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00419.html, I
don't have a plan to develop the Carbon (not Carbon+AppKit) port of
Emacs 23.

> I do not know why you seem to be so offended by the multi-tty code.
> Maybe if you explained it, we could work it through.  Its being
> non-working and without anybody willing to fix it is basically the
> main reason why we started to look into the Emacs.app code.  It is a
> pity to throw away this code.

The breakage of the Carbon port is definitely NOT a reason.  Well, one
of the reasons would be that I found some changes that are totally
unrelated to multi-tty.  Another reason is no clear explanation given
about preloading term/*-win.

>> Just like you literally replaced `next-line' with `forward-line' to
>> remove byte-compiler warnings without considering their meanings.

> Everybody makes mistakes.  Now, can we go back to improving Emacs
> instead of bitching at each other?

Yes, of course.  But some level of carefulness would be expected for
those who have a write access, I think.

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

Re: Next release

[Stefan Monnier]

>> We're still waiting for someone to actually finish the merge w.r.t
>> the Carbon port.  This can only be done by someone who understand
>> enough of the Carbon port.  You seem like our best hope here.

> As I said in
> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00419.html, I
> don't have a plan to develop the Carbon (not Carbon+AppKit) port of
> Emacs 23.

By "Carbon" I mean both Carbon and Carbon+AppKit, since I don't know the
actual difference between the two.

>> I do not know why you seem to be so offended by the multi-tty code.
>> Maybe if you explained it, we could work it through.  Its being
>> non-working and without anybody willing to fix it is basically the
>> main reason why we started to look into the Emacs.app code.  It is a
>> pity to throw away this code.

> The breakage of the Carbon port is definitely NOT a reason.  Well, one
> of the reasons would be that I found some changes that are totally
> unrelated to multi-tty.

Yes, the merge had its share of problems, but the fact that Lorentey
wasn't around made it worse.  But I don't know what unrelated change you
may be thinking about.

> Another reason is no clear explanation given
> about preloading term/*-win.

There was some explanation given via email at some point.  IIRC, the
issue is that the multi-tty feature introduced the possibility that an
Emacs session that starts using X11 (resp tty) may later be asked to
open a tty (resp X11) terminal.  But loading *-win.el after Emacs has
been running for a while apparently introduced problems, so the code was
changed to eagerly load all the term/*-win.el files that may be used
later on during the session.  At that point, since x-win.el is loaded
regardless of whether we only use X11 or tty, it is a perfect candidate
for preloading.
Why is that a problem?


        Stefan

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 03 May 2008 23:21:37 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> By "Carbon" I mean both Carbon and Carbon+AppKit, since I don't know
> the actual difference between the two.

They differs in GUI implementations.  The former uses mactoolbox.c for
that.  As this file is already in the EMACS_22_BASE branch, you can
guess the functionalities the AppKit counterpart provides by browsing
the title of each page in that file.

>> The breakage of the Carbon port is definitely NOT a reason.  Well,
>> one of the reasons would be that I found some changes that are
>> totally unrelated to multi-tty.

> Yes, the merge had its share of problems, but the fact that Lorentey
> wasn't around made it worse.  But I don't know what unrelated change
> you may be thinking about.

Of course I can give concrete examples, which are Mac-specific.  But
the point is: I found some, then how can I assure there's no other?
Rather, I would doubt the quality and reliability of the whole code
from such kinds of changes.

>> Another reason is no clear explanation given about preloading
>> term/*-win.

> There was some explanation given via email at some point.

To the list?  Then I missed the one.  I'm sorry about that.

> IIRC, the issue is that the multi-tty feature introduced the
> possibility that an Emacs session that starts using X11 (resp tty)
> may later be asked to open a tty (resp X11) terminal.  But loading
> *-win.el after Emacs has been running for a while apparently
> introduced problems, so the code was changed to eagerly load all the
> term/*-win.el files that may be used later on during the session.
> At that point, since x-win.el is loaded regardless of whether we
> only use X11 or tty, it is a perfect candidate for preloading.  Why
> is that a problem?

Thanks for the explanation.  So, they are not necessary to be
preloaded at the bootstrap stage?

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

Re: Next release

[Stefan Monnier]

>> IIRC, the issue is that the multi-tty feature introduced the
>> possibility that an Emacs session that starts using X11 (resp tty)
>> may later be asked to open a tty (resp X11) terminal.  But loading
>> *-win.el after Emacs has been running for a while apparently
>> introduced problems, so the code was changed to eagerly load all the
>> term/*-win.el files that may be used later on during the session.
>> At that point, since x-win.el is loaded regardless of whether we
>> only use X11 or tty, it is a perfect candidate for preloading.  Why
>> is that a problem?

> Thanks for the explanation.  So, they are not necessary to be
> preloaded at the bootstrap stage?

IIUC, they do not have to be preloaded, no.


        Stefan

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 11:52:25 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> So, they are not necessary to be preloaded at the bootstrap stage?

> IIUC, they do not have to be preloaded, no.

Then that would be the solution to the problem that the X11 build does
not bootstrap on Darwin.  It would also reduce the required
STATIC_HEAP_SIZE in sheap.c for Cygwin.

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

Re: Next release

[Stefan Monnier]

> Then that would be the solution to the problem that the X11 build does
> not bootstrap on Darwin.

Doesn't it?  I have missed the corresponding discussion, sorry.
Is there some detailed info about it somewhere?

If delaying the load of x-win.el resolves this problem, then maybe
it's a good solution.  It would be good to try and figure out what's the
root cause of the problem, tho, of course.

> It would also reduce the required STATIC_HEAP_SIZE in sheap.c
> for Cygwin.

Does preloading x-win.el make a large difference here?
If so, does anybody know why?


        Stefan

Re: Next release

[Chong Yidong]

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

>> Yes, the merge had its share of problems, but the fact that Lorentey
>> wasn't around made it worse.  But I don't know what unrelated change
>> you may be thinking about.
>
> Of course I can give concrete examples, which are Mac-specific.  But
> the point is: I found some, then how can I assure there's no other?
> Rather, I would doubt the quality and reliability of the whole code
> from such kinds of changes.

Would you prefer that other Emacs developers avoid touching the
Carbon-specifics part of the Emacs tree, even if compilation breaks, so
that you are the only one responsible for changes to that part of the
code?  That might be an acceptable arrangement, if that is what you
want.

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 17:35:18 -0400, Chong Yidong <cyd@stupidchicken.com> said:

>>> Yes, the merge had its share of problems, but the fact that
>>> Lorentey wasn't around made it worse.  But I don't know what
>>> unrelated change you may be thinking about.
>> 
>> Of course I can give concrete examples, which are Mac-specific.
>> But the point is: I found some, then how can I assure there's no
>> other?  Rather, I would doubt the quality and reliability of the
>> whole code from such kinds of changes.

> Would you prefer that other Emacs developers avoid touching the
> Carbon-specifics part of the Emacs tree, even if compilation breaks,
> so that you are the only one responsible for changes to that part of
> the code?  That might be an acceptable arrangement, if that is what
> you want.

I'd appreciate changes from experts on other area, of course.
I've been keeping the similarity of the Carbon-specific code not
only for consistency with other platforms but also those who are
familiar with other platforms but not with Carbon can easily find
and touch the part for changes that are common to several
platforms.
(BTW, that's one difference from the Cocoa/GNUstep port.)

The problem in the multi-tty case is, some changes that are
totally unrelated to multi-tty were mixed into the multi-tty
merger.  If it was intentional, that's unfair.  Otherwise, I
doubt if the author did that job with enough understanding of the
code.

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

Re: Next release

[Stefan Monnier]

> The problem in the multi-tty case is, some changes that are
> totally unrelated to multi-tty were mixed into the multi-tty
> merger.  If it was intentional, that's unfair.  Otherwise, I
> doubt if the author did that job with enough understanding of the
> code.

The multi-tty code was first written as a kind of "fork" of Emacs.
It included various changes that were just preferences of the author
(e.g. the way the emacsclient interface was changed).

Part of the integration of the code involved splitting the patch into
the multi-tty functionality and the "user preferences".  This was not
done very well, AFAICT and several changes were applied later on to
revert some parts of the multi-tty merge (I am personally familiar with
the emacsclient/server.el part of it).

The multi-tty change is not different from any other: if there's a part
which you find dubious, please bring it up here so we can fix it
(either reverting that part of the change, or adding comments to better
explain it, ...).

Notice that it's not too late to revert parts of the multi-tty merge.


        Stefan

Re: Next release

[Juanma Barranquero]

On Mon, May 5, 2008 at 2:56 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>  The multi-tty change is not different from any other: if there's a part
>  which you find dubious, please bring it up here so we can fix it
>  (either reverting that part of the change, or adding comments to better
>  explain it, ...).

From admin/FOR-RELEASE, Windows section:

** libxpm is loaded too soon
Since the multi-tty merge, libxpm is loaded before the init files because
of changes in toolbar setup; that prevents using image-library-alist in
.emacs to select the desired XPM library.  Reported by Takashi Hiromatsu.
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02191.html

 Juanma

Re: Next release

[Stefan Monnier]

>> The multi-tty change is not different from any other: if there's a part
>> which you find dubious, please bring it up here so we can fix it
>> (either reverting that part of the change, or adding comments to better
>> explain it, ...).

>> From admin/FOR-RELEASE, Windows section:

> ** libxpm is loaded too soon
> Since the multi-tty merge, libxpm is loaded before the init files because
> of changes in toolbar setup; that prevents using image-library-alist in
> .emacs to select the desired XPM library.  Reported by Takashi Hiromatsu.
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02191.html

I've just installed a change in tool-bar.el which delays the call to
find-image.  Instead of being called in tool-bar-setup, it's now called
when looking up the tool-bar keymap.  This may also allow the toolbar
to use different icons on different displays (e.g. some color, some b&w)
in the same Emacs instance.

This probably won't fix the problem right away (after all, the toolbar
is displayed before reading the .emacs, so the tool-bar filter will be
triggered (and will call find-image) before the .emacs is read).  But we
may then just change `tool-bar-make-keymap' so it just returns nil if
after-init-time is nil.  I'm curious: if Emacs-22 on W32 only loads the
image libraries after the .emacs, does that mean that it doesn't display
the tool-bar while loading the .emacs?

If this works, we may then move the call to tool-bar-setup to an even
earlier place (e.g. frame-initialize or even earlier), so we can get rid
of the tool-bar-setup variable.


        Stefan

Re: Next release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 07 May 2008 14:28:34 -0400
> Cc: emacs-devel@gnu.org
> 
> I'm curious: if Emacs-22 on W32 only loads the
> image libraries after the .emacs, does that mean that it doesn't display
> the tool-bar while loading the .emacs?

It depends, I guess: if .emacs includes something that could cause
redisplay (e.g., it puts flyspell on some mode-hook, and later desktop
actually turns that mode on when restoring your session), then we
cannot avoid displaying the tool bar, I think.

Re: Next release

[Stefan Monnier]

>> I'm curious: if Emacs-22 on W32 only loads the image libraries after
>> the .emacs, does that mean that it doesn't display the tool-bar while
>> loading the .emacs?

> It depends, I guess: if .emacs includes something that could cause
> redisplay (e.g., it puts flyspell on some mode-hook, and later desktop
> actually turns that mode on when restoring your session), then we
> cannot avoid displaying the tool bar, I think.

On X11, when I start `emacs', the first thing that happens is to open
a frame, with the toolbar, and only after that is the .emacs
file loaded.

So how can Emacs-22 on W32 avoid loading the image libraries before
loading the .emacs, other than by not displaying the tool-bar, and if so
how does it avoid displaying the tool-bar before loading the .emacs?


        Stefan

Re: Next release

[Jason Rumney]

Stefan Monnier wrote:
> On X11, when I start `emacs', the first thing that happens is to open
> a frame, with the toolbar, and only after that is the .emacs
> file loaded.
>
> So how can Emacs-22 on W32 avoid loading the image libraries before
> loading the .emacs, other than by not displaying the tool-bar, and if so
> how does it avoid displaying the tool-bar before loading the .emacs?
>   

I don't know how, but when Emacs starts on Windows, the frame is blank. 
When messages start appearing as .emacs is loaded, the mode-line and 
echo area are drawn, but the rest of the frame, including toolbar, is 
only drawn after .emacs has been loaded.

I don't think this is done especially for the toolbar images, Emacs has 
always started like this on Windows.

Re: Next release

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Stefan Monnier wrote:
>> On X11, when I start `emacs', the first thing that happens is to open
>> a frame, with the toolbar, and only after that is the .emacs
>> file loaded.
>>
>> So how can Emacs-22 on W32 avoid loading the image libraries before
>> loading the .emacs, other than by not displaying the tool-bar, and if so
>> how does it avoid displaying the tool-bar before loading the .emacs?
>>   
>
> I don't know how, but when Emacs starts on Windows, the frame is
> blank. When messages start appearing as .emacs is loaded, the
> mode-line and echo area are drawn, but the rest of the frame,
> including toolbar, is only drawn after .emacs has been loaded.
>
> I don't think this is done especially for the toolbar images, Emacs
> has always started like this on Windows.

It would be worthwhile to start mapping Emacs usually only after .emacs
has been processed and/or the command line processed.  That way you can
select fonts, geometry, toolbar or not and so on in .emacs and have
emacs start right away without resizing or flicker.  Or you can even use
a special .emacs file (now that we have multitty) that does not even
open a frame but waits for Emacsclient invocations.  It would not just
be useful on X.

-- 
David Kastrup

Re: Next release

[David Reitter]

On 8 May 2008, at 09:32, David Kastrup wrote:
>
> It would be worthwhile to start mapping Emacs usually only  
> after .emacs
> has been processed and/or the command line processed.  That way you  
> can
> select fonts, geometry, toolbar or not and so on in .emacs and have
> emacs start right away without resizing or flicker.

Indeed. The way we got around this in Aquamacs was to create the frame  
with (visibility . nil), process .emacs (etc.) and only make it  
visible after frame-notice-user-settings, as in the patch below.  That  
way, the frame is already be present and may be manipulated directly  
in .emacs, without any annoying visual effects.




Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.436.2.16
diff -c -r1.436.2.16 startup.el
*** lisp/startup.el	6 Mar 2008 00:08:01 -0000	1.436.2.16
--- lisp/startup.el	30 Apr 2008 16:33:28 -0000
***************
*** 473,479 ****
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame)))))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
--- 473,482 ----
   		  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
   				    term)
   		      (setq default-frame-background-mode 'light)))
! 		(frame-set-background-mode (selected-frame))))
!
! 	  ;; time to make the frame visible (Aquamacs)
! 	  (make-frame-visible))

   	;; Now we know the user's default font, so add it to the menu.
   	(if (fboundp 'font-menu-add-default)
***************
*** 756,764 ****

     (run-hooks 'before-init-hook)

!   ;; Under X Window, this creates the X frame and deletes the  
terminal frame.
!   (when (fboundp 'frame-initialize)
!     (frame-initialize))

     ;; Turn off blinking cursor if so specified in X resources.  This  
is here
     ;; only because all other settings of no-blinking-cursor are here.
--- 759,774 ----

     (run-hooks 'before-init-hook)

!   ;; the initial frame is hidden in Aquamacs
!   (let ((initial-frame-alist (append '((visibility . nil)
! 				       (left . 99)) ;; bug #166 workaround
! 				       initial-frame-alist)))
!     ;; Under X Window, this creates the X frame and deletes the  
terminal frame.
!     (when (fboundp 'frame-initialize)
!       (frame-initialize)
!       ;; allow frame-notice-user-settings to override
!       (setq frame-initial-geometry-arguments
! 	    (delete '(visibility . nil) (delete '(left . 99) frame-initial- 
geometry-arguments)))))

     ;; Turn off blinking cursor if so specified in X resources.  This  
is here
     ;; only because all other settings of no-blinking-cursor are here.
***************
*** 2153,2158 ****
--- 2128,2136 ----
         (when (fboundp 'frame-notice-user-settings)
   	(frame-notice-user-settings))

+       ;; time to make the frame visible (Aquamacs)
+       (make-frame-visible)
+
         ;; If there are no switches to process, we might as well
         ;; run this hook now, and there may be some need to do it
         ;; before doing any output.

Re: Next release

[Jan Djärv]

David Reitter skrev:
> On 8 May 2008, at 09:32, David Kastrup wrote:
>>
>> It would be worthwhile to start mapping Emacs usually only after .emacs
>> has been processed and/or the command line processed.  That way you can
>> select fonts, geometry, toolbar or not and so on in .emacs and have
>> emacs start right away without resizing or flicker.
> 
> Indeed. The way we got around this in Aquamacs was to create the frame 
> with (visibility . nil), process .emacs (etc.) and only make it visible 
> after frame-notice-user-settings, as in the patch below.  That way, the 
> frame is already be present and may be manipulated directly in .emacs, 
> without any annoying visual effects.
> 

How do you handle --debug-init?

	Jan D.

Re: Next release

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
> How do you handle --debug-init?

Seems like that would just map the frame earlier...

-Miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: Next release

[Richard M Stallman]

    How do you handle --debug-init?

I suggest mapping the frame beforehand, as now,
if --debug-init is specified.

Re: Next release

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     How do you handle --debug-init?
>
> I suggest mapping the frame beforehand, as now,
> if --debug-init is specified.

This could turn display related startup bugs into Heisenbugs (disappear
when trying to debug them).  I'd go that way only if we find that just
putting the debug-init output onto either startup splash or stderr
really don't do the trick.  It would be my guess that an option like
--debug-init would mostly be given on a console, so stderr might
actually work pretty well for a traceback or something.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Next release

[David Reitter]

On 10 May 2008, at 21:30, David Kastrup wrote:
>>
>> I suggest mapping the frame beforehand, as now,
>> if --debug-init is specified.
>
> This could turn display related startup bugs into Heisenbugs  
> (disappear
> when trying to debug them).

Yes, but these would likely be bugs in Emacs and not the user's code,  
such as bug #166.  They should be rather rare!
Frame operations ought to work on visible and invisible frames alike,  
correct?

>  I'd go that way only if we find that just
> putting the debug-init output onto either startup splash or stderr
> really don't do the trick.

Is that instead of entering the standard debugger?
Is the non-debuggable visibility issue going to cause enough problems  
to merit this sort of workaround?

>  It would be my guess that an option like
> --debug-init would mostly be given on a console, so stderr might
> actually work pretty well for a traceback or something.

The normal debugger allows interaction and inspection of variables  
etc.  That's nice to have.

Re: Next release

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> It would be worthwhile to start mapping Emacs usually only after .emacs
> has been processed and/or the command line processed.  That way you can
> select fonts, geometry, toolbar or not and so on in .emacs and have
> emacs start right away without resizing or flicker.

I would _love_ it if Emacs did this, but IIRC, Gerd tried that, and got
shot down because it was incompatible with wacky code in people's .emacs
files.

Maybe now's the time to revisit the issue though.

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Re: Next release

[Jason Rumney]

Miles Bader wrote:
> David Kastrup <dak@gnu.org> writes:
>   
>> It would be worthwhile to start mapping Emacs usually only after .emacs
>> has been processed and/or the command line processed.  That way you can
>> select fonts, geometry, toolbar or not and so on in .emacs and have
>> emacs start right away without resizing or flicker.
>>     
>
> I would _love_ it if Emacs did this, but IIRC, Gerd tried that, and got
> shot down because it was incompatible with wacky code in people's .emacs
> files.
>
> Maybe now's the time to revisit the issue though.
>   

Another problem with it is that it would appear that nothing is 
happening as Emacs is starting. Displaying a temporary frame with the 
splash screen might help, but that brings us back to the original 
problem on Windows of wanting to override which image libraries are 
loaded (to avoid Cygwin ones for example, as they cause Emacs to crash).

Re: Next release

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> Another problem with it is that it would appear that nothing is
> happening as Emacs is starting.

Is that really such a problem though?  Other apps seem to do that quite
often.

Anyway, a specialized "Starting Emacs..." splash screen could use a simple
hard-wired image and skip all the grot associated with emacs image
loading.  [Indeed, just embed the image as a pixmap in the C code...]

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: Next release

[David Kastrup]

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

> Jason Rumney <jasonr@gnu.org> writes:
>> Another problem with it is that it would appear that nothing is
>> happening as Emacs is starting.
>
> Is that really such a problem though?  Other apps seem to do that quite
> often.

GTK+ even has a special "startup notification" thing which gives a
visual feedback "something is happening" so that you don't click starter
buttons several times.

Anyway, until Emacs is mapped, startup messages could appear on stderr.
That is no help when started without a terminal, but would be reasonable
in many cases, including Emacs in a tty.

-- 
David Kastrup

Re: Next release

[Stephen J. Turnbull]

David Kastrup writes:

 > Anyway, until Emacs is mapped, startup messages could appear on stderr.
 > That is no help when started without a terminal, but would be reasonable
 > in many cases, including Emacs in a tty.

FWIW, XEmacs users complain a lot about startup messages on stderr in
the rare cases they appear.  Of course those are usually things like
"loading some-standard-library ..." messages which leak out due to
some snafu, and that is different from "Wow, what a big .emacs you
have!  It'll take be a second to process this..."  Still, it may be
indicative of one segment of opinion.

Re: Next release

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Anyway, until Emacs is mapped, startup messages could appear on stderr.
>  > That is no help when started without a terminal, but would be reasonable
>  > in many cases, including Emacs in a tty.
>
> FWIW, XEmacs users complain a lot about startup messages on stderr in
> the rare cases they appear.

I'd propose hitting them with a clue stick, but of course that's
strenuous.

So thanks for that data point.  It would appear the pseudo-splash screen
with a single-line message area in a fixed small font would be the
safest best till now.

And stderr for ttys, I guess.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Next release

[Stefan Monnier]

> So thanks for that data point.  It would appear the pseudo-splash screen
> with a single-line message area in a fixed small font would be the
> safest best till now.

Yes, and as mentioned, we already have 90% of that, except the
"single-line message area" happens to be a "normal sized and featured
frame".  Basically what we're discussing here is to replace the "small
readjustment that looks weird" by a "big readjustment which looks like
something people can relate to".

> And stderr for ttys, I guess.

Why?  Nobody's ever complained about the current behavior on ttys.


        Stefan

Re: Next release

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Basically what we're discussing here is to replace the "small
> readjustment that looks weird" by a "big readjustment which looks like
> something people can relate to".

Indeed, though I'd hope there would be an option to simply not map at
all -- one of my big objections with the silly frame-resizing-dance is
that it seems to make emacs startup take significantly more time
[emacs handling of default face size changes is.... not efficient...]

However even with a "splash frame", since it seems to be specifically
font _changing__ that's dog slow, it may in fact be faster to create two
frames with initially correct fonts than making one frame that changes
fonts.

-Miles

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

Re: Next release

[Tassilo Horn]

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

>> And stderr for ttys, I guess.
>
> Why?  Nobody's ever complained about the current behavior on ttys.

At least the emacs startup with my .emacs looks weird on ttys as well.
First I have a normal frame with tmm menu bar and mode-line and messages
are printed in the echo area.  That's before my .emacs is processed.

Then, shortly after starting to load my .emacs, the mode-line vanishes
and messages appear somewhere in the middle of the frame.  At last the
window is split in two side-by-side windows, the left one showing
*scratch* and the right one my org agenda.

It seems to be the line

  (org-agenda-list)

in my .emacs which causes the troubles, but I guess any function call
which involves splitting of windows will do.

Bye,
Tassilo

Re: Next release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  Miles Bader <miles@gnu.org>,  lekktu@gmail.com,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Jason Rumney <jasonr@gnu.org>
> Date: Thu, 08 May 2008 20:52:11 -0400
> 
> > So thanks for that data point.  It would appear the pseudo-splash screen
> > with a single-line message area in a fixed small font would be the
> > safest best till now.
> 
> Yes, and as mentioned, we already have 90% of that, except the
> "single-line message area" happens to be a "normal sized and featured
> frame".  Basically what we're discussing here is to replace the "small
> readjustment that looks weird" by a "big readjustment which looks like
> something people can relate to".

Could we use some of the code that displays tooltips?

Re: Next release

[Jason Rumney]

Miles Bader wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>   
>> Another problem with it is that it would appear that nothing is
>> happening as Emacs is starting.
>>     
>
> Is that really such a problem though?  Other apps seem to do that quite
> often.
>
> Anyway, a specialized "Starting Emacs..." splash screen could use a simple
> hard-wired image and skip all the grot associated with emacs image
> loading.  [Indeed, just embed the image as a pixmap in the C code...]
>   

Yes, PPM is an option, as that does not require external libraries. I 
think the problem with displaying nothing is that loading .emacs could 
take a very long time if the user has a lot of code in there (comparable 
to Gimp loading all its plugins). It is probably a good idea to also 
display messages in the splash screen so the user can see progress 
happening (including any "el is newer than elc" and "XXX is obsolete" 
messages that come up).

Re: Next release

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Miles Bader wrote:
>> Jason Rumney <jasonr@gnu.org> writes:
>>   
>>> Another problem with it is that it would appear that nothing is
>>> happening as Emacs is starting.
>>>     
>>
>> Is that really such a problem though?  Other apps seem to do that quite
>> often.
>>
>> Anyway, a specialized "Starting Emacs..." splash screen could use a simple
>> hard-wired image and skip all the grot associated with emacs image
>> loading.  [Indeed, just embed the image as a pixmap in the C code...]
>>   
>
> Yes, PPM is an option, as that does not require external libraries. I
> think the problem with displaying nothing is that loading .emacs could
> take a very long time if the user has a lot of code in there
> (comparable to Gimp loading all its plugins). It is probably a good
> idea to also display messages in the splash screen so the user can see
> progress happening (including any "el is newer than elc" and "XXX is
> obsolete" messages that come up).

A single line area with a fixed font may be sufficient for that.

-- 
David Kastrup

Re: Next release

[Eli Zaretskii]

> From: Miles Bader <miles.bader@necel.com>
> Cc: lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,
>         Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> Date: Thu, 08 May 2008 18:35:38 +0900
> 
> Jason Rumney <jasonr@gnu.org> writes:
> > Another problem with it is that it would appear that nothing is
> > happening as Emacs is starting.
> 
> Is that really such a problem though?

It would be for me: my .emacs processing tends to be very long, due to
large sessions loaded by desktop.

> Other apps seem to do that quite often.

Which is an annoying misfeature, IMO.  And most (all?) apps that do
this tend to load very quickly, since they don't need to load anything
as large as my desktop.

> Anyway, a specialized "Starting Emacs..." splash screen could use a simple
> hard-wired image and skip all the grot associated with emacs image
> loading.  [Indeed, just embed the image as a pixmap in the C code...]

That could be a good solution, I think.  We could even simply show a
simple text-only frame with an echo area showing the various messages,
to avoid the impression that nothing happens.

Re: Next release

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Miles Bader <miles.bader@necel.com>
>> Cc: lekktu@gmail.com, Eli Zaretskii <eliz@gnu.org>,
>>         Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>> Date: Thu, 08 May 2008 18:35:38 +0900
>> 
>> Jason Rumney <jasonr@gnu.org> writes:
>> > Another problem with it is that it would appear that nothing is
>> > happening as Emacs is starting.
>> 
>> Is that really such a problem though?
>
> It would be for me: my .emacs processing tends to be very long, due to
> large sessions loaded by desktop.

Desktop loading should be last in processing.  We could start it off by
mapping the screen explicitly.

-- 
David Kastrup

Re: Next release

[Juri Linkov]

>> Anyway, a specialized "Starting Emacs..." splash screen could use a simple
>> hard-wired image and skip all the grot associated with emacs image
>> loading.  [Indeed, just embed the image as a pixmap in the C code...]
>
> That could be a good solution, I think.  We could even simply show a
> simple text-only frame with an echo area showing the various messages,
> to avoid the impression that nothing happens.

Or better yet to show the *Messages* buffer with some fixed text
in its header line.

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

Re: Next release

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Miles Bader wrote:
>> David Kastrup <dak@gnu.org> writes:
>>   
>>> It would be worthwhile to start mapping Emacs usually only after .emacs
>>> has been processed and/or the command line processed.  That way you can
>>> select fonts, geometry, toolbar or not and so on in .emacs and have
>>> emacs start right away without resizing or flicker.
>>>     
>>
>> I would _love_ it if Emacs did this, but IIRC, Gerd tried that, and got
>> shot down because it was incompatible with wacky code in people's .emacs
>> files.
>>
>> Maybe now's the time to revisit the issue though.
>
> Another problem with it is that it would appear that nothing is
> happening as Emacs is starting.

Everybody else does that, too.  Possibly after doing something that
changes the mouse pointer to "busy".  Don't see a problem with that.

-- 
David Kastrup

Re: Next release

[Eli Zaretskii]

> From: Miles Bader <miles.bader@necel.com>
> Cc: Jason Rumney <jasonr@gnu.org>, lekktu@gmail.com,
>         Eli Zaretskii <eliz@gnu.org>,
>         Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> Date: Thu, 08 May 2008 18:06:45 +0900
> 
> David Kastrup <dak@gnu.org> writes:
> > It would be worthwhile to start mapping Emacs usually only after .emacs
> > has been processed and/or the command line processed.  That way you can
> > select fonts, geometry, toolbar or not and so on in .emacs and have
> > emacs start right away without resizing or flicker.
> 
> I would _love_ it if Emacs did this, but IIRC, Gerd tried that, and got
> shot down because it was incompatible with wacky code in people's .emacs
> files.

Yes, this was a source of considerable pain during Emacs 21.1
development, and is the reason for the horrible jumps through the
hoops with frame-notice-user-settings and its ilk.

Re: Next release

[Stefan Monnier]

>> It would be worthwhile to start mapping Emacs usually only after .emacs
>> has been processed and/or the command line processed.  That way you can
>> select fonts, geometry, toolbar or not and so on in .emacs and have
>> emacs start right away without resizing or flicker.

> I would _love_ it if Emacs did this, but IIRC, Gerd tried that, and
> got shot down because it was incompatible with wacky code in people's
> .emacs files.

My local changes include such a hack, which causes Emacs to start in
"batch-like" mode and only open the tty or X11 frame after loading the
.emacs.

I like it, but I'm not sure it's a good idea in general.
The suggestion to have a splash-like screen while loading the .emacs
might be a good idea and could be very simple: just change the startup
such that the frame created before reading the .emacs contains no
tool-bar, no menu, and may be of a smaller fixed size.


        Stefan

Re: Next release

[Juanma Barranquero]

On Thu, May 8, 2008 at 3:51 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>  My local changes include such a hack [...]

[After several such comments by you along the years] your local Emacs
is starting to reach some kind of mythical status in my mind...

 Juanma

Re: Next release

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I like it, but I'm not sure it's a good idea in general.

Why not?

The necessity of duplicating settings in the xrdb data base if you want
at avoid your initial frame resizing itself 10 times at startup is both
annoying and confusing.  Simply waiting a bit to map the frame seems
like quite a reasonable solution.

A splash screen, whether hardwired or a hacked emacs frame that avoids
the initial-settings issues would seem to take care of "users will get
worried" issues.

-Miles

-- 
Alliance, n. In international politics, the union of two thieves who have
their hands so deeply inserted in each other's pockets that they cannot
separately plunder a third.

Re: Next release

[Richard M Stallman]

    A splash screen, whether hardwired or a hacked emacs frame that avoids
    the initial-settings issues would seem to take care of "users will get
    worried" issues.

A special splash screen would address that issue.

It is useful that there is a real Emacs frame
during loading the init file.  You get to see progress
messages, and you also can use it in the case of an error
in the init file.

If messages from `message' get displayed in the splash screen,
and if error messages get displayed in a real Emacs frame if
the init file fails, than might be good enough.

Re: Next release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 07 May 2008 21:26:57 -0400
> 
> On X11, when I start `emacs', the first thing that happens is to open
> a frame, with the toolbar, and only after that is the .emacs
> file loaded.
> 
> So how can Emacs-22 on W32 avoid loading the image libraries before
> loading the .emacs, other than by not displaying the tool-bar, and if so
> how does it avoid displaying the tool-bar before loading the .emacs?

Like Jason, I don't have the detailed explanation why, but as a matter
of fact, when Emacs starts on Windows, it only shows the initial frame
with empty text area, and the menu bar.  The tool bar appears only
when the first time Emacs performs a full redisplay, e.g. if it asks
me whether to load a desktop file that is locked by another session.

AFAIR, the tool bar is handled by Emacs as a special kind of window,
which could explain why it isn't shown until redisplay.

As for why this is different from X11: what toolkit was used in the
version of Emacs you started above?  If that was GTK+, perhaps what
you see is something specific to GTK, which handles the tool bar in
some different way?  Can you try with other toolkits?

Re: Next release

[Stefan Monnier]

> As for why this is different from X11: what toolkit was used in the
> version of Emacs you started above?  If that was GTK+, perhaps what
> you see is something specific to GTK, which handles the tool bar in
> some different way?  Can you try with other toolkits?

Actually, I see the same under X11 (except that my .emacs causes
a redisplay at some point, which causes the toolbar to be drawn).
Thanks for helping me clear it up.


        Stefan

Re: Next release

[Juanma Barranquero]

On Wed, May 7, 2008 at 8:28 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>  I've just installed a change in tool-bar.el which delays the call to
>  find-image.  Instead of being called in tool-bar-setup, it's now called
>  when looking up the tool-bar keymap.

Thanks!

>  This probably won't fix the problem right away (after all, the toolbar
>  is displayed before reading the .emacs, so the tool-bar filter will be
>  triggered (and will call find-image) before the .emacs is read).

Funnily enough, it *does* fix it. With a simple .emacs with

;;; .emacs
(let ((xpm (assq 'xpm image-library-alist)))
	 (setcdr xpm (cons "my-xpm.dll" (cdr xpm))))
;;; end

I get this:

C:\test> runemacs
C:\test> listdlls emacs.exe | grep -i xpm
  0x20800000  0x7e000                   C:\emacs\libs\my-xpm.dll

C:\test> runemacs -q
C:\test> listdlls emacs.exe | grep -i xpm
  0x20800000  0x7e000                   C:\emacs\libs\libxpm.dll

>  I'm curious: if Emacs-22 on W32 only loads the
>  image libraries after the .emacs, does that mean that it doesn't display
>  the tool-bar while loading the .emacs?

Eli has answered that, but if you add

(message-box "Not yet finished")

to the end of .emacs, the tool bar is not visible until *after* you
dismiss the message.

 Juanma

Tool-bar changes (Was: Next release)

[Chong Yidong]

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

> I've just installed a change in tool-bar.el which delays the call to
> find-image.  Instead of being called in tool-bar-setup, it's now called
> when looking up the tool-bar keymap.  This may also allow the toolbar
> to use different icons on different displays (e.g. some color, some b&w)
> in the same Emacs instance.

This change did Something Bad to the tool-bar on i686-pc-linux-gnu, GTK+
Version 2.12.9.  Only the Cut, Paste, Customize, and Help icons are now
displayed on the tool-bar; the other images are missing.

I didn't, however, try bootstrapping, only `make recompile' followed by
`make' (should a bootstrap be necessary?).

2008-05-07  Stefan Monnier  <monnier@iro.umontreal.ca>

	* tool-bar.el: Choose images dynamically.
	(tool-bar-make-keymap, tool-bar-find-image): New function.
	(tool-bar-find-image-cache): New var.
	(tool-bar-local-item, tool-bar-local-item-from-menu):
	Don't select the image yet, do it later in tool-bar-make-keymap.

Re: Tool-bar changes

[Stefan Monnier]

>> I've just installed a change in tool-bar.el which delays the call to
>> find-image.  Instead of being called in tool-bar-setup, it's now called
>> when looking up the tool-bar keymap.  This may also allow the toolbar
>> to use different icons on different displays (e.g. some color, some b&w)
>> in the same Emacs instance.

> This change did Something Bad to the tool-bar on i686-pc-linux-gnu, GTK+
> Version 2.12.9.  Only the Cut, Paste, Customize, and Help icons are now
> displayed on the tool-bar; the other images are missing.

Hmm... I didn't notice any such problem here.  But admittedly, I haven't
tested it extensively.

> I didn't, however, try bootstrapping, only `make recompile' followed by
> `make' (should a bootstrap be necessary?).

That should be enough.


        Stefan

Re: Tool-bar changes

[Tassilo Horn]

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

>> I didn't, however, try bootstrapping, only `make recompile' followed
>> by `make' (should a bootstrap be necessary?).
>
> That should be enough.

Same here with make bootstrap.

Bye,
Tassilo

Re: Tool-bar changes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I've just installed a change in tool-bar.el which delays the call to
>> find-image.  Instead of being called in tool-bar-setup, it's now called
>> when looking up the tool-bar keymap.  This may also allow the toolbar
>> to use different icons on different displays (e.g. some color, some b&w)
>> in the same Emacs instance.
>
> This change did Something Bad to the tool-bar on i686-pc-linux-gnu, GTK+
> Version 2.12.9.  Only the Cut, Paste, Customize, and Help icons are now
> displayed on the tool-bar; the other images are missing.

The problem was the the use of plist-get and plist-put in
tool-bar-make-keymap failed to account for the format of menu-item
lists, which can contain an optional KEY-BINDING-DATA entry that screws
up the property list ordering.  I just checked in a fix.

Re: Tool-bar changes

[Stefan Monnier]

> The problem was the the use of plist-get and plist-put in
> tool-bar-make-keymap failed to account for the format of menu-item
> lists, which can contain an optional KEY-BINDING-DATA entry that screws
> up the property list ordering.  I just checked in a fix.

Thank you.  I wonder why it never hit me.... Oh yes now I remember:
I threw away this caching code in my own Emacs (I threw it out a long
time ago, i.e. when I added the where-is-internal reverse keymap cache,
since this made on-the-fly recomputation sufficiently fast for me to
make the cache unnecessary (or even harmful since it's not correctly
maaintained: when the cache key-sequence becomes invalid, it is
correclty thrown out, but if a key-sequence becomes later available,
the cache will prevent it from being discovered)).


        Stefan

Re: Tool-bar changes

[David Reitter]

On 13 May 2008, at 19:19, Stefan Monnier wrote:
> I threw away this caching code in my own Emacs (I threw it out a long
> time ago, i.e. when I added the where-is-internal reverse keymap  
> cache,
> since this made on-the-fly recomputation sufficiently fast for me to
> make the cache unnecessary (or even harmful since it's not correctly
> maaintained: when the cache key-sequence becomes invalid, it is
> correclty thrown out, but if a key-sequence becomes later available,
> the cache will prevent it from being discovered)).


Is there a way to trigger an update of the cache, or turn it off?

I think I may be seeing such a problem (in certain, unclear  
circumstances, :key-sequence nil works correctly when evaluating  
define-key manually, but not in my package that is loaded early) and  
thought I could try debugging this by turning off the caching.

Re: Tool-bar changes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Tue, 13 May 2008 14:19:29 -0400
> Cc: Tassilo Horn <thorn+news@fastmail.fm>,
> 	Reiner Steib <reinersteib+gmane@imap.cc>,
> 	Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org,
> 	"Sebastian P. Luque" <spluque@gmail.com>,
> 	225-done@emacsbugs.donarmstrong.com
> 
> Thank you.  I wonder why it never hit me.... Oh yes now I remember:
> I threw away this caching code in my own Emacs (I threw it out a long
> time ago, i.e. when I added the where-is-internal reverse keymap cache,
> since this made on-the-fly recomputation sufficiently fast for me to
> make the cache unnecessary

I really don't see how can an active Emacs maintainer afford using
such a deviant code base.  I think in the long run, this will hamper
your testing of both yours and others' code, like it did in this case.

Re: Tool-bar changes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> I've just installed a change in tool-bar.el which delays the call to
>>> find-image.  Instead of being called in tool-bar-setup, it's now called
>>> when looking up the tool-bar keymap.  This may also allow the toolbar
>>> to use different icons on different displays (e.g. some color, some b&w)
>>> in the same Emacs instance.
>>
>> This change did Something Bad to the tool-bar on i686-pc-linux-gnu, GTK+
>> Version 2.12.9.  Only the Cut, Paste, Customize, and Help icons are now
>> displayed on the tool-bar; the other images are missing.
>
> The problem was the the use of plist-get and plist-put in
> tool-bar-make-keymap failed to account for the format of menu-item
> lists, which can contain an optional KEY-BINDING-DATA entry that screws
> up the property list ordering.  I just checked in a fix.

There seems to be a further problem with your patch, somewhere in the
image caching code.  Here is how I am reproducing it:

1. M-x gnus
2. Open a group
3. q q [exit gnus]
4. M-x gnus
5. Open a group

I get an error.  What seems to be happening is that the contents of
tool-bar-find-image-cache are getting corrupted.  Do you see anything
like this happening?

Re: Tool-bar changes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> There seems to be a further problem with your patch, somewhere in the
> image caching code.  Here is how I am reproducing it:
>
> 1. M-x gnus
> 2. Open a group
> 3. q q [exit gnus]
> 4. M-x gnus
> 5. Open a group
>
> I get an error.  What seems to be happening is that the contents of
> tool-bar-find-image-cache are getting corrupted.

Here is a list of the value entries in tool-bar-find-image-cache:

((image :type xpm :file "/home/cyd/trunk/etc/images/gnus/toggle-subscription.xpm")
 (image :type xpm :file "/home/cyd/trunk/etc/images/describe.xpm")
 ("DEAD" . 19103923)
 ("DEAD" . 19103899)
 ("DEAD" . 19103875)
 ....

Looks like some of the lists in there have been garbage-collected.  This
is probably a GC bug.  Does the GC code know not to reap lists that are
stored in hash tables?

Re: Tool-bar changes

[Stefan Monnier]

>> There seems to be a further problem with your patch, somewhere in the
>> image caching code.  Here is how I am reproducing it:
>> 
>> 1. M-x gnus
>> 2. Open a group
>> 3. q q [exit gnus]
>> 4. M-x gnus
>> 5. Open a group
>> 
>> I get an error.  What seems to be happening is that the contents of
>> tool-bar-find-image-cache are getting corrupted.

> Here is a list of the value entries in tool-bar-find-image-cache:

> ((image :type xpm :file "/home/cyd/trunk/etc/images/gnus/toggle-subscription.xpm")
>  (image :type xpm :file "/home/cyd/trunk/etc/images/describe.xpm")
>  ("DEAD" . 19103923)
>  ("DEAD" . 19103899)
>  ("DEAD" . 19103875)
>  ....

> Looks like some of the lists in there have been garbage-collected.  This
> is probably a GC bug.  Does the GC code know not to reap lists that are
> stored in hash tables?

Hmm... I'll take a look at it.  The hash-table is marked as weak
specifically so that those can be GC'd (whether it's a good idea or
not, I don't know), but if they're GC'd then they should be removed from
the hash-table as well.


        Stefan

Re: Tool-bar changes

[Chong Yidong]

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

>> Looks like some of the lists in there have been garbage-collected.  This
>> is probably a GC bug.  Does the GC code know not to reap lists that are
>> stored in hash tables?
>
> Hmm... I'll take a look at it.  The hash-table is marked as weak
> specifically so that those can be GC'd (whether it's a good idea or
> not, I don't know), but if they're GC'd then they should be removed
> from the hash-table as well.

It appears that the C variable weak_hash_tables, which points to a
linked list of weak hash tables, is 0x0.  I added the following debug
code to fns.c:

*** trunk/src/fns.c.~1.443.~	2008-05-14 12:41:03.000000000 -0400
--- trunk/src/fns.c	2008-05-14 15:24:08.000000000 -0400
***************
*** 4770,4776 ****
       (table)
       Lisp_Object table;
  {
!   return check_hash_table (table)->weak;
  }
  
  
--- 4770,4792 ----
       (table)
       Lisp_Object table;
  {
!   Lisp_Object weak = check_hash_table (table)->weak;
!   struct Lisp_Hash_Table *hash = XHASH_TABLE (table);
!   if (!NILP (weak))
!     {
!       int found = 0;
!       struct Lisp_Hash_Table *h;
! 
!       for (h = weak_hash_tables; h; h = h->next_weak)
! 	{
! 	  if (h == hash)
! 	    found = 1;
! 	}
!       if (found == 0)
! 	abort();
!     }
! 
!   return weak;
  }
  

Then, doing M-: (hash-table-weakness tool-bar-find-image-cache) RET
leads to an abort, with the following backtrace:

#0  abort () at emacs.c:428
#1  0x081720b6 in Fhash_table_weakness (table=144383500) at fns.c:4786
#2  0x0816bea7 in Feval (form=147691741) at eval.c:2361
#3  0x0816c9cf in Ffuncall (nargs=2, args=0xbfc7ea50) at eval.c:3030
...

(gdb) p weak_hash_tables
$1 = (struct Lisp_Hash_Table *) 0x0
(gdb) f 1
#1  0x081720b6 in Fhash_table_weakness (table=144383500) at fns.c:4786
4786            abort();
(gdb) p hash
$2 = (struct Lisp_Hash_Table *) 0x89b1e08
(gdb) p hash->weak
$3 = 137839209
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0x8374268
"key-and-value"

I noticed that sweep_weak_hash_tables() removes empty weak hash tables
from the linked list pointed to by weak_hash_tables.  This may be
related to the bug.

Re: Tool-bar changes

[Chong Yidong]

Here's my explanation for the bug:

Each time Emacs starts up, main() calls init_fns(), which sets
weak_hash_tables to NULL.  This means that any weak hash tables that
were loaded into memory by temacs are orphaned, and can't be found by
sweep_weak_hash_tables.

So the solution is to make a new function, init_weak_hash_tables,
analogous to init_float etc., and call it from init_alloc_once.  The
following patch accomplishes this.  WDYT?


*** trunk/src/alloc.c.~1.439.~	2008-05-14 12:41:02.000000000 -0400
--- trunk/src/alloc.c	2008-05-14 16:40:48.000000000 -0400
***************
*** 6247,6252 ****
--- 6247,6253 ----
    init_marker ();
    init_float ();
    init_intervals ();
+   init_weak_hash_tables ();
  
  #ifdef REL_ALLOC
    malloc_hysteresis = 32;
*** trunk/src/fns.c.~1.443.~	2008-05-14 12:41:03.000000000 -0400
--- trunk/src/fns.c	2008-05-14 16:42:02.000000000 -0400
***************
*** 4257,4262 ****
--- 4257,4268 ----
  			   Weak Hash Tables
   ************************************************************************/
  
+ void
+ init_weak_hash_tables ()
+ {
+   weak_hash_tables = NULL;
+ }
+ 
  /* Sweep weak hash table H.  REMOVE_ENTRIES_P non-zero means remove
     entries from the table that don't survive the current GC.
     REMOVE_ENTRIES_P zero means mark entries that are in use.  Value is
***************
*** 5284,5290 ****
  void
  init_fns ()
  {
-   weak_hash_tables = NULL;
  }
  
  /* arch-tag: 787f8219-5b74-46bd-8469-7e1cc475fa31
--- 5290,5295 ----

Re: Tool-bar changes

[Stefan Monnier]

> Here's my explanation for the bug:
> Each time Emacs starts up, main() calls init_fns(), which sets
> weak_hash_tables to NULL.  This means that any weak hash tables that
> were loaded into memory by temacs are orphaned, and can't be found by
> sweep_weak_hash_tables.

> So the solution is to make a new function, init_weak_hash_tables,
> analogous to init_float etc., and call it from init_alloc_once.  The
> following patch accomplishes this.  WDYT?

Sounds right on the mark.
Thank you for tracking it down, I'm kind of swamped with other things
right now,


        Stefan

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 20:56:47 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> The problem in the multi-tty case is, some changes that are totally
>> unrelated to multi-tty were mixed into the multi-tty merger.  If it
>> was intentional, that's unfair.  Otherwise, I doubt if the author
>> did that job with enough understanding of the code.

> The multi-tty code was first written as a kind of "fork" of Emacs.
> It included various changes that were just preferences of the author
> (e.g. the way the emacsclient interface was changed).

I think the Mac-specific part was not a part of the multi-tty "fork".

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

Re: Next release

[Chong Yidong]

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

>> We're still waiting for someone to actually finish the merge w.r.t
>> the Carbon port.  This can only be done by someone who understand
>> enough of the Carbon port.  You seem like our best hope here.
>
> As I said in
> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00419.html, I
> don't have a plan to develop the Carbon (not Carbon+AppKit) port of
> Emacs 23.
>
>> I do not know why you seem to be so offended by the multi-tty code.
>> Maybe if you explained it, we could work it through.  Its being
>> non-working and without anybody willing to fix it is basically the
>> main reason why we started to look into the Emacs.app code.  It is a
>> pity to throw away this code.
>
> The breakage of the Carbon port is definitely NOT a reason.  Well, one
> of the reasons would be that I found some changes that are totally
> unrelated to multi-tty.  Another reason is no clear explanation given
> about preloading term/*-win.

Can you, or someone else, summarize the situation on Carbon and
multi-tty?

IIUC, the way things are right now is that multi-tty works on free
software platforms, but not on Carbon.  It was merged onto the trunk, in
such a way that the Carbon port does not possess multi-tty functionality
but at least still compiles.  I understand that you're unhappy about the
changes made to ensure that Carbon port compiles.  Would it be possible
to simply fix up these changes, and let this matter slide?

If, ultimately, no one is willing to work on getting multi-tty
functionality working for Carbon, we'll release Emacs 23 with multi-tty
functionality turned on for free software platforms (and whatever other
platforms people can get it working on).  So the work to "at least get
it compiling on Carbon" is a necessary step.

Re: Next release

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 04 May 2008 17:23:21 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> IIUC, the way things are right now is that multi-tty works on free
> software platforms, but not on Carbon.  It was merged onto the
> trunk, in such a way that the Carbon port does not possess multi-tty
> functionality but at least still compiles.

It could compile after the multi-tty merger but the resulting binary
became unbearably unresponsive.  I don't know if it possessed
multi-tty functionality.

> If, ultimately, no one is willing to work on getting multi-tty
> functionality working for Carbon, we'll release Emacs 23 with
> multi-tty functionality turned on for free software platforms (and
> whatever other platforms people can get it working on).  So the work
> to "at least get it compiling on Carbon" is a necessary step.

As I've been saying, if the Cocoa/GNUstep port becomes good enough, we
don't have to do anything about the Carbon(+AppKit) port of Emacs 23.
Maybe the maintainers can put some time schedule to judge if the
Cocoa/GNUstep port is good enough for the official Emacs 23?

I may develop the Carbon+AppKit port of Emacs 23 for my private use or
just for fun.  But the quality and efforts required for the official
distribution are quite different from those for the private use.  For
the latter, I can limit the OS version to the latest one, and I can
omit the features that I don't use.

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

Re: Next release

[Dan Nicolaescu]

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

  > >>>>> On Sat, 03 May 2008 17:56:03 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > Yidong, does this work OK with the goals for the 22 branch?  Allow
  > > development for the Mac, and only minor bug fixes for the other
  > > platforms?  Will a quick security fix release work in this scenario?
  > 
  > Of course, these changes have been made in a way that the branch is
  > always ready to a sudden release.

That is not the issue here, the issue is in the lines excessively
trimmed: do the stated rules for "only minor fixes" apply everywhere or
there are some exceptions.  And if there are exceptions, what are those
exceptions.

  > >> What was the motivation to do that then?  If you were familiar with
  > >> either Carbon or multi-tty, I could understand that.  Did you want
  > >> to pretend as if multi-tty was ready to get merged to the trunk?
  > 
  > > Thanks again, questioning a gift and bashing the giver is indeed the
  > > ideal way to treat the giver.  No good deed should ever go
  > > unpunished!
  > 
  > It seemed to me that you just superficially removed compilation
  > errors, with minimal test (you said that it was minimally-tested).
  > Just like you literally replaced `next-line' with `forward-line' to
  > remove byte-compiler warnings without considering their meanings.

Thank you yet again for your graciousness!  Again given statements like:

"As for Mac, I'm planning to quit the development of the Carbon port
for Emacs 23, as the Cocoa/GNUstep port will replace it on that
version.  So, personally I don't care if multitty is incompatible with
the current Carbon code as long as it is not for Emacs 22.x (x > 1)."

and the excellent job at whining, moaning and dissing the multi-tty
effort, coupled with no code/documentation or any other type of positive
contribution should be appreciated as a great upper hand that can be
used to disparage volunteer work by other people.  Marvelous!

Re: Next release

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 03 May 2008 19:06:50 -0700
> Cc: Glenn Morris <rgm@gnu.org>, Chong Yidong <cyd@stupidchicken.com>,
> 	Nick Roberts <nickrob@snap.net.nz>, emacs-devel@gnu.org
> 
>   > It seemed to me that you just superficially removed compilation
>   > errors, with minimal test (you said that it was minimally-tested).
>   > Just like you literally replaced `next-line' with `forward-line' to
>   > remove byte-compiler warnings without considering their meanings.
> 
> Thank you yet again for your graciousness!  Again given statements like:
> 
> "As for Mac, I'm planning to quit the development of the Carbon port
> for Emacs 23, as the Cocoa/GNUstep port will replace it on that
> version.  So, personally I don't care if multitty is incompatible with
> the current Carbon code as long as it is not for Emacs 22.x (x > 1)."
> 
> and the excellent job at whining, moaning and dissing the multi-tty
> effort, coupled with no code/documentation or any other type of positive
> contribution should be appreciated as a great upper hand that can be
> used to disparage volunteer work by other people.  Marvelous!

Dan, please stop this.  All that Mitsuharu asks for is higher level of
quality for the code committed to CVS.  I think it's a reasonable
request.

You seem to assert that when faced with changes which could
potentially break other platforms, there's only two possible
alternatives: either live with the breakage or don't commit the code
at all.  But in fact, there's a 3rd alternative: learn enough about
those other platforms to make the code right on them as well.  There's
even a 4th alternative: make the new code be conditionally compiled
only on platforms you understand and can test.  All of those are IMO
better than breakage.

So I don't understand why you reject such suggestions as ``whining''.
Certainly, being the one who works on the code imposes some
responsibility on you.

Re: Next release

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Sat, 03 May 2008 19:06:50 -0700
  > > Cc: Glenn Morris <rgm@gnu.org>, Chong Yidong <cyd@stupidchicken.com>,
  > > 	Nick Roberts <nickrob@snap.net.nz>, emacs-devel@gnu.org
  > > 
  > >   > It seemed to me that you just superficially removed compilation
  > >   > errors, with minimal test (you said that it was minimally-tested).
  > >   > Just like you literally replaced `next-line' with `forward-line' to
  > >   > remove byte-compiler warnings without considering their meanings.
  > > 
  > > Thank you yet again for your graciousness!  Again given statements like:
  > > 
  > > "As for Mac, I'm planning to quit the development of the Carbon port
  > > for Emacs 23, as the Cocoa/GNUstep port will replace it on that
  > > version.  So, personally I don't care if multitty is incompatible with
  > > the current Carbon code as long as it is not for Emacs 22.x (x > 1)."
  > > 
  > > and the excellent job at whining, moaning and dissing the multi-tty
  > > effort, coupled with no code/documentation or any other type of positive
  > > contribution should be appreciated as a great upper hand that can be
  > > used to disparage volunteer work by other people.  Marvelous!
  > 
  > Dan, please stop this.  

Can you please first get all the background before intervening?  
Doing that is absolutely not helpful.  
I am very disappointed, I didn't expect this from you Eli.

  > All that Mitsuharu asks for is higher level of quality for the code
  > committed to CVS.  I think it's a reasonable request.

Except that is not what is going on.

  > You seem to assert that when faced with changes which could
  > potentially break other platforms, there's only two possible
  > alternatives: either live with the breakage or don't commit the code
  > at all.  But in fact, there's a 3rd alternative: learn enough about
  > those other platforms to make the code right on them as well.
  > There's even a 4th alternative: make the new code be conditionally
  > compiled only on platforms you understand and can test.  All of
  > those are IMO better than breakage.

This is totally unrelated to the problem at hand.

  > So I don't understand why you reject such suggestions as
  > ``whining''.  Certainly, being the one who works on the code imposes
  > some responsibility on you.

Again, you have completely misunderstood the issue, ths has absolutely
no relation with what is happening here.

Now, I really don't like doing this, but I feel that I really need to
get my name cleared here, so let's go back to what has actually
happened.

In the discussion about next release:

  Chong Yidong <cyd@stupidchicken.com> writes:
  
    > If all goes well, the Emacs 23 freeze will begin sometime in late June,
    > depending on how long Handa's font-backend branch and (hopefully) ECB
    > take to merge into the trunk.  From that point, I'm hoping for around
    > six months of testing until the 23.1 release.  With this time frame, I
    > don't think we will release 22.3 , unless a security hole appears that
    > we need to fix.
    > 
    > In other words, go ahead and check in minor fixed to the branch if you
    > like, but it's not necessary.  Major fixes definitely should *not* go
                                                             ^^^^^^^^^^^^^^   
    > into the branch, since there will be no time to do extensive testing if
    > a security release is needed.
Me:  
  Does the above apply to all platforms?  Looking at src/ChangeLog there
  are pages after pages of changes for the Mac, which don't look at all
  like minor changes...


Anything wrong with this?  It's just a discussion on the policy for the
22 branch.  

Now comes the reply from Yamamoto Mitsuharu:

   > You're seeing the changes that have been accumulated for a
   > relatively long period because I restricted the changes between
   > 22.1 and 22.2 to strict bug fixes.

This was corrected in a subsequent email:
   > Correction: not "between 22.1 and 22.2", but "between 22.0.90 and
   > 22.2".  That's why the recent changes include those as of
   > before-merge-multi-tty-to-trunk.

Continuation from the first Yamamoto Mitsuharu email:
   >
   > Don't worry.  They don't break the Carbon port of Emacs 22 unlike
   > the minimally-tested multi-tty support you've done for the Carbon
   > port of Emacs 23.

Seriously?  Where did this attack come from?  We where talking about the
release policy for the 22 branch.

Now let's see what has been going on with multi-tty.

The author of multi-tty has stopped contributing to emacs before the
branch was merged, so I took up the task to get it merged.
I had to go through all the red tape to get RMS to approve the merger,
like rewrite ChangeLogs and reimplement setting environment variables,
and fixed many many bugs after the merger.
I also did a significant chunk of getting the Windows port to work (the
rest of the work was done by Jason).  Logs are all available, look on
the multi-tty branch in CVS.

Only GNU/Linux and Windows where mentioned as show stoppers for the
merge.

But I thought I could help to get the merge going on the Mac too.  So I
did that, and sent an email about it to the mac maintainer, Yamamoto
Mitsuharu, and he replied: 

>>>>> On Mon, 21 May 2007 08:25:27 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> YAMAMOTO-san,

> I have ported the emacs multi-tty branch to MacOS. It seems to work
> fine, but I have only done minimal testing. (I did this in a few
> hours on a borrowed machine that I had to return).

> I have tried to keep the changes to a minimum to minimize merging
> effort between the branch and trunk. (for example mac-win.el should
> be re-indented after the branch is merged to the trunk, a lot of
> global forms are now in a function).

> If you have a chance to test the branch more that would be very
> good.  I don't have access to a MacOS machine, so if you find
> problems, I can only help in a limited way.

Thanks for your effort.  But as I already said in
http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00310.html,
I'm not interested in developing/maintaining the Carbon port for Emacs
23.

I have some pending changes locally, and they are kept for Emacs 22.x
after the release.  I guess they don't interfere with your changes for
multi-tty.

----
"Minimal testing" above meant that "emacs -nw" worked and the GUI
started and emacsclient and emacsclient -t could connect to it.

So this states pretty clearly that the Mac Carbon port was going to be
unmaintained.  I have fixed a few more bugs after that, and tried to
help quite a few users to get it working.
I am sure I could have finished the work, although it would have meant
that I needed to get access to a Mac machine again. AFAIK there's a
just a problem with the input being very slow.

But given that the maintainer abandoned the platform, why would any
reasonable person spend more time trying to develop it?  So I didn't.

Note that this work was all on the multi-tty branch, not in CVS HEAD.
So if Yamamoto Mitsuharu would have actually cared about this code, he
could have said something a year ago when this was happening, asked for
the code to be changed/fixed/removed or even blocked the merger.
Nothing of the sort was done at the time. 
For good measure Carbon is unsupported now in CVS HEAD because it is
unmaintained and nobody has done any actual work to get it going.
Again, reports are 

And yes, I do stand by the work I did then.  It was incomplete (due to
circumstances explained in detail a few times on the list), but it was
the major chunk needed to get the Carbon port working.  I did not even
compile before that.

And yes, in retrospect, even trying to help with this work was a great
mistake and waste of time and energy.

And no, someone that has not helped that effort in any way
(i.e. Yamamoto Mitsuharu), despite being the most qualified person for
the job, has absolutely no standing to send nastygrams about it today.

I am puzzled about the motivation to even bring this up today in an
unrelated discussion.

Yamamoto Mitsuharu has been pestering the list about multi-tty (with no
clear explanation of the reason for this fixation) since multi-tty was
merged.  It is indeed strange, he does not plan to work on it, but he
still has a problem with it.  
Just search for his name and "multi-tty".  
This is what I called "whining".

Thank you for your attention.

Now can we please stop this? It is absolutely annoying, unproductive and
a complete waste of time.

Re: Next release

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>   > Dan, please stop this.  
>
> Can you please first get all the background before intervening?  

[...]

> Now, I really don't like doing this, but I feel that I really need to
> get my name cleared here, so let's go back to what has actually
> happened.

There is no need to get your "name cleared" since we already
participated the original discussion.  Doing another summary from your
point of view does not change that.

There was nothing gained for you picking up the ball unnecessarily
thrown at you in this context.  I am not saying that your reaction was
uncalled for or understandable.  It is just that it did not help.
Neither did the original bickering, but it wasted a lot less energy of
the attacker than the reply did of you.

Not hitting back when nothing can be gained by it is something hard to
learn for people with a strong sense of justice (and many programmers
are so, and possibly enthusiastic free software programmers more so).
But it saves a lot of headaches and, believe me, in the end even makes
you look better.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Next release

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: emacs-devel@gnu.org
> Date: Sat, 03 May 2008 23:58:57 -0700
> 
> Can you please first get all the background before intervening?  
> Doing that is absolutely not helpful.  
> I am very disappointed, I didn't expect this from you Eli.

Well, I'm sorry I disappoint you, but I still think that we should be
able to discuss technical issues, even if we disagree, without
non-technical words such as ``whining'' or ``pestering''.

> I feel that I really need to get my name cleared here

You don't need your name cleared, believe me.  Your name as one of the
more active contributors to Emacs development is as clear as it gets.
Thank you for you past and future work!

> And no, someone that has not helped that effort in any way
> (i.e. Yamamoto Mitsuharu), despite being the most qualified person for
> the job, has absolutely no standing to send nastygrams about it today.

Sorry, but I beg to disagree.  Asking developers to do a good job is a
reasonable thing, and anyone who contributes to Emacs is in a position
to do that.  As someone who did the job that is being criticized, you
can, of course, disagree, but please let's try not to make this
personal.

> I am puzzled about the motivation to even bring this up today in an
> unrelated discussion.

Well, I think if you re-read what you just wrote (and I omitted), the
motivation will be clear.

> Now can we please stop this?

That's what I was asking: to stop.

Re: Next release

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Cc: emacs-devel@gnu.org
  > > Date: Sat, 03 May 2008 23:58:57 -0700
  > > 
  > > Can you please first get all the background before intervening?  
  > > Doing that is absolutely not helpful.  
  > > I am very disappointed, I didn't expect this from you Eli.
  > 
  > Well, I'm sorry I disappoint you, but I still think that we should be
  > able to discuss technical issues, even if we disagree, without
  > non-technical words such as ``whining'' or ``pestering''.

I am sorry, but this has not been a technical discussion, and I can't
find better words to find describe the treatment that I got from
Yamamoto Mituharu and the way he describes the multi-tty work, please
actually _read_ his messages.

  > > And no, someone that has not helped that effort in any way
  > > (i.e. Yamamoto Mitsuharu), despite being the most qualified person for
  > > the job, has absolutely no standing to send nastygrams about it today.
  > 
  > Sorry, but I beg to disagree.  

As I do with you here, you seem to ignore the details of what has been
happening.  And the details are actually important.  And by doing that
you seem to support a point of view that has no basis in reality.

  > Asking developers to do a good job is a reasonable thing, and anyone
  > who contributes to Emacs is in a position to do that.  

This is a true statement, but it has no relation to what is going on here.

  > As someone who did the job that is being criticized, you can, of
  > course, disagree, but please let's try not to make this personal.

Sorry, but Yamamoto Mitsuharu's comments like: "Did you want to pretend
as if multi-tty was ready to get merged to the trunk?" are exactly
personal and meant _only_ to discredit me.

Let me repeat it for the Nth time: the I did the original work in a
limited time because it was done on a borrowed machine.  I did not
continue the work precisely because Yamamoto Mitsuharu declared that the
platform is unsupported.  I am sorry, but in this circumstance I don't
see why should I take any blame for "not doing a good job"?
What would YOU have done if you where in my position?
In retrospect, it would have been much better for me to just revert the
changes when I heard that the Carbon platform will be unsupported.

  > > I am puzzled about the motivation to even bring this up today in an
  > > unrelated discussion.
  > 
  > Well, I think if you re-read what you just wrote (and I omitted), the
  > motivation will be clear.

Seriously? What is the motivation for statements like: "Did you want to
pretend as if multi-tty was ready to get merged to the trunk?"?

Again the original discussion was about what is the policy for checking
in things on the 22 branch, totally unrelated to ANY of this.

Re: Next release

[Thomas Lord]

Dan Nicolaescu wrote:
> Seriously? What is the motivation for statements like: "Did you want to
> pretend as if multi-tty was ready to get merged to the trunk?"?
>   

In the context of that statement, it expressed puzzlement about why
instead of answering the issues about the quality of certain code,
you became indignant because you felt you hadn't been properly
thanked.

-t

Re: Next release

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Certainly, being the one who works on the code imposes some
> responsibility on you.

We need to have the code in Emacs in a state where an outside programmer
has a chance to read code and documentation and in a reasonable time
frame can understand enough of its workings to fix problems or extend
it.

If the code is not at that level, it is a time bomb.  I have (however
well-founded that may be) the impression that XEmacs is falling apart at
the seams due to central code parts that nobody feels fit to work on
anymore.

Now in this case, we had a conscious decision to incorporate code into
Emacs that was not in that state, and where its author was no longer
available.

Dan was a more vocal proponent of including the code, but that does not
make him better suited to do the integration work, just better suited
for bitching at.  But the work does not get done by bitching and
fingerpointing long enough, it does only get done by doing work.  Like
in a democracy, where there is just one common country to live in, the
decisions that were made by a majority have to be born by everybody.

It is good that Dan is doing a part of the necessary work, even on
platforms he does not work on himself.  And having worked on that makes
him a good candidate for further work, or for helping others getting
work done.

But it does not make him responsible for that, beyond the responsibility
that capable people feel compelled to take upon themselves to help the
less capable ones.  But he did not become more capable by magic or
birth, but by setting his mind on it and working on it.

The documentation state of multi-tty leaves a lot to be desired, and
that is the fault of work that did not get done yet.  But none of us is
in a situation where he could lean back and say "this certainly is
somebody else's job to do".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Next release

[Stefan Monnier]

> Now in this case, we had a conscious decision to incorporate code into
> Emacs that was not in that state, and where its author was no longer
> available.

IIUC the multi-tty code isn't particularly tricky.  The problem is the
input handling in general, and its interaction with signals, multiple
threads, and the GUI event-loop or callbacks.  This part is tricky, and
varies between platforms.  The multi-tty code was written for X11 and
worked there, but apparently the merge into the Carbon port was done by
someone who doesn't understand the way the Carbon port handles input
(which seems to be a particularly tricky problem, since IIUC it's been
changed a few times and works (or fails to) yet differently in the
Emacs.app code).

So yes, our code has dark corners that are poorly understood.
But I don't think the multi-tty code is really it.


        Stefan

Re: Next release

[Jason Rumney]

Eli Zaretskii wrote:
> You seem to assert that when faced with changes which could
> potentially break other platforms, there's only two possible
> alternatives: either live with the breakage or don't commit the code
> at all.  But in fact, there's a 3rd alternative: learn enough about
> those other platforms to make the code right on them as well.  There's
> even a 4th alternative: make the new code be conditionally compiled
> only on platforms you understand and can test.  All of those are IMO
> better than breakage.
>   

I think the lack of detailed documentation for some of the large code 
changes that have been developed on a branch makes things difficult for 
those who need to port the changes to other platforms. It can be quite 
daunting to be faced with such code breakage coming from three different 
sources (multi-tty, unicode and font-backend) at around the same time, 
when you have limited time to spend on getting things working again, 
meanwhile complaints from users flood in.

Re: Next release

[Richard M Stallman]

Please find someone to finish up the Rmail mbox branch and merge that
in for Emacs 23.  It is important, since it will make Rmail much more
content-type, and it is small and localized compared with the changes
already installed.

Re: Next release

[Chong Yidong]

Richard M Stallman <rms@gnu.org> writes:

> Please find someone to finish up the Rmail mbox branch and merge that
> in for Emacs 23.  It is important, since it will make Rmail much more
> content-type, and it is small and localized compared with the changes
> already installed.

Who was working on the mbox branch before?

Re: Next release

[Glenn Morris]

Chong Yidong wrote:

> Who was working on the mbox branch before?

A quick glance at the CVS logs indicate mainly Henrik Enberg and Alex
Schroeder.

Re: Next release

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> Who was working on the mbox branch before?
>
> A quick glance at the CVS logs indicate mainly Henrik Enberg and Alex
> Schroeder.

Are any of you interested in finishing the work on the mbox branch?

Re: Next release

[Alex]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

Not me. At the beginning of January Venkatesh Pitta had expressed some
interest in working on it.


On Sat, May 3, 2008 at 4:49 PM, Chong Yidong <cyd@stupidchicken.com> wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
> > Chong Yidong wrote:
> >
> >> Who was working on the mbox branch before?
> >
> > A quick glance at the CVS logs indicate mainly Henrik Enberg and Alex
> > Schroeder.
>
> Are any of you interested in finishing the work on the mbox branch?
>

[-- Attachment #2: Type: text/html, Size: 778 bytes --]

Re: Next release

[Richard M Stallman]

The one remaining issue in the Rmail-mbox branch is that of decoding
messages.  To handle it requires someone who is clever and
understands the coding system features well.  He does not need
to understand most of the Rmail code.

Re: Next release

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> Date: Sat, 03 May 2008 17:00:44 -0400
> Cc: rgm@gnu.org, nickrob@snap.net.nz, emacs-devel@gnu.org
> 
> The one remaining issue in the Rmail-mbox branch is that of decoding
> messages.  To handle it requires someone who is clever and
> understands the coding system features well.

Actually, not even that, IMO: the code to do this is already written
in the current rmail.el, it just needs to be moved to run whenever a
message is displayed, as opposed to when it is first read from the
incoming mail stream.