* Next release @ 2008-05-01 9:48 Nick Roberts 2008-05-01 10:32 ` Jason Rumney 2008-05-01 17:43 ` Glenn Morris 0 siblings, 2 replies; 110+ messages in thread From: Nick Roberts @ 2008-05-01 9:48 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 9:48 Next release Nick Roberts @ 2008-05-01 10:32 ` Jason Rumney 2008-05-01 23:07 ` Nick Roberts 2008-05-01 17:43 ` Glenn Morris 1 sibling, 1 reply; 110+ messages in thread From: Jason Rumney @ 2008-05-01 10:32 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 10:32 ` Jason Rumney @ 2008-05-01 23:07 ` Nick Roberts 2008-05-02 0:04 ` Jason Rumney 0 siblings, 1 reply; 110+ messages in thread From: Nick Roberts @ 2008-05-01 23:07 UTC (permalink / raw) To: Jason Rumney; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 23:07 ` Nick Roberts @ 2008-05-02 0:04 ` Jason Rumney 0 siblings, 0 replies; 110+ messages in thread From: Jason Rumney @ 2008-05-02 0:04 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 9:48 Next release Nick Roberts 2008-05-01 10:32 ` Jason Rumney @ 2008-05-01 17:43 ` Glenn Morris 2008-05-01 19:52 ` David Kastrup 2008-05-01 20:30 ` Chong Yidong 1 sibling, 2 replies; 110+ messages in thread From: Glenn Morris @ 2008-05-01 17:43 UTC (permalink / raw) To: Nick Roberts; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 17:43 ` Glenn Morris @ 2008-05-01 19:52 ` David Kastrup 2008-05-01 20:30 ` Chong Yidong 1 sibling, 0 replies; 110+ messages in thread From: David Kastrup @ 2008-05-01 19:52 UTC (permalink / raw) To: Glenn Morris; +Cc: Nick Roberts, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 17:43 ` Glenn Morris 2008-05-01 19:52 ` David Kastrup @ 2008-05-01 20:30 ` Chong Yidong 2008-05-02 1:00 ` Glenn Morris ` (3 more replies) 1 sibling, 4 replies; 110+ messages in thread From: Chong Yidong @ 2008-05-01 20:30 UTC (permalink / raw) To: Glenn Morris; +Cc: Nick Roberts, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 20:30 ` Chong Yidong @ 2008-05-02 1:00 ` Glenn Morris 2008-05-02 6:48 ` CHENG Gao ` (2 subsequent siblings) 3 siblings, 0 replies; 110+ messages in thread From: Glenn Morris @ 2008-05-02 1:00 UTC (permalink / raw) To: Chong Yidong; +Cc: Nick Roberts, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 20:30 ` Chong Yidong 2008-05-02 1:00 ` Glenn Morris @ 2008-05-02 6:48 ` CHENG Gao 2008-05-03 1:00 ` Bob ` (2 more replies) 2008-05-02 13:31 ` Next release Dan Nicolaescu 2008-05-02 21:13 ` Richard M Stallman 3 siblings, 3 replies; 110+ messages in thread From: CHENG Gao @ 2008-05-02 6:48 UTC (permalink / raw) To: emacs-devel *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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 6:48 ` CHENG Gao @ 2008-05-03 1:00 ` Bob 2008-05-03 8:09 ` Richard M Stallman 2008-05-06 0:38 ` YAMAMOTO Mitsuharu 2 siblings, 0 replies; 110+ messages in thread From: Bob @ 2008-05-03 1:00 UTC (permalink / raw) To: CHENG Gao, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 6:48 ` CHENG Gao 2008-05-03 1:00 ` Bob @ 2008-05-03 8:09 ` Richard M Stallman 2008-05-03 9:22 ` CHENG Gao 2008-05-06 0:38 ` YAMAMOTO Mitsuharu 2 siblings, 1 reply; 110+ messages in thread From: Richard M Stallman @ 2008-05-03 8:09 UTC (permalink / raw) To: CHENG Gao; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 8:09 ` Richard M Stallman @ 2008-05-03 9:22 ` CHENG Gao 2008-05-03 9:49 ` YAMAMOTO Mitsuharu 2008-05-04 9:37 ` Richard M Stallman 0 siblings, 2 replies; 110+ messages in thread From: CHENG Gao @ 2008-05-03 9:22 UTC (permalink / raw) To: emacs-devel *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. `---- ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 9:22 ` CHENG Gao @ 2008-05-03 9:49 ` YAMAMOTO Mitsuharu 2008-05-03 18:59 ` Stefan Monnier 2008-05-04 9:37 ` Richard M Stallman 1 sibling, 1 reply; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-03 9:49 UTC (permalink / raw) To: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 9:49 ` YAMAMOTO Mitsuharu @ 2008-05-03 18:59 ` Stefan Monnier 2008-05-03 19:08 ` Glenn Morris 2008-05-04 9:37 ` Richard M Stallman 0 siblings, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-03 18:59 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: emacs-devel >>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 18:59 ` Stefan Monnier @ 2008-05-03 19:08 ` Glenn Morris 2008-05-03 21:42 ` Stefan Monnier 2008-05-04 9:37 ` Richard M Stallman 1 sibling, 1 reply; 110+ messages in thread From: Glenn Morris @ 2008-05-03 19:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: YAMAMOTO Mitsuharu, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 19:08 ` Glenn Morris @ 2008-05-03 21:42 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-03 21:42 UTC (permalink / raw) To: Glenn Morris; +Cc: YAMAMOTO Mitsuharu, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 18:59 ` Stefan Monnier 2008-05-03 19:08 ` Glenn Morris @ 2008-05-04 9:37 ` Richard M Stallman 1 sibling, 0 replies; 110+ messages in thread From: Richard M Stallman @ 2008-05-04 9:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: mituharu, emacs-devel > GNUstep is currently one of CANNOT_DUMP platforms, Reloading everything at each start is a nuisance, so can someone fix dumping with GNUstep? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 9:22 ` CHENG Gao 2008-05-03 9:49 ` YAMAMOTO Mitsuharu @ 2008-05-04 9:37 ` Richard M Stallman 1 sibling, 0 replies; 110+ messages in thread From: Richard M Stallman @ 2008-05-04 9:37 UTC (permalink / raw) To: CHENG Gao; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 6:48 ` CHENG Gao 2008-05-03 1:00 ` Bob 2008-05-03 8:09 ` Richard M Stallman @ 2008-05-06 0:38 ` YAMAMOTO Mitsuharu 2008-05-23 20:18 ` Problems preloading x-win.el (was: Next release) Stefan Monnier 2 siblings, 1 reply; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-06 0:38 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Problems preloading x-win.el (was: Next release) 2008-05-06 0:38 ` YAMAMOTO Mitsuharu @ 2008-05-23 20:18 ` Stefan Monnier 2008-05-23 21:54 ` Dan Nicolaescu 2008-05-24 3:19 ` Problems preloading x-win.el (was: Next release) YAMAMOTO Mitsuharu 0 siblings, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-23 20:18 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Problems preloading x-win.el (was: Next release) 2008-05-23 20:18 ` Problems preloading x-win.el (was: Next release) Stefan Monnier @ 2008-05-23 21:54 ` Dan Nicolaescu 2008-05-24 2:22 ` Problems preloading x-win.el Stefan Monnier 2008-05-24 3:19 ` Problems preloading x-win.el (was: Next release) YAMAMOTO Mitsuharu 1 sibling, 1 reply; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-23 21:54 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Nick Roberts, YAMAMOTO Mitsuharu, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Problems preloading x-win.el 2008-05-23 21:54 ` Dan Nicolaescu @ 2008-05-24 2:22 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-24 2:22 UTC (permalink / raw) To: Dan Nicolaescu Cc: Glenn Morris, Chong Yidong, Nick Roberts, YAMAMOTO Mitsuharu, emacs-devel >> >>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Problems preloading x-win.el (was: Next release) 2008-05-23 20:18 ` Problems preloading x-win.el (was: Next release) Stefan Monnier 2008-05-23 21:54 ` Dan Nicolaescu @ 2008-05-24 3:19 ` YAMAMOTO Mitsuharu 1 sibling, 0 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-24 3:19 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 20:30 ` Chong Yidong 2008-05-02 1:00 ` Glenn Morris 2008-05-02 6:48 ` CHENG Gao @ 2008-05-02 13:31 ` Dan Nicolaescu 2008-05-02 13:52 ` Jason Rumney 2008-05-02 15:24 ` YAMAMOTO Mitsuharu 2008-05-02 21:13 ` Richard M Stallman 3 siblings, 2 replies; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-02 13:31 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, Nick Roberts, emacs-devel 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... ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 13:31 ` Next release Dan Nicolaescu @ 2008-05-02 13:52 ` Jason Rumney 2008-05-02 15:24 ` YAMAMOTO Mitsuharu 1 sibling, 0 replies; 110+ messages in thread From: Jason Rumney @ 2008-05-02 13:52 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 13:31 ` Next release Dan Nicolaescu 2008-05-02 13:52 ` Jason Rumney @ 2008-05-02 15:24 ` YAMAMOTO Mitsuharu 2008-05-02 16:10 ` Dan Nicolaescu 1 sibling, 1 reply; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-02 15:24 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 15:24 ` YAMAMOTO Mitsuharu @ 2008-05-02 16:10 ` Dan Nicolaescu 2008-05-03 9:38 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-02 16:10 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 16:10 ` Dan Nicolaescu @ 2008-05-03 9:38 ` YAMAMOTO Mitsuharu 2008-05-03 19:05 ` Stefan Monnier 2008-05-04 0:56 ` Dan Nicolaescu 0 siblings, 2 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-03 9:38 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 9:38 ` YAMAMOTO Mitsuharu @ 2008-05-03 19:05 ` Stefan Monnier 2008-05-04 0:56 ` Dan Nicolaescu 1 sibling, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-03 19:05 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 9:38 ` YAMAMOTO Mitsuharu 2008-05-03 19:05 ` Stefan Monnier @ 2008-05-04 0:56 ` Dan Nicolaescu 2008-05-04 1:25 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-04 0:56 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 0:56 ` Dan Nicolaescu @ 2008-05-04 1:25 ` YAMAMOTO Mitsuharu 2008-05-04 1:40 ` Stefan Monnier 2008-05-04 2:06 ` Dan Nicolaescu 0 siblings, 2 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-04 1:25 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 1:25 ` YAMAMOTO Mitsuharu @ 2008-05-04 1:40 ` Stefan Monnier 2008-05-04 1:57 ` YAMAMOTO Mitsuharu 2008-05-04 2:06 ` Dan Nicolaescu 1 sibling, 1 reply; 110+ messages in thread From: Stefan Monnier @ 2008-05-04 1:40 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 1:40 ` Stefan Monnier @ 2008-05-04 1:57 ` YAMAMOTO Mitsuharu 2008-05-04 3:21 ` Stefan Monnier 2008-05-04 21:23 ` Chong Yidong 0 siblings, 2 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-04 1:57 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 1:57 ` YAMAMOTO Mitsuharu @ 2008-05-04 3:21 ` Stefan Monnier 2008-05-04 5:07 ` YAMAMOTO Mitsuharu 2008-05-04 21:23 ` Chong Yidong 1 sibling, 1 reply; 110+ messages in thread From: Stefan Monnier @ 2008-05-04 3:21 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 3:21 ` Stefan Monnier @ 2008-05-04 5:07 ` YAMAMOTO Mitsuharu 2008-05-04 15:52 ` Stefan Monnier 2008-05-04 21:35 ` Chong Yidong 0 siblings, 2 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-04 5:07 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 5:07 ` YAMAMOTO Mitsuharu @ 2008-05-04 15:52 ` Stefan Monnier 2008-05-05 1:28 ` YAMAMOTO Mitsuharu 2008-05-04 21:35 ` Chong Yidong 1 sibling, 1 reply; 110+ messages in thread From: Stefan Monnier @ 2008-05-04 15:52 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 15:52 ` Stefan Monnier @ 2008-05-05 1:28 ` YAMAMOTO Mitsuharu 2008-05-05 5:48 ` Stefan Monnier 0 siblings, 1 reply; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-05 1:28 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-05 1:28 ` YAMAMOTO Mitsuharu @ 2008-05-05 5:48 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-05 5:48 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 5:07 ` YAMAMOTO Mitsuharu 2008-05-04 15:52 ` Stefan Monnier @ 2008-05-04 21:35 ` Chong Yidong 2008-05-04 23:52 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-04 21:35 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Nick Roberts, Dan Nicolaescu, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 21:35 ` Chong Yidong @ 2008-05-04 23:52 ` YAMAMOTO Mitsuharu 2008-05-05 0:56 ` Stefan Monnier 0 siblings, 1 reply; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-04 23:52 UTC (permalink / raw) To: Chong Yidong Cc: Glenn Morris, Nick Roberts, Dan Nicolaescu, Stefan Monnier, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 23:52 ` YAMAMOTO Mitsuharu @ 2008-05-05 0:56 ` Stefan Monnier 2008-05-05 7:43 ` Juanma Barranquero 2008-05-06 0:40 ` Next release YAMAMOTO Mitsuharu 0 siblings, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-05 0:56 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-05 0:56 ` Stefan Monnier @ 2008-05-05 7:43 ` Juanma Barranquero 2008-05-07 18:28 ` Stefan Monnier 2008-05-06 0:40 ` Next release YAMAMOTO Mitsuharu 1 sibling, 1 reply; 110+ messages in thread From: Juanma Barranquero @ 2008-05-05 7:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-05 7:43 ` Juanma Barranquero @ 2008-05-07 18:28 ` Stefan Monnier 2008-05-07 19:13 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-07 18:28 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-07 18:28 ` Stefan Monnier @ 2008-05-07 19:13 ` Eli Zaretskii 2008-05-08 1:26 ` Stefan Monnier 2008-05-08 2:34 ` Juanma Barranquero 2008-05-09 1:35 ` Tool-bar changes (Was: Next release) Chong Yidong 2 siblings, 1 reply; 110+ messages in thread From: Eli Zaretskii @ 2008-05-07 19:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-07 19:13 ` Eli Zaretskii @ 2008-05-08 1:26 ` Stefan Monnier 2008-05-08 8:22 ` Jason Rumney 2008-05-08 9:32 ` Eli Zaretskii 0 siblings, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-08 1:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 1:26 ` Stefan Monnier @ 2008-05-08 8:22 ` Jason Rumney 2008-05-08 8:32 ` David Kastrup 2008-05-08 9:32 ` Eli Zaretskii 1 sibling, 1 reply; 110+ messages in thread From: Jason Rumney @ 2008-05-08 8:22 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 8:22 ` Jason Rumney @ 2008-05-08 8:32 ` David Kastrup 2008-05-08 9:04 ` David Reitter 2008-05-08 9:06 ` Miles Bader 0 siblings, 2 replies; 110+ messages in thread From: David Kastrup @ 2008-05-08 8:32 UTC (permalink / raw) To: Jason Rumney; +Cc: lekktu, Eli Zaretskii, Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 8:32 ` David Kastrup @ 2008-05-08 9:04 ` David Reitter 2008-05-08 10:40 ` Jan Djärv 2008-05-08 9:06 ` Miles Bader 1 sibling, 1 reply; 110+ messages in thread From: David Reitter @ 2008-05-08 9:04 UTC (permalink / raw) To: David Kastrup, emacs- devel Cc: Juanma Barranquero, Eli Zaretskii, Stefan Monnier, Jason Rumney 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:04 ` David Reitter @ 2008-05-08 10:40 ` Jan Djärv 2008-05-08 10:55 ` Miles Bader 2008-05-10 8:55 ` Richard M Stallman 0 siblings, 2 replies; 110+ messages in thread From: Jan Djärv @ 2008-05-08 10:40 UTC (permalink / raw) To: David Reitter Cc: Juanma Barranquero, Jason Rumney, Stefan Monnier, Eli Zaretskii, emacs- devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 10:40 ` Jan Djärv @ 2008-05-08 10:55 ` Miles Bader 2008-05-10 8:55 ` Richard M Stallman 1 sibling, 0 replies; 110+ messages in thread From: Miles Bader @ 2008-05-08 10:55 UTC (permalink / raw) To: Jan Djärv Cc: David Reitter, Jason Rumney, Stefan Monnier, Juanma Barranquero, Eli Zaretskii, emacs- devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 10:40 ` Jan Djärv 2008-05-08 10:55 ` Miles Bader @ 2008-05-10 8:55 ` Richard M Stallman 2008-05-10 20:30 ` David Kastrup 1 sibling, 1 reply; 110+ messages in thread From: Richard M Stallman @ 2008-05-10 8:55 UTC (permalink / raw) To: Jan Djärv; +Cc: david.reitter, jasonr, monnier, lekktu, eliz, emacs-devel How do you handle --debug-init? I suggest mapping the frame beforehand, as now, if --debug-init is specified. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-10 8:55 ` Richard M Stallman @ 2008-05-10 20:30 ` David Kastrup 2008-05-10 23:53 ` David Reitter 0 siblings, 1 reply; 110+ messages in thread From: David Kastrup @ 2008-05-10 20:30 UTC (permalink / raw) To: rms Cc: emacs-devel, lekktu, jasonr, monnier, david.reitter, eliz, Jan Djärv 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-10 20:30 ` David Kastrup @ 2008-05-10 23:53 ` David Reitter 0 siblings, 0 replies; 110+ messages in thread From: David Reitter @ 2008-05-10 23:53 UTC (permalink / raw) To: David Kastrup Cc: emacs-devel, rms, lekktu, jasonr, monnier, eliz, Jan Djärv 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 8:32 ` David Kastrup 2008-05-08 9:04 ` David Reitter @ 2008-05-08 9:06 ` Miles Bader 2008-05-08 9:22 ` Jason Rumney ` (2 more replies) 1 sibling, 3 replies; 110+ messages in thread From: Miles Bader @ 2008-05-08 9:06 UTC (permalink / raw) To: David Kastrup Cc: lekktu, Eli Zaretskii, emacs-devel, Stefan Monnier, Jason Rumney 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:06 ` Miles Bader @ 2008-05-08 9:22 ` Jason Rumney 2008-05-08 9:35 ` Miles Bader 2008-05-08 9:45 ` David Kastrup 2008-05-08 10:04 ` Eli Zaretskii 2008-05-08 13:51 ` Stefan Monnier 2 siblings, 2 replies; 110+ messages in thread From: Jason Rumney @ 2008-05-08 9:22 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, Eli Zaretskii, Stefan Monnier, emacs-devel 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). ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:22 ` Jason Rumney @ 2008-05-08 9:35 ` Miles Bader 2008-05-08 9:44 ` David Kastrup ` (2 more replies) 2008-05-08 9:45 ` David Kastrup 1 sibling, 3 replies; 110+ messages in thread From: Miles Bader @ 2008-05-08 9:35 UTC (permalink / raw) To: Jason Rumney; +Cc: lekktu, Eli Zaretskii, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:35 ` Miles Bader @ 2008-05-08 9:44 ` David Kastrup 2008-05-08 19:47 ` Stephen J. Turnbull 2008-05-08 9:51 ` Jason Rumney 2008-05-08 10:16 ` Eli Zaretskii 2 siblings, 1 reply; 110+ messages in thread From: David Kastrup @ 2008-05-08 9:44 UTC (permalink / raw) To: Miles Bader Cc: lekktu, Eli Zaretskii, emacs-devel, Stefan Monnier, Jason Rumney 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:44 ` David Kastrup @ 2008-05-08 19:47 ` Stephen J. Turnbull 2008-05-08 20:56 ` David Kastrup 0 siblings, 1 reply; 110+ messages in thread From: Stephen J. Turnbull @ 2008-05-08 19:47 UTC (permalink / raw) To: David Kastrup Cc: lekktu, emacs-devel, Stefan Monnier, Eli Zaretskii, Jason Rumney, Miles Bader 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 19:47 ` Stephen J. Turnbull @ 2008-05-08 20:56 ` David Kastrup 2008-05-09 0:52 ` Stefan Monnier 0 siblings, 1 reply; 110+ messages in thread From: David Kastrup @ 2008-05-08 20:56 UTC (permalink / raw) To: Stephen J. Turnbull Cc: lekktu, emacs-devel, Stefan Monnier, Eli Zaretskii, Jason Rumney, Miles Bader "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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 20:56 ` David Kastrup @ 2008-05-09 0:52 ` Stefan Monnier 2008-05-09 1:04 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-09 0:52 UTC (permalink / raw) To: David Kastrup Cc: lekktu, emacs-devel, Stephen J. Turnbull, Jason Rumney, Eli Zaretskii, Miles Bader > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-09 0:52 ` Stefan Monnier @ 2008-05-09 1:04 ` Miles Bader 2008-05-09 6:07 ` Tassilo Horn 2008-05-09 7:02 ` Eli Zaretskii 2 siblings, 0 replies; 110+ messages in thread From: Miles Bader @ 2008-05-09 1:04 UTC (permalink / raw) To: Stefan Monnier Cc: lekktu, Jason Rumney, Stephen J. Turnbull, emacs-devel, Eli Zaretskii 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.' ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-09 0:52 ` Stefan Monnier 2008-05-09 1:04 ` Miles Bader @ 2008-05-09 6:07 ` Tassilo Horn 2008-05-09 7:02 ` Eli Zaretskii 2 siblings, 0 replies; 110+ messages in thread From: Tassilo Horn @ 2008-05-09 6:07 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-09 0:52 ` Stefan Monnier 2008-05-09 1:04 ` Miles Bader 2008-05-09 6:07 ` Tassilo Horn @ 2008-05-09 7:02 ` Eli Zaretskii 2 siblings, 0 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-09 7:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, emacs-devel, stephen, jasonr, miles > 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:35 ` Miles Bader 2008-05-08 9:44 ` David Kastrup @ 2008-05-08 9:51 ` Jason Rumney 2008-05-08 10:08 ` David Kastrup 2008-05-08 10:16 ` Eli Zaretskii 2 siblings, 1 reply; 110+ messages in thread From: Jason Rumney @ 2008-05-08 9:51 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, Eli Zaretskii, Stefan Monnier, emacs-devel 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). ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:51 ` Jason Rumney @ 2008-05-08 10:08 ` David Kastrup 0 siblings, 0 replies; 110+ messages in thread From: David Kastrup @ 2008-05-08 10:08 UTC (permalink / raw) To: Jason Rumney Cc: lekktu, Eli Zaretskii, emacs-devel, Stefan Monnier, Miles Bader 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:35 ` Miles Bader 2008-05-08 9:44 ` David Kastrup 2008-05-08 9:51 ` Jason Rumney @ 2008-05-08 10:16 ` Eli Zaretskii 2008-05-08 10:36 ` David Kastrup 2008-05-09 23:54 ` Juri Linkov 2 siblings, 2 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-08 10:16 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, emacs-devel, monnier, jasonr > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 10:16 ` Eli Zaretskii @ 2008-05-08 10:36 ` David Kastrup 2008-05-09 23:54 ` Juri Linkov 1 sibling, 0 replies; 110+ messages in thread From: David Kastrup @ 2008-05-08 10:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel, jasonr, monnier, Miles Bader 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 10:16 ` Eli Zaretskii 2008-05-08 10:36 ` David Kastrup @ 2008-05-09 23:54 ` Juri Linkov 1 sibling, 0 replies; 110+ messages in thread From: Juri Linkov @ 2008-05-09 23:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel, jasonr, monnier, Miles Bader >> 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/ ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:22 ` Jason Rumney 2008-05-08 9:35 ` Miles Bader @ 2008-05-08 9:45 ` David Kastrup 1 sibling, 0 replies; 110+ messages in thread From: David Kastrup @ 2008-05-08 9:45 UTC (permalink / raw) To: Jason Rumney Cc: lekktu, Eli Zaretskii, emacs-devel, Stefan Monnier, Miles Bader 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:06 ` Miles Bader 2008-05-08 9:22 ` Jason Rumney @ 2008-05-08 10:04 ` Eli Zaretskii 2008-05-08 13:51 ` Stefan Monnier 2 siblings, 0 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-08 10:04 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, emacs-devel, monnier, jasonr > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:06 ` Miles Bader 2008-05-08 9:22 ` Jason Rumney 2008-05-08 10:04 ` Eli Zaretskii @ 2008-05-08 13:51 ` Stefan Monnier 2008-05-08 13:57 ` Juanma Barranquero 2008-05-08 14:50 ` Miles Bader 2 siblings, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-08 13:51 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, Eli Zaretskii, emacs-devel, Jason Rumney >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 13:51 ` Stefan Monnier @ 2008-05-08 13:57 ` Juanma Barranquero 2008-05-08 14:50 ` Miles Bader 1 sibling, 0 replies; 110+ messages in thread From: Juanma Barranquero @ 2008-05-08 13:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 13:51 ` Stefan Monnier 2008-05-08 13:57 ` Juanma Barranquero @ 2008-05-08 14:50 ` Miles Bader 2008-05-09 11:12 ` Richard M Stallman 1 sibling, 1 reply; 110+ messages in thread From: Miles Bader @ 2008-05-08 14:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, Eli Zaretskii, Jason Rumney, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 14:50 ` Miles Bader @ 2008-05-09 11:12 ` Richard M Stallman 0 siblings, 0 replies; 110+ messages in thread From: Richard M Stallman @ 2008-05-09 11:12 UTC (permalink / raw) To: Miles Bader; +Cc: lekktu, eliz, emacs-devel, monnier, jasonr 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 1:26 ` Stefan Monnier 2008-05-08 8:22 ` Jason Rumney @ 2008-05-08 9:32 ` Eli Zaretskii 2008-05-08 13:46 ` Stefan Monnier 1 sibling, 1 reply; 110+ messages in thread From: Eli Zaretskii @ 2008-05-08 9:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, emacs-devel > 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-08 9:32 ` Eli Zaretskii @ 2008-05-08 13:46 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-08 13:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-07 18:28 ` Stefan Monnier 2008-05-07 19:13 ` Eli Zaretskii @ 2008-05-08 2:34 ` Juanma Barranquero 2008-05-09 1:35 ` Tool-bar changes (Was: Next release) Chong Yidong 2 siblings, 0 replies; 110+ messages in thread From: Juanma Barranquero @ 2008-05-08 2:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Tool-bar changes (Was: Next release) 2008-05-07 18:28 ` Stefan Monnier 2008-05-07 19:13 ` Eli Zaretskii 2008-05-08 2:34 ` Juanma Barranquero @ 2008-05-09 1:35 ` Chong Yidong 2008-05-09 3:25 ` Tool-bar changes Stefan Monnier 2008-05-13 18:07 ` Chong Yidong 2 siblings, 2 replies; 110+ messages in thread From: Chong Yidong @ 2008-05-09 1:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-09 1:35 ` Tool-bar changes (Was: Next release) Chong Yidong @ 2008-05-09 3:25 ` Stefan Monnier 2008-05-09 5:53 ` Tassilo Horn 2008-05-13 18:07 ` Chong Yidong 1 sibling, 1 reply; 110+ messages in thread From: Stefan Monnier @ 2008-05-09 3:25 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-09 3:25 ` Tool-bar changes Stefan Monnier @ 2008-05-09 5:53 ` Tassilo Horn 0 siblings, 0 replies; 110+ messages in thread From: Tassilo Horn @ 2008-05-09 5:53 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-09 1:35 ` Tool-bar changes (Was: Next release) Chong Yidong 2008-05-09 3:25 ` Tool-bar changes Stefan Monnier @ 2008-05-13 18:07 ` Chong Yidong 2008-05-13 18:19 ` Stefan Monnier 2008-05-14 2:17 ` Chong Yidong 1 sibling, 2 replies; 110+ messages in thread From: Chong Yidong @ 2008-05-13 18:07 UTC (permalink / raw) To: Stefan Monnier Cc: Tassilo Horn, Reiner Steib, Juanma Barranquero, emacs-devel, Sebastian P. Luque, 225-done 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-13 18:07 ` Chong Yidong @ 2008-05-13 18:19 ` Stefan Monnier 2008-05-13 18:38 ` David Reitter 2008-05-13 19:06 ` Eli Zaretskii 2008-05-14 2:17 ` Chong Yidong 1 sibling, 2 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-13 18:19 UTC (permalink / raw) To: Chong Yidong Cc: Tassilo Horn, Reiner Steib, Juanma Barranquero, emacs-devel, Sebastian P. Luque, 225-done > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-13 18:19 ` Stefan Monnier @ 2008-05-13 18:38 ` David Reitter 2008-05-13 19:06 ` Eli Zaretskii 1 sibling, 0 replies; 110+ messages in thread From: David Reitter @ 2008-05-13 18:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs- devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-13 18:19 ` Stefan Monnier 2008-05-13 18:38 ` David Reitter @ 2008-05-13 19:06 ` Eli Zaretskii 1 sibling, 0 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-13 19:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-13 18:07 ` Chong Yidong 2008-05-13 18:19 ` Stefan Monnier @ 2008-05-14 2:17 ` Chong Yidong 2008-05-14 4:28 ` Chong Yidong 1 sibling, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-14 2:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-14 2:17 ` Chong Yidong @ 2008-05-14 4:28 ` Chong Yidong 2008-05-14 4:47 ` Stefan Monnier 0 siblings, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-14 4:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-14 4:28 ` Chong Yidong @ 2008-05-14 4:47 ` Stefan Monnier 2008-05-14 19:30 ` Chong Yidong 0 siblings, 1 reply; 110+ messages in thread From: Stefan Monnier @ 2008-05-14 4:47 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-14 4:47 ` Stefan Monnier @ 2008-05-14 19:30 ` Chong Yidong 2008-05-14 20:50 ` Chong Yidong 0 siblings, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-14 19:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-14 19:30 ` Chong Yidong @ 2008-05-14 20:50 ` Chong Yidong 2008-05-15 1:10 ` Stefan Monnier 0 siblings, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-14 20:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ---- ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Tool-bar changes 2008-05-14 20:50 ` Chong Yidong @ 2008-05-15 1:10 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-15 1:10 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-05 0:56 ` Stefan Monnier 2008-05-05 7:43 ` Juanma Barranquero @ 2008-05-06 0:40 ` YAMAMOTO Mitsuharu 1 sibling, 0 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-06 0:40 UTC (permalink / raw) To: Stefan Monnier Cc: Glenn Morris, Chong Yidong, Dan Nicolaescu, Nick Roberts, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 1:57 ` YAMAMOTO Mitsuharu 2008-05-04 3:21 ` Stefan Monnier @ 2008-05-04 21:23 ` Chong Yidong 2008-05-05 0:44 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-04 21:23 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Glenn Morris, Nick Roberts, Dan Nicolaescu, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 21:23 ` Chong Yidong @ 2008-05-05 0:44 ` YAMAMOTO Mitsuharu 0 siblings, 0 replies; 110+ messages in thread From: YAMAMOTO Mitsuharu @ 2008-05-05 0:44 UTC (permalink / raw) To: Chong Yidong Cc: Glenn Morris, Nick Roberts, Dan Nicolaescu, Stefan Monnier, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 1:25 ` YAMAMOTO Mitsuharu 2008-05-04 1:40 ` Stefan Monnier @ 2008-05-04 2:06 ` Dan Nicolaescu 2008-05-04 4:21 ` Eli Zaretskii 1 sibling, 1 reply; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-04 2:06 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Glenn Morris, Chong Yidong, Nick Roberts, emacs-devel 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! ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 2:06 ` Dan Nicolaescu @ 2008-05-04 4:21 ` Eli Zaretskii 2008-05-04 6:58 ` Dan Nicolaescu ` (2 more replies) 0 siblings, 3 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-04 4:21 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 4:21 ` Eli Zaretskii @ 2008-05-04 6:58 ` Dan Nicolaescu 2008-05-04 8:15 ` David Kastrup 2008-05-04 18:17 ` Eli Zaretskii 2008-05-04 7:36 ` David Kastrup 2008-05-04 14:34 ` Jason Rumney 2 siblings, 2 replies; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-04 6:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 6:58 ` Dan Nicolaescu @ 2008-05-04 8:15 ` David Kastrup 2008-05-04 18:17 ` Eli Zaretskii 1 sibling, 0 replies; 110+ messages in thread From: David Kastrup @ 2008-05-04 8:15 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 6:58 ` Dan Nicolaescu 2008-05-04 8:15 ` David Kastrup @ 2008-05-04 18:17 ` Eli Zaretskii 2008-05-04 18:59 ` Dan Nicolaescu 1 sibling, 1 reply; 110+ messages in thread From: Eli Zaretskii @ 2008-05-04 18:17 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 18:17 ` Eli Zaretskii @ 2008-05-04 18:59 ` Dan Nicolaescu 2008-05-04 20:31 ` Thomas Lord 0 siblings, 1 reply; 110+ messages in thread From: Dan Nicolaescu @ 2008-05-04 18:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 18:59 ` Dan Nicolaescu @ 2008-05-04 20:31 ` Thomas Lord 0 siblings, 0 replies; 110+ messages in thread From: Thomas Lord @ 2008-05-04 20:31 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 4:21 ` Eli Zaretskii 2008-05-04 6:58 ` Dan Nicolaescu @ 2008-05-04 7:36 ` David Kastrup 2008-05-04 16:00 ` Stefan Monnier 2008-05-04 14:34 ` Jason Rumney 2 siblings, 1 reply; 110+ messages in thread From: David Kastrup @ 2008-05-04 7:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Dan Nicolaescu, emacs-devel 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 7:36 ` David Kastrup @ 2008-05-04 16:00 ` Stefan Monnier 0 siblings, 0 replies; 110+ messages in thread From: Stefan Monnier @ 2008-05-04 16:00 UTC (permalink / raw) To: David Kastrup; +Cc: Eli Zaretskii, Dan Nicolaescu, emacs-devel > 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 ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-04 4:21 ` Eli Zaretskii 2008-05-04 6:58 ` Dan Nicolaescu 2008-05-04 7:36 ` David Kastrup @ 2008-05-04 14:34 ` Jason Rumney 2 siblings, 0 replies; 110+ messages in thread From: Jason Rumney @ 2008-05-04 14:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Dan Nicolaescu, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-01 20:30 ` Chong Yidong ` (2 preceding siblings ...) 2008-05-02 13:31 ` Next release Dan Nicolaescu @ 2008-05-02 21:13 ` Richard M Stallman 2008-05-02 21:32 ` Chong Yidong 3 siblings, 1 reply; 110+ messages in thread From: Richard M Stallman @ 2008-05-02 21:13 UTC (permalink / raw) To: Chong Yidong; +Cc: rgm, nickrob, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 21:13 ` Richard M Stallman @ 2008-05-02 21:32 ` Chong Yidong 2008-05-03 0:11 ` Glenn Morris 2008-05-03 21:00 ` Richard M Stallman 0 siblings, 2 replies; 110+ messages in thread From: Chong Yidong @ 2008-05-02 21:32 UTC (permalink / raw) To: rms; +Cc: rgm, nickrob, emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 21:32 ` Chong Yidong @ 2008-05-03 0:11 ` Glenn Morris 2008-05-03 14:49 ` Chong Yidong 2008-05-03 21:00 ` Richard M Stallman 1 sibling, 1 reply; 110+ messages in thread From: Glenn Morris @ 2008-05-03 0:11 UTC (permalink / raw) To: Chong Yidong; +Cc: nickrob, rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 0:11 ` Glenn Morris @ 2008-05-03 14:49 ` Chong Yidong 2008-05-03 17:02 ` Alex 0 siblings, 1 reply; 110+ messages in thread From: Chong Yidong @ 2008-05-03 14:49 UTC (permalink / raw) To: alex, enberg, Glenn Morris; +Cc: nickrob, rms, emacs-devel 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? ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 14:49 ` Chong Yidong @ 2008-05-03 17:02 ` Alex 0 siblings, 0 replies; 110+ messages in thread From: Alex @ 2008-05-03 17:02 UTC (permalink / raw) To: Chong Yidong Cc: Glenn Morris, rms, nickrob, emacs-devel, alex, Venkatesh Pitta, enberg [-- 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 --] ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-02 21:32 ` Chong Yidong 2008-05-03 0:11 ` Glenn Morris @ 2008-05-03 21:00 ` Richard M Stallman 2008-05-04 3:53 ` Eli Zaretskii 1 sibling, 1 reply; 110+ messages in thread From: Richard M Stallman @ 2008-05-03 21:00 UTC (permalink / raw) To: Chong Yidong; +Cc: rgm, nickrob, emacs-devel 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
* Re: Next release 2008-05-03 21:00 ` Richard M Stallman @ 2008-05-04 3:53 ` Eli Zaretskii 0 siblings, 0 replies; 110+ messages in thread From: Eli Zaretskii @ 2008-05-04 3:53 UTC (permalink / raw) To: rms; +Cc: rgm, cyd, nickrob, emacs-devel > 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. ^ permalink raw reply [flat|nested] 110+ messages in thread
end of thread, other threads:[~2008-05-24 3:19 UTC | newest] Thread overview: 110+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-01 9:48 Next release Nick Roberts 2008-05-01 10:32 ` Jason Rumney 2008-05-01 23:07 ` Nick Roberts 2008-05-02 0:04 ` Jason Rumney 2008-05-01 17:43 ` Glenn Morris 2008-05-01 19:52 ` David Kastrup 2008-05-01 20:30 ` Chong Yidong 2008-05-02 1:00 ` Glenn Morris 2008-05-02 6:48 ` CHENG Gao 2008-05-03 1:00 ` Bob 2008-05-03 8:09 ` Richard M Stallman 2008-05-03 9:22 ` CHENG Gao 2008-05-03 9:49 ` YAMAMOTO Mitsuharu 2008-05-03 18:59 ` Stefan Monnier 2008-05-03 19:08 ` Glenn Morris 2008-05-03 21:42 ` Stefan Monnier 2008-05-04 9:37 ` Richard M Stallman 2008-05-04 9:37 ` Richard M Stallman 2008-05-06 0:38 ` YAMAMOTO Mitsuharu 2008-05-23 20:18 ` Problems preloading x-win.el (was: Next release) Stefan Monnier 2008-05-23 21:54 ` Dan Nicolaescu 2008-05-24 2:22 ` Problems preloading x-win.el Stefan Monnier 2008-05-24 3:19 ` Problems preloading x-win.el (was: Next release) YAMAMOTO Mitsuharu 2008-05-02 13:31 ` Next release Dan Nicolaescu 2008-05-02 13:52 ` Jason Rumney 2008-05-02 15:24 ` YAMAMOTO Mitsuharu 2008-05-02 16:10 ` Dan Nicolaescu 2008-05-03 9:38 ` YAMAMOTO Mitsuharu 2008-05-03 19:05 ` Stefan Monnier 2008-05-04 0:56 ` Dan Nicolaescu 2008-05-04 1:25 ` YAMAMOTO Mitsuharu 2008-05-04 1:40 ` Stefan Monnier 2008-05-04 1:57 ` YAMAMOTO Mitsuharu 2008-05-04 3:21 ` Stefan Monnier 2008-05-04 5:07 ` YAMAMOTO Mitsuharu 2008-05-04 15:52 ` Stefan Monnier 2008-05-05 1:28 ` YAMAMOTO Mitsuharu 2008-05-05 5:48 ` Stefan Monnier 2008-05-04 21:35 ` Chong Yidong 2008-05-04 23:52 ` YAMAMOTO Mitsuharu 2008-05-05 0:56 ` Stefan Monnier 2008-05-05 7:43 ` Juanma Barranquero 2008-05-07 18:28 ` Stefan Monnier 2008-05-07 19:13 ` Eli Zaretskii 2008-05-08 1:26 ` Stefan Monnier 2008-05-08 8:22 ` Jason Rumney 2008-05-08 8:32 ` David Kastrup 2008-05-08 9:04 ` David Reitter 2008-05-08 10:40 ` Jan Djärv 2008-05-08 10:55 ` Miles Bader 2008-05-10 8:55 ` Richard M Stallman 2008-05-10 20:30 ` David Kastrup 2008-05-10 23:53 ` David Reitter 2008-05-08 9:06 ` Miles Bader 2008-05-08 9:22 ` Jason Rumney 2008-05-08 9:35 ` Miles Bader 2008-05-08 9:44 ` David Kastrup 2008-05-08 19:47 ` Stephen J. Turnbull 2008-05-08 20:56 ` David Kastrup 2008-05-09 0:52 ` Stefan Monnier 2008-05-09 1:04 ` Miles Bader 2008-05-09 6:07 ` Tassilo Horn 2008-05-09 7:02 ` Eli Zaretskii 2008-05-08 9:51 ` Jason Rumney 2008-05-08 10:08 ` David Kastrup 2008-05-08 10:16 ` Eli Zaretskii 2008-05-08 10:36 ` David Kastrup 2008-05-09 23:54 ` Juri Linkov 2008-05-08 9:45 ` David Kastrup 2008-05-08 10:04 ` Eli Zaretskii 2008-05-08 13:51 ` Stefan Monnier 2008-05-08 13:57 ` Juanma Barranquero 2008-05-08 14:50 ` Miles Bader 2008-05-09 11:12 ` Richard M Stallman 2008-05-08 9:32 ` Eli Zaretskii 2008-05-08 13:46 ` Stefan Monnier 2008-05-08 2:34 ` Juanma Barranquero 2008-05-09 1:35 ` Tool-bar changes (Was: Next release) Chong Yidong 2008-05-09 3:25 ` Tool-bar changes Stefan Monnier 2008-05-09 5:53 ` Tassilo Horn 2008-05-13 18:07 ` Chong Yidong 2008-05-13 18:19 ` Stefan Monnier 2008-05-13 18:38 ` David Reitter 2008-05-13 19:06 ` Eli Zaretskii 2008-05-14 2:17 ` Chong Yidong 2008-05-14 4:28 ` Chong Yidong 2008-05-14 4:47 ` Stefan Monnier 2008-05-14 19:30 ` Chong Yidong 2008-05-14 20:50 ` Chong Yidong 2008-05-15 1:10 ` Stefan Monnier 2008-05-06 0:40 ` Next release YAMAMOTO Mitsuharu 2008-05-04 21:23 ` Chong Yidong 2008-05-05 0:44 ` YAMAMOTO Mitsuharu 2008-05-04 2:06 ` Dan Nicolaescu 2008-05-04 4:21 ` Eli Zaretskii 2008-05-04 6:58 ` Dan Nicolaescu 2008-05-04 8:15 ` David Kastrup 2008-05-04 18:17 ` Eli Zaretskii 2008-05-04 18:59 ` Dan Nicolaescu 2008-05-04 20:31 ` Thomas Lord 2008-05-04 7:36 ` David Kastrup 2008-05-04 16:00 ` Stefan Monnier 2008-05-04 14:34 ` Jason Rumney 2008-05-02 21:13 ` Richard M Stallman 2008-05-02 21:32 ` Chong Yidong 2008-05-03 0:11 ` Glenn Morris 2008-05-03 14:49 ` Chong Yidong 2008-05-03 17:02 ` Alex 2008-05-03 21:00 ` Richard M Stallman 2008-05-04 3:53 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.