* On the rebasing problem of Emacs on Cygwin @ 2006-12-16 9:29 Angelo Graziosi 2006-12-16 14:01 ` Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Angelo Graziosi @ 2006-12-16 9:29 UTC (permalink / raw) Cc: Eli Zaretskii I want to report the following, hoping it can be useful for other users of Emacs on Cygwin. Usually, on Cygwin, one needs to rebase (the DLLs) if an application aborts with a message like this example: ------------- C:\cygwin\bin\python.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to same address as parent(0xDF0000) != 0xE00000 ------------- But, since Cygwin DLL 1.5.17 was released, after the rebasing, Emacs hangs. This happens for the current version 21.2-13 and the exp. ver. 21.3.50-2 on Cygwin. And also for Emacs-CVS. So I have found useful to build Emacs-CVS in this way ---------------------------------------------- LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \ ../configure --prefix=/usr/local/emacs-cvs make LD='$(CC)' bootstrap make LD='$(CC)' install ----------------------------------------------- This makes Emacs independent of rebasing. Note that it needs LD='$(CC)' in the bootstrap so that the GCC command line is gcc ... -Wl,--enable-auto-import -Wl,--enable-auto-image-base ... otherwise it would be gcc ... -Wl,--image-base,0x20000000 -Wl,--enable-auto-import -Wl,--enable-auto-image-base... and Emacs would be built with the base address 0x20000000 and rebasing Cygwin DLLs would cause the hanging. Regards, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: On the rebasing problem of Emacs on Cygwin 2006-12-16 9:29 On the rebasing problem of Emacs on Cygwin Angelo Graziosi @ 2006-12-16 14:01 ` Eli Zaretskii 2006-12-26 9:43 ` WARNING from config.status " Angelo Graziosi ` (2 more replies) 0 siblings, 3 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-12-16 14:01 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 16 Dec 2006 10:29:28 +0100 (MET) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: Eli Zaretskii <eliz@gnu.org> > > I want to report the following, hoping it can be useful for other users of > Emacs on Cygwin. > > Usually, on Cygwin, one needs to rebase (the DLLs) if an application > aborts with a message like this example: > > ------------- > C:\cygwin\bin\python.exe: *** unable to remap C:\cygwin\bin\cygssl.dll to > same address as parent(0xDF0000) != 0xE00000 > ------------- > > > But, since Cygwin DLL 1.5.17 was released, after the rebasing, Emacs > hangs. > > This happens for the current version 21.2-13 and the exp. ver. 21.3.50-2 > on Cygwin. > > And also for Emacs-CVS. > > > So I have found useful to build Emacs-CVS in this way > ---------------------------------------------- > LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \ > ../configure --prefix=/usr/local/emacs-cvs > > make LD='$(CC)' bootstrap > > make LD='$(CC)' install > ----------------------------------------------- > > This makes Emacs independent of rebasing. Thanks, I added a suitable entry to etc/PROBLEMS, describing the problem and its solution, as you proposed. ^ permalink raw reply [flat|nested] 317+ messages in thread
* WARNING from config.status on Cygwin 2006-12-16 14:01 ` Eli Zaretskii @ 2006-12-26 9:43 ` Angelo Graziosi 2006-12-26 11:38 ` Andreas Schwab 2007-01-15 9:02 ` Problems building recent Emacs-CVS " Angelo Graziosi 2007-02-23 13:07 ` cygwin succesfull straight build Angelo Graziosi 2 siblings, 1 reply; 317+ messages in thread From: Angelo Graziosi @ 2006-12-26 9:43 UTC (permalink / raw) Cc: emacs-devel I want to flag that recently at the end of 'configure', bootstrapping Emacs-CVS on Cygwin, there are the following WARNINGS: ------------------------------------------------------ configure: creating ./config.status config.status: creating Makefile config.status: WARNING: /tmp/emacs/Makefile.in seems to ignore the --datarootdir setting config.status: creating lib-src/Makefile.c config.status: creating oldXMenu/Makefile config.status: creating man/Makefile config.status: creating lwlib/Makefile config.status: creating src/Makefile.c config.status: creating lisp/Makefile config.status: creating lispref/Makefile config.status: creating lispintro/Makefile config.status: creating leim/Makefile config.status: WARNING: /tmp/emacs/leim/Makefile.in seems to ignore the --datarootdir setting config.status: creating src/config.h config.status: executing default commands ------------------------------------------------------ Perhaps we need to add datarootdir=@datarootdir@ to those Makefile.in ?! Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: WARNING from config.status on Cygwin 2006-12-26 9:43 ` WARNING from config.status " Angelo Graziosi @ 2006-12-26 11:38 ` Andreas Schwab 0 siblings, 0 replies; 317+ messages in thread From: Andreas Schwab @ 2006-12-26 11:38 UTC (permalink / raw) Cc: Eli Zaretskii, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > I want to flag that recently at the end of 'configure', bootstrapping > Emacs-CVS on Cygwin, there are the following WARNINGS: > > ------------------------------------------------------ > configure: creating ./config.status > config.status: creating Makefile > config.status: WARNING: /tmp/emacs/Makefile.in seems to ignore the > --datarootdir setting > config.status: creating lib-src/Makefile.c > config.status: creating oldXMenu/Makefile > config.status: creating man/Makefile > config.status: creating lwlib/Makefile > config.status: creating src/Makefile.c > config.status: creating lisp/Makefile > config.status: creating lispref/Makefile > config.status: creating lispintro/Makefile > config.status: creating leim/Makefile > config.status: WARNING: /tmp/emacs/leim/Makefile.in seems to ignore the > --datarootdir setting > config.status: creating src/config.h > config.status: executing default commands > ------------------------------------------------------ > > Perhaps we need to add > > datarootdir=@datarootdir@ > > to those Makefile.in ?! The warnings are harmless, the only effect is that the --datarootdir configure option has no effect. But I have added them anyway. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 317+ messages in thread
* Problems building recent Emacs-CVS on Cygwin 2006-12-16 14:01 ` Eli Zaretskii 2006-12-26 9:43 ` WARNING from config.status " Angelo Graziosi @ 2007-01-15 9:02 ` Angelo Graziosi 2007-02-23 13:07 ` cygwin succesfull straight build Angelo Graziosi 2 siblings, 0 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-01-15 9:02 UTC (permalink / raw) Cc: Eli Zaretskii I want to flag that the build of Emacs fails (toward the end, I think) as follow: --------------------------------------------------------------- make[3]: Entering directory `/tmp/emacs/.build/leim' mkdir quail touch stamp-subdir EMACSLOADPATH=/tmp/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /tmp/emacs/leim/../lisp/international/titdic-cnv \ -f batch-titdic-convert -dir quail /tmp/emacs/leim/CXTERM-DIC; \ echo "changed" > changed.tit Fatal error (6)/bin/sh: line 2: 1648 Aborted (core dumped) EMACSLOADPATH=/tmp/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /tmp/emacs/leim/../lisp/international/titdic-cnv -f batch-titdic-convert -dir quail /tmp/emacs/leim/CXTERM-DIC EMACSLOADPATH=/tmp/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile quail/CCDOSPY.el >>Error occurred processing quail/CCDOSPY.el: File error (("Opening input file" "no such file or directory" "/tmp/emacs/.build/leim/quail/CCDOSPY.el")) make[3]: *** [quail/CCDOSPY.elc] Error 1 make[3]: Leaving directory `/tmp/emacs/.build/leim' make[2]: *** [leim] Error 2 make[2]: Leaving directory `/tmp/emacs/.build' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/tmp/emacs/.build' make: *** [bootstrap] Error 2 --------------------------------------------------------------- I did the last useful build with CVS-20070106 (cvs... -D 20070106...). I have observed that deleting LC_ALL=C from leim/Makefile.in allows for the build to be completed but the resulting Emacs does not work. Also, increasing the nested level of building directory (/home/Angelo/Downloads/cygwin_varie/emacs-cvs/Build/emacs/.build instead of /tmp/emacs/.build) allows for the build to be stopped near the end, i.e. it fail later. In recent src/ChangeLog there is written: ------------------------------------------ 2007-01-13 Eli Zaretskii <eliz@gnu.org> * process.c (Fdelete_process, Fprocess_id, sigchld_handler): Copy PID into EMACS_INT to avoid GCC warnings. ------------------------------------------ To build I use GCC 4.0.3 (on Cygwin, as you remember, 3.4.4 gives an Emacs that segment faults) and there is, in any case, the warning: ------------------------------------------- /tmp/emacs/src/process.c: In function 'status_message': /tmp/emacs/src/process.c:491: warning: assignment discards qualifiers from pointer target type ------------------------------------------- in building 'temacs.exe' (after 'configure' and toward the end). Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: cygwin succesfull straight build 2006-12-16 14:01 ` Eli Zaretskii 2006-12-26 9:43 ` WARNING from config.status " Angelo Graziosi 2007-01-15 9:02 ` Problems building recent Emacs-CVS " Angelo Graziosi @ 2007-02-23 13:07 ` Angelo Graziosi 2007-02-23 18:15 ` Eli Zaretskii 2 siblings, 1 reply; 317+ messages in thread From: Angelo Graziosi @ 2007-02-23 13:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii wrote: > It is important for us to know whether the distribution tarball builds > (./configure; make; make install) cleanly on all supported platforms. If the pretest is ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.93.tar.gz (timestamp 01/23/2007 01:16, size 37,118,034), I have built it on Cygwin, since it was released, without problems (using GCC-4.0.3 for stability reasons). Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: cygwin succesfull straight build 2007-02-23 13:07 ` cygwin succesfull straight build Angelo Graziosi @ 2007-02-23 18:15 ` Eli Zaretskii 2007-03-07 1:26 ` Pretest? Angelo Graziosi ` (2 more replies) 0 siblings, 3 replies; 317+ messages in thread From: Eli Zaretskii @ 2007-02-23 18:15 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel > Date: Fri, 23 Feb 2007 14:07:19 +0100 (MET) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > > It is important for us to know whether the distribution tarball builds > > (./configure; make; make install) cleanly on all supported platforms. > > > If the pretest is > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.93.tar.gz (timestamp > 01/23/2007 01:16, size 37,118,034), I have built it on Cygwin, since it > was released, without problems (using GCC-4.0.3 for stability reasons). Thanks. But I'd like to hear from other Cygwin users as well, if there are any. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-02-23 18:15 ` Eli Zaretskii @ 2007-03-07 1:26 ` Angelo Graziosi 2007-03-08 19:40 ` Pretest? Chong Yidong 2007-03-07 13:37 ` Help: build emacs in cygwin Angelo Graziosi 2007-03-09 1:06 ` Killing buffers with mouse Angelo Graziosi 2 siblings, 1 reply; 317+ messages in thread From: Angelo Graziosi @ 2007-03-07 1:26 UTC (permalink / raw) To: emacs-devel; +Cc: Eli Zaretskii Chong Yidong wrote: > I have rolled a 22.0.95 tarball, which can be found at the usual > location: > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95.tar.gz > ... > I would know, if possible, how emacs-22.0.95.tar.gz has been generated. Thanks, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-07 1:26 ` Pretest? Angelo Graziosi @ 2007-03-08 19:40 ` Chong Yidong 2007-03-09 13:59 ` Pretest? Giorgos Keramidas 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-08 19:40 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > Chong Yidong wrote: > >> I have rolled a 22.0.95 tarball, which can be found at the usual >> location: > >> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95.tar.gz >> ... >> > > I would know, if possible, how emacs-22.0.95.tar.gz has been generated. See admin/make-tarball.txt in the CVS repository. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-08 19:40 ` Pretest? Chong Yidong @ 2007-03-09 13:59 ` Giorgos Keramidas 2007-03-09 14:44 ` Pretest? Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Giorgos Keramidas @ 2007-03-09 13:59 UTC (permalink / raw) To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel On 2007-03-08 14:40, Chong Yidong <cyd@stupidchicken.com> wrote: >> I would know, if possible, how emacs-22.0.95.tar.gz has been generated. > > See admin/make-tarball.txt in the CVS repository. Hi all, just a quick question: Are we going to have a new pretest tarball this week too? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 13:59 ` Pretest? Giorgos Keramidas @ 2007-03-09 14:44 ` Chong Yidong 2007-03-09 17:07 ` Pretest? Christian Faulhammer ` (3 more replies) 0 siblings, 4 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-09 14:44 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: Eli Zaretskii, emacs-devel Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > On 2007-03-08 14:40, Chong Yidong <cyd@stupidchicken.com> wrote: >>> I would know, if possible, how emacs-22.0.95.tar.gz has been generated. >> >> See admin/make-tarball.txt in the CVS repository. > > Hi all, just a quick question: > > Are we going to have a new pretest tarball this week too? I would like to suggest issuing a pretest on Monday the 12th. What do people think? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 14:44 ` Pretest? Chong Yidong @ 2007-03-09 17:07 ` Christian Faulhammer 2007-03-09 17:35 ` Pretest? Juanma Barranquero 2007-03-09 17:49 ` Pretest? Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 317+ messages in thread From: Christian Faulhammer @ 2007-03-09 17:07 UTC (permalink / raw) To: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 299 bytes --] Chong Yidong <cyd@stupidchicken.com>: > > Are we going to have a new pretest tarball this week too? > I would like to suggest issuing a pretest on Monday the 12th. What do > people think? Good idea, as there is a at least one annyoing bug in the snapshot that is fixed in CVS. V-Li [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 17:07 ` Pretest? Christian Faulhammer @ 2007-03-09 17:35 ` Juanma Barranquero 2007-03-09 18:33 ` Pretest? Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-09 17:35 UTC (permalink / raw) To: Christian Faulhammer; +Cc: emacs-devel On 3/9/07, Christian Faulhammer <v-li@gmx.de> wrote: > Good idea, as there is a at least one annyoing bug in the snapshot > that is fixed in CVS. What about M-: (describe-buffer-bindings "*scratch*") => CRASH! Is not annoying, just un-nice. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 17:35 ` Pretest? Juanma Barranquero @ 2007-03-09 18:33 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-09 18:33 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Christian Faulhammer, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/9/07, Christian Faulhammer <v-li@gmx.de> wrote: > >> Good idea, as there is a at least one annyoing bug in the snapshot >> that is fixed in CVS. > > What about > > M-: (describe-buffer-bindings "*scratch*") => CRASH! > > Is not annoying, just un-nice. Thanks for finding that bug (and fixing it). ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 14:44 ` Pretest? Chong Yidong 2007-03-09 17:07 ` Pretest? Christian Faulhammer @ 2007-03-09 17:49 ` Eli Zaretskii 2007-03-09 18:07 ` Pretest? Giorgos Keramidas 2007-03-09 21:26 ` Pretest? Richard Stallman 2007-03-12 10:39 ` Pretest? Juanma Barranquero 3 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2007-03-09 17:49 UTC (permalink / raw) To: Chong Yidong; +Cc: keramida, emacs-devel > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Fri, 09 Mar 2007 09:44:23 -0500 > > I would like to suggest issuing a pretest on Monday the 12th. What do > people think? I think we need a new pretest ASAP, as the current one has a broken ps-print. March 12 is fine. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 17:49 ` Pretest? Eli Zaretskii @ 2007-03-09 18:07 ` Giorgos Keramidas 0 siblings, 0 replies; 317+ messages in thread From: Giorgos Keramidas @ 2007-03-09 18:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Chong Yidong, emacs-devel On 2007-03-09 19:49, Eli Zaretskii <eliz@gnu.org> wrote: > > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > From: Chong Yidong <cyd@stupidchicken.com> > > Date: Fri, 09 Mar 2007 09:44:23 -0500 > > > > I would like to suggest issuing a pretest on Monday the 12th. What do > > people think? > > I think we need a new pretest ASAP, as the current one has a broken > ps-print. March 12 is fine. Cool! This was partly the reason for my asking. emacs-22.0.95 and ps-print fails here, but CVS head works fine. Thanks for the fast replies :) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 14:44 ` Pretest? Chong Yidong 2007-03-09 17:07 ` Pretest? Christian Faulhammer 2007-03-09 17:49 ` Pretest? Eli Zaretskii @ 2007-03-09 21:26 ` Richard Stallman 2007-03-12 10:39 ` Pretest? Juanma Barranquero 3 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-09 21:26 UTC (permalink / raw) To: Chong Yidong; +Cc: keramida, eliz, emacs-devel I would like to suggest issuing a pretest on Monday the 12th. What do people think? Sounds good to me. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-09 14:44 ` Pretest? Chong Yidong ` (2 preceding siblings ...) 2007-03-09 21:26 ` Pretest? Richard Stallman @ 2007-03-12 10:39 ` Juanma Barranquero 2007-03-12 10:42 ` Pretest? David Kastrup ` (3 more replies) 3 siblings, 4 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-12 10:39 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 3/9/07, Chong Yidong <cyd@stupidchicken.com> wrote: > I would like to suggest issuing a pretest on Monday the 12th. What do > people think? If you don't mind, I'd like to reach a consensus with respect to the emacsclient / isearch discussion in emacs-pretest-bugs. The proposed patch is tiny (seven lines plus comments), but the issue is larger, as it seems like Richard doesn't like emacsclient / server "forcibly exit[ing] the minibuffer" or "interfer[ing] with isearch". Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 10:39 ` Pretest? Juanma Barranquero @ 2007-03-12 10:42 ` David Kastrup 2007-03-12 11:46 ` Pretest? Juanma Barranquero 2007-03-12 14:53 ` Pretest? Stefan Monnier ` (2 subsequent siblings) 3 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-12 10:42 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Chong Yidong, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/9/07, Chong Yidong <cyd@stupidchicken.com> wrote: > >> I would like to suggest issuing a pretest on Monday the 12th. What do >> people think? > > If you don't mind, I'd like to reach a consensus with respect to the > emacsclient / isearch discussion in emacs-pretest-bugs. The proposed > patch is tiny (seven lines plus comments), but the issue is larger, as > it seems like Richard doesn't like emacsclient / server "forcibly > exit[ing] the minibuffer" or "interfer[ing] with isearch". Well, seems like diverting the pretest-bug list to emacs-devel might not be the worst idea after all. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 10:42 ` Pretest? David Kastrup @ 2007-03-12 11:46 ` Juanma Barranquero 0 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-12 11:46 UTC (permalink / raw) To: David Kastrup; +Cc: Chong Yidong, emacs-devel On 3/12/07, David Kastrup <dak@gnu.org> wrote: > "Juanma Barranquero" <lekktu@gmail.com> writes: > Well, seems like diverting the pretest-bug list to emacs-devel might > not be the worst idea after all. My thoughs exactly ;-) Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 10:39 ` Pretest? Juanma Barranquero 2007-03-12 10:42 ` Pretest? David Kastrup @ 2007-03-12 14:53 ` Stefan Monnier 2007-03-12 15:46 ` Pretest? Juanma Barranquero 2007-03-12 20:55 ` Pretest? Chong Yidong 2007-03-13 2:43 ` Pretest? Richard Stallman 3 siblings, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2007-03-12 14:53 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Chong Yidong, emacs-devel > If you don't mind, I'd like to reach a consensus with respect to the > emacsclient / isearch discussion in emacs-pretest-bugs. I don't see why this should delay the next pretest. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 14:53 ` Pretest? Stefan Monnier @ 2007-03-12 15:46 ` Juanma Barranquero 2007-03-12 15:53 ` Pretest? David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-12 15:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel On 3/12/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I don't see why this should delay the next pretest. It seems a bit silly to release a pretest just to change something non-trivial immediately afterwards. The patch I'm proposing is trivial, but IIUC what Richard is saying, perhaps greater changes will be needed. There's no harm in waiting a day or three, is it? Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 15:46 ` Pretest? Juanma Barranquero @ 2007-03-12 15:53 ` David Kastrup 0 siblings, 0 replies; 317+ messages in thread From: David Kastrup @ 2007-03-12 15:53 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Chong Yidong, Stefan Monnier, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/12/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >> I don't see why this should delay the next pretest. > > It seems a bit silly to release a pretest just to change something > non-trivial immediately afterwards. The patch I'm proposing is > trivial, but IIUC what Richard is saying, perhaps greater changes will > be needed. There's no harm in waiting a day or three, is it? For every pretest, I hope it will be the last. My next important conference with Emacs tutorials is at the end of April. A release will make persuading people to use Emacs 22 much easier. So I agree that it seems pointless to make a prerelease when fundamental things are scheduled for change or fixes. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 10:39 ` Pretest? Juanma Barranquero 2007-03-12 10:42 ` Pretest? David Kastrup 2007-03-12 14:53 ` Pretest? Stefan Monnier @ 2007-03-12 20:55 ` Chong Yidong 2007-03-12 21:32 ` Pretest? Juanma Barranquero 2007-03-13 2:43 ` Pretest? Richard Stallman 3 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-12 20:55 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/9/07, Chong Yidong <cyd@stupidchicken.com> wrote: > >> I would like to suggest issuing a pretest on Monday the 12th. What do >> people think? > > If you don't mind, I'd like to reach a consensus with respect to the > emacsclient / isearch discussion in emacs-pretest-bugs. The proposed > patch is tiny (seven lines plus comments), but the issue is larger, as > it seems like Richard doesn't like emacsclient / server "forcibly > exit[ing] the minibuffer" or "interfer[ing] with isearch". >From reading the discussion, I don't think there is any indication that a big change to Emacs is being called for (even taking Richard's rather terse comments into account). ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 20:55 ` Pretest? Chong Yidong @ 2007-03-12 21:32 ` Juanma Barranquero 2007-03-13 1:03 ` Pretest? Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-12 21:32 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 3/12/07, Chong Yidong <cyd@stupidchicken.com> wrote: > From reading the discussion, I don't think there is any indication > that a big change to Emacs is being called for I didn't say "big". Still, I think significant would be a good description. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 21:32 ` Pretest? Juanma Barranquero @ 2007-03-13 1:03 ` Chong Yidong 2007-03-13 9:37 ` Pretest? Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-13 1:03 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/12/07, Chong Yidong <cyd@stupidchicken.com> wrote: > >> From reading the discussion, I don't think there is any indication >> that a big change to Emacs is being called for > > I didn't say "big". Still, I think significant would be a good description. OK, let's wait a couple of days till Wednesday the 14th. I'd like to know exactly what "significant" changes Richard is asking for. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 1:03 ` Pretest? Chong Yidong @ 2007-03-13 9:37 ` Juanma Barranquero 0 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-13 9:37 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 3/13/07, Chong Yidong <cyd@stupidchicken.com> wrote: > I'd like to know exactly what "significant" changes Richard is asking > for. The ones in the next message in the thread? Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-12 10:39 ` Pretest? Juanma Barranquero ` (2 preceding siblings ...) 2007-03-12 20:55 ` Pretest? Chong Yidong @ 2007-03-13 2:43 ` Richard Stallman 2007-03-13 9:43 ` Pretest? Juanma Barranquero 3 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-13 2:43 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, emacs-devel If you don't mind, I'd like to reach a consensus with respect to the emacsclient / isearch discussion in emacs-pretest-bugs. The proposed patch is tiny (seven lines plus comments), but the issue is larger, as it seems like Richard doesn't like emacsclient / server "forcibly exit[ing] the minibuffer" or "interfer[ing] with isearch". I think that in cases like this server.el should display the new buffer in another window, so that the user knows to go over and edit it. But server.el should not mess up the command that is being executed. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 2:43 ` Pretest? Richard Stallman @ 2007-03-13 9:43 ` Juanma Barranquero 2007-03-13 9:52 ` Pretest? Andreas Schwab 2007-03-14 3:24 ` Pretest? Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-13 9:43 UTC (permalink / raw) To: rms; +Cc: cyd, emacs-devel On 3/13/07, Richard Stallman <rms@gnu.org> wrote: > I think that in cases like this server.el should display the new buffer > in another window, so that the user knows to go over and edit it. If the user wants server.el to display emacsclient-sent buffers in another window or frame, he can set server-window. > But server.el should not mess up the command that is being executed. As David pointed out, emacsclient is rarely started in an asynchronous way; usually is as a result of user interaction, either clicking somewhere or typing "emacsclient myfile" in a shell. "Messing up" with the command being executed is exactly what I would expect from such an action. And IIRC, both the current isearch issue and the previous patch to abort recursive editing were prompted by users considering not doing that as a bug. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 9:43 ` Pretest? Juanma Barranquero @ 2007-03-13 9:52 ` Andreas Schwab 2007-03-13 10:09 ` Pretest? David Kastrup 2007-03-13 10:23 ` Pretest? Juanma Barranquero 2007-03-14 3:24 ` Pretest? Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: Andreas Schwab @ 2007-03-13 9:52 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, rms, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/13/07, Richard Stallman <rms@gnu.org> wrote: > >> But server.el should not mess up the command that is being executed. > > As David pointed out, emacsclient is rarely started in an asynchronous > way; usually is as a result of user interaction, either clicking > somewhere or typing "emacsclient myfile" in a shell. "Messing up" with > the command being executed is exactly what I would expect from such an > action. I agree. I have sometimes wondered why my emacsclient frame does not pop up (I have set server-window to create a new frame) when I have forgotten to exit an isearch in another frame. Normally almost any command will abort the isearch. > And IIRC, both the current isearch issue and the previous > patch to abort recursive editing were prompted by users considering > not doing that as a bug. Which I agree with aborting isearch, I don't agree with aborting a recursive editing, since the latter is not as much a modal thing. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 9:52 ` Pretest? Andreas Schwab @ 2007-03-13 10:09 ` David Kastrup 2007-03-13 10:23 ` Pretest? Juanma Barranquero 1 sibling, 0 replies; 317+ messages in thread From: David Kastrup @ 2007-03-13 10:09 UTC (permalink / raw) To: Andreas Schwab; +Cc: Juanma Barranquero, cyd, rms, emacs-devel Andreas Schwab <schwab@suse.de> writes: > "Juanma Barranquero" <lekktu@gmail.com> writes: > >> On 3/13/07, Richard Stallman <rms@gnu.org> wrote: >> >>> But server.el should not mess up the command that is being executed. >> >> As David pointed out, emacsclient is rarely started in an asynchronous >> way; usually is as a result of user interaction, either clicking >> somewhere or typing "emacsclient myfile" in a shell. "Messing up" with >> the command being executed is exactly what I would expect from such an >> action. > > I agree. I have sometimes wondered why my emacsclient frame does not pop > up (I have set server-window to create a new frame) when I have forgotten > to exit an isearch in another frame. Normally almost any command will > abort the isearch. > >> And IIRC, both the current isearch issue and the previous >> patch to abort recursive editing were prompted by users considering >> not doing that as a bug. > > Which I agree with aborting isearch, I don't agree with aborting a > recursive editing, since the latter is not as much a modal thing. To make that clear: my suggestion was about exiting the minibuffer. However, if point moves to the buffer window, exiting the minibuffer can probably be left to the normal recursive-minibuffer mechanisms that kick in when the user tries using the minibuffer other than moving back into it with C-x o. So that suggestion of mine was probably not really an improvement. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 9:52 ` Pretest? Andreas Schwab 2007-03-13 10:09 ` Pretest? David Kastrup @ 2007-03-13 10:23 ` Juanma Barranquero 2007-03-19 5:15 ` Pretest? Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-13 10:23 UTC (permalink / raw) To: Andreas Schwab; +Cc: cyd, rms, emacs-devel On 3/13/07, Andreas Schwab <schwab@suse.de> wrote: > Which I agree with aborting isearch, I don't agree with aborting a > recursive editing, since the latter is not as much a modal thing. This is the relevant code from server.el, which has been in place for 107 days now: (when (> (recursion-depth) 0) ;; We're inside a minibuffer already, so if the emacs-client is trying ;; to open a frame on a new display, we might end up with an unusable ;; frame because input from that display will be blocked (until exiting ;; the minibuffer). Better exit this minibuffer right away. ;; Similarly with recursive-edits such as the splash screen. (process-put proc :previous-string string) (run-with-timer 0 nil (lexical-let ((proc proc)) (lambda () (server-process-filter proc "")))) (top-level)) Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 10:23 ` Pretest? Juanma Barranquero @ 2007-03-19 5:15 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-19 5:15 UTC (permalink / raw) To: Juanma Barranquero; +Cc: schwab, cyd, emacs-devel ;; We're inside a minibuffer already, so if the emacs-client is trying ;; to open a frame on a new display, we might end up with an unusable ;; frame because input from that display will be blocked (until exiting ;; the minibuffer). Better exit this minibuffer right away. ;; Similarly with recursive-edits such as the splash screen. In the case where it really is on a different display, and if you don't see that other display, the result would be very undesirable. This code prevents that bad result. Unfortunately, there is no way ot distinguish the various cases, because there is no way for Lisp code to find out which frame or display the minibuffer is on. So I guess this has to be left alone. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-13 9:43 ` Pretest? Juanma Barranquero 2007-03-13 9:52 ` Pretest? Andreas Schwab @ 2007-03-14 3:24 ` Richard Stallman 2007-03-14 7:10 ` Pretest? David Kastrup ` (2 more replies) 1 sibling, 3 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-14 3:24 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, emacs-devel > I think that in cases like this server.el should display the new buffer > in another window, so that the user knows to go over and edit it. If the user wants server.el to display emacsclient-sent buffers in another window or frame, he can set server-window. Yes, but that is a different issue. I am talking about what to do when emacsclient wants to display a buffer, but something like a minibuffer or an isearch prevents it from switching effectively to that buffer in the normal way. It should display that buffer in another window, and not abort anything. And IIRC, both the current isearch issue and the previous patch to abort recursive editing were prompted by users considering not doing that as a bug. I thought they complained because the buffer was not visible. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 3:24 ` Pretest? Richard Stallman @ 2007-03-14 7:10 ` David Kastrup 2007-03-14 13:39 ` Pretest? Stefan Monnier 2007-03-14 9:18 ` Pretest? Juanma Barranquero 2007-03-14 13:56 ` Pretest? Chong Yidong 2 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-14 7:10 UTC (permalink / raw) To: rms; +Cc: Juanma Barranquero, cyd, emacs-devel Richard Stallman <rms@gnu.org> writes: > > I think that in cases like this server.el should display the new buffer > > in another window, so that the user knows to go over and edit it. > > If the user wants server.el to display emacsclient-sent buffers in > another window or frame, he can set server-window. > > Yes, but that is a different issue. I am talking about what to do > when emacsclient wants to display a buffer, but something like a > minibuffer or an isearch prevents it from switching effectively to > that buffer in the normal way. > > It should display that buffer in another window, and not abort > anything. > > And IIRC, both the current isearch issue and the previous > patch to abort recursive editing were prompted by users considering > not doing that as a bug. > > I thought they complained because the buffer was not visible. You can't show the buffer if an isearch is going on in a single frame with a single window and you are not going to interrupt isearch. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 7:10 ` Pretest? David Kastrup @ 2007-03-14 13:39 ` Stefan Monnier 2007-03-14 14:04 ` Pretest? David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2007-03-14 13:39 UTC (permalink / raw) To: David Kastrup; +Cc: Juanma Barranquero, cyd, rms, emacs-devel > You can't show the buffer if an isearch is going on in a single frame > with a single window and you are not going to interrupt isearch. Why not? Why can't it pop up in a new window? Stefan PS: I don't know if it'd be a good idea, tho. I'm just trying to understand. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 13:39 ` Pretest? Stefan Monnier @ 2007-03-14 14:04 ` David Kastrup 2007-03-14 14:19 ` Pretest? Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-14 14:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, cyd, rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> You can't show the buffer if an isearch is going on in a single frame >> with a single window and you are not going to interrupt isearch. > > Why not? Why can't it pop up in a new window? Where would that window be? Are you talking about splitting the frame? That might involve recentering. It would also be out of character to move window-point to the new window, since isearch does not normally offer a way to do window changes without exiting isearch. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 14:04 ` Pretest? David Kastrup @ 2007-03-14 14:19 ` Stefan Monnier 0 siblings, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2007-03-14 14:19 UTC (permalink / raw) To: David Kastrup; +Cc: Juanma Barranquero, cyd, rms, emacs-devel >>> You can't show the buffer if an isearch is going on in a single frame >>> with a single window and you are not going to interrupt isearch. >> Why not? Why can't it pop up in a new window? > Where would that window be? Are you talking about splitting the > frame? Well, yes: a *new* window. > That might involve recentering. Big deal! > It would also be out of character to move window-point to the new window, > since isearch does not normally offer a way to do window changes without > exiting isearch. Well, as I said in my PS whether it's a good idea or not is a separate issue. I was asking specifically why you thought it "can't" be done. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 3:24 ` Pretest? Richard Stallman 2007-03-14 7:10 ` Pretest? David Kastrup @ 2007-03-14 9:18 ` Juanma Barranquero 2007-03-14 9:32 ` Pretest? David Kastrup 2007-03-14 13:56 ` Pretest? Chong Yidong 2 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-14 9:18 UTC (permalink / raw) To: rms; +Cc: cyd, emacs-devel On 3/14/07, Richard Stallman <rms@gnu.org> wrote: > I thought they complained because the buffer was not visible. The reporter said: "emacsclient seems to interrupt find-file, swith-to-buffer and areas marked to be copied, so I think it is somewhat inconsistent not to quit isearch and put the new buffer on top." We haven't done a poll of user expectations with respect to emacsclient, but I certainly wouldn't just expect the buffer to be visible, but selected as well. Cancelling isearch is not something done in extreme circunstances; almost anything you type or do will cancel it (like switching to another frame). What's so special in cancelling it from emacsclient? Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 9:18 ` Pretest? Juanma Barranquero @ 2007-03-14 9:32 ` David Kastrup 2007-03-14 9:44 ` Pretest? Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-14 9:32 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, rms, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/14/07, Richard Stallman <rms@gnu.org> wrote: > >> I thought they complained because the buffer was not visible. > > The reporter said: "emacsclient seems to interrupt find-file, > swith-to-buffer and areas marked to be copied, so I think it is > somewhat inconsistent not to quit isearch and put the new buffer on > top." > > We haven't done a poll of user expectations with respect to > emacsclient, but I certainly wouldn't just expect the buffer to be > visible, but selected as well. > > Cancelling isearch is not something done in extreme circunstances; > almost anything you type or do will cancel it (like switching to > another frame). What's so special in cancelling it from emacsclient? Agreed. However, we should still come up with a suitable strategy concerning what we should do when we are in a minibuffer for other reasons (such as M-x). My initial impulse would be to let an emacsclient call behave like C-x C-f: this would with the default setting of enable-recursive-minibuffers (nil) cancel the minibuffer command, return to a non-minibuffer window and open the given file there. With enable-recursive-minibuffers to t, however, would then cause the message "Cannot switch buffers in minibuffer window". Suboptimal. But at least for the default settings, the behavior would be very much like what is expected. And I think even in the case where emacsclient -eval is used, the assumption of "clear minibuffer usage" seems reasonable, since that is somewhat equivalent to using M-: -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 9:32 ` Pretest? David Kastrup @ 2007-03-14 9:44 ` Juanma Barranquero 2007-03-14 10:07 ` Pretest? David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-14 9:44 UTC (permalink / raw) To: David Kastrup; +Cc: cyd, rms, emacs-devel On 3/14/07, David Kastrup <dak@gnu.org> wrote: > However, we should still come up with a suitable strategy > concerning what we should do when we are in a minibuffer for other > reasons (such as M-x). [...] > With enable-recursive-minibuffers to t, however, would then cause the > message "Cannot switch buffers in minibuffer window". Curious. I have enable-recursive-minibuffers set to t, but I would still expect emacsclient to interrupt M-x, etc. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 9:44 ` Pretest? Juanma Barranquero @ 2007-03-14 10:07 ` David Kastrup 2007-03-14 10:17 ` Pretest? Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-14 10:07 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, rms, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 3/14/07, David Kastrup <dak@gnu.org> wrote: > >> However, we should still come up with a suitable strategy >> concerning what we should do when we are in a minibuffer for other >> reasons (such as M-x). > > [...] > >> With enable-recursive-minibuffers to t, however, would then cause the >> message "Cannot switch buffers in minibuffer window". > > Curious. I have enable-recursive-minibuffers set to t, but I would > still expect emacsclient to interrupt M-x, etc. What is "curious" about that? I proposed what I consider a pretty logical and consistent way of dealing with emacsclient calls, and then mentioned a drawback of this for a certain setting. And now you call it curious that what I mention as a drawback does not strike you as the best behavior? Curious. Anyway: people are ready to forward their expectations all around. The question is how we can tie the various expectations into some rules and behavior that will be acceptable to most people under most settings. If we can find a simple rule set working for all cases reasonably well, this would be optimal. I proposed a simple rule set and mentioned that I considered some special case of it undesirable. Can you can come up with a good rule set (with as few exceptions as possible, since we want to avoid introducing lots of special cases) that is better-behaved? If so, please do. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 10:07 ` Pretest? David Kastrup @ 2007-03-14 10:17 ` Juanma Barranquero 0 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-14 10:17 UTC (permalink / raw) To: David Kastrup; +Cc: cyd, rms, emacs-devel On 3/14/07, David Kastrup <dak@gnu.org> wrote: > What is "curious" about that? I proposed what I consider a pretty > logical and consistent way of dealing with emacsclient calls, and then > mentioned a drawback of this for a certain setting. > > And now you call it curious that what I mention as a drawback does not > strike you as the best behavior? > > Curious. Please, don't be so jumpy, because I tend to answer in the same mood and that leads to me being labeled as "aggressive" pretty fast :) My "curious" was meant as "it is curious how wildly different expectations are from one user (or indeed, developer) to another". No judgement, no implication that my choice was better, no nothing but a little wonder about human variability (and irritability, I would add as an afterthought). Honestly: I just read an old thread from September 2005 where some people was hopeful that 22.1 could be released that same year. So I'm now just a little sad, and the issue of whether emacsclient interrupts or not seems less and less important to me. I'd only like to ask that an option be left somewhere so overeager interrupters like me can do our thing without having to hack server.el. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 3:24 ` Pretest? Richard Stallman 2007-03-14 7:10 ` Pretest? David Kastrup 2007-03-14 9:18 ` Pretest? Juanma Barranquero @ 2007-03-14 13:56 ` Chong Yidong 2007-03-14 14:24 ` Pretest? Stefan Monnier 2007-03-15 1:38 ` Pretest? Richard Stallman 2 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-14 13:56 UTC (permalink / raw) To: rms; +Cc: Juanma Barranquero, emacs-devel Richard Stallman <rms@gnu.org> writes: > > I think that in cases like this server.el should display the new buffer > > in another window, so that the user knows to go over and edit it. > > If the user wants server.el to display emacsclient-sent buffers in > another window or frame, he can set server-window. > > Yes, but that is a different issue. I am talking about what to do > when emacsclient wants to display a buffer, but something like a > minibuffer or an isearch prevents it from switching effectively to > that buffer in the normal way. > > It should display that buffer in another window, and not abort > anything. That might means the new buffer will not be immediately available for editing, until the user cancels the minibuffer or isearch. If the user calls emacsclient, the intention is almost certainly to perform the edit in Emacs, so this is a minor nuisance. Another possible complication (which I haven't thought much about) is when Emacs has frames open on more than one display. If you are currently working on one display, having left isearch on in another display, invoking emacsclient might lead to puzzling behavior. Anyway, I don't feel strongly about this issue one way or another. As Juanma has said, it's rather sad to have the Emacs 22 release drag on and on while we deal with this kind of nitpicky issues. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 13:56 ` Pretest? Chong Yidong @ 2007-03-14 14:24 ` Stefan Monnier 2007-03-15 1:38 ` Pretest? Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2007-03-14 14:24 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, rms, emacs-devel > Another possible complication (which I haven't thought much about) is > when Emacs has frames open on more than one display. If you are > currently working on one display, having left isearch on in another > display, invoking emacsclient might lead to puzzling behavior. Read the relevant code in server.el. It contains a comment that explains that the exit-minibuffer behavior is there specifically to deal with multi-display situations. This same problem doesn't directly affect isearch I believe, or at least not to the same extent (with recursive edits, the active terminal grabs control, so the other display's events are completely blocked). Supposedly, since isearch uses overriding-terminal-local-map, it should be possible to keep isearch running on the other display, but I believe that the current implementation of isearch mixes up terminal-local, buffer-local, and global settings in such a messed up way that it won't work without further changes. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-14 13:56 ` Pretest? Chong Yidong 2007-03-14 14:24 ` Pretest? Stefan Monnier @ 2007-03-15 1:38 ` Richard Stallman 2007-03-15 10:04 ` Pretest? Juanma Barranquero 2007-03-15 15:44 ` Pretest? Chong Yidong 1 sibling, 2 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-15 1:38 UTC (permalink / raw) To: Chong Yidong; +Cc: lekktu, emacs-devel > It should display that buffer in another window, and not abort > anything. That might means the new buffer will not be immediately available for editing, until the user cancels the minibuffer or isearch. That is right. The user will see the other buffer appear, and can either finish or cancel the command that is in progress. I think that is less harsh. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-15 1:38 ` Pretest? Richard Stallman @ 2007-03-15 10:04 ` Juanma Barranquero 2007-03-16 5:20 ` Pretest? Richard Stallman 2007-03-15 15:44 ` Pretest? Chong Yidong 1 sibling, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-15 10:04 UTC (permalink / raw) To: rms; +Cc: Chong Yidong, emacs-devel On 3/15/07, Richard Stallman <rms@gnu.org> wrote: > That is right. The user will see the other buffer appear, and can > either finish or cancel the command that is in progress. I think that > is less harsh. For some definition of "less harsh" that maps nicely to your tastes, perhaps. I much prefer to be interrupted, and profoundly dislike any code that splits my window without my explicit request. (Consider this as a petition to, at the very least, add an option to enable the interrupting, non-window-splitting behavior.) Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-15 10:04 ` Pretest? Juanma Barranquero @ 2007-03-16 5:20 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-16 5:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, emacs-devel (Consider this as a petition to, at the very least, add an option to enable the interrupting, non-window-splitting behavior.) I don't mind having it as an option. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-15 1:38 ` Pretest? Richard Stallman 2007-03-15 10:04 ` Pretest? Juanma Barranquero @ 2007-03-15 15:44 ` Chong Yidong 2007-03-16 5:21 ` Pretest? Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-15 15:44 UTC (permalink / raw) To: rms; +Cc: lekktu, emacs-devel Richard Stallman <rms@gnu.org> writes: > > It should display that buffer in another window, and not abort > > anything. > > That might means the new buffer will not be immediately available for > editing, until the user cancels the minibuffer or isearch. > > That is right. The user will see the other buffer appear, and can > either finish or cancel the command that is in progress. I think that > is less harsh. By the way, do you actually use emacsclient/server yourself? It seems that people who actually do use emacsclient (well, and also everyone else who has weighed in on this matter) feel it is more intuitive for an emacsclient call to interrupt isearch, rather than the behavior you are proposing. In that sense, your "less harsh" behavior---whatever other benefits it might have---is actually more harsh, because it doesn't do what people expect. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-15 15:44 ` Pretest? Chong Yidong @ 2007-03-16 5:21 ` Richard Stallman 2007-03-16 7:36 ` Pretest? David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-16 5:21 UTC (permalink / raw) To: Chong Yidong; +Cc: lekktu, emacs-devel By the way, do you actually use emacsclient/server yourself? No, I don't use it. I have only occasionally tested it. I wonder about the statement that emacsclient is always invoked at specific user request. Indeed, that is usually so, but is it always so? As usage becomes more diverse, I expect it will cease to be true. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest? 2007-03-16 5:21 ` Pretest? Richard Stallman @ 2007-03-16 7:36 ` David Kastrup 0 siblings, 0 replies; 317+ messages in thread From: David Kastrup @ 2007-03-16 7:36 UTC (permalink / raw) To: rms; +Cc: lekktu, Chong Yidong, emacs-devel Richard Stallman <rms@gnu.org> writes: > By the way, do you actually use emacsclient/server yourself? > > No, I don't use it. I have only occasionally tested it. > > I wonder about the statement that emacsclient is always invoked at > specific user request. Indeed, that is usually so, but is it always > so? As usage becomes more diverse, I expect it will cease to be > true. Why? Does your system tend to asynchronously pop up editors which you, as the user, did not request by some particular interaction? I never have experienced anything like that. The only case where one might be having second thoughts is for the _multi-tty_ branch: there it might be nice to not have the home display changed when one has connected via emacsclient from work in between. However, this is completely unfeasible due to Emacs' lack of multi-threading terminals: at some point of time, top-level will get executed in the remote tty, anyway. So I can't see where you get your ideas about typical usage of emacsclient, and it does not particularly help that you state that you don't actually use it, in contrast to the people reporting their expected behaviors. Perhaps you are thinking that one will use emacsclient --eval for doing some noninteractive system task in some asynchronous manner. However, it would be an awful mistake to do this with an interactive Emacs session since the state of such a session and the files it may have open (including password-protected files in different accounts accessed via tramp) are completely unknown. In spite of its name, emacsclient is very much restricted to behaving like an interactive _editor_. Using it for noninteractive non-user-initiated tasks would not be feasible. If you really wanted to build a system service executing Elisp based on it, you'd start an Emacs of its own, non-interactively, detached from a tty. We can't even do that in Emacs 22. So please let us not base our defaults on some weird case that is not likely to become the default usage in future and can't even be usefully employed in that manner in Emacs 22. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Help: build emacs in cygwin 2007-02-23 18:15 ` Eli Zaretskii 2007-03-07 1:26 ` Pretest? Angelo Graziosi @ 2007-03-07 13:37 ` Angelo Graziosi 2007-03-09 1:06 ` Killing buffers with mouse Angelo Graziosi 2 siblings, 0 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-07 13:37 UTC (permalink / raw) To: emacs-devel William Xue wrote: > I have checked the file and it seems that I should upgrade the GCC to > 4.0 first. > I will try the newest GCC release 4.0.1.2 first. If you need pre-built binaries, you can find them here: http://www.webalice.it/angelo.graziosi Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Killing buffers with mouse 2007-02-23 18:15 ` Eli Zaretskii 2007-03-07 1:26 ` Pretest? Angelo Graziosi 2007-03-07 13:37 ` Help: build emacs in cygwin Angelo Graziosi @ 2007-03-09 1:06 ` Angelo Graziosi 2007-03-09 14:56 ` Chong Yidong 2007-03-09 15:41 ` Eli Zaretskii 2 siblings, 2 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-09 1:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel I would ask if this behaviour I observed using Emacs-cvs is correct: When the mouse pointer (an arrow) is on the 'X' icon (Discard current buffer) of the toolbar, moving the wheel of the mouse, without clicking, causes the killing of the buffer. In this manner moving unintentionally the wheel can cause the killing of many buffers. Thanks, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 1:06 ` Killing buffers with mouse Angelo Graziosi @ 2007-03-09 14:56 ` Chong Yidong 2007-03-09 15:15 ` Jan Djärv 2007-03-09 15:41 ` Eli Zaretskii 1 sibling, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-09 14:56 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > I would ask if this behaviour I observed using Emacs-cvs is correct: > > When the mouse pointer (an arrow) is on the 'X' icon (Discard current > buffer) of the toolbar, moving the wheel of the mouse, without clicking, > causes the killing of the buffer. > > In this manner moving unintentionally the wheel can cause the killing of > many buffers. Works fine for me with a GTK build. Maybe this is a limitation of certain toolkits. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 14:56 ` Chong Yidong @ 2007-03-09 15:15 ` Jan Djärv 2007-03-09 15:55 ` Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: Jan Djärv @ 2007-03-09 15:15 UTC (permalink / raw) To: Chong Yidong; +Cc: Eli Zaretskii, Angelo Graziosi, emacs-devel Chong Yidong skrev: > Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > >> I would ask if this behaviour I observed using Emacs-cvs is correct: >> >> When the mouse pointer (an arrow) is on the 'X' icon (Discard current >> buffer) of the toolbar, moving the wheel of the mouse, without clicking, >> causes the killing of the buffer. >> >> In this manner moving unintentionally the wheel can cause the killing of >> many buffers. > > Works fine for me with a GTK build. Maybe this is a limitation of > certain toolkits. It does so with the native tool bar. It is because any mouse down is used as mouse down, not only mouse down with button 1. It is there in 21.4 as well. It is easily fixed, but is it a real bug? Jan D. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 15:15 ` Jan Djärv @ 2007-03-09 15:55 ` Stefan Monnier 2007-03-09 17:43 ` Jan Djärv 2007-03-09 23:19 ` Kim F. Storm 0 siblings, 2 replies; 317+ messages in thread From: Stefan Monnier @ 2007-03-09 15:55 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, Angelo Graziosi, Eli Zaretskii, emacs-devel > It does so with the native tool bar. It is because any mouse down is used > as mouse down, not only mouse down with button 1. It is there in 21.4 as > well. It is easily fixed, but is it a real bug? I'd say that it is. It's OK to accept buttons 1,2,3, but there's no benefit in accepting buttons 4,5,6,7,8.... whereas there is a significant drawback since those buttons are typically used for scrolling with touchpads or wheels and thus aren't "clicks". Stefan PS: I really hope that in post-22 we can refine the toolbar so that we can put different bindings for different buttons and also different bindings for the "down" and the "up" events. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 15:55 ` Stefan Monnier @ 2007-03-09 17:43 ` Jan Djärv 2007-03-09 23:19 ` Kim F. Storm 1 sibling, 0 replies; 317+ messages in thread From: Jan Djärv @ 2007-03-09 17:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, Angelo Graziosi, Eli Zaretskii, emacs-devel Stefan Monnier skrev: >> It does so with the native tool bar. It is because any mouse down is used >> as mouse down, not only mouse down with button 1. It is there in 21.4 as >> well. It is easily fixed, but is it a real bug? > > I'd say that it is. It's OK to accept buttons 1,2,3, but there's no benefit > in accepting buttons 4,5,6,7,8.... whereas there is a significant drawback > since those buttons are typically used for scrolling with touchpads > or wheels and thus aren't "clicks". > > Ok, I've checked in a fix so we ignore buttons > 3 in the tool bar. Jan D. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 15:55 ` Stefan Monnier 2007-03-09 17:43 ` Jan Djärv @ 2007-03-09 23:19 ` Kim F. Storm 2007-03-10 9:35 ` Jan Djärv 2007-03-10 16:00 ` Killing buffers with mouse Stefan Monnier 1 sibling, 2 replies; 317+ messages in thread From: Kim F. Storm @ 2007-03-09 23:19 UTC (permalink / raw) To: Stefan Monnier Cc: Chong Yidong, Jan Djärv, emacs-devel, Eli Zaretskii, Angelo Graziosi Stefan Monnier <monnier@iro.umontreal.ca> writes: > PS: I really hope that in post-22 we can refine the toolbar so that we can > put different bindings for different buttons and also different bindings for > the "down" and the "up" events. Is that possible with e.g. GTK toolbar or W32 toolbar? If not, it doesn't make much sense to do it just for the native toolbar. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 23:19 ` Kim F. Storm @ 2007-03-10 9:35 ` Jan Djärv 2007-03-13 14:24 ` Emacs and GTK Angelo Graziosi 2007-03-10 16:00 ` Killing buffers with mouse Stefan Monnier 1 sibling, 1 reply; 317+ messages in thread From: Jan Djärv @ 2007-03-10 9:35 UTC (permalink / raw) To: Kim F. Storm Cc: Chong Yidong, Angelo Graziosi, Eli Zaretskii, Stefan Monnier, emacs-devel Kim F. Storm skrev: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> PS: I really hope that in post-22 we can refine the toolbar so that we can >> put different bindings for different buttons and also different bindings for >> the "down" and the "up" events. > > Is that possible with e.g. GTK toolbar or W32 toolbar? > > If not, it doesn't make much sense to do it just for the native toolbar. > It is possible for GTK, I can't speek for W32. Jan D. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Emacs and GTK 2007-03-10 9:35 ` Jan Djärv @ 2007-03-13 14:24 ` Angelo Graziosi 2007-03-13 14:41 ` David Kastrup 2007-03-13 14:45 ` Tassilo Horn 0 siblings, 2 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-13 14:24 UTC (permalink / raw) To: Jan Djärv; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 385 bytes --] I have done a build, on GNU/Linux Kubuntu, configuring with GTK. I observe the text on a white background, but the lines not written are grayed. The text looks as a sort of "fractal" as the PNG image shows. Is this the right way that Emacs+GTK works? If it is so, is there a way to customize, resulting all in a white background (as usually emacs appears) ? Thanks, Angelo. [-- Attachment #2: Type: APPLICATION/octet-stream, Size: 121345 bytes --] [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Emacs and GTK 2007-03-13 14:24 ` Emacs and GTK Angelo Graziosi @ 2007-03-13 14:41 ` David Kastrup 2007-03-14 1:21 ` Angelo Graziosi 2007-03-13 14:45 ` Tassilo Horn 1 sibling, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-13 14:41 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, Jan Djärv, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > I have done a build, on GNU/Linux Kubuntu, configuring with GTK. > > I observe the text on a white background, but the lines not written are > grayed. > > The text looks as a sort of "fractal" as the PNG image shows. > > Is this the right way that Emacs+GTK works? > > If it is so, is there a way to customize, resulting all in a white > background (as usually emacs appears) ? You need to uncheck some KDE desktop option named "ruin the appearance of non-KDE applications" or similar. I don't remember the details, but it had something like "non-KDE applications" in its name. -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Emacs and GTK 2007-03-13 14:41 ` David Kastrup @ 2007-03-14 1:21 ` Angelo Graziosi 0 siblings, 0 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-14 1:21 UTC (permalink / raw) To: emacs-devel Tassilo Horn wrote: > That's because you use "GTK-Qt Theme Engine" [1] in an outdated version. Oh yes, Kubuntu Dapper has still 0.6! Thanks for suggestions, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Emacs and GTK 2007-03-13 14:24 ` Emacs and GTK Angelo Graziosi 2007-03-13 14:41 ` David Kastrup @ 2007-03-13 14:45 ` Tassilo Horn 1 sibling, 0 replies; 317+ messages in thread From: Tassilo Horn @ 2007-03-13 14:45 UTC (permalink / raw) To: emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: Hi Angelo, > I observe the text on a white background, but the lines not written > are grayed. That's because you use "GTK-Qt Theme Engine" [1] in an outdated version. I had the same behavior with versions prior to 0.7, with 0.7 it works as expected. HTH, Tassilo Footnotes: [1] http://gtk-qt.ecs.soton.ac.uk/ -- A morning without coffee is like something without something else. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 23:19 ` Kim F. Storm 2007-03-10 9:35 ` Jan Djärv @ 2007-03-10 16:00 ` Stefan Monnier 2007-03-10 23:07 ` Kim F. Storm 1 sibling, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2007-03-10 16:00 UTC (permalink / raw) To: Kim F. Storm Cc: Chong Yidong, Jan Djärv, emacs-devel, Eli Zaretskii, Angelo Graziosi >> PS: I really hope that in post-22 we can refine the toolbar so that we can >> put different bindings for different buttons and also different bindings for >> the "down" and the "up" events. > Is that possible with e.g. GTK toolbar or W32 toolbar? I don't know. > If not, it doesn't make much sense to do it just for the native toolbar. It might be a reason for someone not to spend time on it, but if someone else decides it's important enough and comes up with a patch, I don't think it should be grounds to reject the patch. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-10 16:00 ` Killing buffers with mouse Stefan Monnier @ 2007-03-10 23:07 ` Kim F. Storm 2007-03-11 1:32 ` Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2007-03-10 23:07 UTC (permalink / raw) To: Stefan Monnier Cc: Angelo Graziosi, Chong Yidong, Jan Djärv, Eli Zaretskii, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > It might be a reason for someone not to spend time on it, but if someone > else decides it's important enough and comes up with a patch, I don't think > it should be grounds to reject the patch. If we are moving towards GTK as default in 23.x, then it better work with GTK (Jan says it can). So whoever submits such a patch should at least make it work with GTK too. But if it doesn't work on some of the other platforms the use of such extra features may be limited, as programmers might be reluctant to use them. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-10 23:07 ` Kim F. Storm @ 2007-03-11 1:32 ` Stefan Monnier 0 siblings, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2007-03-11 1:32 UTC (permalink / raw) To: Kim F. Storm Cc: Angelo Graziosi, Chong Yidong, Jan Djärv, Eli Zaretskii, emacs-devel > But if it doesn't work on some of the other platforms the use of such > extra features may be limited, as programmers might be reluctant to > use them. Right. But we're talking about the toolbar: just because there was no toolbar under w32 until Emacs-22 didn't prevent its use. All it provides is other ways to do things, so if it's not available, it just means people have to use menus or key-bindings. No big problem. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 1:06 ` Killing buffers with mouse Angelo Graziosi 2007-03-09 14:56 ` Chong Yidong @ 2007-03-09 15:41 ` Eli Zaretskii 2007-03-09 16:46 ` Angelo Graziosi 1 sibling, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2007-03-09 15:41 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel > Date: Fri, 9 Mar 2007 02:06:14 +0100 (MET) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: emacs-devel@gnu.org > > When the mouse pointer (an arrow) is on the 'X' icon (Discard current > buffer) of the toolbar, moving the wheel of the mouse, without clicking, > causes the killing of the buffer. I don't see this in the native Windows version. Could people please try this on Unix? Angelo, please tell what do you see in the buffer displayed by "C-h l" after you move the wheel over that toolbar icon. (That's a letter ell, not the digit one in "C-h l".) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 15:41 ` Eli Zaretskii @ 2007-03-09 16:46 ` Angelo Graziosi 2007-03-09 17:46 ` Eli Zaretskii 2007-03-10 15:50 ` Killing buffers with mouse Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-09 16:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Chong Yidong, Jan Djärv, Stefan Monnier, emacs-devel On Fri, 9 Mar 2007, Eli Zaretskii wrote: > > Date: Fri, 9 Mar 2007 02:06:14 +0100 (MET) > > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > > cc: emacs-devel@gnu.org > > > > When the mouse pointer (an arrow) is on the 'X' icon (Discard current > > buffer) of the toolbar, moving the wheel of the mouse, without clicking, > > causes the killing of the buffer. > > I don't see this in the native Windows version. Could people please > try this on Unix? I have seen the same thing on Linux-kubuntu (32 bit) and on Scientific Linux (64 bit) (and on Cygwin 32 bit). After moving the wheel (when the pointer is on the 'X' icon of the toolbar) and the buffer is killed, I observe in the minibuffer: tool-bar kill-buffer i.e. the same thing that happens when I kill the buffer clicking with MOUSE-1 on that icon. In other words, it seems that moving the wheel on that icon has the same result of clicking with MOUSE-1 on it. > > Angelo, please tell what do you see in the buffer displayed by "C-h l" > after you move the wheel over that toolbar icon. (That's a letter > ell, not the digit one in "C-h l".) > Regarding this point, after moving the wheel, C-h l (the lowercase of L), I have an help buffer: --------------------------------------------- <help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> <down-mouse-3> <mouse-3> <double-down-mouse-3> <double-mouse-3> <help-echo> <help-echo> <tool-bar> <kill-buffer> <help-echo> <help-echo> <down-mouse-1> <drag-mouse-1> <help-echo> <help-echo> <down-mouse-2> <mouse-2> <down-mouse-5> <mouse-5> <help-echo> <help-echo> <help-echo> <tool-bar> <kill-buffer> <help-echo> <help-echo> C-h l <help-echo> <help-echo> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-movement> <mouse-movement> <help-echo> <mouse-movement> <mouse-movement> <mouse-movement> <mouse-movement> <mouse-movement> <help-echo> <mouse-movement> <mouse-movement> <drag-mouse-1> <help-echo> <help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> <down-mouse-2> <mouse-2> <help-echo> <down-mouse-1> <mouse-1> <help-echo> <down> <return> <return> C-y <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <help-echo> <tool-bar> <save-buffer> <help-echo> <help-echo> <down-mouse-3> <mouse-3> <help-echo> <help-echo> <tool-bar> <open-file> <help-echo> <up> <up> <up> <return> <help-echo> <tool-bar> <open-file> <up> <up> <up> <return> <help-echo> <help-echo> <help-echo> <tool-bar> <kill-buffer> C-h l --------------------------------------------- but I am not sure that what you mean is what I have understood. Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 16:46 ` Angelo Graziosi @ 2007-03-09 17:46 ` Eli Zaretskii 2007-03-14 9:02 ` Connection to emacs CVS broken ? Angelo Graziosi 2007-03-20 13:04 ` Pretest Angelo Graziosi 2007-03-10 15:50 ` Killing buffers with mouse Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: Eli Zaretskii @ 2007-03-09 17:46 UTC (permalink / raw) To: Angelo Graziosi; +Cc: cyd, jan.h.d, monnier, emacs-devel > Date: Fri, 9 Mar 2007 17:46:51 +0100 (MET) > From: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> > cc: Chong Yidong <cyd@stupidchicken.com>, > =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>, > Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org > > > > > Angelo, please tell what do you see in the buffer displayed by "C-h l" > > after you move the wheel over that toolbar icon. (That's a letter > > ell, not the digit one in "C-h l".) > > > > Regarding this point, after moving the wheel, C-h l (the lowercase of L), > I have an help buffer: > > --------------------------------------------- > <help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> > <down-mouse-3> <mouse-3> <double-down-mouse-3> <double-mouse-3> > <help-echo> <help-echo> <tool-bar> <kill-buffer> <help-echo> > <help-echo> <down-mouse-1> <drag-mouse-1> <help-echo> > <help-echo> <down-mouse-2> <mouse-2> <down-mouse-5> > <mouse-5> <help-echo> <help-echo> <help-echo> <tool-bar> > <kill-buffer> <help-echo> <help-echo> C-h l <help-echo> > <help-echo> <down-mouse-1> <mouse-1> <down-mouse-1> > <mouse-movement> <mouse-movement> <help-echo> <mouse-movement> > <mouse-movement> <mouse-movement> <mouse-movement> > <mouse-movement> <help-echo> <mouse-movement> <mouse-movement> > <drag-mouse-1> <help-echo> <help-echo> <help-echo> > <down-mouse-1> <mouse-1> <help-echo> <down-mouse-2> > <mouse-2> <help-echo> <down-mouse-1> <mouse-1> <help-echo> > <down> <return> <return> C-y <help-echo> <help-echo> > <help-echo> <help-echo> <help-echo> <help-echo> <tool-bar> > <save-buffer> <help-echo> <help-echo> <down-mouse-3> > <mouse-3> <help-echo> <help-echo> <tool-bar> <open-file> > <help-echo> <up> <up> <up> <return> <help-echo> <tool-bar> > <open-file> <up> <up> <up> <return> <help-echo> <help-echo> > <help-echo> <tool-bar> <kill-buffer> C-h l > --------------------------------------------- > > but I am not sure that what you mean is what I have understood. That's exactly what I meant, thank you. As seen from the rest of this thread, the problem has been identified already, and it is not specific to Cygwin. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Connection to emacs CVS broken ? 2007-03-09 17:46 ` Eli Zaretskii @ 2007-03-14 9:02 ` Angelo Graziosi 2007-03-14 9:09 ` David Kastrup 2007-03-14 9:09 ` Davi Leal 2007-03-20 13:04 ` Pretest Angelo Graziosi 1 sibling, 2 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-14 9:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Since yesterday (> 24 h) I cannot checkout CVS: $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co -P emacs cvs [checkout aborted]: connect to cvs.savannah.gnu.org(199.232.41.69):2401 fail ed: Connection timed out The same happens if I try to follow the link http://savannah.gnu.org/cgi-bin/viewcvs/emacs/ that allow me to view CVS. I have used different PCs/connections and different SO (Unix/Linux/Win-Cygwin). Any idea? Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 9:02 ` Connection to emacs CVS broken ? Angelo Graziosi @ 2007-03-14 9:09 ` David Kastrup 2007-03-14 17:42 ` Glenn Morris 2007-03-14 9:09 ` Davi Leal 1 sibling, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-14 9:09 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes: > Since yesterday (> 24 h) I cannot checkout CVS: > > $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co -P > emacs > cvs [checkout aborted]: connect to > cvs.savannah.gnu.org(199.232.41.69):2401 fail ed: Connection timed out > > The same happens if I try to follow the link > > http://savannah.gnu.org/cgi-bin/viewcvs/emacs/ > > that allow me to view CVS. > > I have used different PCs/connections and different SO > (Unix/Linux/Win-Cygwin). > > > Any idea? Wait until the replacement shipment for Savanna arrives. Does anybody have an idea yet whether some checkins might have been lost? -- David Kastrup ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 9:09 ` David Kastrup @ 2007-03-14 17:42 ` Glenn Morris 2007-03-15 15:17 ` Kim F. Storm 0 siblings, 1 reply; 317+ messages in thread From: Glenn Morris @ 2007-03-14 17:42 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel David Kastrup wrote: > Wait until the replacement shipment for Savanna arrives. Does anybody > have an idea yet whether some checkins might have been lost? Apparently: "Last confirmed full backup was completed circa 20:30 EDT on Sunday 11 March". (this info from #savannah on irc.gnu.org) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 17:42 ` Glenn Morris @ 2007-03-15 15:17 ` Kim F. Storm 2007-03-15 17:34 ` Glenn Morris 0 siblings, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2007-03-15 15:17 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel Glenn Morris <rgm@gnu.org> writes: > David Kastrup wrote: > >> Wait until the replacement shipment for Savanna arrives. Does anybody >> have an idea yet whether some checkins might have been lost? > > Apparently: "Last confirmed full backup was completed circa 20:30 EDT > on Sunday 11 March". > > (this info from #savannah on irc.gnu.org) Perhaps Miles' Arch repository is more recent ? But what happens if the repository must be restored from an older backup and I then perform a cvs update? To cvs, it will probably look like the newest commits have been forcefully deleted. So will cvs just mark files with never changes as modified here, revert those changes, or get confused in some other way?? In any case, someone with an up-to-date local copy need to take charge to install newer commits into the repository -- being careful not to commit local changes if such are present... And being very careful NOT to do a cvs update which could delete the newer changes... Perhaps doing a "tar cvzf ..." _right now_ before the cvs repository is back online would be a good thing, just to preserve the "mostly up-to-date" version you have, in case we need it to recover newer changes. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 15:17 ` Kim F. Storm @ 2007-03-15 17:34 ` Glenn Morris 2007-03-15 20:00 ` Glenn Morris 2007-03-15 20:26 ` NIIMI Satoshi 0 siblings, 2 replies; 317+ messages in thread From: Glenn Morris @ 2007-03-15 17:34 UTC (permalink / raw) To: Kim F. Storm; +Cc: emacs-devel Kim F. Storm wrote: > Perhaps Miles' Arch repository is more recent ? The info should also be available from the emacs-diff and commit lists, I think. http://lists.gnu.org/archive/html/emacs-diffs/2007-03/index.html suggests about 60 changes occurred in the time between the last backup and the crash. So if necessary we could just put all the missing changes back in by hand. But I guess we should see what the situation is when savannah comes back. This will be a general problem, and hopefully the savannah people will have suggestions about how best to recover. > But what happens if the repository must be restored from > an older backup and I then perform a cvs update? > > To cvs, it will probably look like the newest commits have > been forcefully deleted. > > So will cvs just mark files with never changes as modified here, > revert those changes, or get confused in some other way?? Don't know. I think it would be very advisable to refrain from making commits until this is sorted out. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 17:34 ` Glenn Morris @ 2007-03-15 20:00 ` Glenn Morris 2007-03-15 20:18 ` Eli Zaretskii ` (2 more replies) 2007-03-15 20:26 ` NIIMI Satoshi 1 sibling, 3 replies; 317+ messages in thread From: Glenn Morris @ 2007-03-15 20:00 UTC (permalink / raw) To: Kim F. Storm; +Cc: emacs-devel savannah is back up and anoncvs at least is working. I tried a cvs update on src/process.c in an anoncvs tree that was up-to-date at the time of the crash. It reverted back three revisions. So some work needs to be done to recover the lost changes, it seems. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:00 ` Glenn Morris @ 2007-03-15 20:18 ` Eli Zaretskii 2007-03-16 3:28 ` Giorgos Keramidas ` (2 more replies) 2007-03-15 20:27 ` Chong Yidong 2007-03-15 21:06 ` Glenn Morris 2 siblings, 3 replies; 317+ messages in thread From: Eli Zaretskii @ 2007-03-15 20:18 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel > From: Glenn Morris <rgm@gnu.org> > Date: Thu, 15 Mar 2007 16:00:18 -0400 > Cc: emacs-devel@gnu.org > > I tried a cvs update on src/process.c in an anoncvs tree that was > up-to-date at the time of the crash. It reverted back three revisions. Too bad. > So some work needs to be done to recover the lost changes, it seems. Yes. One way of doing that would be to checkout a full tree in a different directory, diff that directory with the most recent tree before the crash, then committing all the files that are newer. Could people who sync regularly please state the UTC time when they did the last "cvs up"? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:18 ` Eli Zaretskii @ 2007-03-16 3:28 ` Giorgos Keramidas 2007-03-16 5:21 ` Richard Stallman 2007-03-16 15:07 ` James Cloos 2 siblings, 0 replies; 317+ messages in thread From: Giorgos Keramidas @ 2007-03-16 3:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Glenn Morris, emacs-devel On 2007-03-15 22:18, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Glenn Morris <rgm@gnu.org> >> Date: Thu, 15 Mar 2007 16:00:18 -0400 >> Cc: emacs-devel@gnu.org >> >> I tried a cvs update on src/process.c in an anoncvs tree that was >> up-to-date at the time of the crash. It reverted back three revisions. > > Too bad. > > > So some work needs to be done to recover the lost changes, it seems. > > Yes. One way of doing that would be to checkout a full tree in a > different directory, diff that directory with the most recent tree > before the crash, then committing all the files that are newer. > > Could people who sync regularly please state the UTC time when they > did the last "cvs up"? The last time I rsync'ed the repository was: Thu Mar 08 15:18:13 2007 +0000 ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:18 ` Eli Zaretskii 2007-03-16 3:28 ` Giorgos Keramidas @ 2007-03-16 5:21 ` Richard Stallman 2007-03-16 11:58 ` ttn 2007-03-16 15:07 ` James Cloos 2 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-16 5:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rgm, emacs-devel Yes. One way of doing that would be to checkout a full tree in a different directory, diff that directory with the most recent tree before the crash, then committing all the files that are newer. It is important to commit each change with its specific change log entry. Don't do a mass commit! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-16 5:21 ` Richard Stallman @ 2007-03-16 11:58 ` ttn 0 siblings, 0 replies; 317+ messages in thread From: ttn @ 2007-03-16 11:58 UTC (permalink / raw) To: emacs-devel From: Richard Stallman <rms@gnu.org> Date: Fri, 16 Mar 2007 01:21:39 -0400 It is important to commit each change with its specific change log entry. Don't do a mass commit! below is some elisp that does ,v file "unparsing". it was omitted from vc-rcs.el changes related to vc-annotate support for RCS since i didn't think it would be useful. however, in this case, we can use it to write new ,v files directly, after a "tree append" operation. something like: (let* ((old (vc-rcs-parse (find-file "OLD,v"))) (new (vc-rcs-parse (find-file "NEW,v"))) (merged (APPEND-NEW-ENTRIES old new))) (set-buffer (generate-new-buffer "GEN,v")) (erase-buffer) (comma-v-unparse merged) (write-file "GEN,v")) someone would have to write APPEND-NEW-ENTRIES, of course, but at least that can be done more at the semantic level... note that verification by a human will still be needed, in any case. thi ____________________________________________________________ (defun comma-v-unparse (tree &optional buffer) "Insert TREE into current buffer in RCS-style masterfile format. Optional second arg BUFFER specifies another buffer to insert into. You can use `comma-v-parse' to get TREE." (setq buffer (get-buffer (or buffer (current-buffer)))) (let ((standard-output buffer) (headers (cdr (assq 'headers tree))) (revisions (cdr (assq 'revisions tree)))) (flet ((spew! (look name finish &optional proc) (princ name) (let ((v (funcall (or proc 'identity) (funcall look name)))) (unless (string= "" v) (unless proc (princ "\t")) (princ v))) (princ ";") (princ finish))) (flet ((hspew (name finish &optional proc) (spew! (lambda (name) (cdr (assq name headers))) name finish proc))) (hspew 'head "\n") (when (assq 'branch headers) (hspew 'branch "\n")) (hspew 'access "\n") (hspew 'symbols "\n" (lambda (ls) (apply 'concat (mapcar (lambda (x) (format "\n\t%s:%s" (car x) (cdr x))) ls)))) (hspew 'locks " ") (hspew 'strict "\n") (hspew 'comment "\n\n\n" (lambda (s) (format "\t@%s@" s)))) (dolist (rev revisions) (princ (car rev)) (princ "\n") (flet ((rlook (name) (cdr (assq name (cdr rev)))) (rspew (name finish &optional proc) (spew! 'rlook name finish proc))) (rspew 'date "\t" (lambda (v) (format-time-string "\t%Y.%m.%d.%H.%M.%S" v))) (rspew 'author "\t" (lambda (v) (concat " " v))) (rspew 'state "\n" (lambda (v) (concat " " v))) (rspew 'branches "\n") (rspew 'next "\n\n")))) (princ "\n") (flet ((spew! (look name finish &optional proc) (princ name) (princ "\n@") (princ (with-temp-buffer (insert (funcall (or proc 'identity) (funcall look name))) (while (search-backward "@" (point-min) t) (insert "@") (forward-char -1)) (buffer-string))) (princ "@\n") (princ finish))) (spew! (lambda (name) (cdr (assq name headers))) 'desc "") (dolist (rev revisions) (princ "\n\n") (princ (car rev)) (princ "\n") (flet ((rlook (name) (cdr (assq name (cdr rev))))) (spew! 'rlook 'log "") (spew! (if (assq :insn (cdr rev)) (let ((s (with-temp-buffer (dolist (cmd (nreverse (rlook :insn))) (case (cadr cmd) (k (insert (format "d%d %d\n" (car cmd) (caddr cmd)))) (i (insert (format "a%d " (1- (car cmd)))) (save-excursion (insert (caddr cmd))) (insert (format "%d\n" (count-lines (point) (point-max)))) (goto-char (point-max))))) (buffer-string)))) `(lambda (x) ,s)) 'rlook) 'text "")))))) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:18 ` Eli Zaretskii 2007-03-16 3:28 ` Giorgos Keramidas 2007-03-16 5:21 ` Richard Stallman @ 2007-03-16 15:07 ` James Cloos 2 siblings, 0 replies; 317+ messages in thread From: James Cloos @ 2007-03-16 15:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Glenn Morris, emacs-devel >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes: Eli> Could people who sync regularly please state the UTC time when they Eli> did the last "cvs up"? I have an rsync of rsync://cvs.sv.gnu.org/sources/emacs/ that was last updated at 2007-Mar-11 13:58 UTC. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:00 ` Glenn Morris 2007-03-15 20:18 ` Eli Zaretskii @ 2007-03-15 20:27 ` Chong Yidong 2007-03-15 20:49 ` Nick Roberts 2007-03-16 5:21 ` Richard Stallman 2007-03-15 21:06 ` Glenn Morris 2 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-15 20:27 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel, Kim F. Storm Glenn Morris <rgm@gnu.org> writes: > savannah is back up and anoncvs at least is working. > > I tried a cvs update on src/process.c in an anoncvs tree that was > up-to-date at the time of the crash. It reverted back three revisions. > So some work needs to be done to recover the lost changes, it seems. How do we want to go about doing this? I have a tree that's up-to-date as of the crash. Will the problem be fixed if I simply do a "cvs ci" on the entire tree? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:27 ` Chong Yidong @ 2007-03-15 20:49 ` Nick Roberts 2007-03-15 22:17 ` Jason Rumney 2007-03-15 23:04 ` Vinicius Jose Latorre 2007-03-16 5:21 ` Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: Nick Roberts @ 2007-03-15 20:49 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, Kim F. Storm, emacs-devel > How do we want to go about doing this? > > I have a tree that's up-to-date as of the crash. Will the problem be > fixed if I simply do a "cvs ci" on the entire tree? Does CVS get confused if your checked out file thinks it's a later version than the most recent in the repository? How about trying it on a single, non-source file first? -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:49 ` Nick Roberts @ 2007-03-15 22:17 ` Jason Rumney 2007-03-15 23:15 ` Miles Bader 2007-03-15 23:04 ` Vinicius Jose Latorre 1 sibling, 1 reply; 317+ messages in thread From: Jason Rumney @ 2007-03-15 22:17 UTC (permalink / raw) To: Nick Roberts; +Cc: Glenn Morris, Chong Yidong, emacs-devel, Kim F. Storm Nick Roberts wrote: > Does CVS get confused if your checked out file thinks it's a later version than > the most recent in the repository? How about trying it on a single, non-source > file first? > Yes, in my experience. The way around it is to check out a fresh copy, then copy the up to date files (without copying the CVS directories) into that tree, and check them in. But this will not preserve any checkin comments, so it would be better to restore what we can from arch and other sources first. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 22:17 ` Jason Rumney @ 2007-03-15 23:15 ` Miles Bader 2007-03-15 23:34 ` NIIMI Satoshi 2007-03-15 23:47 ` [DIFFS] " Kim F. Storm 0 siblings, 2 replies; 317+ messages in thread From: Miles Bader @ 2007-03-15 23:15 UTC (permalink / raw) To: Jason Rumney Cc: Glenn Morris, Nick Roberts, Kim F. Storm, Chong Yidong, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > The way around it is to check out a fresh copy, then copy the up to date > files (without copying the CVS directories) into that tree, and check > them in. But this will not preserve any checkin comments, so it would be > better to restore what we can from arch and other sources first. Things seem to be working up now, and I had a look around. Indeed the restored CVS repository is a little old. My arch repository (emacs@sv.gnu.org) seems to have been restored intact, but it doesn't have all the missing CVS contents. According to "cvs -nq update", there's only one change in the arch repository which isn't in the restored CVS repository: 2007-03-11 Andreas Seltenreich <uwi7@rz.uni-karlsruhe.de> * man/gnus.texi (Mail and Post): Update documentation for gnus-user-agent. The variable now uses a list of symbols instead of just a symbol. Reported by Christoph Conrad <christoph.conrad@gmx.de>. [synced to arch at 2007-03-11 23:54:42 GMT] Oddly enough, that's _not_ the latest commit in the arch repository -- there's one other which is later, which _is_ in the restored CVS repository: 2007-03-11 Juri Linkov <juri@jurta.org> * lisp/replace.el (match): Use yellow background on light-bg terminals. [synced to arch 2007-03-12 00:37:04 GMT] So it looks like not every directory is restored from the same time? [There's a bit more in other branches, e.g. my latest trunk->unicode sync seems to be missing from the restored CVS repository.] Maybe the best thing is to restore from NIIMI Satoshi's rsync of the repository? [He said it's from 2007-03-13 02:48 GMT] I think the changes from the restored repository to the rsync would be small enough that they could probably be verified by eye. -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 23:15 ` Miles Bader @ 2007-03-15 23:34 ` NIIMI Satoshi 2007-03-16 4:55 ` Vinicius Jose Latorre 2007-03-15 23:47 ` [DIFFS] " Kim F. Storm 1 sibling, 1 reply; 317+ messages in thread From: NIIMI Satoshi @ 2007-03-15 23:34 UTC (permalink / raw) To: Miles Bader Cc: Glenn Morris, Nick Roberts, emacs-devel, Kim F. Storm, Jason Rumney, Chong Yidong 2007/3/16, Miles Bader <miles@gnu.org>: > Maybe the best thing is to restore from NIIMI Satoshi's rsync of the > repository? [He said it's from 2007-03-13 02:48 GMT] > > I think the changes from the restored repository to the rsync would be > small enough that they could probably be verified by eye. I've uploaded the CVS repository at: http://www.and.or.jp/~sa2c/emacs-cvs-20070313.tar.bz2 -- NIIMI Satoshi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 23:34 ` NIIMI Satoshi @ 2007-03-16 4:55 ` Vinicius Jose Latorre 2007-03-16 5:25 ` Miles Bader 2007-03-16 5:47 ` Kenichi Handa 0 siblings, 2 replies; 317+ messages in thread From: Vinicius Jose Latorre @ 2007-03-16 4:55 UTC (permalink / raw) To: NIIMI Satoshi Cc: Glenn Morris, Nick Roberts, emacs-devel, Kim F. Storm, Jason Rumney, Chong Yidong, Miles Bader NIIMI Satoshi wrote: > 2007/3/16, Miles Bader <miles@gnu.org>: >> Maybe the best thing is to restore from NIIMI Satoshi's rsync of the >> repository? [He said it's from 2007-03-13 02:48 GMT] >> >> I think the changes from the restored repository to the rsync would be >> small enough that they could probably be verified by eye. > > I've uploaded the CVS repository at: > http://www.and.or.jp/~sa2c/emacs-cvs-20070313.tar.bz2 Does anyone have a restore for emacs-unicode-2? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-16 4:55 ` Vinicius Jose Latorre @ 2007-03-16 5:25 ` Miles Bader 2007-03-16 5:47 ` Kenichi Handa 1 sibling, 0 replies; 317+ messages in thread From: Miles Bader @ 2007-03-16 5:25 UTC (permalink / raw) To: emacs-devel Vinicius Jose Latorre <viniciusjl@ig.com.br> writes: >> I've uploaded the CVS repository at: >> http://www.and.or.jp/~sa2c/emacs-cvs-20070313.tar.bz2 > > Does anyone have a restore for emacs-unicode-2? All branches are in the same repository. [But I've got a separate copy of emacs-unicode-2 if you want...] -Miles -- 80% of success is just showing up. --Woody Allen ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-16 4:55 ` Vinicius Jose Latorre 2007-03-16 5:25 ` Miles Bader @ 2007-03-16 5:47 ` Kenichi Handa 2007-03-16 6:28 ` Herbert Euler 1 sibling, 1 reply; 317+ messages in thread From: Kenichi Handa @ 2007-03-16 5:47 UTC (permalink / raw) To: Vinicius Jose Latorre Cc: rgm, nickrob, sa2c, jasonr, storm, emacs-devel, cyd, miles In article <45FA2326.4020201@ig.com.br>, Vinicius Jose Latorre <viniciusjl@ig.com.br> writes: > NIIMI Satoshi wrote: > > 2007/3/16, Miles Bader <miles@gnu.org>: >>> Maybe the best thing is to restore from NIIMI Satoshi's rsync of the >>> repository? [He said it's from 2007-03-13 02:48 GMT] >>> >>> I think the changes from the restored repository to the rsync would be >>> small enough that they could probably be verified by eye. > > > > I've uploaded the CVS repository at: > > http://www.and.or.jp/~sa2c/emacs-cvs-20070313.tar.bz2 > Does anyone have a restore for emacs-unicode-2? I have the version of date 2007.03.05. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-16 5:47 ` Kenichi Handa @ 2007-03-16 6:28 ` Herbert Euler 0 siblings, 0 replies; 317+ messages in thread From: Herbert Euler @ 2007-03-16 6:28 UTC (permalink / raw) To: handa, viniciusjl Cc: rgm, nickrob, sa2c, emacs-devel, storm, jasonr, cyd, miles >In article <45FA2326.4020201@ig.com.br>, Vinicius Jose Latorre ><viniciusjl@ig.com.br> writes: > > > NIIMI Satoshi wrote: > > > 2007/3/16, Miles Bader <miles@gnu.org>: > >>> Maybe the best thing is to restore from NIIMI Satoshi's rsync of the > >>> repository? [He said it's from 2007-03-13 02:48 GMT] > >>> > >>> I think the changes from the restored repository to the rsync would be > >>> small enough that they could probably be verified by eye. > > > > > > I've uploaded the CVS repository at: > > > http://www.and.or.jp/~sa2c/emacs-cvs-20070313.tar.bz2 > > > Does anyone have a restore for emacs-unicode-2? > >I have the version of date 2007.03.05. I have the version of date 2007.03.13, including the web repository on that day. Regards, Guanpeng Xu _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ^ permalink raw reply [flat|nested] 317+ messages in thread
* [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-15 23:15 ` Miles Bader 2007-03-15 23:34 ` NIIMI Satoshi @ 2007-03-15 23:47 ` Kim F. Storm 2007-03-16 0:41 ` Nick Roberts 1 sibling, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2007-03-15 23:47 UTC (permalink / raw) To: Miles Bader Cc: Glenn Morris, Nick Roberts, emacs-devel, Chong Yidong, Jason Rumney Miles Bader <miles@gnu.org> writes: > So it looks like not every directory is restored from the same time? That's what happens when you backup a live system - changes may happen while the backup is running. > Maybe the best thing is to restore from NIIMI Satoshi's rsync of the > repository? [He said it's from 2007-03-13 02:48 GMT] Indeed! This would restore the CVS files, not just the changes. > I think the changes from the restored repository to the rsync would be > small enough that they could probably be verified by eye. I believe I have a a very recent checkout of the trunk before the crash. Time-stamp seems to be Mar 13 14.01 UTC. It includes RMS' last dired.c change, so I think it is complete. Here's the complete diff between the current emacs-cvs and the files of Mar 13: *** ../emacs-cvs/admin/notes/copyright 2007-03-15 23:55:01.000000000 +0100 --- ./admin/notes/copyright 2007-03-12 09:56:25.000000000 +0100 *************** *** 381,387 **** etc/TERMS rms: "surely written either by me or by ESR. (If you can figure out which year, I can probably tell you which.) Either way, we have papers ! for it." Present in Emacs-16.56 (15-jul-85). etc/ulimit.hack Very obsolete file removed March 2007. Doesn't say who the author --- 381,388 ---- etc/TERMS rms: "surely written either by me or by ESR. (If you can figure out which year, I can probably tell you which.) Either way, we have papers ! for it." It was present in Emacs-16.56 (15-jul-85). rms: "Then I ! conclude it was written by me." etc/ulimit.hack Very obsolete file removed March 2007. Doesn't say who the author *************** *** 443,449 **** No info on author. File removed March 2007. rms: "It says it is RLK's way of remapping his keyboard, so it is not constrained. I think it was written by RLK. Let's delete it; if we contact RLK again, we ! can put it back." src/m/mips4.h, news-risc.h, pmax.h --- 444,451 ---- No info on author. File removed March 2007. rms: "It says it is RLK's way of remapping his keyboard, so it is not constrained. I think it was written by RLK. Let's delete it; if we contact RLK again, we ! can put it back." Actually, RLK == Robert Krawitz has an Emacs ! assignment. So this could be restored if it is still useful. src/m/mips4.h, news-risc.h, pmax.h *** ../emacs-cvs/admin/FOR-RELEASE 2007-03-15 23:55:00.000000000 +0100 --- ./admin/FOR-RELEASE 2007-03-13 14:37:49.000000000 +0100 *************** *** 51,65 **** ** henman@it.to-be.co.jp 09 Aug 2006: ispell.el problem on Cygwin. (Did we decide that is unreproducible?) - ** lennart.borgman@gmail.com, Feb 22: C-h k does not catch text properies keymaps - * BUGS ** Fix up copyright confusions. See end of admin/notes/copyright. ! ** david.hansen@gmx.net, Mar 7: shell.el patch to install * DOCUMENTATION --- 51,71 ---- ** henman@it.to-be.co.jp 09 Aug 2006: ispell.el problem on Cygwin. (Did we decide that is unreproducible?) * BUGS + ** md5i@cs.cmu.edu, Feb 20: move-end-of-line in comint buffers + ** Fix up copyright confusions. See end of admin/notes/copyright. ! ** flyspell and check-comments ! ! ** handa@m17n.org, Mar 7: Display bug [Re: My Emacs unicode 2 crash again ...] ! ! ** lennart.borgman@gmail.com, Feb 22: C-h k does not catch text properies keymaps ! Update: Problem is only seen when viper-mode is enabled. ! * DOCUMENTATION *** ../emacs-cvs/etc/PROBLEMS 2007-03-15 23:55:01.000000000 +0100 --- ./etc/PROBLEMS 2007-03-13 14:37:50.000000000 +0100 *************** *** 2393,2402 **** reported to either fail or cause Emacs to segfault at run time. In addition, the Cygwin GCC 3.4.4-2 has problems with generating debug info. Cygwin users are advised not to use these versions of GCC for ! compiling Emacs. GCC versions 4.0.3 and 4.1.1 reportedly build a ! working Cygwin binary of Emacs, so we recommend these GCC versions. ! Note that these two versions of GCC, 4.0.3 and 4.1.1, are the _only_ ! versions known to succeed in building Emacs (as of v22.1). *** Building the native MS-Windows port with Cygwin GCC can fail. --- 2393,2403 ---- reported to either fail or cause Emacs to segfault at run time. In addition, the Cygwin GCC 3.4.4-2 has problems with generating debug info. Cygwin users are advised not to use these versions of GCC for ! compiling Emacs. GCC versions 4.0.3, 4.1.1, and 4.1.2 reportedly ! build a working Cygwin binary of Emacs, so we recommend these GCC ! versions. Note that these three versions of GCC, 4.0.3, 4.1.1, and ! 4.1.2, are currently the _only_ versions known to succeed in building ! Emacs (as of v22.1). *** Building the native MS-Windows port with Cygwin GCC can fail. *** ../emacs-cvs/etc/TODO 2007-03-15 23:55:01.000000000 +0100 --- ./etc/TODO 2007-03-13 10:36:47.000000000 +0100 *************** *** 509,514 **** --- 509,517 ---- * Internal changes + ** Cleanup all the GC_ mark bit stuff -- there is no longer any distiction + since the mark bit is no longer stored in the Lisp_Object itself. + ** Merge ibuffer.el and buff-menu.el. More specifically do what's needed to make ibuffer.el the default, or just an extension of buff-menu.el. *************** *** 548,553 **** --- 551,557 ---- button classes inherit from it. Set the default face of the "link" button class to the standard "link" face. + * Other known bugs: ** a two-char comment-starter whose two chars are symbol constituents will *** ../emacs-cvs/etc/emacs.csh 2007-03-15 23:55:01.000000000 +0100 --- ./etc/emacs.csh 2007-03-12 09:56:25.000000000 +0100 *************** *** 1,5 **** --- 1,7 ---- ### emacs.csh + ## Add legal notice if non-trivial amounts of code are added. + ## Author: Michael DeCorte ### Commentary: *** ../emacs-cvs/etc/NEWS.19 2007-03-15 23:55:01.000000000 +0100 --- ./etc/NEWS.19 2007-03-12 09:56:25.000000000 +0100 *************** *** 4557,4563 **** ** Changes to calendar/diary. Time zone data is now determined automatically, including the ! start/stop days and times of daylight savings time. The code now works correctly almost anywhere in the world. The format of the holiday specifications has changed and IS NO LONGER --- 4557,4563 ---- ** Changes to calendar/diary. Time zone data is now determined automatically, including the ! start/stop days and times of daylight saving time. The code now works correctly almost anywhere in the world. The format of the holiday specifications has changed and IS NO LONGER *** ../emacs-cvs/lisp/calc/calc-forms.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calc/calc-forms.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 1312,1331 **** (calcFunc-unixtime (calcFunc-unixtime date z1) z2))) (defun math-std-daylight-savings (date dt zone bump) ! "Standard North American daylight savings algorithm. ! This implements the rules for the U.S. and Canada as of 1987. ! Daylight savings begins on the first Sunday of April at 2 a.m., ! and ends on the last Sunday of October at 2 a.m." ! (cond ((< (nth 1 dt) 4) 0) ! ((= (nth 1 dt) 4) ! (let ((sunday (math-prev-weekday-in-month date dt 7 0))) (cond ((< (nth 2 dt) sunday) 0) ((= (nth 2 dt) sunday) (if (>= (nth 3 dt) (+ 3 bump)) -1 0)) (t -1)))) ! ((< (nth 1 dt) 10) -1) ! ((= (nth 1 dt) 10) ! (let ((sunday (math-prev-weekday-in-month date dt 31 0))) (cond ((< (nth 2 dt) sunday) -1) ((= (nth 2 dt) sunday) (if (>= (nth 3 dt) (+ 2 bump)) 0 -1)) --- 1312,1331 ---- (calcFunc-unixtime (calcFunc-unixtime date z1) z2))) (defun math-std-daylight-savings (date dt zone bump) ! "Standard North American daylight saving algorithm. ! This implements the rules for the U.S. and Canada as of 2007. ! Daylight saving begins on the second Sunday of March at 2 a.m., ! and ends on the first Sunday of November at 2 a.m." ! (cond ((< (nth 1 dt) 3) 0) ! ((= (nth 1 dt) 3) ! (let ((sunday (math-prev-weekday-in-month date dt 14 0))) (cond ((< (nth 2 dt) sunday) 0) ((= (nth 2 dt) sunday) (if (>= (nth 3 dt) (+ 3 bump)) -1 0)) (t -1)))) ! ((< (nth 1 dt) 11) -1) ! ((= (nth 1 dt) 11) ! (let ((sunday (math-prev-weekday-in-month date dt 7 0))) (cond ((< (nth 2 dt) sunday) -1) ((= (nth 2 dt) sunday) (if (>= (nth 3 dt) (+ 2 bump)) 0 -1)) *** ../emacs-cvs/lisp/ChangeLog 2007-03-15 23:55:02.000000000 +0100 --- ./lisp/ChangeLog 2007-03-13 14:37:51.000000000 +0100 *************** *** 1,26 **** ! 2007-03-11 Juri Linkov <juri@jurta.org> * replace.el (match): Use yellow background on light-bg terminals. 2007-03-11 Richard Stallman <rms@gnu.org> ! * emacs-lisp/bytecomp.el (byte-compile-warning-prefix): Correctly compute line number. ! 2007-03-11 Guanpeng Xu <herberteuler@hotmail.com> ! * type-break.el (type-break-get-previous-count): Repeat previous change here. 2007-03-11 Dan Nicolaescu <dann@ics.uci.edu> ! * progmodes/grep.el (grep-find-ignored-directories): Add .git and ! .bzr to list. 2007-03-11 Andreas Schwab <schwab@suse.de> ! * diff-mode.el (diff-apply-hunk): Use proper format string for ! error. 2007-03-11 Stefan Monnier <monnier@iro.umontreal.ca> --- 1,67 ---- ! 2007-03-13 Chong Yidong <cyd@stupidchicken.com> ! ! * comint.el (comint-arguments): Mark backslash-escaped chars. ! (comint-delim-arg): Don't treat them as delimiters. ! ! 2007-03-12 Kim F. Storm <storm@cua.dk> ! ! * ido.el (ido-init-completion-maps): Remap delete-backward-char. ! ! 2007-03-12 Lawrence Mitchell <wence@gmx.li> (tiny change) ! ! * tempo.el (tempo-insert): Deal with 'r> if it appears ! specified with a prompt argument. ! ! 2007-03-12 Carsten Dominik <dominik@science.uva.nl> ! ! * textmodes/org.el (org-set-font-lock-defaults): Handle narrow ! table columns correctly. ! ! 2007-03-12 Mark A. Hershberger <mah@everybody.org> ! ! * xml.el (xml-parse-tag, xml-parse-string, xml-parse-attlist) ! (xml-parse-dtd, xml-parse-elem-type, xml-substitute-special): ! Return to use of the -no-properties variants. There was ! consensus on emacs-devel that the speed of these variants was ! prefered since we are usually parsing files (from the internet ! or on disk) instead of XML created in Emacs. ! ! * eshell/esh-mode.el (eshell-handle-ansi-color): New function. ! Add customize option. ! ! 2007-03-12 Glenn Morris <rgm@gnu.org> ! ! * calc/calc-forms.el (math-std-daylight-savings): Switch to new ! North American rule. ! ! * woman.el (woman-change-fonts): Tweak previous change by using ! woman-request-regexp rather than "^\\.". ! ! * startup.el (command-line-1): Make insertion of ! initial-scratch-message not depend on scratch being selected. ! ! 2007-03-11 Juri Linkov <juri@jurta.org> * replace.el (match): Use yellow background on light-bg terminals. 2007-03-11 Richard Stallman <rms@gnu.org> ! * emacs-lisp/bytecomp.el (byte-compile-warning-prefix): Correctly compute line number. ! 2007-03-11 Guanpeng Xu <herberteuler@hotmail.com> ! * type-break.el (type-break-get-previous-count): Repeat previous change here. 2007-03-11 Dan Nicolaescu <dann@ics.uci.edu> ! * progmodes/grep.el (grep-find-ignored-directories): ! Add .git and .bzr to list. 2007-03-11 Andreas Schwab <schwab@suse.de> ! * diff-mode.el (diff-apply-hunk): Use proper format string for error. 2007-03-11 Stefan Monnier <monnier@iro.umontreal.ca> *** ../emacs-cvs/lisp/ChangeLog.3 2007-03-15 23:55:03.000000000 +0100 --- ./lisp/ChangeLog.3 2007-03-12 09:56:27.000000000 +0100 *************** *** 5091,5097 **** * holidays.el (calendar-holiday-function-sexp): New function. *calendar.el (calendar-holidays): Describe it and use it for daylight ! savings. * calendar.el, cal-mayan.el, cal-french.el: Change names of all calendar-goto-next- or calendar-goto-previous- commands to --- 5091,5097 ---- * holidays.el (calendar-holiday-function-sexp): New function. *calendar.el (calendar-holidays): Describe it and use it for daylight ! saving. * calendar.el, cal-mayan.el, cal-french.el: Change names of all calendar-goto-next- or calendar-goto-previous- commands to *** ../emacs-cvs/lisp/ChangeLog.4 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/ChangeLog.4 2007-03-12 09:56:27.000000000 +0100 *************** *** 6131,6137 **** * cal-dst.el (calendar-time-zone-daylight-rules): Remove special case for Israel. Israel has changed its daylight ! savings time rules. We don't know what the current rules are, but the special case was definitely incorrect. 1993-09-06 Roland McGrath (roland@churchy.gnu.ai.mit.edu) --- 6131,6137 ---- * cal-dst.el (calendar-time-zone-daylight-rules): Remove special case for Israel. Israel has changed its daylight ! saving time rules. We don't know what the current rules are, but the special case was definitely incorrect. 1993-09-06 Roland McGrath (roland@churchy.gnu.ai.mit.edu) *************** *** 8087,8093 **** (general-holidays, calendar-holidays, hebrew-holidays, christian-holidays, islamic-holidays, solar-holidays): Rewritten to include require of cal-dst.el and to ! show the time of the change to/from daylight savings time. (calendar-current-time-zone, calendar-time-zone, calendar-daylight-time-offset, calendar-standard-time-zone-name, calendar-daylight-time-zone-name, calendar-daylight-savings-starts, --- 8087,8093 ---- (general-holidays, calendar-holidays, hebrew-holidays, christian-holidays, islamic-holidays, solar-holidays): Rewritten to include require of cal-dst.el and to ! show the time of the change to/from daylight saving time. (calendar-current-time-zone, calendar-time-zone, calendar-daylight-time-offset, calendar-standard-time-zone-name, calendar-daylight-time-zone-name, calendar-daylight-savings-starts, *************** *** 8772,8778 **** (solar-time-string): Use calendar-daylight-time-offset instead of 1 hr, and use calendar-daylight-savings-switchover-time instead of midnight. Add an optional parameter to allow forcing the use of ! standard or daylight savings time. Fix code so it works in southern hemisphere (start of dst precedes end of dst in a calendar year) and when dst either starts or ends in a calendar year, but not both. --- 8772,8778 ---- (solar-time-string): Use calendar-daylight-time-offset instead of 1 hr, and use calendar-daylight-savings-switchover-time instead of midnight. Add an optional parameter to allow forcing the use of ! standard or daylight saving time. Fix code so it works in southern hemisphere (start of dst precedes end of dst in a calendar year) and when dst either starts or ends in a calendar year, but not both. *** ../emacs-cvs/lisp/comint.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/comint.el 2007-03-13 14:37:51.000000000 +0100 *************** *** 1347,1353 **** (defun comint-delim-arg (arg) "Return a list of arguments from ARG. Break it up at the delimiters in `comint-delimiter-argument-list'. ! Returned list is backwards." (if (null comint-delimiter-argument-list) (list arg) (let ((args nil) --- 1347,1357 ---- (defun comint-delim-arg (arg) "Return a list of arguments from ARG. Break it up at the delimiters in `comint-delimiter-argument-list'. ! Returned list is backwards. ! ! Characters with non-nil values of the text property `literal' are ! assumed to have literal values (e.g., backslash-escaped ! characters), and are not considered to be delimiters." (if (null comint-delimiter-argument-list) (list arg) (let ((args nil) *************** *** 1356,1367 **** (while (< pos len) (let ((char (aref arg pos)) (start pos)) ! (if (memq char comint-delimiter-argument-list) (while (and (< pos len) (eq (aref arg pos) char)) (setq pos (1+ pos))) (while (and (< pos len) ! (not (memq (aref arg pos) ! comint-delimiter-argument-list))) (setq pos (1+ pos)))) (setq args (cons (substring arg start pos) args)))) args))) --- 1360,1375 ---- (while (< pos len) (let ((char (aref arg pos)) (start pos)) ! (if (and (memq char comint-delimiter-argument-list) ! ;; Ignore backslash-escaped characters. ! (not (get-text-property pos 'literal arg))) (while (and (< pos len) (eq (aref arg pos) char)) (setq pos (1+ pos))) (while (and (< pos len) ! (not (and (memq (aref arg pos) ! comint-delimiter-argument-list) ! (not (get-text-property ! pos 'literal arg))))) (setq pos (1+ pos)))) (setq args (cons (substring arg start pos) args)))) args))) *************** *** 1381,1404 **** ;; The third matches '-quoted strings. ;; The fourth matches `-quoted strings. ;; This seems to fit the syntax of BASH 2.0. ! (let* ((first (if (if (fboundp 'w32-shell-dos-semantics) ! (w32-shell-dos-semantics)) ! "[^ \n\t\"'`]+\\|" ! "[^ \n\t\"'`\\]+\\|\\\\[\"'`\\ \t]+\\|")) (argpart (concat first "\\(\"\\([^\"\\]\\|\\\\.\\)*\"\\|\ '[^']*'\\|\ `[^`]*`\\)")) (args ()) (pos 0) (count 0) beg str quotes) ;; Build a list of all the args until we have as many as we want. (while (and (or (null mth) (<= count mth)) (string-match argpart string pos)) (if (and beg (= pos (match-beginning 0))) ;; It's contiguous, part of the same arg. (setq pos (match-end 0) ! quotes (or quotes (match-beginning 1))) ;; It's a new separate arg. (if beg ;; Put the previous arg, if there was one, onto ARGS. --- 1389,1420 ---- ;; The third matches '-quoted strings. ;; The fourth matches `-quoted strings. ;; This seems to fit the syntax of BASH 2.0. ! (let* ((backslash-escape (not (and (fboundp 'w32-shell-dos-semantics) ! (w32-shell-dos-semantics)))) ! (first (if backslash-escape ! "[^ \n\t\"'`\\]\\|\\(\\\\.\\)\\|" ! "[^ \n\t\"'`]+\\|")) (argpart (concat first "\\(\"\\([^\"\\]\\|\\\\.\\)*\"\\|\ '[^']*'\\|\ `[^`]*`\\)")) + (quote-subexpr (if backslash-escape 2 1)) (args ()) (pos 0) (count 0) beg str quotes) ;; Build a list of all the args until we have as many as we want. (while (and (or (null mth) (<= count mth)) (string-match argpart string pos)) + ;; Apply the `literal' text property to backslash-escaped + ;; characters, so that `comint-delim-arg' won't break them up. + (and backslash-escape + (match-beginning 1) + (put-text-property (match-beginning 1) (match-end 1) + 'literal t string)) (if (and beg (= pos (match-beginning 0))) ;; It's contiguous, part of the same arg. (setq pos (match-end 0) ! quotes (or quotes (match-beginning quote-subexpr))) ;; It's a new separate arg. (if beg ;; Put the previous arg, if there was one, onto ARGS. *************** *** 1406,1412 **** args (if quotes (cons str args) (nconc (comint-delim-arg str) args)))) (setq count (length args)) ! (setq quotes (match-beginning 1)) (setq beg (match-beginning 0)) (setq pos (match-end 0)))) (if beg --- 1422,1428 ---- args (if quotes (cons str args) (nconc (comint-delim-arg str) args)))) (setq count (length args)) ! (setq quotes (match-beginning quote-subexpr)) (setq beg (match-beginning 0)) (setq pos (match-end 0)))) (if beg *** ../emacs-cvs/lisp/ido.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/ido.el 2007-03-12 23:41:42.000000000 +0100 *************** *** 1575,1580 **** --- 1575,1581 ---- (define-key map [(meta down)] 'ido-next-work-directory) (define-key map [backspace] 'ido-delete-backward-updir) (define-key map "\d" 'ido-delete-backward-updir) + (define-key map [remap delete-backward-char] 'ido-delete-backward-updir) ; BS (define-key map [remap backward-kill-word] 'ido-delete-backward-word-updir) ; M-DEL (define-key map [(control backspace)] 'ido-up-directory) *** ../emacs-cvs/lisp/startup.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/startup.el 2007-03-12 09:56:27.000000000 +0100 *************** *** 1995,2007 **** (with-no-warnings (setq menubar-bindings-done t)) ! ;; If *scratch* is selected and it is empty, insert an ! ;; initial message saying not to create a file there. ! (when (and initial-scratch-message ! (equal (buffer-name) "*scratch*") ! (= 0 (buffer-size))) ! (insert initial-scratch-message) ! (set-buffer-modified-p nil)) ;; If user typed input during all that work, ;; abort the startup screen. Otherwise, display it now. --- 1995,2007 ---- (with-no-warnings (setq menubar-bindings-done t)) ! ;; If *scratch* exists and is empty, insert initial-scratch-message. ! (and initial-scratch-message ! (get-buffer "*scratch*") ! (with-current-buffer "*scratch*" ! (when (zerop (buffer-size)) ! (insert initial-scratch-message) ! (set-buffer-modified-p nil)))) ;; If user typed input during all that work, ;; abort the startup screen. Otherwise, display it now. *** ../emacs-cvs/lisp/tempo.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/tempo.el 2007-03-12 23:03:51.000000000 +0100 *************** *** 266,271 **** --- 266,273 ---- that you often should place this item after the text you want on the line. - `r>': Like `r', but it also indents the region. + - (r> PROMPT <NAME> <NOINSERT>): Like (r ...), but is also indents + the region. - `n>': Inserts a newline and indents line. - `o': Like `%' but leaves the point before the newline. - nil: It is ignored. *************** *** 352,357 **** --- 354,366 ---- (goto-char tempo-region-stop) (tempo-insert-prompt-compat (cdr element)))) + ((and (consp element) + (eq (car element) 'r>)) (if on-region + (progn + (goto-char tempo-region-stop) + (indent-region (mark) (point) nil)) + (tempo-insert-prompt-compat + (cdr element)))) ((and (consp element) (eq (car element) 's)) (tempo-insert-named (car (cdr element)))) ((and (consp element) *** ../emacs-cvs/lisp/woman.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/woman.el 2007-03-12 09:56:27.000000000 +0100 *************** *** 3327,3333 **** ;; otherwise match woman-request-regexp. The "\\&" which is ;; inserted to prevent this is removed by woman2-process-escapes. (and fescape ! (looking-at "^\\.") (insert "\\&")) (woman-set-face previous-pos (point) current-font) (if beg --- 3327,3333 ---- ;; otherwise match woman-request-regexp. The "\\&" which is ;; inserted to prevent this is removed by woman2-process-escapes. (and fescape ! (looking-at woman-request-regexp) (insert "\\&")) (woman-set-face previous-pos (point) current-font) (if beg *** ../emacs-cvs/lisp/xml.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/xml.el 2007-03-12 22:19:35.000000000 +0100 *************** *** 76,83 **** ;;; Code: ! ;; Note that {buffer-substring,match-string}-no-properties were ! ;; formerly used in several places, but that removes composition info. ;;******************************************************************* ;;** --- 76,87 ---- ;;; Code: ! ;; Note that buffer-substring and match-string were formerly used in ! ;; several places, because the -no-properties variants remove ! ;; composition info. However, after some discussion on emacs-devel, ! ;; the consensus was that the speed of the -no-properties variants was ! ;; a worthwhile tradeoff especially since we're usually parsing files ! ;; instead of hand-crafted XML. ;;******************************************************************* ;;** *************** *** 406,412 **** (unless (search-forward "]]>" nil t) (error "XML: (Not Well Formed) CDATA section does not end anywhere in the document")) (concat ! (buffer-substring pos (match-beginning 0)) (xml-parse-string)))) ;; DTD for the document ((looking-at "<!DOCTYPE") --- 410,416 ---- (unless (search-forward "]]>" nil t) (error "XML: (Not Well Formed) CDATA section does not end anywhere in the document")) (concat ! (buffer-substring-no-properties pos (match-beginning 0)) (xml-parse-string)))) ;; DTD for the document ((looking-at "<!DOCTYPE") *************** *** 427,433 **** (goto-char (match-end 1)) ;; Parse this node ! (let* ((node-name (match-string 1)) ;; Parse the attribute list. (attrs (xml-parse-attlist xml-ns)) children pos) --- 431,437 ---- (goto-char (match-end 1)) ;; Parse this node ! (let* ((node-name (match-string-no-properties 1)) ;; Parse the attribute list. (attrs (xml-parse-attlist xml-ns)) children pos) *************** *** 480,486 **** (nreverse children))) ;; This was an invalid start tag (Expected ">", but didn't see it.) (error "XML: (Well-Formed) Couldn't parse tag: %s" ! (buffer-substring (- (point) 10) (+ (point) 1))))))) (t ;; (Not one of PI, CDATA, Comment, End tag, or Start tag) (unless xml-sub-parser ; Usually, we error out. (error "XML: (Well-Formed) Invalid character")) --- 484,490 ---- (nreverse children))) ;; This was an invalid start tag (Expected ">", but didn't see it.) (error "XML: (Well-Formed) Couldn't parse tag: %s" ! (buffer-substring-no-properties (- (point) 10) (+ (point) 1))))))) (t ;; (Not one of PI, CDATA, Comment, End tag, or Start tag) (unless xml-sub-parser ; Usually, we error out. (error "XML: (Well-Formed) Invalid character")) *************** *** 495,501 **** (string (progn (if (search-forward "<" nil t) (forward-char -1) (goto-char (point-max))) ! (buffer-substring pos (point))))) ;; Clean up the string. As per XML specifications, the XML ;; processor should always pass the whole string to the ;; application. But \r's should be replaced: --- 499,505 ---- (string (progn (if (search-forward "<" nil t) (forward-char -1) (goto-char (point-max))) ! (buffer-substring-no-properties pos (point))))) ;; Clean up the string. As per XML specifications, the XML ;; processor should always pass the whole string to the ;; application. But \r's should be replaced: *************** *** 516,522 **** (while (looking-at (eval-when-compile (concat "\\(" xml-name-regexp "\\)\\s-*=\\s-*"))) (setq end-pos (match-end 0)) ! (setq name (xml-maybe-do-ns (match-string 1) nil xml-ns)) (goto-char end-pos) ;; See also: http://www.w3.org/TR/2000/REC-xml-20001006#AVNormalize --- 520,526 ---- (while (looking-at (eval-when-compile (concat "\\(" xml-name-regexp "\\)\\s-*=\\s-*"))) (setq end-pos (match-end 0)) ! (setq name (xml-maybe-do-ns (match-string-no-properties 1) nil xml-ns)) (goto-char end-pos) ;; See also: http://www.w3.org/TR/2000/REC-xml-20001006#AVNormalize *************** *** 535,541 **** ;; Multiple whitespace characters should be replaced with a single one ;; in the attributes ! (let ((string (match-string 1)) (pos 0)) (replace-regexp-in-string "\\s-\\{2,\\}" " " string) (let ((expansion (xml-substitute-special string))) --- 539,545 ---- ;; Multiple whitespace characters should be replaced with a single one ;; in the attributes ! (let ((string (match-string-no-properties 1)) (pos 0)) (replace-regexp-in-string "\\s-\\{2,\\}" " " string) (let ((expansion (xml-substitute-special string))) *************** *** 575,581 **** ;; Get the name of the document (looking-at xml-name-regexp) ! (let ((dtd (list (match-string 0) 'dtd)) type element end-pos) (goto-char (match-end 0)) --- 579,585 ---- ;; Get the name of the document (looking-at xml-name-regexp) ! (let ((dtd (list (match-string-no-properties 0) 'dtd)) type element end-pos) (goto-char (match-end 0)) *************** *** 590,607 **** "\\='\\([[:space:][:alnum:]-()+,./:=?;!*#@$_%]*\\)'" nil t)) (error "XML: Missing Public ID")) ! (let ((pubid (match-string 1))) (skip-syntax-forward " ") (unless (or (re-search-forward "\\='\\([^']*\\)'" nil t) (re-search-forward "\\=\"\\([^\"]*\\)\"" nil t)) (error "XML: Missing System ID")) ! (push (list pubid (match-string 1) 'public) dtd))) ((looking-at "SYSTEM\\s-+") (goto-char (match-end 0)) (unless (or (re-search-forward "\\='\\([^']*\\)'" nil t) (re-search-forward "\\=\"\\([^\"]*\\)\"" nil t)) (error "XML: Missing System ID")) ! (push (list (match-string 1) 'system) dtd))) (skip-syntax-forward " ") (if (eq ?> (char-after)) (forward-char) --- 594,611 ---- "\\='\\([[:space:][:alnum:]-()+,./:=?;!*#@$_%]*\\)'" nil t)) (error "XML: Missing Public ID")) ! (let ((pubid (match-string-no-properties 1))) (skip-syntax-forward " ") (unless (or (re-search-forward "\\='\\([^']*\\)'" nil t) (re-search-forward "\\=\"\\([^\"]*\\)\"" nil t)) (error "XML: Missing System ID")) ! (push (list pubid (match-string-no-properties 1) 'public) dtd))) ((looking-at "SYSTEM\\s-+") (goto-char (match-end 0)) (unless (or (re-search-forward "\\='\\([^']*\\)'" nil t) (re-search-forward "\\=\"\\([^\"]*\\)\"" nil t)) (error "XML: Missing System ID")) ! (push (list (match-string-no-properties 1) 'system) dtd))) (skip-syntax-forward " ") (if (eq ?> (char-after)) (forward-char) *************** *** 618,624 **** ((looking-at "<!ELEMENT\\s-+\\([[:alnum:].%;]+\\)\\s-+\\([^>]+\\)>") ! (setq element (match-string 1) type (match-string-no-properties 2)) (setq end-pos (match-end 0)) --- 622,628 ---- ((looking-at "<!ELEMENT\\s-+\\([[:alnum:].%;]+\\)\\s-+\\([^>]+\\)>") ! (setq element (match-string-no-properties 1) type (match-string-no-properties 2)) (setq end-pos (match-end 0)) *************** *** 629,635 **** ((string-match "^ANY[ \t\n\r]*$" type) ;; any type of contents (setq type 'any)) ((string-match "^(\\(.*\\))[ \t\n\r]*$" type) ;; children ([47]) ! (setq type (xml-parse-elem-type (match-string 1 type)))) ((string-match "^%[^;]+;[ \t\n\r]*$" type) ;; substitution nil) (t --- 633,639 ---- ((string-match "^ANY[ \t\n\r]*$" type) ;; any type of contents (setq type 'any)) ((string-match "^(\\(.*\\))[ \t\n\r]*$" type) ;; children ([47]) ! (setq type (xml-parse-elem-type (match-string-no-properties 1 type)))) ((string-match "^%[^;]+;[ \t\n\r]*$" type) ;; substitution nil) (t *************** *** 659,667 **** ((looking-at (concat "<!ENTITY[ \t\n\r]*\\(" xml-name-re "\\)[ \t\n\r]*\\(" xml-entity-value-re "\\)[ \t\n\r]*>")) ! (let ((name (match-string 1)) ! (value (substring (match-string 2) 1 ! (- (length (match-string 2)) 1)))) (goto-char (match-end 0)) (setq xml-entity-alist (append xml-entity-alist --- 663,671 ---- ((looking-at (concat "<!ENTITY[ \t\n\r]*\\(" xml-name-re "\\)[ \t\n\r]*\\(" xml-entity-value-re "\\)[ \t\n\r]*>")) ! (let ((name (match-string-no-properties 1)) ! (value (substring (match-string-no-properties 2) 1 ! (- (length (match-string-no-properties 2)) 1)))) (goto-char (match-end 0)) (setq xml-entity-alist (append xml-entity-alist *************** *** 681,689 **** "\\|'[- \r\na-zA-Z0-9()+,./:=?;!*#@$_%]*'" "[ \t\n\r]+\\(\"[^\"]*\"\\|'[^']*'\\)" "[ \t\n\r]*>"))) ! (let ((name (match-string 1)) ! (file (substring (match-string 2) 1 ! (- (length (match-string 2)) 1)))) (goto-char (match-end 0)) (setq xml-entity-alist (append xml-entity-alist --- 685,693 ---- "\\|'[- \r\na-zA-Z0-9()+,./:=?;!*#@$_%]*'" "[ \t\n\r]+\\(\"[^\"]*\"\\|'[^']*'\\)" "[ \t\n\r]*>"))) ! (let ((name (match-string-no-properties 1)) ! (file (substring (match-string-no-properties 2) 1 ! (- (length (match-string-no-properties 2)) 1)))) (goto-char (match-end 0)) (setq xml-entity-alist (append xml-entity-alist *************** *** 722,729 **** (let (elem modifier) (if (string-match "(\\([^)]+\\))\\([+*?]?\\)" string) (progn ! (setq elem (match-string 1 string) ! modifier (match-string 2 string)) (if (string-match "|" elem) (setq elem (cons 'choice (mapcar 'xml-parse-elem-type --- 726,733 ---- (let (elem modifier) (if (string-match "(\\([^)]+\\))\\([+*?]?\\)" string) (progn ! (setq elem (match-string-no-properties 1 string) ! modifier (match-string-no-properties 2 string)) (if (string-match "|" elem) (setq elem (cons 'choice (mapcar 'xml-parse-elem-type *************** *** 733,740 **** (mapcar 'xml-parse-elem-type (split-string elem ","))))))) (if (string-match "[ \t\n\r]*\\([^+*?]+\\)\\([+*?]?\\)" string) ! (setq elem (match-string 1 string) ! modifier (match-string 2 string)))) (if (and (stringp elem) (string= elem "#PCDATA")) (setq elem 'pcdata)) --- 737,744 ---- (mapcar 'xml-parse-elem-type (split-string elem ","))))))) (if (string-match "[ \t\n\r]*\\([^+*?]+\\)\\([+*?]?\\)" string) ! (setq elem (match-string-no-properties 1 string) ! modifier (match-string-no-properties 2 string)))) (if (and (stringp elem) (string= elem "#PCDATA")) (setq elem 'pcdata)) *************** *** 765,783 **** children end-point) (while (string-match "&\\([^;]*\\);" string point) (setq end-point (match-end 0)) ! (let* ((this-part (match-string 1 string)) (prev-part (substring string point (match-beginning 0))) (entity (assoc this-part xml-entity-alist)) (expansion (cond ((string-match "#\\([0-9]+\\)" this-part) (let ((c (decode-char 'ucs ! (string-to-number (match-string 1 this-part))))) (if c (string c)))) ((string-match "#x\\([[:xdigit:]]+\\)" this-part) (let ((c (decode-char 'ucs ! (string-to-number (match-string 1 this-part) 16)))) (if c (string c)))) (entity (cdr entity)) --- 769,787 ---- children end-point) (while (string-match "&\\([^;]*\\);" string point) (setq end-point (match-end 0)) ! (let* ((this-part (match-string-no-properties 1 string)) (prev-part (substring string point (match-beginning 0))) (entity (assoc this-part xml-entity-alist)) (expansion (cond ((string-match "#\\([0-9]+\\)" this-part) (let ((c (decode-char 'ucs ! (string-to-number (match-string-no-properties 1 this-part))))) (if c (string c)))) ((string-match "#x\\([[:xdigit:]]+\\)" this-part) (let ((c (decode-char 'ucs ! (string-to-number (match-string-no-properties 1 this-part) 16)))) (if c (string c)))) (entity (cdr entity)) *** ../emacs-cvs/lisp/calendar/cal-china.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calendar/cal-china.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 83,90 **** ; The correct value is as follows, but the Chinese calendrical ; authorities do NOT use DST in determining astronomical events: ; 60 ! "*Number of minutes difference between daylight savings and standard time ! for Chinese calendar. Default is for no daylight savings time." :type 'integer :group 'chinese-calendar) --- 83,90 ---- ; The correct value is as follows, but the Chinese calendrical ; authorities do NOT use DST in determining astronomical events: ; 60 ! "*Number of minutes difference between daylight saving and standard time ! for Chinese calendar. Default is for no daylight saving time." :type 'integer :group 'chinese-calendar) *************** *** 99,105 **** :group 'chinese-calendar) (defcustom chinese-calendar-daylight-time-zone-name "CDT" ! "*Abbreviated name of daylight-savings time zone used for Chinese calendar." :type 'string :group 'chinese-calendar) --- 99,105 ---- :group 'chinese-calendar) (defcustom chinese-calendar-daylight-time-zone-name "CDT" ! "*Abbreviated name of daylight saving time zone used for Chinese calendar." :type 'string :group 'chinese-calendar) *************** *** 109,116 **** ; '(cond ((< 1986 year) (calendar-nth-named-day 1 0 4 year 10)) ; ((= 1986 year) '(5 4 1986)) ; (t nil)) ! "*Sexp giving the date on which daylight savings time starts for Chinese ! calendar. Default is for no daylight savings time. See documentation of `calendar-daylight-savings-starts'." :type 'sexp :group 'chinese-calendar) --- 109,116 ---- ; '(cond ((< 1986 year) (calendar-nth-named-day 1 0 4 year 10)) ; ((= 1986 year) '(5 4 1986)) ; (t nil)) ! "*Sexp giving the date on which daylight saving time starts for Chinese ! calendar. Default is for no daylight saving time. See documentation of `calendar-daylight-savings-starts'." :type 'sexp :group 'chinese-calendar) *************** *** 119,139 **** ; The correct value is as follows, but the Chinese calendrical ; authorities do NOT use DST in determining astronomical events: ; '(if (<= 1986 year) (calendar-nth-named-day 1 0 9 year 11)) ! "*Sexp giving the date on which daylight savings time ends for Chinese ! calendar. Default is for no daylight savings time. See documentation of `calendar-daylight-savings-ends'." :type 'sexp :group 'chinese-calendar) (defcustom chinese-calendar-daylight-savings-starts-time 0 ! "*Number of minutes after midnight that daylight savings time starts for ! Chinese calendar. Default is for no daylight savings time." :type 'integer :group 'chinese-calendar) (defcustom chinese-calendar-daylight-savings-ends-time 0 ! "*Number of minutes after midnight that daylight savings time ends for ! Chinese calendar. Default is for no daylight savings time." :type 'integer :group 'chinese-calendar) --- 119,139 ---- ; The correct value is as follows, but the Chinese calendrical ; authorities do NOT use DST in determining astronomical events: ; '(if (<= 1986 year) (calendar-nth-named-day 1 0 9 year 11)) ! "*Sexp giving the date on which daylight saving time ends for Chinese ! calendar. Default is for no daylight saving time. See documentation of `calendar-daylight-savings-ends'." :type 'sexp :group 'chinese-calendar) (defcustom chinese-calendar-daylight-savings-starts-time 0 ! "*Number of minutes after midnight that daylight saving time starts for ! Chinese calendar. Default is for no daylight saving time." :type 'integer :group 'chinese-calendar) (defcustom chinese-calendar-daylight-savings-ends-time 0 ! "*Number of minutes after midnight that daylight saving time ends for ! Chinese calendar. Default is for no daylight saving time." :type 'integer :group 'chinese-calendar) *** ../emacs-cvs/lisp/calendar/cal-dst.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calendar/cal-dst.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 1,4 **** ! ;;; cal-dst.el --- calendar functions for daylight savings rules ;; Copyright (C) 1993, 1994, 1995, 1996, 2001, 2002, 2003, 2004, 2005, ;; 2006, 2007 Free Software Foundation, Inc. --- 1,4 ---- ! ;;; cal-dst.el --- calendar functions for daylight saving rules ;; Copyright (C) 1993, 1994, 1995, 1996, 2001, 2002, 2003, 2004, 2005, ;; 2006, 2007 Free Software Foundation, Inc. *************** *** 7,13 **** ;; Edward M. Reingold <reingold@cs.uiuc.edu> ;; Maintainer: Glenn Morris <rgm@gnu.org> ;; Keywords: calendar ! ;; Human-Keywords: daylight savings time, calendar, diary, holidays ;; This file is part of GNU Emacs. --- 7,13 ---- ;; Edward M. Reingold <reingold@cs.uiuc.edu> ;; Maintainer: Glenn Morris <rgm@gnu.org> ;; Keywords: calendar ! ;; Human-Keywords: daylight saving time, calendar, diary, holidays ;; This file is part of GNU Emacs. *************** *** 29,35 **** ;;; Commentary: ;; This collection of functions implements the features of calendar.el and ! ;; holiday.el that deal with daylight savings time. ;; Comments, corrections, and improvements should be sent to ;; Edward M. Reingold Department of Computer Science --- 29,35 ---- ;;; Commentary: ;; This collection of functions implements the features of calendar.el and ! ;; holiday.el that deal with daylight saving time. ;; Comments, corrections, and improvements should be sent to ;; Edward M. Reingold Department of Computer Science *************** *** 46,52 **** "Non-nil means to check each year for DST transitions as needed. Otherwise assume the next two transitions found after the current date apply to all years. This is faster, but not always ! correct, since the dates of Daylight Saving transitions sometimes change." :type 'boolean :version "22.1" --- 46,52 ---- "Non-nil means to check each year for DST transitions as needed. Otherwise assume the next two transitions found after the current date apply to all years. This is faster, but not always ! correct, since the dates of daylight saving transitions sometimes change." :type 'boolean :version "22.1" *************** *** 142,149 **** (defun calendar-time-zone-daylight-rules (abs-date utc-diff) "Return daylight transition rule for ABS-DATE, UTC-DIFF sec offset from UTC. ! ABS-DATE must specify a day that contains a daylight savings transition. ! The result has the proper form for calendar-daylight-savings-starts'." (let* ((date (calendar-gregorian-from-absolute abs-date)) (weekday (% abs-date 7)) (m (extract-calendar-month date)) --- 142,149 ---- (defun calendar-time-zone-daylight-rules (abs-date utc-diff) "Return daylight transition rule for ABS-DATE, UTC-DIFF sec offset from UTC. ! ABS-DATE must specify a day that contains a daylight saving transition. ! The result has the proper form for `calendar-daylight-savings-starts'." (let* ((date (calendar-gregorian-from-absolute abs-date)) (weekday (% abs-date 7)) (m (extract-calendar-month date)) *************** *** 215,221 **** ;; See thread ;; http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00060.html (defun calendar-dst-find-data (&optional time) ! "Find data on the first Daylight Saving Time transitions after TIME. TIME defaults to `current-time'. Return value is as described for `calendar-current-time-zone'." (let* ((t0 (or time (current-time))) --- 215,221 ---- ;; See thread ;; http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00060.html (defun calendar-dst-find-data (&optional time) ! "Find data on the first daylight saving time transitions after TIME. TIME defaults to `current-time'. Return value is as described for `calendar-current-time-zone'." (let* ((t0 (or time (current-time))) *************** *** 228,236 **** (let* ((t1 (calendar-next-time-zone-transition t0)) (t2 (and t1 (calendar-next-time-zone-transition t1)))) (if (not t2) ! ;; This locale does not have daylight savings time. (list (/ t0-utc-diff 60) 0 t0-name t0-name nil nil 0 0) ! ;; Use heuristics to find daylight savings parameters. (let* ((t1-zone (current-time-zone t1)) (t1-utc-diff (car t1-zone)) (t1-name (car (cdr t1-zone))) --- 228,236 ---- (let* ((t1 (calendar-next-time-zone-transition t0)) (t2 (and t1 (calendar-next-time-zone-transition t1)))) (if (not t2) ! ;; This locale does not have daylight saving time. (list (/ t0-utc-diff 60) 0 t0-name t0-name nil nil 0 0) ! ;; Use heuristics to find daylight saving parameters. (let* ((t1-zone (current-time-zone t1)) (t1-utc-diff (car t1-zone)) (t1-name (car (cdr t1-zone))) *************** *** 254,267 **** ))))))))) (defvar calendar-dst-transition-cache nil ! "Internal cal-dst variable storing date of Daylight Saving Time transitions. Value is a list with elements of the form (YEAR START END), where START and END are expressions that when evaluated return the start and end dates (respectively) for DST in YEAR. Used by the function `calendar-dst-find-startend'.") (defun calendar-dst-find-startend (year) ! "Find the dates in YEAR on which Daylight Saving Time starts and ends. Returns a list (YEAR START END), where START and END are expressions that when evaluated return the start and end dates, respectively. This function first attempts to use pre-calculated --- 254,267 ---- ))))))))) (defvar calendar-dst-transition-cache nil ! "Internal cal-dst variable storing date of daylight saving time transitions. Value is a list with elements of the form (YEAR START END), where START and END are expressions that when evaluated return the start and end dates (respectively) for DST in YEAR. Used by the function `calendar-dst-find-startend'.") (defun calendar-dst-find-startend (year) ! "Find the dates in YEAR on which daylight saving time starts and ends. Returns a list (YEAR START END), where START and END are expressions that when evaluated return the start and end dates, respectively. This function first attempts to use pre-calculated *************** *** 288,303 **** UTC-DIFF is an integer specifying the number of minutes difference between standard time in the current time zone and Coordinated Universal Time (Greenwich Mean Time). A negative value means west of Greenwich. ! DST-OFFSET is an integer giving the daylight savings time offset in minutes. STD-ZONE is a string giving the name of the time zone when no seasonal time adjustment is in effect. DST-ZONE is a string giving the name of the time zone when there is a seasonal time adjustment in effect. DST-STARTS and DST-ENDS are sexps in the variable `year' giving the daylight ! savings time start and end rules, in the form expected by `calendar-daylight-savings-starts'. DST-STARTS-TIME and DST-ENDS-TIME are integers giving the number of minutes ! after midnight that daylight savings time starts and ends. If the local area does not use a seasonal time adjustment, STD-ZONE and DST-ZONE are equal, and all the DST-* integer variables are 0. --- 288,303 ---- UTC-DIFF is an integer specifying the number of minutes difference between standard time in the current time zone and Coordinated Universal Time (Greenwich Mean Time). A negative value means west of Greenwich. ! DST-OFFSET is an integer giving the daylight saving time offset in minutes. STD-ZONE is a string giving the name of the time zone when no seasonal time adjustment is in effect. DST-ZONE is a string giving the name of the time zone when there is a seasonal time adjustment in effect. DST-STARTS and DST-ENDS are sexps in the variable `year' giving the daylight ! saving time start and end rules, in the form expected by `calendar-daylight-savings-starts'. DST-STARTS-TIME and DST-ENDS-TIME are integers giving the number of minutes ! after midnight that daylight saving time starts and ends. If the local area does not use a seasonal time adjustment, STD-ZONE and DST-ZONE are equal, and all the DST-* integer variables are 0. *************** *** 308,314 **** (unless calendar-current-time-zone-cache (setq calendar-current-time-zone-cache (calendar-dst-find-data)))) ! ;;; The following eight defvars relating to daylight savings time should NOT be ;;; marked to go into loaddefs.el where they would be evaluated when Emacs is ;;; dumped. These variables' appropriate values depend on the conditions under ;;; which the code is INVOKED; so it's inappropriate to initialize them when --- 308,314 ---- (unless calendar-current-time-zone-cache (setq calendar-current-time-zone-cache (calendar-dst-find-data)))) ! ;;; The following eight defvars relating to daylight saving time should NOT be ;;; marked to go into loaddefs.el where they would be evaluated when Emacs is ;;; dumped. These variables' appropriate values depend on the conditions under ;;; which the code is INVOKED; so it's inappropriate to initialize them when *************** *** 324,332 **** (defvar calendar-daylight-time-offset (or (car (cdr calendar-current-time-zone-cache)) 60) ! "*Number of minutes difference between daylight savings and standard time. ! If the locale never uses daylight savings time, set this to 0.") (defvar calendar-standard-time-zone-name (or (car (nthcdr 2 calendar-current-time-zone-cache)) "EST") --- 324,332 ---- (defvar calendar-daylight-time-offset (or (car (cdr calendar-current-time-zone-cache)) 60) ! "*Number of minutes difference between daylight saving and standard time. ! If the locale never uses daylight saving time, set this to 0.") (defvar calendar-standard-time-zone-name (or (car (nthcdr 2 calendar-current-time-zone-cache)) "EST") *************** *** 335,346 **** (defvar calendar-daylight-time-zone-name (or (car (nthcdr 3 calendar-current-time-zone-cache)) "EDT") ! "*Abbreviated name of daylight-savings time zone at `calendar-location-name'. For example, \"EDT\" in New York City, \"PDT\" for Los Angeles.") (defun calendar-dst-starts (year) ! "Return the date of YEAR on which Daylight Saving Time starts. This function respects the value of `calendar-dst-check-each-year-flag'." (or (let ((expr (if calendar-dst-check-each-year-flag (cadr (calendar-dst-find-startend year)) --- 335,346 ---- (defvar calendar-daylight-time-zone-name (or (car (nthcdr 3 calendar-current-time-zone-cache)) "EDT") ! "*Abbreviated name of daylight saving time zone at `calendar-location-name'. For example, \"EDT\" in New York City, \"PDT\" for Los Angeles.") (defun calendar-dst-starts (year) ! "Return the date of YEAR on which daylight saving time starts. This function respects the value of `calendar-dst-check-each-year-flag'." (or (let ((expr (if calendar-dst-check-each-year-flag (cadr (calendar-dst-find-startend year)) *************** *** 351,357 **** (calendar-nth-named-day 2 0 3 year)))) (defun calendar-dst-ends (year) ! "Return the date of YEAR on which Daylight Saving Time ends. This function respects the value of `calendar-dst-check-each-year-flag'." (or (let ((expr (if calendar-dst-check-each-year-flag (nth 2 (calendar-dst-find-startend year)) --- 351,357 ---- (calendar-nth-named-day 2 0 3 year)))) (defun calendar-dst-ends (year) ! "Return the date of YEAR on which daylight saving time ends. This function respects the value of `calendar-dst-check-each-year-flag'." (or (let ((expr (if calendar-dst-check-each-year-flag (nth 2 (calendar-dst-find-startend year)) *************** *** 366,378 **** (put 'calendar-daylight-savings-starts 'risky-local-variable t) (defvar calendar-daylight-savings-starts '(calendar-dst-starts year) ! "*Sexp giving the date on which daylight savings time starts. This is an expression in the variable `year' whose value gives the Gregorian ! date in the form (month day year) on which daylight savings time starts. It is ! used to determine the starting date of daylight savings time for the holiday list and for correcting times of day in the solar and lunar calculations. ! For example, if daylight savings time is mandated to start on October 1, you would set `calendar-daylight-savings-starts' to '(10 1 year) --- 366,378 ---- (put 'calendar-daylight-savings-starts 'risky-local-variable t) (defvar calendar-daylight-savings-starts '(calendar-dst-starts year) ! "*Sexp giving the date on which daylight saving time starts. This is an expression in the variable `year' whose value gives the Gregorian ! date in the form (month day year) on which daylight saving time starts. It is ! used to determine the starting date of daylight saving time for the holiday list and for correcting times of day in the solar and lunar calculations. ! For example, if daylight saving time is mandated to start on October 1, you would set `calendar-daylight-savings-starts' to '(10 1 year) *************** *** 381,415 **** '(calendar-nth-named-day 1 0 4 year) ! If the locale never uses daylight savings time, set this to nil.") ;;;###autoload (put 'calendar-daylight-savings-ends 'risky-local-variable t) (defvar calendar-daylight-savings-ends '(calendar-dst-ends year) ! "*Sexp giving the date on which daylight savings time ends. This is an expression in the variable `year' whose value gives the Gregorian ! date in the form (month day year) on which daylight savings time ends. It is ! used to determine the starting date of daylight savings time for the holiday list and for correcting times of day in the solar and lunar calculations. ! For example, if daylight savings time ends on the last Sunday in October: '(calendar-nth-named-day -1 0 10 year) ! If the locale never uses daylight savings time, set this to nil.") (defvar calendar-daylight-savings-starts-time (or (car (nthcdr 6 calendar-current-time-zone-cache)) 120) ! "*Number of minutes after midnight that daylight savings time starts.") (defvar calendar-daylight-savings-ends-time (or (car (nthcdr 7 calendar-current-time-zone-cache)) calendar-daylight-savings-starts-time) ! "*Number of minutes after midnight that daylight savings time ends.") (defun dst-in-effect (date) ! "True if on absolute DATE daylight savings time is in effect. Fractional part of DATE is local standard time of day." (let* ((year (extract-calendar-year (calendar-gregorian-from-absolute (floor date)))) --- 381,415 ---- '(calendar-nth-named-day 1 0 4 year) ! If the locale never uses daylight saving time, set this to nil.") ;;;###autoload (put 'calendar-daylight-savings-ends 'risky-local-variable t) (defvar calendar-daylight-savings-ends '(calendar-dst-ends year) ! "*Sexp giving the date on which daylight saving time ends. This is an expression in the variable `year' whose value gives the Gregorian ! date in the form (month day year) on which daylight saving time ends. It is ! used to determine the starting date of daylight saving time for the holiday list and for correcting times of day in the solar and lunar calculations. ! For example, if daylight saving time ends on the last Sunday in October: '(calendar-nth-named-day -1 0 10 year) ! If the locale never uses daylight saving time, set this to nil.") (defvar calendar-daylight-savings-starts-time (or (car (nthcdr 6 calendar-current-time-zone-cache)) 120) ! "*Number of minutes after midnight that daylight saving time starts.") (defvar calendar-daylight-savings-ends-time (or (car (nthcdr 7 calendar-current-time-zone-cache)) calendar-daylight-savings-starts-time) ! "*Number of minutes after midnight that daylight saving time ends.") (defun dst-in-effect (date) ! "True if on absolute DATE daylight saving time is in effect. Fractional part of DATE is local standard time of day." (let* ((year (extract-calendar-year (calendar-gregorian-from-absolute (floor date)))) *************** *** 438,447 **** decimal fraction time, and `zone' is a string. Optional parameter STYLE forces the result time to be standard time when its ! value is 'standard and daylight savings time (if available) when its value is 'daylight. ! Conversion to daylight savings time is done according to `calendar-daylight-savings-starts', `calendar-daylight-savings-ends', `calendar-daylight-savings-starts-time', `calendar-daylight-savings-ends-time', and --- 438,447 ---- decimal fraction time, and `zone' is a string. Optional parameter STYLE forces the result time to be standard time when its ! value is 'standard and daylight saving time (if available) when its value is 'daylight. ! Conversion to daylight saving time is done according to `calendar-daylight-savings-starts', `calendar-daylight-savings-ends', `calendar-daylight-savings-starts-time', `calendar-daylight-savings-ends-time', and *** ../emacs-cvs/lisp/calendar/calendar.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calendar/calendar.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 57,63 **** ;; appt.el Appointment notification ;; cal-china.el Chinese calendar ;; cal-coptic.el Coptic/Ethiopic calendars ! ;; cal-dst.el Daylight savings time rules ;; cal-hebrew.el Hebrew calendar ;; cal-islam.el Islamic calendar ;; cal-bahai.el Baha'i calendar --- 57,63 ---- ;; appt.el Appointment notification ;; cal-china.el Chinese calendar ;; cal-coptic.el Coptic/Ethiopic calendars ! ;; cal-dst.el Daylight saving time rules ;; cal-hebrew.el Hebrew calendar ;; cal-islam.el Islamic calendar ;; cal-bahai.el Baha'i calendar *************** *** 1160,1166 **** (funcall 'holiday-sexp calendar-daylight-savings-starts ! '(format "Daylight Savings Time Begins %s" (if (fboundp 'atan) (solar-time-string (/ calendar-daylight-savings-starts-time (float 60)) --- 1160,1166 ---- (funcall 'holiday-sexp calendar-daylight-savings-starts ! '(format "Daylight Saving Time Begins %s" (if (fboundp 'atan) (solar-time-string (/ calendar-daylight-savings-starts-time (float 60)) *************** *** 1169,1175 **** (funcall 'holiday-sexp calendar-daylight-savings-ends ! '(format "Daylight Savings Time Ends %s" (if (fboundp 'atan) (solar-time-string (/ calendar-daylight-savings-ends-time (float 60)) --- 1169,1175 ---- (funcall 'holiday-sexp calendar-daylight-savings-ends ! '(format "Daylight Saving Time Ends %s" (if (fboundp 'atan) (solar-time-string (/ calendar-daylight-savings-ends-time (float 60)) *** ../emacs-cvs/lisp/calendar/diary-lib.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calendar/diary-lib.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 300,309 **** day's and the next day's entries will be displayed. The value can also be a vector such as [0 2 2 2 2 4 1]; this value ! says to display no diary entries on Sunday, the display the entries ! for the current date and the day after on Monday through Thursday, ! display Friday through Monday's entries on Friday, and display only ! Saturday's entries on Saturday. This variable does not affect the diary display with the `d' command from the calendar; in that case, the prefix argument controls the --- 300,309 ---- day's and the next day's entries will be displayed. The value can also be a vector such as [0 2 2 2 2 4 1]; this value ! says to display no diary entries on Sunday, the entries for ! the current date and the day after on Monday through Thursday, ! Friday through Monday's entries on Friday, and only Saturday's ! entries on Saturday. This variable does not affect the diary display with the `d' command from the calendar; in that case, the prefix argument controls the *** ../emacs-cvs/lisp/calendar/lunar.el 2007-03-15 23:55:04.000000000 +0100 --- ./lisp/calendar/lunar.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 377,383 **** "Astronomical (Julian) day number of first new moon on or after astronomical \(Julian) day number d. The fractional part is the time of day. ! The date and time are local time, including any daylight savings rules, as governed by the values of calendar-daylight-savings-starts, calendar-daylight-savings-starts-time, calendar-daylight-savings-ends, calendar-daylight-savings-ends-time, calendar-daylight-time-offset, and --- 377,383 ---- "Astronomical (Julian) day number of first new moon on or after astronomical \(Julian) day number d. The fractional part is the time of day. ! The date and time are local time, including any daylight saving rules, as governed by the values of calendar-daylight-savings-starts, calendar-daylight-savings-starts-time, calendar-daylight-savings-ends, calendar-daylight-savings-ends-time, calendar-daylight-time-offset, and *** ../emacs-cvs/lisp/calendar/solar.el 2007-03-15 23:55:05.000000000 +0100 --- ./lisp/calendar/solar.el 2007-03-12 09:56:28.000000000 +0100 *************** *** 507,513 **** (defun solar-date-next-longitude (d l) "First moment on or after Julian day number D when sun's longitude is a multiple of L degrees at calendar-location-name with that location's ! local time (including any daylight savings rules). L must be an integer divisor of 360. --- 507,513 ---- (defun solar-date-next-longitude (d l) "First moment on or after Julian day number D when sun's longitude is a multiple of L degrees at calendar-location-name with that location's ! local time (including any daylight saving rules). L must be an integer divisor of 360. *** ../emacs-cvs/lisp/emacs-lisp/lisp-mode.el 2007-03-15 23:55:05.000000000 +0100 --- ./lisp/emacs-lisp/lisp-mode.el 2007-03-13 14:37:51.000000000 +0100 *************** *** 96,102 **** (regexp-opt '("defun" "defun*" "defsubst" "defmacro" "defadvice" "define-skeleton" ! "define-minor-mode" "define-global-minor-mode" "define-globalized-minor-mode" "define-derived-mode" "define-generic-mode" "define-compiler-macro" "define-modify-macro" --- 96,102 ---- (regexp-opt '("defun" "defun*" "defsubst" "defmacro" "defadvice" "define-skeleton" ! "define-minor-mode" "define-globalized-minor-mode" "define-globalized-minor-mode" "define-derived-mode" "define-generic-mode" "define-compiler-macro" "define-modify-macro" *** ../emacs-cvs/lisp/eshell/esh-mode.el 2007-03-15 23:55:05.000000000 +0100 --- ./lisp/eshell/esh-mode.el 2007-03-12 22:19:35.000000000 +0100 *************** *** 1078,1083 **** --- 1078,1091 ---- (custom-add-option 'eshell-output-filter-functions 'eshell-handle-control-codes) + (defun eshell-handle-ansi-color () + "Handle ANSI color codes." + (ansi-color-apply-on-region eshell-last-output-start + eshell-last-output-end)) + + (custom-add-option 'eshell-output-filter-functions + 'eshell-handle-ansi-color) + ;;; Code: ;;; arch-tag: ec65bc2b-da14-4547-81d3-a32af3a4dc57 *** ../emacs-cvs/lisp/textmodes/org.el 2007-03-15 23:55:05.000000000 +0100 --- ./lisp/textmodes/org.el 2007-03-12 22:19:35.000000000 +0100 *************** *** 3912,3917 **** --- 3912,3918 ---- (if (memq 'radio lk) '(org-activate-target-links (0 'org-link t))) (if (memq 'date lk) '(org-activate-dates (0 'org-date t))) (if (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend))) + '(org-hide-wide-columns (0 nil append)) ;; TODO lines (list (concat "^\\*+[ \t]*" org-not-done-regexp) '(1 'org-todo t)) *** ../emacs-cvs/lispref/os.texi 2007-03-15 23:55:05.000000000 +0100 --- ./lispref/os.texi 2007-03-12 09:56:29.000000000 +0100 *************** *** 1042,1048 **** @var{offset} is an integer giving the number of seconds ahead of UTC (east of Greenwich). A negative value means west of Greenwich. The second element, @var{name}, is a string giving the name of the time ! zone. Both elements change when daylight savings time begins or ends; if the user has specified a time zone that does not use a seasonal time adjustment, then the value is constant through time. --- 1042,1048 ---- @var{offset} is an integer giving the number of seconds ahead of UTC (east of Greenwich). A negative value means west of Greenwich. The second element, @var{name}, is a string giving the name of the time ! zone. Both elements change when daylight saving time begins or ends; if the user has specified a time zone that does not use a seasonal time adjustment, then the value is constant through time. *************** *** 1125,1131 **** The day of week, as an integer between 0 and 6, where 0 stands for Sunday. @item dst ! @code{t} if daylight savings time is effect, otherwise @code{nil}. @item zone An integer indicating the time zone, as the number of seconds east of Greenwich. --- 1125,1131 ---- The day of week, as an integer between 0 and 6, where 0 stands for Sunday. @item dst ! @code{t} if daylight saving time is effect, otherwise @code{nil}. @item zone An integer indicating the time zone, as the number of seconds east of Greenwich. *************** *** 1145,1155 **** yourself before you call @code{encode-time}. The optional argument @var{zone} defaults to the current time zone and ! its daylight savings time rules. If specified, it can be either a list (as you would get from @code{current-time-zone}), a string as in the @code{TZ} environment variable, @code{t} for Universal Time, or an integer (as you would get from @code{decode-time}). The specified ! zone is used without any further alteration for daylight savings time. If you pass more than seven arguments to @code{encode-time}, the first six are used as @var{seconds} through @var{year}, the last argument is --- 1145,1155 ---- yourself before you call @code{encode-time}. The optional argument @var{zone} defaults to the current time zone and ! its daylight saving time rules. If specified, it can be either a list (as you would get from @code{current-time-zone}), a string as in the @code{TZ} environment variable, @code{t} for Universal Time, or an integer (as you would get from @code{decode-time}). The specified ! zone is used without any further alteration for daylight saving time. If you pass more than seven arguments to @code{encode-time}, the first six are used as @var{seconds} through @var{year}, the last argument is *** ../emacs-cvs/man/ChangeLog 2007-03-15 23:55:06.000000000 +0100 --- ./man/ChangeLog 2007-03-12 09:56:30.000000000 +0100 *************** *** 1,3 **** --- 1,15 ---- + 2007-03-12 Glenn Morris <rgm@gnu.org> + + * calc.texi (Time Zones): Switch to new North America DST rule. + + * calendar.texi (Daylight Saving): Rename node from "Daylight Savings". + + 2007-03-11 Andreas Seltenreich <uwi7@rz.uni-karlsruhe.de> + + * gnus.texi (Mail and Post): Update documentation for gnus-user-agent. + The variable now uses a list of symbols instead of just a symbol. + Reported by Christoph Conrad <christoph.conrad@gmx.de>. + 2007-03-06 Romain Francoise <romain@orebokech.com> * faq.texi (New in Emacs 22): Don't say "now" too much. Add MH-E to *************** *** 315,323 **** 2006-12-24 Kevin Ryde <user42@zip.com.au> ! * calendar.texi (Holidays): US daylight savings begins second Sunday in March for 2007 onwards. ! (Daylight Savings): Show new US default daylight savings rules, 2nd Sun in Mar to 1st Sun in Nov, now in cal-dst.el. 2006-12-23 Chong Yidong <cyd@stupidchicken.com> --- 327,335 ---- 2006-12-24 Kevin Ryde <user42@zip.com.au> ! * calendar.texi (Holidays): US daylight saving begins second Sunday in March for 2007 onwards. ! (Daylight Savings): Show new US default daylight saving rules, 2nd Sun in Mar to 1st Sun in Nov, now in cal-dst.el. 2006-12-23 Chong Yidong <cyd@stupidchicken.com> *** ../emacs-cvs/man/calc.texi 2007-03-15 23:55:07.000000000 +0100 --- ./man/calc.texi 2007-03-12 09:56:31.000000000 +0100 *************** *** 17364,17394 **** @noindent @cindex Time zones ! @cindex Daylight savings time ! Time zones and daylight savings time are a complicated business. The conversions to and from Julian and Unix-style dates automatically ! compute the correct time zone and daylight savings adjustment to use, provided they can figure out this information. This section describes Calc's time zone adjustment algorithm in detail, in case you want to do conversions in different time zones or in case Calc's algorithms can't determine the right correction to use. ! Adjustments for time zones and daylight savings time are done by @kbd{t U}, @kbd{t J}, @kbd{t N}, and @kbd{t C}, but not by any other commands. In particular, @samp{<may 1 1991> - <apr 1 1991>} evaluates ! to exactly 30 days even though there is a daylight-savings transition in between. This is also true for Julian pure dates: @samp{julian(<may 1 1991>) - julian(<apr 1 1991>)}. But Julian ! and Unix date/times will adjust for daylight savings time: @samp{julian(<12am may 1 1991>) - julian(<12am apr 1 1991>)} evaluates to @samp{29.95834} (that's 29 days and 23 hours) ! because one hour was lost when daylight savings commenced on April 7, 1991. In brief, the idiom @samp{julian(@var{date1}) - julian(@var{date2})} computes the actual number of 24-hour periods between two dates, whereas @samp{@var{date1} - @var{date2}} computes the number of calendar ! days between two dates without taking daylight savings into account. @pindex calc-time-zone @ignore --- 17364,17394 ---- @noindent @cindex Time zones ! @cindex Daylight saving time ! Time zones and daylight saving time are a complicated business. The conversions to and from Julian and Unix-style dates automatically ! compute the correct time zone and daylight saving adjustment to use, provided they can figure out this information. This section describes Calc's time zone adjustment algorithm in detail, in case you want to do conversions in different time zones or in case Calc's algorithms can't determine the right correction to use. ! Adjustments for time zones and daylight saving time are done by @kbd{t U}, @kbd{t J}, @kbd{t N}, and @kbd{t C}, but not by any other commands. In particular, @samp{<may 1 1991> - <apr 1 1991>} evaluates ! to exactly 30 days even though there is a daylight-saving transition in between. This is also true for Julian pure dates: @samp{julian(<may 1 1991>) - julian(<apr 1 1991>)}. But Julian ! and Unix date/times will adjust for daylight saving time: @samp{julian(<12am may 1 1991>) - julian(<12am apr 1 1991>)} evaluates to @samp{29.95834} (that's 29 days and 23 hours) ! because one hour was lost when daylight saving commenced on April 7, 1991. In brief, the idiom @samp{julian(@var{date1}) - julian(@var{date2})} computes the actual number of 24-hour periods between two dates, whereas @samp{@var{date1} - @var{date2}} computes the number of calendar ! days between two dates without taking daylight saving into account. @pindex calc-time-zone @ignore *************** *** 17400,17406 **** seconds difference from Greenwich mean time (GMT). If the argument is a number, the result is simply that value multiplied by 3600. Typical arguments for North America are 5 (Eastern) or 8 (Pacific). If ! Daylight Savings time is in effect, one hour should be subtracted from the normal difference. If you give a prefix of plain @kbd{C-u}, @code{calc-time-zone} (like other --- 17400,17406 ---- seconds difference from Greenwich mean time (GMT). If the argument is a number, the result is simply that value multiplied by 3600. Typical arguments for North America are 5 (Eastern) or 8 (Pacific). If ! Daylight Saving time is in effect, one hour should be subtracted from the normal difference. If you give a prefix of plain @kbd{C-u}, @code{calc-time-zone} (like other *************** *** 17411,17422 **** adjustment. The time-zone argument can also be an HMS form, or it can be a variable which is a time zone name in upper- or lower-case. For example @samp{tzone(PST) = tzone(8)} and @samp{tzone(pdt) = tzone(7)} ! (for Pacific standard and daylight savings times, respectively). North American and European time zone names are defined as follows; note that for each time zone there is one name for standard time, ! another for daylight savings time, and a third for ``generalized'' time ! in which the daylight savings adjustment is computed from context. @smallexample @group --- 17411,17422 ---- adjustment. The time-zone argument can also be an HMS form, or it can be a variable which is a time zone name in upper- or lower-case. For example @samp{tzone(PST) = tzone(8)} and @samp{tzone(pdt) = tzone(7)} ! (for Pacific standard and daylight saving times, respectively). North American and European time zone names are defined as follows; note that for each time zone there is one name for standard time, ! another for daylight saving time, and a third for ``generalized'' time ! in which the daylight saving adjustment is computed from context. @smallexample @group *************** *** 17441,17447 **** @smallexample @group ( ( "PST" 8 0 ) ; Name as an upper-case string, then standard ! ( "PDT" 8 -1 ) ; adjustment, then daylight savings adjustment. ( "PGT" 8 "PST" "PDT" ) ) ; Generalized time zone. @end group @end smallexample --- 17441,17447 ---- @smallexample @group ( ( "PST" 8 0 ) ; Name as an upper-case string, then standard ! ( "PDT" 8 -1 ) ; adjustment, then daylight saving adjustment. ( "PGT" 8 "PST" "PDT" ) ) ; Generalized time zone. @end group @end smallexample *************** *** 17464,17473 **** command. If the time zone name found is one of the standard or daylight ! savings zone names from the above table, and Calc's internal ! daylight savings algorithm says that time and zone are consistent (e.g., @code{PDT} accompanies a date that Calc's algorithm would also ! consider to be daylight savings, or @code{PST} accompanies a date that Calc would consider to be standard time), then Calc substitutes the corresponding generalized time zone (like @code{PGT}). --- 17464,17473 ---- command. If the time zone name found is one of the standard or daylight ! saving zone names from the above table, and Calc's internal ! daylight saving algorithm says that time and zone are consistent (e.g., @code{PDT} accompanies a date that Calc's algorithm would also ! consider to be daylight saving, or @code{PST} accompanies a date that Calc would consider to be standard time), then Calc substitutes the corresponding generalized time zone (like @code{PGT}). *************** *** 17484,17521 **** arguments do the same thing as @samp{tzone()}. If the current time zone is a generalized time zone, e.g., @code{EGT}, Calc examines the date being converted to tell whether to use standard ! or daylight savings time. But if the current time zone is explicit, e.g., @code{EST} or @code{EDT}, then that adjustment is used exactly ! and Calc's daylight savings algorithm is not consulted. ! Some places don't follow the usual rules for daylight savings time. ! The state of Arizona, for example, does not observe daylight savings time. If you run Calc during the winter season in Arizona, the Unix @code{date} command will report @code{MST} time zone, which Calc will change to @code{MGT}. If you then convert a time that lies in the summer months, Calc will apply an incorrect daylight ! savings time adjustment. To avoid this, set your @code{TimeZone} variable explicitly to @code{MST} to force the use of standard, ! non-daylight-savings time. @vindex math-daylight-savings-hook @findex math-std-daylight-savings ! By default Calc always considers daylight savings time to begin at ! 2 a.m.@: on the first Sunday of April, and to end at 2 a.m.@: on the ! last Sunday of October. This is the rule that has been in effect ! in North America since 1987. If you are in a country that uses ! different rules for computing daylight savings time, you have two ! choices: Write your own daylight savings hook, or control time zones explicitly by setting the @code{TimeZone} variable and/or always giving a time-zone argument for the conversion functions. The Lisp variable @code{math-daylight-savings-hook} holds the ! name of a function that is used to compute the daylight savings adjustment for a given date. The default is @code{math-std-daylight-savings}, which computes an adjustment (either 0 or @mathit{-1}) using the North American rules given above. ! The daylight savings hook function is called with four arguments: The date, as a floating-point number in standard Calc format; a six-element list of the date decomposed into year, month, day, hour, minute, and second, respectively; a string which contains --- 17484,17521 ---- arguments do the same thing as @samp{tzone()}. If the current time zone is a generalized time zone, e.g., @code{EGT}, Calc examines the date being converted to tell whether to use standard ! or daylight saving time. But if the current time zone is explicit, e.g., @code{EST} or @code{EDT}, then that adjustment is used exactly ! and Calc's daylight saving algorithm is not consulted. ! Some places don't follow the usual rules for daylight saving time. ! The state of Arizona, for example, does not observe daylight saving time. If you run Calc during the winter season in Arizona, the Unix @code{date} command will report @code{MST} time zone, which Calc will change to @code{MGT}. If you then convert a time that lies in the summer months, Calc will apply an incorrect daylight ! saving time adjustment. To avoid this, set your @code{TimeZone} variable explicitly to @code{MST} to force the use of standard, ! non-daylight-saving time. @vindex math-daylight-savings-hook @findex math-std-daylight-savings ! By default Calc always considers daylight saving time to begin at ! 2 a.m.@: on the second Sunday of March, and to end at 2 a.m.@: on the ! first Sunday of November. This is the rule that has been in effect ! in North America since 2007. If you are in a country that uses ! different rules for computing daylight saving time, you have two ! choices: Write your own daylight saving hook, or control time zones explicitly by setting the @code{TimeZone} variable and/or always giving a time-zone argument for the conversion functions. The Lisp variable @code{math-daylight-savings-hook} holds the ! name of a function that is used to compute the daylight saving adjustment for a given date. The default is @code{math-std-daylight-savings}, which computes an adjustment (either 0 or @mathit{-1}) using the North American rules given above. ! The daylight saving hook function is called with four arguments: The date, as a floating-point number in standard Calc format; a six-element list of the date decomposed into year, month, day, hour, minute, and second, respectively; a string which contains *************** *** 17525,17542 **** @findex math-prev-weekday-in-month The Lisp function @code{math-prev-weekday-in-month} is useful for ! daylight savings computations. This is an internal version of the user-level @code{pwday} function described in the previous section. It takes four arguments: The floating-point date value, the corresponding six-element date list, the day-of-month number, and the weekday number (0-6). ! The default daylight savings hook ignores the time zone name, but a more sophisticated hook could use different algorithms for different time zones. It would also be possible to use different algorithms depending on the year number, but the default hook always uses the algorithm for 1987 and later. Here is a listing of the default ! daylight savings hook: @smallexample (defun math-std-daylight-savings (date dt zone bump) --- 17525,17542 ---- @findex math-prev-weekday-in-month The Lisp function @code{math-prev-weekday-in-month} is useful for ! daylight saving computations. This is an internal version of the user-level @code{pwday} function described in the previous section. It takes four arguments: The floating-point date value, the corresponding six-element date list, the day-of-month number, and the weekday number (0-6). ! The default daylight saving hook ignores the time zone name, but a more sophisticated hook could use different algorithms for different time zones. It would also be possible to use different algorithms depending on the year number, but the default hook always uses the algorithm for 1987 and later. Here is a listing of the default ! daylight saving hook: @smallexample (defun math-std-daylight-savings (date dt zone bump) *************** *** 17566,17590 **** and reasonably around the 2 a.m.@: transition in each direction. There is a ``missing'' hour between 2 a.m.@: and 3 a.m.@: at the ! beginning of daylight savings time; converting a date/time form that falls in this hour results in a time value for the following hour, ! from 3 a.m.@: to 4 a.m. At the end of daylight savings time, the hour from 1 a.m.@: to 2 a.m.@: repeats itself; converting a date/time form that falls in this hour results in a time value for the first manifestation of that time (@emph{not} the one that occurs one hour later). If @code{math-daylight-savings-hook} is @code{nil}, then the ! daylight savings adjustment is always taken to be zero. In algebraic formulas, @samp{tzone(@var{zone}, @var{date})} computes the time zone adjustment for a given zone name at a given date. The @var{date} is ignored unless @var{zone} is a generalized time zone. If @var{date} is a date form, the ! daylight savings computation is applied to it as it appears. If @var{date} is a numeric date value, it is adjusted for the ! daylight-savings version of @var{zone} before being given to ! the daylight savings hook. This odd-sounding rule ensures ! that the daylight-savings computation is always done in local time, not in the GMT time that a numeric @var{date} is typically represented in. --- 17566,17590 ---- and reasonably around the 2 a.m.@: transition in each direction. There is a ``missing'' hour between 2 a.m.@: and 3 a.m.@: at the ! beginning of daylight saving time; converting a date/time form that falls in this hour results in a time value for the following hour, ! from 3 a.m.@: to 4 a.m. At the end of daylight saving time, the hour from 1 a.m.@: to 2 a.m.@: repeats itself; converting a date/time form that falls in this hour results in a time value for the first manifestation of that time (@emph{not} the one that occurs one hour later). If @code{math-daylight-savings-hook} is @code{nil}, then the ! daylight saving adjustment is always taken to be zero. In algebraic formulas, @samp{tzone(@var{zone}, @var{date})} computes the time zone adjustment for a given zone name at a given date. The @var{date} is ignored unless @var{zone} is a generalized time zone. If @var{date} is a date form, the ! daylight saving computation is applied to it as it appears. If @var{date} is a numeric date value, it is adjusted for the ! daylight-saving version of @var{zone} before being given to ! the daylight saving hook. This odd-sounding rule ensures ! that the daylight-saving computation is always done in local time, not in the GMT time that a numeric @var{date} is typically represented in. *************** *** 17593,17601 **** @end ignore @tindex dsadj The @samp{dsadj(@var{date}, @var{zone})} function computes the ! daylight savings adjustment that is appropriate for @var{date} in time zone @var{zone}. If @var{zone} is explicitly in or not in ! daylight savings time (e.g., @code{PDT} or @code{PST}) the @var{date} is ignored. If @var{zone} is a generalized time zone, the algorithms described above are used. If @var{zone} is omitted, the computation is done for the current time zone. --- 17593,17601 ---- @end ignore @tindex dsadj The @samp{dsadj(@var{date}, @var{zone})} function computes the ! daylight saving adjustment that is appropriate for @var{date} in time zone @var{zone}. If @var{zone} is explicitly in or not in ! daylight saving time (e.g., @code{PDT} or @code{PST}) the @var{date} is ignored. If @var{zone} is a generalized time zone, the algorithms described above are used. If @var{zone} is omitted, the computation is done for the current time zone. *** ../emacs-cvs/man/calendar.texi 2007-03-15 23:55:07.000000000 +0100 --- ./man/calendar.texi 2007-03-12 09:56:31.000000000 +0100 *************** *** 43,49 **** * Diary:: Displaying events from your diary. * Appointments:: Reminders when it's time to do something. * Importing Diary:: Converting diary events to/from other formats. ! * Daylight Savings:: How to specify when daylight savings time is active. * Time Intervals:: Keeping track of time intervals. @ifnottex * Advanced Calendar/Diary Usage:: Advanced Calendar/Diary customization. --- 43,49 ---- * Diary:: Displaying events from your diary. * Appointments:: Reminders when it's time to do something. * Importing Diary:: Converting diary events to/from other formats. ! * Daylight Saving:: How to specify when daylight saving time is active. * Time Intervals:: Keeping track of time intervals. @ifnottex * Advanced Calendar/Diary Usage:: Advanced Calendar/Diary customization. *************** *** 604,611 **** @code{calendar-standard-time-zone-name} and @code{calendar-daylight-time-zone-name} are the abbreviations used in your time zone. Emacs displays the times of sunrise and sunset ! @emph{corrected for daylight savings time}. @xref{Daylight Savings}, ! for how daylight savings time is determined. As a user, you might find it convenient to set the calendar location variables for your usual physical location in your @file{.emacs} file. --- 604,611 ---- @code{calendar-standard-time-zone-name} and @code{calendar-daylight-time-zone-name} are the abbreviations used in your time zone. Emacs displays the times of sunrise and sunset ! @emph{corrected for daylight saving time}. @xref{Daylight Saving}, ! for how daylight saving time is determined. As a user, you might find it convenient to set the calendar location variables for your usual physical location in your @file{.emacs} file. *************** *** 646,654 **** year. The dates and times given for the phases of the moon are given in ! local time (corrected for daylight savings, when appropriate); but if the variable @code{calendar-time-zone} is void, Coordinated Universal ! Time (the Greenwich time zone) is used. @xref{Daylight Savings}. @node Other Calendars @section Conversion To and From Other Calendars --- 646,654 ---- year. The dates and times given for the phases of the moon are given in ! local time (corrected for daylight saving, when appropriate); but if the variable @code{calendar-time-zone} is void, Coordinated Universal ! Time (the Greenwich time zone) is used. @xref{Daylight Saving}. @node Other Calendars @section Conversion To and From Other Calendars *************** *** 1553,1566 **** file, mark the relevant area, and call @code{icalendar-export-region}. In both cases the result is appended to the target file. ! @node Daylight Savings ! @section Daylight Savings Time ! @cindex daylight savings time Emacs understands the difference between standard time and daylight ! savings time---the times given for sunrise, sunset, solstices, equinoxes, and the phases of the moon take that into account. The rules ! for daylight savings time vary from place to place and have also varied historically from year to year. To do the job properly, Emacs needs to know which rules to use. --- 1553,1566 ---- file, mark the relevant area, and call @code{icalendar-export-region}. In both cases the result is appended to the target file. ! @node Daylight Saving ! @section Daylight Saving Time ! @cindex daylight saving time Emacs understands the difference between standard time and daylight ! saving time---the times given for sunrise, sunset, solstices, equinoxes, and the phases of the moon take that into account. The rules ! for daylight saving time vary from place to place and have also varied historically from year to year. To do the job properly, Emacs needs to know which rules to use. *************** *** 1577,1588 **** These values should be Lisp expressions that refer to the variable @code{year}, and evaluate to the Gregorian date on which daylight ! savings time starts or (respectively) ends, in the form of a list @code{(@var{month} @var{day} @var{year})}. The values should be ! @code{nil} if your area does not use daylight savings time. Emacs uses these expressions to determine the starting date of ! daylight savings time for the holiday list and for correcting times of day in the solar and lunar calculations. The values for Cambridge, Massachusetts are as follows: --- 1577,1588 ---- These values should be Lisp expressions that refer to the variable @code{year}, and evaluate to the Gregorian date on which daylight ! saving time starts or (respectively) ends, in the form of a list @code{(@var{month} @var{day} @var{year})}. The values should be ! @code{nil} if your area does not use daylight saving time. Emacs uses these expressions to determine the starting date of ! daylight saving time for the holiday list and for correcting times of day in the solar and lunar calculations. The values for Cambridge, Massachusetts are as follows: *************** *** 1595,1601 **** @noindent That is, the second 0th day (Sunday) of the third month (March) in the year specified by @code{year}, and the first Sunday of the eleventh month ! (November) of that year. If daylight savings time were changed to start on October 1, you would set @code{calendar-daylight-savings-starts} to this: --- 1595,1601 ---- @noindent That is, the second 0th day (Sunday) of the third month (March) in the year specified by @code{year}, and the first Sunday of the eleventh month ! (November) of that year. If daylight saving time were changed to start on October 1, you would set @code{calendar-daylight-savings-starts} to this: *************** *** 1603,1615 **** (list 10 1 year) @end example ! If there is no daylight savings time at your location, or if you want all times in standard time, set @code{calendar-daylight-savings-starts} and @code{calendar-daylight-savings-ends} to @code{nil}. @vindex calendar-daylight-time-offset The variable @code{calendar-daylight-time-offset} specifies the ! difference between daylight savings time and standard time, measured in minutes. The value for Cambridge, Massachusetts is 60. @c @vindex calendar-daylight-savings-starts-time too long! --- 1603,1615 ---- (list 10 1 year) @end example ! If there is no daylight saving time at your location, or if you want all times in standard time, set @code{calendar-daylight-savings-starts} and @code{calendar-daylight-savings-ends} to @code{nil}. @vindex calendar-daylight-time-offset The variable @code{calendar-daylight-time-offset} specifies the ! difference between daylight saving time and standard time, measured in minutes. The value for Cambridge, Massachusetts is 60. @c @vindex calendar-daylight-savings-starts-time too long! *************** *** 1617,1623 **** The two variables @code{calendar-daylight-savings-starts-time} and @code{calendar-daylight-savings-ends-time} specify the number of minutes after midnight local time when the transition to and from daylight ! savings time should occur. For Cambridge, Massachusetts both variables' values are 120. @node Time Intervals --- 1617,1623 ---- The two variables @code{calendar-daylight-savings-starts-time} and @code{calendar-daylight-savings-ends-time} specify the number of minutes after midnight local time when the transition to and from daylight ! saving time should occur. For Cambridge, Massachusetts both variables' values are 120. @node Time Intervals *** ../emacs-cvs/man/emacs.texi 2007-03-15 23:55:07.000000000 +0100 --- ./man/emacs.texi 2007-03-12 09:56:32.000000000 +0100 *************** *** 812,818 **** * Diary:: Displaying events from your diary. * Appointments:: Reminders when it's time to do something. * Importing Diary:: Converting diary events to/from other formats. ! * Daylight Savings:: How to specify when daylight savings time is active. * Time Intervals:: Keeping track of time intervals. * Advanced Calendar/Diary Usage:: Advanced Calendar/Diary customization. --- 812,818 ---- * Diary:: Displaying events from your diary. * Appointments:: Reminders when it's time to do something. * Importing Diary:: Converting diary events to/from other formats. ! * Daylight Saving:: How to specify when daylight saving time is active. * Time Intervals:: Keeping track of time intervals. * Advanced Calendar/Diary Usage:: Advanced Calendar/Diary customization. *** ../emacs-cvs/man/gnus.texi 2007-03-15 23:55:09.000000000 +0100 --- ./man/gnus.texi 2007-03-12 09:56:33.000000000 +0100 *************** *** 11799,11810 **** @cindex User-Agent This variable controls which information should be exposed in the ! User-Agent header. It can be one of the symbols @code{gnus} (show only ! Gnus version), @code{emacs-gnus} (show only Emacs and Gnus versions), ! @code{emacs-gnus-config} (same as @code{emacs-gnus} plus system ! configuration), @code{emacs-gnus-type} (same as @code{emacs-gnus} plus ! system type) or a custom string. If you set it to a string, be sure to ! use a valid format, see RFC 2616. @end table --- 11799,11810 ---- @cindex User-Agent This variable controls which information should be exposed in the ! User-Agent header. It can be a list of symbols or a string. Valid ! symbols are @code{gnus} (show Gnus version) and @code{emacs} (show Emacs ! version). In addition to the Emacs version, you can add @code{codename} ! (show (S)XEmacs codename) or either @code{config} (show system ! configuration) or @code{type} (show system type). If you set it to a ! string, be sure to use a valid format, see RFC 2616. @end table *** ../emacs-cvs/src/ChangeLog 2007-03-15 23:55:10.000000000 +0100 --- ./src/ChangeLog 2007-03-12 22:19:37.000000000 +0100 *************** *** 1,3 **** --- 1,21 ---- + 2007-03-12 Andreas Schwab <schwab@suse.de> + + * lisp.h: Declare check_obarray. + + * process.c (Fdelete_process): Properly handle deletion of first + element of deleted_pid_list. + (create_process): Declare pid as pid_t. + + 2007-03-12 Kim F. Storm <storm@cua.dk> + + * process.c (sigchld_handler): Change type of pid to pid_t. + Scan deleted_pid_list explicitly to avoid using Fmember which don't + know about mark bits and make_fixnum_or_float which may malloc. + Reported by Andreas Schwab. + + * keyboard.c (read_key_sequence): Store original event into keybuf + when replaying sequence with local keymap(s) from string. + 2007-03-11 Sam Steingold <sds@gnu.org> * process.c (sigchld_handler): Sleep before wait3 to avoid a busyloop. *** ../emacs-cvs/src/ChangeLog.3 2007-03-15 23:55:11.000000000 +0100 --- ./src/ChangeLog.3 2007-03-12 09:56:34.000000000 +0100 *************** *** 5706,5712 **** HAVE_TIMEVAL is defined and NEED_TIME_H isn't. * systime.h: Note that the tz_dsttime field of the struct timezone ! returned by gettimeofday doesn't say whether daylight savings is _currently- active; rather it specifies whether it is *ever* active. (EMACS_GET_TZ_OFFSET_AND_SAVINGS): Removed `savings_flag' --- 5706,5712 ---- HAVE_TIMEVAL is defined and NEED_TIME_H isn't. * systime.h: Note that the tz_dsttime field of the struct timezone ! returned by gettimeofday doesn't say whether daylight saving is _currently- active; rather it specifies whether it is *ever* active. (EMACS_GET_TZ_OFFSET_AND_SAVINGS): Removed `savings_flag' *** ../emacs-cvs/src/dired.c 2007-03-15 23:55:11.000000000 +0100 --- ./src/dired.c 2007-03-13 14:37:51.000000000 +0100 *************** *** 670,677 **** if (!NILP (predicate)) { Lisp_Object decoded; decoded = Fexpand_file_name (DECODE_FILE (name), dirname); ! if (NILP (call1 (predicate, decoded))) continue; } --- 670,684 ---- if (!NILP (predicate)) { Lisp_Object decoded; + Lisp_Object val; + struct gcpro gcpro1; + + GCPRO1 (name); decoded = Fexpand_file_name (DECODE_FILE (name), dirname); ! val = call1 (predicate, decoded); ! UNGCPRO; ! ! if (NILP (val)) continue; } *************** *** 694,700 **** compare = min (bestmatchsize, len); p1 = SDATA (bestmatch); p2 = (unsigned char *) dp->d_name; ! matchsize = scmp(p1, p2, compare); if (matchsize < 0) matchsize = compare; if (completion_ignore_case) --- 701,707 ---- compare = min (bestmatchsize, len); p1 = SDATA (bestmatch); p2 = (unsigned char *) dp->d_name; ! matchsize = scmp (p1, p2, compare); if (matchsize < 0) matchsize = compare; if (completion_ignore_case) -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-15 23:47 ` [DIFFS] " Kim F. Storm @ 2007-03-16 0:41 ` Nick Roberts 2007-03-16 1:14 ` Miles Bader 0 siblings, 1 reply; 317+ messages in thread From: Nick Roberts @ 2007-03-16 0:41 UTC (permalink / raw) To: Kim F. Storm Cc: Glenn Morris, Chong Yidong, Jason Rumney, emacs-devel, Miles Bader > > Maybe the best thing is to restore from NIIMI Satoshi's rsync of the > > repository? [He said it's from 2007-03-13 02:48 GMT] > > Indeed! This would restore the CVS files, not just the changes. I don't know NIIMI Satoshi, but I'm sure he's a fine fellow. However, it's one thing to rely on an outside source for the last few changes, and another to rely on such a source for the *entire* revision history of Emacs. If we do follow this route then I would urge caution and suggest that someone, perhaps from Savannah, check that the only differences are, indeed, only in the last few changes. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 0:41 ` Nick Roberts @ 2007-03-16 1:14 ` Miles Bader 2007-03-16 1:52 ` Glenn Morris 0 siblings, 1 reply; 317+ messages in thread From: Miles Bader @ 2007-03-16 1:14 UTC (permalink / raw) To: emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > > Maybe the best thing is to restore from NIIMI Satoshi's rsync of the > > > repository? [He said it's from 2007-03-13 02:48 GMT] > > > > Indeed! This would restore the CVS files, not just the changes. > > I don't know NIIMI Satoshi, but I'm sure he's a fine fellow. However, it's one > thing to rely on an outside source for the last few changes, and another to > rely on such a source for the *entire* revision history of Emacs. > > If we do follow this route then I would urge caution and suggest that someone, > perhaps from Savannah, check that the only differences are, indeed, only in the > last few changes. Right. That's why I said: "I think the changes from the restored repository to the rsync would be small enough that they could probably be verified by eye." What I had in mind was simply doing a diff of the raw restored repository tree to the rsync repository tree. CVS files are fairly understandable text format, and the number of changes on the trunk is small enough that I think simply looking at that diff should be good enough for a small number of trunk changes. Unfortunately, now that I've thought about it more, a potential problem comes to mind: I think my last trunk->unicode sync is missing from the restored repository, and is probably in the rsync'd repository, and _those_ changes are not small. Since CVS mixes all branches in a single CVS file, interpreting those parts of the diff might not be so nice (and it affects a lot of files)... -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 1:14 ` Miles Bader @ 2007-03-16 1:52 ` Glenn Morris 2007-03-16 2:47 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 317+ messages in thread From: Glenn Morris @ 2007-03-16 1:52 UTC (permalink / raw) To: emacs-devel So it seems the recovery options are: 1) use NIIMI Satoshi's rsync copy (how does one get one of these, BTW?) to patch the repository. 2) use the recipe suggested on savannah to make a big commit of the missing differences, as per Kim's DIFF mail. http://savannah.gnu.org/forum/forum.php?forum_id=4793 3) use the emacs-diff and commit mailing lists to re-commit the lost changes (plus a couple of extra ones). 1) messing with the ,v files seems a bit risky to me, regardless of the provenance. 2) would be fine, but loses the original cvs commit logs. 3) I wouldn't mind doing my changes again... ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 1:52 ` Glenn Morris @ 2007-03-16 2:47 ` Miles Bader 2007-03-16 17:31 ` Richard Stallman 2007-03-16 2:56 ` NIIMI Satoshi 2007-03-16 4:08 ` Chong Yidong 2 siblings, 1 reply; 317+ messages in thread From: Miles Bader @ 2007-03-16 2:47 UTC (permalink / raw) To: emacs-devel Glenn Morris <rgm@gnu.org> writes: > 1) messing with the ,v files seems a bit risky to me, regardless of > the provenance. Messing with ,v files is not dangerous if you are simply copying them. The big cost seems to be verifying them. -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 2:47 ` Miles Bader @ 2007-03-16 17:31 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-16 17:31 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel Messing with ,v files is not dangerous if you are simply copying them. The big cost seems to be verifying them. That is right. Can someone write a script which can be used to determine the difference between two ,v files, as a set of commits plus their log entries? The script could also check that the difference consists of material added in one file. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 1:52 ` Glenn Morris 2007-03-16 2:47 ` Miles Bader @ 2007-03-16 2:56 ` NIIMI Satoshi 2007-03-16 17:31 ` Richard Stallman 2007-03-16 4:08 ` Chong Yidong 2 siblings, 1 reply; 317+ messages in thread From: NIIMI Satoshi @ 2007-03-16 2:56 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 2007/3/16, Glenn Morris <rgm@gnu.org>: > So it seems the recovery options are: > > 1) use NIIMI Satoshi's rsync copy (how does one get one of these, > BTW?) to patch the repository. rsync of repository is documented at: http://savannah.gnu.org/forum/forum.php?forum_id=4168 > 2) use the recipe suggested on savannah to make a big commit of the > missing differences, as per Kim's DIFF mail. > > http://savannah.gnu.org/forum/forum.php?forum_id=4793 > > 3) use the emacs-diff and commit mailing lists to re-commit the lost > changes (plus a couple of extra ones). 4) extract changesets from my copy of CVS repository (e.g. convert the repository to changeset based SCM), verify changesets missing in savannah, commit them into savannah. > 1) messing with the ,v files seems a bit risky to me, regardless of > the provenance. > > 2) would be fine, but loses the original cvs commit logs. > > 3) I wouldn't mind doing my changes again... 4) Not sure how to commit changesets with logs into CVS automatically. -- NIIMI Satoshi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 2:56 ` NIIMI Satoshi @ 2007-03-16 17:31 ` Richard Stallman 2007-03-16 19:24 ` NIIMI Satoshi 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-16 17:31 UTC (permalink / raw) To: NIIMI Satoshi; +Cc: rgm, emacs-devel 4) extract changesets from my copy of CVS repository (e.g. convert the repository to changeset based SCM), verify changesets missing in savannah, commit them into savannah. Can you (or anyone) point us at documentation on how to do this? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 17:31 ` Richard Stallman @ 2007-03-16 19:24 ` NIIMI Satoshi 0 siblings, 0 replies; 317+ messages in thread From: NIIMI Satoshi @ 2007-03-16 19:24 UTC (permalink / raw) To: emacs-devel 2007/3/17, Richard Stallman <rms@gnu.org>: > 4) extract changesets from my copy of CVS repository (e.g. convert the > repository to changeset based SCM), verify changesets missing in > savannah, commit them into savannah. > > Can you (or anyone) point us at documentation on how to do this? Here is a script to extract changesets with Mercurial (Distributed SCM) and cvs20hg (CVS to Mercurial converter). One problem of this script is extracted changeset "emacs-trunk-09" contains incorrect difference for "$Id$" since cvs20hg seems to ignore sticky flag for keyword expansion. But it can be fixed to edit the changeset by hand because its format is usual unified diff. --------CUT HERE-------- #! /bin/sh set -e -x # limit processing range for speed up date='2007-03-11 00:00:00 UTC' # path to savannah repository backup cvsroot_savannah=/repo/emacs # path to my repository backup cvsroot_new=/repo/bak/emacs workdir=/tmp/emacs.$$ mkdir ${workdir} cd ${workdir} # import initial source as of ${date} cvs -Q -R -d ${cvsroot_savannah} co -P -D "${date}" emacs find emacs -name CVS -type d | xargs rm -rf hg -q init emacs hg -q --cwd emacs commit -A -m 'initial commit' -d "${date}" -u admin # convert savannah repository backup to hg cvs20hg ${cvsroot_savannah} emacs emacs # get (1+ newest) revision new=$(expr $(hg -q -R emacs tip --template '{rev}') + 1) # convert my repository backup to hg cvs20hg ${cvsroot_new} emacs emacs # extract missing changesets hg -q -R emacs export -o emacs-trunk-%n ${new}: --------CUT HERE-------- -- NIIMI Satoshi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 1:52 ` Glenn Morris 2007-03-16 2:47 ` Miles Bader 2007-03-16 2:56 ` NIIMI Satoshi @ 2007-03-16 4:08 ` Chong Yidong 2007-03-16 9:38 ` Juanma Barranquero 2007-03-16 17:31 ` Richard Stallman 2 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-16 4:08 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel Glenn Morris <rgm@gnu.org> writes: > 2) use the recipe suggested on savannah to make a big commit of the > missing differences, as per Kim's DIFF mail. > > http://savannah.gnu.org/forum/forum.php?forum_id=4793 > > 2) would be fine, but loses the original cvs commit logs. This is the most straightforward method. I think the loss of commit logs is tolerable, since this would be a one-time event. I'd suggest going ahead with this approach. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 4:08 ` Chong Yidong @ 2007-03-16 9:38 ` Juanma Barranquero 2007-03-16 9:51 ` Juanma Barranquero 2007-03-17 2:44 ` Glenn Morris 2007-03-16 17:31 ` Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-16 9:38 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, emacs-devel On 3/16/07, Chong Yidong <cyd@stupidchicken.com> wrote: > This is the most straightforward method. OTOH, the best method, results-wise, would be for everyone who did a commit in the last week or so to check whether their code is in, and re-commit if not. We're talking of about three or four days of changes; it's not that big of a problem after all. The obvious downside is that it'll be a PITA for people who did many, or complex, commits because they'll have to disentangle them from one another or from other people's changes :( Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 9:38 ` Juanma Barranquero @ 2007-03-16 9:51 ` Juanma Barranquero 2007-03-16 10:08 ` Kim F. Storm 2007-03-17 2:44 ` Glenn Morris 1 sibling, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2007-03-16 9:51 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, emacs-devel On 3/16/07, Juanma Barranquero <lekktu@gmail.com> wrote: > The obvious downside is that it'll be a PITA for people who did many, > or complex, commits because they'll have to disentangle them from one > another or from other people's changes :( FWIW, thanks to Gmail I have all the messages from emacs-diffs from the past thirty days. I could take everything from 2007/03/10 or so and re-send every change to its author, to help in sorting out what is missing (at least on the trunk). Just a suggestion. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 9:51 ` Juanma Barranquero @ 2007-03-16 10:08 ` Kim F. Storm 2007-03-16 15:48 ` Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2007-03-16 10:08 UTC (permalink / raw) To: emacs-devel "Herbert Euler" <herberteuler@hotmail.com> writes: > I have the version of date 2007.03.13, including the web repository on > that day. So there's a plan: Both NIIMI Satoshi and Guanpeng Xu alias Herbert Euler have a fully rsync repository from 2007-03-13. So what if we get both of these, and compare them. If both are valid copies (I have not reason to think otherwise, but as Nick said we need some assurance), the diffs should be absolutely minimal, and we should be able to install the most recent of the two. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 10:08 ` Kim F. Storm @ 2007-03-16 15:48 ` Chong Yidong 2007-03-16 16:14 ` Kim F. Storm 2007-03-16 16:56 ` Jason Rumney 0 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-16 15:48 UTC (permalink / raw) To: Kim F. Storm; +Cc: emacs-devel storm@cua.dk (Kim F. Storm) writes: > Both NIIMI Satoshi and Guanpeng Xu alias Herbert Euler have a fully > rsync repository from 2007-03-13. > > So what if we get both of these, and compare them. Wouldn't it be easier to just check this in by hand? We don't have to do a mass commit, since Richard objects, but checking the patches in individually won't be such a chore. From looking at the diffs you generated, there are only 16 separate major sets of changes to the code and manuals (plus a few more minor changes to auxilliary files). It would take at most an hour for someone to check these in with the appropriate CVS logs. I volunteer do this if we decide it's a good idea. lisp/ChangeLog 2007-03-13 Chong Yidong comint.el 2007-03-12 Kim F. Storm ido.el 2007-03-12 Lawrence Mitchell (tiny change) tempo.el 2007-03-12 Carsten Dominik textmodes/org.el 2007-03-12 Mark A. Hershberger xml.el eshell/esh-mode.el 2007-03-12 Glenn Morris calc/calc-forms.el woman.el startup.el man/ChangeLog 2007-03-12 Glenn Morris calc.texi calendar.texi 2007-03-11 Andreas Seltenreich gnus.texi src/ChangeLog 2007-03-12 Andreas Schwab lisp.h process.c 2007-03-12 Kim F. Storm process.c keyboard.c ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 15:48 ` Chong Yidong @ 2007-03-16 16:14 ` Kim F. Storm 2007-03-16 18:54 ` Chong Yidong 2007-03-16 16:56 ` Jason Rumney 1 sibling, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2007-03-16 16:14 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > storm@cua.dk (Kim F. Storm) writes: > >> Both NIIMI Satoshi and Guanpeng Xu alias Herbert Euler have a fully >> rsync repository from 2007-03-13. >> >> So what if we get both of these, and compare them. > > Wouldn't it be easier to just check this in by hand? We don't have to > do a mass commit, since Richard objects, but checking the patches in > individually won't be such a chore. From looking at the diffs you > generated, there are only 16 separate major sets of changes to the > code and manuals (plus a few more minor changes to auxilliary files). > It would take at most an hour for someone to check these in with the > appropriate CVS logs. > > I volunteer do this if we decide it's a good idea. > lisp/ChangeLog > 2007-03-13 Chong Yidong comint.el > 2007-03-12 Kim F. Storm ido.el > 2007-03-12 Lawrence Mitchell (tiny change) tempo.el > 2007-03-12 Carsten Dominik textmodes/org.el > 2007-03-12 Mark A. Hershberger xml.el eshell/esh-mode.el > 2007-03-12 Glenn Morris calc/calc-forms.el woman.el startup.el > > man/ChangeLog > 2007-03-12 Glenn Morris calc.texi calendar.texi > 2007-03-11 Andreas Seltenreich gnus.texi > > src/ChangeLog > 2007-03-12 Andreas Schwab lisp.h process.c > 2007-03-12 Kim F. Storm process.c keyboard.c That list is not complete (ref the DIFFS I posted). At least RMS updated dired.c. Also, it only covers the trunk. By installing the most recent rsync tar-ball, we would get the branches up-to-date as well. It probably wouldn't take more than 1 hour to compare two very similar rsync tarballs either. So if you could get the two rsync tar-balls, compare and validate them, and send the "best one" to the Savannah people, it would be time well spent. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 16:14 ` Kim F. Storm @ 2007-03-16 18:54 ` Chong Yidong 2007-03-16 19:22 ` Glenn Morris 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-16 18:54 UTC (permalink / raw) To: Kim F. Storm; +Cc: Herbert Euler, NIIMI Satoshi, emacs-devel >> Wouldn't it be easier to just check this in by hand? > > it only covers the trunk. By installing the most recent rsync > tar-ball, we would get the branches up-to-date as well. > > It probably wouldn't take more than 1 hour to compare two > very similar rsync tarballs either. > > So if you could get the two rsync tar-balls, compare and validate > them, and send the "best one" to the Savannah people, it would be time > well spent. Except that Herbert Euler doesn't have a server to upload his tarball to. Can someone help him out here? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 18:54 ` Chong Yidong @ 2007-03-16 19:22 ` Glenn Morris 2007-03-17 1:32 ` Herbert Euler 0 siblings, 1 reply; 317+ messages in thread From: Glenn Morris @ 2007-03-16 19:22 UTC (permalink / raw) To: Chong Yidong; +Cc: Herbert Euler, emacs-devel, NIIMI Satoshi, Kim F. Storm Chong Yidong wrote: > Except that Herbert Euler doesn't have a server to upload his tarball > to. Can someone help him out here? Herbert, feel free to upload it via anonymous ftp to xoc1.stanford.edu, then I can put it on the web. Username "ftp" Password "cvsemacs" Use directory "upload". Let me know if any problems (usually firewall related). ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 19:22 ` Glenn Morris @ 2007-03-17 1:32 ` Herbert Euler 2007-03-17 2:19 ` Glenn Morris 0 siblings, 1 reply; 317+ messages in thread From: Herbert Euler @ 2007-03-17 1:32 UTC (permalink / raw) To: rgm, cyd; +Cc: storm, sa2c, emacs-devel >Herbert, feel free to upload it via anonymous ftp to >xoc1.stanford.edu, then I can put it on the web. > >Username "ftp" >Password "cvsemacs" >Use directory "upload". > >Let me know if any problems (usually firewall related). I tried to upload, but it failed in uploading. The error is ``connection closed by remote site.'' When I reconnected and tried again, I could not either delete the file or create a new file with the same name. Please delete that file and let me try again. Thank you very much. Regards, Guanpeng Xu _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 1:32 ` Herbert Euler @ 2007-03-17 2:19 ` Glenn Morris 2007-03-17 6:28 ` Leo 0 siblings, 1 reply; 317+ messages in thread From: Glenn Morris @ 2007-03-17 2:19 UTC (permalink / raw) To: Herbert Euler; +Cc: cyd, storm, sa2c, emacs-devel "Herbert Euler" wrote: > I tried to upload, but it failed in uploading. OK, so I got the file after whacking the firewall with a big stick. It's an anonymous CVS checkout of the web-pages and unicode-2 branch from 13 March. This does not really help us, but thanks for trying. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 2:19 ` Glenn Morris @ 2007-03-17 6:28 ` Leo 0 siblings, 0 replies; 317+ messages in thread From: Leo @ 2007-03-17 6:28 UTC (permalink / raw) To: emacs-devel On 2007-03-17, Glenn Morris said: > "Herbert Euler" wrote: > >> I tried to upload, but it failed in uploading. > > OK, so I got the file after whacking the firewall with a big stick. > > It's an anonymous CVS checkout of the web-pages and unicode-2 branch > from 13 March. > > This does not really help us, but thanks for trying. Time stamp of lisp/ChangeLog: Mar 13 13:41 ChangeLog. I have uploaded it to: http://people.pwf.cam.ac.uk/sl392/emacs/emacs.tar.bz2 Hope it helps. Let me know when you don't need it any more. -- Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 15:48 ` Chong Yidong 2007-03-16 16:14 ` Kim F. Storm @ 2007-03-16 16:56 ` Jason Rumney 1 sibling, 0 replies; 317+ messages in thread From: Jason Rumney @ 2007-03-16 16:56 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel, Kim F. Storm Chong Yidong wrote: > Wouldn't it be easier to just check this in by hand? Given the time we will spend discussing other options, probably. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 9:38 ` Juanma Barranquero 2007-03-16 9:51 ` Juanma Barranquero @ 2007-03-17 2:44 ` Glenn Morris 2007-03-17 17:26 ` Chong Yidong 1 sibling, 1 reply; 317+ messages in thread From: Glenn Morris @ 2007-03-17 2:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel "Juanma Barranquero" wrote: > OTOH, the best method, results-wise, would be for everyone who did a > commit in the last week or so to check whether their code is in, and > re-commit if not. We're talking of about three or four days of > changes; it's not that big of a problem after all. <rant> I absolutely agree with this. I could have happily recommitted my changes ten times over since Savannah was restored. But now I haven't got time any more, after sitting around waiting for super-magic-fun-happy-wonder-solution. </rant> ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 2:44 ` Glenn Morris @ 2007-03-17 17:26 ` Chong Yidong 2007-03-17 19:31 ` Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-17 17:26 UTC (permalink / raw) To: Glenn Morris; +Cc: Juanma Barranquero, emacs-devel Glenn Morris <rgm@gnu.org> writes: > "Juanma Barranquero" wrote: > >> OTOH, the best method, results-wise, would be for everyone who did a >> commit in the last week or so to check whether their code is in, and >> re-commit if not. We're talking of about three or four days of >> changes; it's not that big of a problem after all. > > I absolutely agree with this. > > I could have happily recommitted my changes ten times over since > Savannah was restored. But now I haven't got time any more, after > sitting around waiting for super-magic-fun-happy-wonder-solution. Well, in any case the super-magic-fun-happy-wonder-solution is clearly unworkable now that we don't have a second rsync'ed repository to verify against. I'll try recommitting the changes based on the contents of emacs-diffs. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 17:26 ` Chong Yidong @ 2007-03-17 19:31 ` Chong Yidong 2007-03-17 23:08 ` Miles Bader ` (3 more replies) 0 siblings, 4 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-17 19:31 UTC (permalink / raw) To: Glenn Morris; +Cc: Juanma Barranquero, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: >> I could have happily recommitted my changes ten times over since >> Savannah was restored. But now I haven't got time any more, after >> sitting around waiting for super-magic-fun-happy-wonder-solution. > > Well, in any case the super-magic-fun-happy-wonder-solution is clearly > unworkable now that we don't have a second rsync'ed repository to > verify against. > > I'll try recommitting the changes based on the contents of > emacs-diffs. HEAD is now up to date, with the exception of the very latest dired.c change (I couldn't find a ChangeLog entry or emacs-diffs commit log, so I'm not sure if that commit was completed before the crash). Is there a recent checkout of the unicode branch? I can update that too. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 19:31 ` Chong Yidong @ 2007-03-17 23:08 ` Miles Bader 2007-03-17 23:52 ` Kim F. Storm ` (2 subsequent siblings) 3 siblings, 0 replies; 317+ messages in thread From: Miles Bader @ 2007-03-17 23:08 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, emacs-devel, Juanma Barranquero Chong Yidong <cyd@stupidchicken.com> writes: > Is there a recent checkout of the unicode branch? I can update that > too. It probably doesn't matter too much, as there are really only two people that ever commit there -- Kenichi and me (from syncing). I did do a large commit which was lost, but can re-do it. -Miles -- "Suppose we've chosen the wrong god. Every time we go to church we're just making him madder and madder." -- Homer Simpson ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 19:31 ` Chong Yidong 2007-03-17 23:08 ` Miles Bader @ 2007-03-17 23:52 ` Kim F. Storm 2007-03-18 0:01 ` Andreas Schwab ` (3 more replies) 2007-03-18 12:19 ` Richard Stallman 2007-03-19 18:28 ` Glenn Morris 3 siblings, 4 replies; 317+ messages in thread From: Kim F. Storm @ 2007-03-17 23:52 UTC (permalink / raw) To: Chong Yidong; +Cc: Glenn Morris, emacs-devel, Juanma Barranquero Chong Yidong <cyd@stupidchicken.com> writes: > HEAD is now up to date, Thank you very much. I have verified that it matches the check-out I have from just before the crash with two exceptions: dired.c and lisp-mode.el. > with the exception of the very latest dired.c > change (I couldn't find a ChangeLog entry or emacs-diffs commit log, > so I'm not sure if that commit was completed before the crash). I suspect RMS forgot to commit the changelog, but in any case I've installed the dired.c change and added a ChangeLog entry for it. There's also a change to lisp-mode.el which looks a bit odd: *** ../latest/lisp/emacs-lisp/lisp-mode.el 2007-03-15 23:55:05.000000000 +0100 --- lisp/emacs-lisp/lisp-mode.el 2007-03-13 14:37:51.000000000 +0100 *************** *** 96,102 **** (regexp-opt '("defun" "defun*" "defsubst" "defmacro" "defadvice" "define-skeleton" ! "define-minor-mode" "define-global-minor-mode" "define-globalized-minor-mode" "define-derived-mode" "define-generic-mode" "define-compiler-macro" "define-modify-macro" --- 96,102 ---- (regexp-opt '("defun" "defun*" "defsubst" "defmacro" "defadvice" "define-skeleton" ! "define-minor-mode" "define-globalized-minor-mode" "define-globalized-minor-mode" "define-derived-mode" "define-generic-mode" "define-compiler-macro" "define-modify-macro" It looks plain wrong (it replaces define-global-minor-mode with define-globalized-minor-mode which is already in the list) - so I don't know what that change is supposed to fix. But there was this recent bug-report which might be related: > From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> > Subject: define-globalized-minor-mode is not fontified as a keyword > To: emacs-pretest-bug@gnu.org > Date: Mon, 12 Mar 2007 19:14:37 +0100 > > ... but define-global-minor-mode is in emacs-lisp-mode. > > > In GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) > of 2007-03-08 to which RMS responded: > From: Richard Stallman <rms@gnu.org> > Subject: Re: define-globalized-minor-mode is not fontified as a keyword > Date: Mon, 12 Mar 2007 22:44:49 -0400 > > Thanks. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 23:52 ` Kim F. Storm @ 2007-03-18 0:01 ` Andreas Schwab 2007-03-18 0:25 ` Kim F. Storm 2007-03-18 0:14 ` Lennart Borgman (gmail) ` (2 subsequent siblings) 3 siblings, 1 reply; 317+ messages in thread From: Andreas Schwab @ 2007-03-18 0:01 UTC (permalink / raw) To: Kim F. Storm; +Cc: Juanma Barranquero, Glenn Morris, Chong Yidong, emacs-devel storm@cua.dk (Kim F. Storm) writes: > There's also a change to lisp-mode.el which looks a bit odd: > > *** ../latest/lisp/emacs-lisp/lisp-mode.el 2007-03-15 23:55:05.000000000 +0100 > --- lisp/emacs-lisp/lisp-mode.el 2007-03-13 14:37:51.000000000 +0100 > *************** > *** 96,102 **** > (regexp-opt > '("defun" "defun*" "defsubst" "defmacro" > "defadvice" "define-skeleton" > ! "define-minor-mode" "define-global-minor-mode" > "define-globalized-minor-mode" > "define-derived-mode" "define-generic-mode" > "define-compiler-macro" "define-modify-macro" > --- 96,102 ---- > (regexp-opt > '("defun" "defun*" "defsubst" "defmacro" > "defadvice" "define-skeleton" > ! "define-minor-mode" "define-globalized-minor-mode" > "define-globalized-minor-mode" > "define-derived-mode" "define-generic-mode" > "define-compiler-macro" "define-modify-macro" > > > It looks plain wrong (it replaces define-global-minor-mode with > define-globalized-minor-mode which is already in the list) I think you are looking at it in the wrong order: the first part is the current version, which looks correct. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-18 0:01 ` Andreas Schwab @ 2007-03-18 0:25 ` Kim F. Storm 0 siblings, 0 replies; 317+ messages in thread From: Kim F. Storm @ 2007-03-18 0:25 UTC (permalink / raw) To: Andreas Schwab Cc: Juanma Barranquero, Chong Yidong, emacs-devel, Glenn Morris Andreas Schwab <schwab@suse.de> writes: > storm@cua.dk (Kim F. Storm) writes: > >> There's also a change to lisp-mode.el which looks a bit odd: >> >> *** ../latest/lisp/emacs-lisp/lisp-mode.el 2007-03-15 23:55:05.000000000 +0100 >> --- lisp/emacs-lisp/lisp-mode.el 2007-03-13 14:37:51.000000000 +0100 >> *************** >> *** 96,102 **** >> (regexp-opt >> '("defun" "defun*" "defsubst" "defmacro" >> "defadvice" "define-skeleton" >> ! "define-minor-mode" "define-global-minor-mode" >> "define-globalized-minor-mode" >> "define-derived-mode" "define-generic-mode" >> "define-compiler-macro" "define-modify-macro" >> --- 96,102 ---- >> (regexp-opt >> '("defun" "defun*" "defsubst" "defmacro" >> "defadvice" "define-skeleton" >> ! "define-minor-mode" "define-globalized-minor-mode" >> "define-globalized-minor-mode" >> "define-derived-mode" "define-generic-mode" >> "define-compiler-macro" "define-modify-macro" >> >> >> It looks plain wrong (it replaces define-global-minor-mode with >> define-globalized-minor-mode which is already in the list) > > I think you are looking at it in the wrong order: the first part is the > current version, which looks correct. The first part is the current version, the second one is the one that was in the repository just before the disk crash - so it is not in the wrong order. I agree that it looks like the second version is wrong and the first (current) is correct. So I wonder how the second version it ended up in my repository on 2007-03-13 -- unless someone committed that change on 2007-03-12 or 2007-03-13. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 23:52 ` Kim F. Storm 2007-03-18 0:01 ` Andreas Schwab @ 2007-03-18 0:14 ` Lennart Borgman (gmail) 2007-03-18 1:16 ` Chong Yidong 2007-03-18 15:56 ` Richard Stallman 3 siblings, 0 replies; 317+ messages in thread From: Lennart Borgman (gmail) @ 2007-03-18 0:14 UTC (permalink / raw) To: Kim F. Storm; +Cc: Juanma Barranquero, Glenn Morris, Chong Yidong, emacs-devel Kim F. Storm wrote: > There's also a change to lisp-mode.el which looks a bit odd: > > *** ../latest/lisp/emacs-lisp/lisp-mode.el 2007-03-15 23:55:05.000000000 +0100 > --- lisp/emacs-lisp/lisp-mode.el 2007-03-13 14:37:51.000000000 +0100 > *************** > *** 96,102 **** > (regexp-opt > '("defun" "defun*" "defsubst" "defmacro" > "defadvice" "define-skeleton" > ! "define-minor-mode" "define-global-minor-mode" > "define-globalized-minor-mode" > "define-derived-mode" "define-generic-mode" > "define-compiler-macro" "define-modify-macro" > --- 96,102 ---- > (regexp-opt > '("defun" "defun*" "defsubst" "defmacro" > "defadvice" "define-skeleton" > ! "define-minor-mode" "define-globalized-minor-mode" > "define-globalized-minor-mode" > "define-derived-mode" "define-generic-mode" > "define-compiler-macro" "define-modify-macro" > > > It looks plain wrong (it replaces define-global-minor-mode with > define-globalized-minor-mode which is already in the list) - so > I don't know what that change is supposed to fix. But there was > this recent bug-report which might be related: > >> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> >> Subject: define-globalized-minor-mode is not fontified as a keyword >> To: emacs-pretest-bug@gnu.org >> Date: Mon, 12 Mar 2007 19:14:37 +0100 >> >> ... but define-global-minor-mode is in emacs-lisp-mode. >> >> >> In GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) >> of 2007-03-08 > > to which RMS responded: > >> From: Richard Stallman <rms@gnu.org> >> Subject: Re: define-globalized-minor-mode is not fontified as a keyword >> Date: Mon, 12 Mar 2007 22:44:49 -0400 >> >> Thanks. Maybe there is some misunderstanding. What I was complaining about was that the function name define-globalized-minor-mode does not get the font-lock-keyword-face. (I do not know how to change that.) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 23:52 ` Kim F. Storm 2007-03-18 0:01 ` Andreas Schwab 2007-03-18 0:14 ` Lennart Borgman (gmail) @ 2007-03-18 1:16 ` Chong Yidong 2007-03-18 2:11 ` Lennart Borgman (gmail) 2007-03-18 8:30 ` martin rudalics 2007-03-18 15:56 ` Richard Stallman 3 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-18 1:16 UTC (permalink / raw) To: Kim F. Storm; +Cc: Glenn Morris, emacs-devel, Juanma Barranquero storm@cua.dk (Kim F. Storm) writes: > There's also a change to lisp-mode.el which looks a bit odd: > ! "define-minor-mode" "define-global-minor-mode" > --- 96,102 ---- > ! "define-minor-mode" "define-globalized-minor-mode" > > > It looks plain wrong (it replaces define-global-minor-mode with > define-globalized-minor-mode which is already in the list) - so > I don't know what that change is supposed to fix. Yes, it's definitely an incorrect change. That's why I didn't re-commit it. storm@cua.dk (Kim F. Storm) writes: ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-18 1:16 ` Chong Yidong @ 2007-03-18 2:11 ` Lennart Borgman (gmail) 2007-03-18 8:30 ` martin rudalics 1 sibling, 0 replies; 317+ messages in thread From: Lennart Borgman (gmail) @ 2007-03-18 2:11 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, Glenn Morris, emacs-devel, Kim F. Storm Chong Yidong wrote: > storm@cua.dk (Kim F. Storm) writes: > >> There's also a change to lisp-mode.el which looks a bit odd: >> ! "define-minor-mode" "define-global-minor-mode" >> --- 96,102 ---- >> ! "define-minor-mode" "define-globalized-minor-mode" >> >> >> It looks plain wrong (it replaces define-global-minor-mode with >> define-globalized-minor-mode which is already in the list) - so >> I don't know what that change is supposed to fix. > > Yes, it's definitely an incorrect change. That's why I didn't > re-commit it. storm@cua.dk (Kim F. Storm) writes: But what should the correct change be? Why is not define-globalized-minor-mode fontified correctly? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-18 1:16 ` Chong Yidong 2007-03-18 2:11 ` Lennart Borgman (gmail) @ 2007-03-18 8:30 ` martin rudalics 2007-03-19 15:45 ` Chong Yidong 1 sibling, 1 reply; 317+ messages in thread From: martin rudalics @ 2007-03-18 8:30 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, Glenn Morris, emacs-devel, Kim F. Storm [-- Attachment #1: Type: text/plain, Size: 345 bytes --] >>It looks plain wrong (it replaces define-global-minor-mode with >>define-globalized-minor-mode which is already in the list) - so >>I don't know what that change is supposed to fix. > > > Yes, it's definitely an incorrect change. That's why I didn't > re-commit it. storm@cua.dk (Kim F. Storm) writes: You probably want the attached one. [-- Attachment #2: font-lock.patch --] [-- Type: text/plain, Size: 835 bytes --] *** font-lock.el Fri Feb 23 07:56:28 2007 --- font-lock.el Sun Mar 18 09:25:26 2007 *************** *** 2190,2196 **** "\\(advice\\|alias\\|generic\\|macro\\*?\\|method\\|" "setf\\|subst\\*?\\|un\\*?\\|" "ine-\\(condition\\|" ! "\\(?:derived\\|\\(?:global-\\)?minor\\|generic\\)-mode\\|" "method-combination\\|setf-expander\\|skeleton\\|widget\\|" "function\\|\\(compiler\\|modify\\|symbol\\)-macro\\)\\)\\|" ;; Variable declarations. --- 2190,2196 ---- "\\(advice\\|alias\\|generic\\|macro\\*?\\|method\\|" "setf\\|subst\\*?\\|un\\*?\\|" "ine-\\(condition\\|" ! "\\(?:derived\\|\\(?:global\\(?:ized\\)?-\\)?minor\\|generic\\)-mode\\|" "method-combination\\|setf-expander\\|skeleton\\|widget\\|" "function\\|\\(compiler\\|modify\\|symbol\\)-macro\\)\\)\\|" ;; Variable declarations. [-- Attachment #3: Type: text/plain, Size: 142 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-18 8:30 ` martin rudalics @ 2007-03-19 15:45 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-19 15:45 UTC (permalink / raw) To: martin rudalics Cc: Juanma Barranquero, Glenn Morris, emacs-devel, Kim F. Storm martin rudalics <rudalics@gmx.at> writes: > You probably want the attached one. Thanks, I checked it in. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 23:52 ` Kim F. Storm ` (2 preceding siblings ...) 2007-03-18 1:16 ` Chong Yidong @ 2007-03-18 15:56 ` Richard Stallman 3 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-18 15:56 UTC (permalink / raw) To: Kim F. Storm; +Cc: lekktu, rgm, cyd, emacs-devel > with the exception of the very latest dired.c > change (I couldn't find a ChangeLog entry or emacs-diffs commit log, > so I'm not sure if that commit was completed before the crash). I suspect RMS forgot to commit the changelog, but in any case I've installed the dired.c change and added a ChangeLog entry for it. I tried to, but it did not work. At that time, I found I could commit source files but not change log files. It looks plain wrong (it replaces define-global-minor-mode with define-globalized-minor-mode which is already in the list) - so I don't know what that change is supposed to fix. It is clear I was in too much of a hurry to check carefully what I was doing in that patch. I don't have the time it takes to do this job right, which is why I hope to step down for a new maintenance time. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 19:31 ` Chong Yidong 2007-03-17 23:08 ` Miles Bader 2007-03-17 23:52 ` Kim F. Storm @ 2007-03-18 12:19 ` Richard Stallman 2007-03-19 18:28 ` Glenn Morris 3 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-18 12:19 UTC (permalink / raw) To: Chong Yidong; +Cc: rgm, emacs-devel, lekktu HEAD is now up to date, with the exception of the very latest dired.c change (I couldn't find a ChangeLog entry or emacs-diffs commit log, so I'm not sure if that commit was completed before the crash). Since I made that dired.c change, I will check it in again. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 19:31 ` Chong Yidong ` (2 preceding siblings ...) 2007-03-18 12:19 ` Richard Stallman @ 2007-03-19 18:28 ` Glenn Morris 2007-03-19 19:46 ` Stefan Monnier 3 siblings, 1 reply; 317+ messages in thread From: Glenn Morris @ 2007-03-19 18:28 UTC (permalink / raw) To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel Chong Yidong wrote: >> I'll try recommitting the changes based on the contents of >> emacs-diffs. > > HEAD is now up to date Many thanks for doing this (and apologies for being grumpy). Does it matter that for the restored changes the dates of the entries in the ChangeLogs and the dates of the changes in the CVS repository are now out of sync? Ie, should the dates of the ChangeLog entries be adjusted to reflect the date you restored the commits to the CVS repo, rather than the date they were originally made? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-19 18:28 ` Glenn Morris @ 2007-03-19 19:46 ` Stefan Monnier 0 siblings, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2007-03-19 19:46 UTC (permalink / raw) To: Glenn Morris; +Cc: Juanma Barranquero, Chong Yidong, emacs-devel > Does it matter that for the restored changes the dates of the entries > in the ChangeLogs and the dates of the changes in the CVS repository > are now out of sync? No, Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 4:08 ` Chong Yidong 2007-03-16 9:38 ` Juanma Barranquero @ 2007-03-16 17:31 ` Richard Stallman 2007-03-17 0:12 ` Nick Roberts 1 sibling, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-16 17:31 UTC (permalink / raw) To: Chong Yidong; +Cc: rgm, emacs-devel Do not use a method that will lose the CVS logs. That would be a terrible mistake. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-16 17:31 ` Richard Stallman @ 2007-03-17 0:12 ` Nick Roberts 2007-03-17 0:33 ` Miles Bader 2007-03-17 15:46 ` Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Nick Roberts @ 2007-03-17 0:12 UTC (permalink / raw) To: rms; +Cc: rgm, Chong Yidong, emacs-devel > Do not use a method that will lose the CVS logs. That would be a > terrible mistake. It wouldn't lose them assuming that they are identical to the ChangeLogs. If Chong does this then we can compare the results with our local copies and make adjustments, if necessary e.g your change to dired.c which AFAICS has no ChangeLog entry. I think working directly with the ,v files would be the terrible mistake. This clearly is not the intended way to work with CVS, possibly even you are an expert. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 0:12 ` Nick Roberts @ 2007-03-17 0:33 ` Miles Bader 2007-03-17 5:00 ` Nick Roberts 2007-03-17 15:46 ` Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Miles Bader @ 2007-03-17 0:33 UTC (permalink / raw) To: Nick Roberts; +Cc: rgm, Chong Yidong, rms, emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > I think working directly with the ,v files would be the terrible mistake. This > clearly is not the intended way to work with CVS, possibly even you are an > expert. We are suggesting _replacing_ the ,v files en-mass, which is most certainly safe; why do you think otherwise? -miles -- What the fuck do white people have to be blue about!? Banana Republic ran out of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish are breaking up??! Shit, white people oughtta understand, their job is to GIVE people the blues, not to get them! -- George Carlin ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 0:33 ` Miles Bader @ 2007-03-17 5:00 ` Nick Roberts 2007-03-17 6:02 ` Miles Bader 2007-03-18 12:18 ` Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Nick Roberts @ 2007-03-17 5:00 UTC (permalink / raw) To: Miles Bader; +Cc: rgm, Chong Yidong, rms, emacs-devel > > I think working directly with the ,v files would be the terrible mistake. > > This clearly is not the intended way to work with CVS, possibly even you > > are an expert. > > We are suggesting _replacing_ the ,v files en-mass, which is most > certainly safe; why do you think otherwise? If you're replacing them en-mass why is Richard asking someone to write a scriptwhich can be used to determine the difference between two ,v files, as a set of commits plus their log entries? > > -miles > > -- > What the fuck do white people have to be blue about!? Banana Republic ran > out of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish are > breaking up??! Shit, white people oughtta understand, their job is to GIVE > people the blues, not to get them! -- George Carlin I know this is just a fortune cookie, but it keeps repeating and it's racist drivel. Can you remove it please? -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 5:00 ` Nick Roberts @ 2007-03-17 6:02 ` Miles Bader 2007-03-18 12:18 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Miles Bader @ 2007-03-17 6:02 UTC (permalink / raw) To: Nick Roberts; +Cc: rgm, Chong Yidong, rms, emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > We are suggesting _replacing_ the ,v files en-mass, which is most > > certainly safe; why do you think otherwise? > > If you're replacing them en-mass why is Richard asking someone to write a > scriptwhich can be used to determine the difference between two ,v files, as a > set of commits plus their log entries? Because we want to be 100% sure of what we're getting -- though there's no reason to believe the rsynced files are anything other than what's claimed, for something as important as repository, one wants proof positive. -Miles -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 5:00 ` Nick Roberts 2007-03-17 6:02 ` Miles Bader @ 2007-03-18 12:18 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-18 12:18 UTC (permalink / raw) To: Nick Roberts; +Cc: rgm, cyd, emacs-devel, miles > We are suggesting _replacing_ the ,v files en-mass, which is most > certainly safe; why do you think otherwise? If you're replacing them en-mass why is Richard asking someone to write a scriptwhich can be used to determine the difference between two ,v files, as a set of commits plus their log entries? This is called exploring more than one option in parallel. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [DIFFS] Re: Connection to emacs CVS broken ? 2007-03-17 0:12 ` Nick Roberts 2007-03-17 0:33 ` Miles Bader @ 2007-03-17 15:46 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-17 15:46 UTC (permalink / raw) To: Nick Roberts; +Cc: rgm, cyd, emacs-devel > Do not use a method that will lose the CVS logs. That would be a > terrible mistake. It wouldn't lose them assuming that they are identical to the ChangeLogs. I do not follow you. What does that mean? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:49 ` Nick Roberts 2007-03-15 22:17 ` Jason Rumney @ 2007-03-15 23:04 ` Vinicius Jose Latorre 1 sibling, 0 replies; 317+ messages in thread From: Vinicius Jose Latorre @ 2007-03-15 23:04 UTC (permalink / raw) To: Nick Roberts; +Cc: Glenn Morris, Chong Yidong, emacs-devel, Kim F. Storm Nick Roberts wrote: > > How do we want to go about doing this? > > > > I have a tree that's up-to-date as of the crash. Will the problem be > > fixed if I simply do a "cvs ci" on the entire tree? > > Does CVS get confused if your checked out file thinks it's a later version than > the most recent in the repository? How about trying it on a single, non-source > file first? > Well, I've done this: $ mv emacs emacs-orig $ cp -rf emacs-orig emacs #### recursive copy but without preserving file/dir timestamp $ cvs -z3 -d:ext:viniciusjl@cvs.sv.gnu.org:/sources/emacs co emacs CVS loops, I aborted after 10 minutes. Now, doing: $ cp -rpf emacs-orig emacs $ cvs -z3 -d:ext:viniciusjl@cvs.sv.gnu.org:/sources/emacs co emacs CVS updates emacs dir. But I noted that emacs/lisp/ChangeLog lost the last entries of 2007-03-12, maybe there are other differences. The emacs/lisp/ChangeLog lost entries are: 2007-03-12 Carsten Dominik <dominik@science.uva.nl> * textmodes/org.el (org-set-font-lock-defaults): Handle narrow table columns correctly. 2007-03-12 Mark A. Hershberger <mah@everybody.org> * xml.el (xml-parse-tag, xml-parse-string, xml-parse-attlist) (xml-parse-dtd, xml-parse-elem-type, xml-substitute-special): Return to use of the -no-properties variants. There was consensus on emacs-devel that the speed of these variants was prefered since we are usually parsing files (from the internet or on disk) instead of XML created in Emacs. * eshell/esh-mode.el (eshell-handle-ansi-color): New function. Add customize option. 2007-03-12 Glenn Morris <rgm@gnu.org> * calc/calc-forms.el (math-std-daylight-savings): Switch to new North American rule. * woman.el (woman-change-fonts): Tweak previous change by using woman-request-regexp rather than "^\\.". * startup.el (command-line-1): Make insertion of initial-scratch-message not depend on scratch being selected. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:27 ` Chong Yidong 2007-03-15 20:49 ` Nick Roberts @ 2007-03-16 5:21 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-16 5:21 UTC (permalink / raw) To: Chong Yidong; +Cc: rgm, storm, emacs-devel I have a tree that's up-to-date as of the crash. Will the problem be fixed if I simply do a "cvs ci" on the entire tree? Please don't do that! It is essential to check in each change with the corresponding change log info as the CVS log entry. Alas, this means reinstalling each change one by one. But it is the only way to get the right result. If we take a short cut here, we will regret it later! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:00 ` Glenn Morris 2007-03-15 20:18 ` Eli Zaretskii 2007-03-15 20:27 ` Chong Yidong @ 2007-03-15 21:06 ` Glenn Morris 2 siblings, 0 replies; 317+ messages in thread From: Glenn Morris @ 2007-03-15 21:06 UTC (permalink / raw) To: emacs-devel Glenn Morris wrote: > savannah is back up and anoncvs at least is working. CVS has gone again. It seems to still have some issues. See #savannah on irc.gnu.org. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 17:34 ` Glenn Morris 2007-03-15 20:00 ` Glenn Morris @ 2007-03-15 20:26 ` NIIMI Satoshi 2007-03-15 20:43 ` Nick Roberts 1 sibling, 1 reply; 317+ messages in thread From: NIIMI Satoshi @ 2007-03-15 20:26 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel, Kim F. Storm 2007/3/16, Glenn Morris <rgm@gnu.org>: > Kim F. Storm wrote: > > > Perhaps Miles' Arch repository is more recent ? > > The info should also be available from the emacs-diff and commit > lists, I think. > > http://lists.gnu.org/archive/html/emacs-diffs/2007-03/index.html > > suggests about 60 changes occurred in the time between the last backup > and the crash. So if necessary we could just put all the missing > changes back in by hand. I have rsync'ed mirror of CVS repository whose status is % env TZ=UTC ls -l emacs/CVSROOT/history -rw-rw-r-- 1 sa2c sa2c 5588994 2007-03-13 02:48 emacs/CVSROOT/history The only missing change seems to be: http://lists.gnu.org/archive/html/emacs-diffs/2007-03/msg00336.html -- NIIMI Satoshi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:26 ` NIIMI Satoshi @ 2007-03-15 20:43 ` Nick Roberts 2007-03-15 21:05 ` NIIMI Satoshi 0 siblings, 1 reply; 317+ messages in thread From: Nick Roberts @ 2007-03-15 20:43 UTC (permalink / raw) To: NIIMI Satoshi; +Cc: Glenn Morris, Kim F. Storm, emacs-devel > > The info should also be available from the emacs-diff and commit > > lists, I think. > > > > http://lists.gnu.org/archive/html/emacs-diffs/2007-03/index.html > > > > suggests about 60 changes occurred in the time between the last backup > > and the crash. So if necessary we could just put all the missing > > changes back in by hand. > > I have rsync'ed mirror of CVS repository whose status is > > % env TZ=UTC ls -l emacs/CVSROOT/history > -rw-rw-r-- 1 sa2c sa2c 5588994 2007-03-13 02:48 emacs/CVSROOT/history > > The only missing change seems to be: > http://lists.gnu.org/archive/html/emacs-diffs/2007-03/msg00336.html I can see a change to dired.c that doesn't appear to be in emacs-diffs (or src/ChangeLog!). My version of dired.c before the crash is 1.131, while my version from a checkout after the crash is 1.130. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 20:43 ` Nick Roberts @ 2007-03-15 21:05 ` NIIMI Satoshi 0 siblings, 0 replies; 317+ messages in thread From: NIIMI Satoshi @ 2007-03-15 21:05 UTC (permalink / raw) To: Nick Roberts; +Cc: Glenn Morris, emacs-devel, Kim F. Storm 2007/3/16, Nick Roberts <nickrob@snap.net.nz>: > I can see a change to dired.c that doesn't appear to be in emacs-diffs > (or src/ChangeLog!). > > My version of dired.c before the crash is 1.131, while my version from a > checkout after the crash is 1.130. % tail emacs/CVSROOT/history M45f5d000|kfstorm|<remote>|emacs/admin|1.571|FOR-RELEASE M45f5d12b|kfstorm|<remote>|emacs/admin|1.572|FOR-RELEASE M45f5d544|kfstorm|<remote>|emacs/admin|1.573|FOR-RELEASE M45f5d741|kfstorm|<remote>|emacs/lisp|1.10817|ChangeLog M45f5d74e|kfstorm|<remote>|emacs/lisp|1.128|ido.el M45f5f6f8|cyd|<remote>|emacs/lisp|1.10818|ChangeLog M45f5faf6|rms|<remote>|emacs/lisp/emacs-lisp|1.201|lisp-mode.el M45f60c96|cyd|<remote>|emacs/lisp|1.359|comint.el M45f60ce0|cyd|<remote>|emacs/admin|1.574|FOR-RELEASE M45f610f9|rms|<remote>|emacs/src|1.131|dired.c It seems that at least 5 changes were not sent to emacs-diffs. -- NIIMI Satoshi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 9:02 ` Connection to emacs CVS broken ? Angelo Graziosi 2007-03-14 9:09 ` David Kastrup @ 2007-03-14 9:09 ` Davi Leal 2007-03-14 9:39 ` Angelo Graziosi 2007-03-14 10:06 ` Andreas Schwab 1 sibling, 2 replies; 317+ messages in thread From: Davi Leal @ 2007-03-14 9:09 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel Angelo Graziosi wrote: > Since yesterday (> 24 h) I cannot checkout CVS: Same problem for others Savannah hosted projects. For example "GNU Herds". $ cvs update ssh: connect to host cvs.savannah.nongnu.org port 22: Connection timed out Davi ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 9:09 ` Davi Leal @ 2007-03-14 9:39 ` Angelo Graziosi 2007-03-14 10:06 ` Andreas Schwab 1 sibling, 0 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-14 9:39 UTC (permalink / raw) To: Davi Leal; +Cc: Eli Zaretskii, emacs-devel On Wed, 14 Mar 2007, Davi Leal wrote: > Angelo Graziosi wrote: > > Since yesterday (> 24 h) I cannot checkout CVS: > > Same problem for others Savannah hosted projects. For example "GNU Herds". > > $ cvs update > ssh: connect to host cvs.savannah.nongnu.org port 22: Connection timed out > > > Davi > Same result if one tries to connect to http://savannah.gnu.org. Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 9:09 ` Davi Leal 2007-03-14 9:39 ` Angelo Graziosi @ 2007-03-14 10:06 ` Andreas Schwab 2007-03-15 23:35 ` Angelo Graziosi 1 sibling, 1 reply; 317+ messages in thread From: Andreas Schwab @ 2007-03-14 10:06 UTC (permalink / raw) To: Davi Leal; +Cc: Eli Zaretskii, Angelo Graziosi, emacs-devel Davi Leal <david@leals.com> writes: > Angelo Graziosi wrote: >> Since yesterday (> 24 h) I cannot checkout CVS: > > Same problem for others Savannah hosted projects. For example "GNU Herds". See <http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00766.html>. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-14 10:06 ` Andreas Schwab @ 2007-03-15 23:35 ` Angelo Graziosi 2007-03-15 23:54 ` Vinicius Jose Latorre 0 siblings, 1 reply; 317+ messages in thread From: Angelo Graziosi @ 2007-03-15 23:35 UTC (permalink / raw) To: emacs-devel; +Cc: Eli Zaretskii Glenn Morris wrote: > Apparently: "Last confirmed full backup was completed circa 20:30 EDT > on Sunday 11 March". I did the last checkout Mar 12 14:30. Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Connection to emacs CVS broken ? 2007-03-15 23:35 ` Angelo Graziosi @ 2007-03-15 23:54 ` Vinicius Jose Latorre 0 siblings, 0 replies; 317+ messages in thread From: Vinicius Jose Latorre @ 2007-03-15 23:54 UTC (permalink / raw) To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel Angelo Graziosi wrote: > Glenn Morris wrote: > > >> Apparently: "Last confirmed full backup was completed circa 20:30 EDT >> on Sunday 11 March". >> > > I did the last checkout Mar 12 14:30. > my last checkout was 2007-03-12 15:48. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-09 17:46 ` Eli Zaretskii 2007-03-14 9:02 ` Connection to emacs CVS broken ? Angelo Graziosi @ 2007-03-20 13:04 ` Angelo Graziosi 1 sibling, 0 replies; 317+ messages in thread From: Angelo Graziosi @ 2007-03-20 13:04 UTC (permalink / raw) To: emacs-devel Chong Yidong wrote: > I have rolled the 22.0.96 pretest tarball. It is available at the > usual location: > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta (Pure) Cygwin binaries at: http://www.webalice.it/angelo.graziosi/Emacs.html Cheers, Angelo. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Killing buffers with mouse 2007-03-09 16:46 ` Angelo Graziosi 2007-03-09 17:46 ` Eli Zaretskii @ 2007-03-10 15:50 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Richard Stallman @ 2007-03-10 15:50 UTC (permalink / raw) To: Angelo Graziosi; +Cc: eliz, jan.h.d, emacs-devel, cyd, monnier I have seen the same thing on Linux-kubuntu (32 bit) and on Scientific Linux (64 bit) (and on Cygwin 32 bit). You're talking about versions of the GNU operating system. Please do not call them "Linux" -- that's unfair to us. Please call them GNU/Linux. We are the system's principal developers, so we deserve equal mention. See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Pretest @ 2011-09-19 18:52 Chong Yidong 2011-09-19 21:13 ` Pretest Drew Adams 2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen 0 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2011-09-19 18:52 UTC (permalink / raw) To: emacs-devel Unless something comes up, I would like to make the first pretest this Sunday, the 25th. Please plan your commits accordingly; thanks. ^ permalink raw reply [flat|nested] 317+ messages in thread
* RE: Pretest 2011-09-19 18:52 Pretest Chong Yidong @ 2011-09-19 21:13 ` Drew Adams 2011-09-20 15:27 ` Pretest Chong Yidong 2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen 1 sibling, 1 reply; 317+ messages in thread From: Drew Adams @ 2011-09-19 21:13 UTC (permalink / raw) To: 'Chong Yidong', emacs-devel > Unless something comes up, I would like to make the first pretest this > Sunday, the 25th. Please plan your commits accordingly; thanks. Are you kidding? Or did you perhaps mean Sunday, Nov 25, 2012 (that sounds more like it)? After Martin relentlessly and carefully worked out the bugs from his humongous, many-faceted, and detailed buffer-display changes, you suddenly changed it all again (recently). And during a feature freeze, no less. Even Martin (our resident window/buffer-display expert) has admitted that he does not yet understand the new code. Does that count as "something coming up"? How much design, development, and testing time did you put into the new design, compared to the hundreds of hours (perhaps 100s of days?) that Martin spent on his approach? I'm not defending or attacking either design (I was OK with the Emacs 18-23 one). I'm just asking about the relative effort and care expressed, as one possible measure of how fully baked this might be. There has hardly been time to collect reports of the fallout, let alone attempt to repair the damage from this change. I've had the experience of only one Windows build with the new approach, and there have been code changes since that build. I immediately filed one bug - but got no reply to it of any substance (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9532#11). Think, for contrast, how long you let people digest the lex-bind changes... And AFAICT there is still no user-understandable doc explaining simply and clearly how to use the new system and how to map pre-Emacs-24 behavior and preferences to it. Not to mention a clear presentation of the changes in NEWS. (Is there even an UNclear one? All I see is "FIXME: buffer-display-alist changes"). I thought the decision about this (user-unrequested) feature was that we were going to _take the time to get it right_. Two nano-seconds after a sudden design change you want to start pretest? Bad. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-19 21:13 ` Pretest Drew Adams @ 2011-09-20 15:27 ` Chong Yidong 2011-09-20 21:13 ` Pretest Andy Moreton 2011-09-21 1:27 ` Pretest Stefan Monnier 0 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2011-09-20 15:27 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > After Martin relentlessly and carefully worked out the bugs from his > humongous, many-faceted, and detailed buffer-display changes, you > suddenly changed it all again (recently). And during a feature > freeze, no less. Even Martin (our resident window/buffer-display > expert) has admitted that he does not yet understand the new code. > > Does that count as "something coming up"? No. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-20 15:27 ` Pretest Chong Yidong @ 2011-09-20 21:13 ` Andy Moreton 2011-09-20 21:33 ` Pretest Chong Yidong 2011-09-21 1:27 ` Pretest Stefan Monnier 1 sibling, 1 reply; 317+ messages in thread From: Andy Moreton @ 2011-09-20 21:13 UTC (permalink / raw) To: emacs-devel On Tue 20 Sep 2011, Chong Yidong wrote: > "Drew Adams" <drew.adams@oracle.com> writes: > >> After Martin relentlessly and carefully worked out the bugs from his >> humongous, many-faceted, and detailed buffer-display changes, you >> suddenly changed it all again (recently). And during a feature >> freeze, no less. Even Martin (our resident window/buffer-display >> expert) has admitted that he does not yet understand the new code. >> >> Does that count as "something coming up"? > > No. I think you dismiss Drew's concerns too lightly. Where is the user level documentation comprehensible by mere mortals to explain the new display code and its customisation ? It seems to me that most ordinary users of emacs have little chance of understanding what the new features are, never mind how to configure emacs to their liking. Please assuage my doubts by pointing out the relevant sections in the manual. AndyM ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-20 21:13 ` Pretest Andy Moreton @ 2011-09-20 21:33 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2011-09-20 21:33 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel Andy Moreton <andrewjmoreton@gmail.com> writes: > Where is the user level documentation comprehensible by mere mortals > to explain the new display code and its customisation ? I've been working on it, and it should be ready by this weekend. But in any case, complete manuals has never been a condition for beginning an Emacs pretest; in previous release cycles, manual updates were written during the first part of the pretest period. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-20 15:27 ` Pretest Chong Yidong 2011-09-20 21:13 ` Pretest Andy Moreton @ 2011-09-21 1:27 ` Stefan Monnier 2011-09-21 2:11 ` Pretest Drew Adams 1 sibling, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2011-09-21 1:27 UTC (permalink / raw) To: Chong Yidong; +Cc: Drew Adams, emacs-devel >> After Martin relentlessly and carefully worked out the bugs from his >> humongous, many-faceted, and detailed buffer-display changes, you >> suddenly changed it all again (recently). And during a feature >> freeze, no less. Even Martin (our resident window/buffer-display >> expert) has admitted that he does not yet understand the new code. >> Does that count as "something coming up"? > No. Just to put some argument behind it: the new code that replaces Martin's is not humongous, not many-faceted, ... instead it's a fairly small change, localized change, with a reasonably clear "backward compatibility argument". That's why we haven't seen too many bug reports since this new scheme has been installed. Sadly, it goes much less far than Martin's change, so some of the more interesting developments end up postponed to 24.2. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* RE: Pretest 2011-09-21 1:27 ` Pretest Stefan Monnier @ 2011-09-21 2:11 ` Drew Adams 0 siblings, 0 replies; 317+ messages in thread From: Drew Adams @ 2011-09-21 2:11 UTC (permalink / raw) To: 'Stefan Monnier', 'Chong Yidong'; +Cc: emacs-devel > >> After Martin relentlessly and carefully worked out the > >> bugs from his humongous, many-faceted, and detailed > >> buffer-display changes, you suddenly changed it all again > >> (recently). And during a feature freeze, no less. Even > >> Martin (our resident window/buffer-display expert) has > >> admitted that he does not yet understand the new code. > >> Does that count as "something coming up"? > > > > No. > > Just to put some argument behind it: the new code that > replaces Martin's is not humongous, not many-faceted, ... > instead it's a fairly small change, localized change, with > a reasonably clear "backward compatibility argument". However simple, it still needs time for testing - pre-pretesting. > That's why we haven't seen too many bug reports since this > new scheme has been installed. Is it a joke? I've had the new changes for a little over a week now, in Emacs Windows builds. As soon as the changes were in, things were broken for me and I filed a bug. It's not surprising that few bugs have been reported yet - the change has not been in the code for long. Reminds me of the elementary school teacher who said, "Take-out-your-books--take-out-your-books--take-out-your-books. That's 3 times and your books aren't out yet!" > Sadly, it goes much less far than Martin's change, so some of the more > interesting developments end up postponed to 24.2. I have no problem with that. My main concerns with this, or Martin's, or any other such changes are (a) backward compatibility, (b) conceptual simplicity, (c) usage simplicity, and (d) covering the use cases I use (hey, I'm one user) as well as before (that is, once I've learned how to go beyond backward compatibility and use the new system). Martin's stuff never reached the point where people understood it enough to explain it in simple terms. But it at least had the advantage (for me) that it worked (for my use cases). I know that he spent a _lot_ of time fixing bugs to cover various use cases: mine and those of others. I have nothing against a new approach, if it covers the various use cases and it is reasonably simple to use. But I think more than a couple of weeks should pass before you declare it ready for pretest. Presumably the reason (or at least one of the main reasons) for all these changes is to simply the interface for users. And perhaps to cover more use cases (dunno). I'm unaware of any users having actually asked for this (solution looking for a problem?), but that's OK if it is really an improvement. On the other hand, if it doesn't match the old system in simplicity and use-case coverage, then I don't see the point. People need time to judge. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-19 18:52 Pretest Chong Yidong 2011-09-19 21:13 ` Pretest Drew Adams @ 2011-09-19 22:29 ` Lars Magne Ingebrigtsen 2011-09-20 15:27 ` Pretest Chong Yidong 1 sibling, 1 reply; 317+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-09-19 22:29 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Unless something comes up, I would like to make the first pretest this > Sunday, the 25th. That's great news. > Please plan your commits accordingly; thanks. What changes in the bug-fixing department, though? We've been in a feature freeze for a couple of months, like... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen @ 2011-09-20 15:27 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2011-09-20 15:27 UTC (permalink / raw) To: emacs-devel Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> Please plan your commits accordingly; thanks. > > What changes in the bug-fixing department, though? Nothing, except that if a bug fix needs significant code changes, don't wait till Sunday to check it in. ^ permalink raw reply [flat|nested] 317+ messages in thread
* [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] @ 2007-03-26 3:52 Richard Stallman 2007-03-26 4:40 ` Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2007-03-26 3:52 UTC (permalink / raw) To: emacs-devel; +Cc: Michael Albinus Would someone please DTRT and ack? ------- Start of forwarded message ------- X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=s7BXyK+4GhOwW5H7jKdX9z5Vz4neRHIL2YqUkZgGtU6dWuhYC6BcFujLBLTrEPa09HRu0Di1NCR+jtLHuvR4f9wY8gC61A0libpAcUGY0k3ZK74H15WvMZn8c8NIzrWp3RcglmnIRhACDhqT0m5q3Y7doc4c2PboX/AjM3A+Cdw= Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: emacs-pretest-bug@gnu.org From: David Reitter <david.reitter@gmail.com> Date: Fri, 23 Mar 2007 21:53:59 +0000 Subject: file-remote-p malfunctions at site-start (file-name-handler-alist init) If a site-start.el file is created with the following contents: (print file-name-handler-alist) (print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2")) the output of the last expression is nil for me. It should (correctly) be non-nil. The reason for that is that `file-name-handler-alist' does not contain handlers for tramp file names when the site-start file is loaded - at a later point, the appropriate handlers are added. The practical relevance is that when users (or site or distribution admins) load and turn on recentf-mode from a site-start file together with a `file-remote-p' predicate in `recentf-keep', then all recent- file entries containing a tramp path will be purged. That's very inconvenient. The problem would go away if `file-name-handler-alist' was correctly initialized before site-start files are executed. Additionally, please consider defining the handler function for tramp files somewhere outside of tramp so that `file-remote-p' doesn't cause tramp to load just because it is checked for some file. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions. In GNU Emacs 22.0.96.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0) of 2007-03-22 on rodrigues.inf.ed.ac.uk Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--without-x' '--prefix=/usr/local'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: <down-mouse-1> <mouse-1> <help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> <report-emacs-bug> Recent messages: (("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'\\|\ \.tbz\\'\\|\\.tgz\\'\\|\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.dz\\'" . jka-compr-handler) ("\\`/:" . file-name-non-special)) nil For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done Loading encoded-kb...done _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ------- End of forwarded message ------- ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 3:52 [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] Richard Stallman @ 2007-03-26 4:40 ` Chong Yidong 2007-03-26 13:14 ` Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-26 4:40 UTC (permalink / raw) To: rms; +Cc: Michael Albinus, emacs-devel > If a site-start.el file is created with the following contents: > > (print file-name-handler-alist) > (print (file-remote-p "/ssh:dreitter@ssh:/home/dreitter/test2")) > > the output of the last expression is nil for me. > It should (correctly) be non-nil. > > The reason for that is that `file-name-handler-alist' does not > contain handlers for tramp file names when the site-start file is > loaded - at a later point, the appropriate handlers are added. This could conceivably be achieved by moving tramp-register-file-name-handlers from after-init-hook to before-init-hook. On the other hand, the risk of making a change to the init sequence at this stage probably outweighs the marginal benefit; I don't think the above is a very common scenario. What do people think? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 4:40 ` Chong Yidong @ 2007-03-26 13:14 ` Stefan Monnier 2007-03-26 13:37 ` Michael Albinus 0 siblings, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2007-03-26 13:14 UTC (permalink / raw) To: Chong Yidong; +Cc: Michael Albinus, rms, emacs-devel > This could conceivably be achieved by moving > tramp-register-file-name-handlers from after-init-hook to > before-init-hook. Why is it done so late? Why not do it at dump time? Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 13:14 ` Stefan Monnier @ 2007-03-26 13:37 ` Michael Albinus 2007-03-26 14:16 ` Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Michael Albinus @ 2007-03-26 13:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> This could conceivably be achieved by moving >> tramp-register-file-name-handlers from after-init-hook to >> before-init-hook. > > Why is it done so late? Why not do it at dump time? It was there initially. Then it was changed, because people didn't want to get Tramp enabled mandatory for file name completion. Now the registration is done only in case `partial-completion-mode' is active, which must be checked. The comment in the code says ;; During autoload, it shall be checked whether ;; `partial-completion-mode' is active. Therefore registering will be ;; delayed. See also <http://lists.gnu.org/archive/html/emacs-devel/2006-05/msg00017.html> > Stefan Best regards, Michael. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 13:37 ` Michael Albinus @ 2007-03-26 14:16 ` Chong Yidong 2007-03-26 14:44 ` Michael Albinus 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-26 14:16 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel, Stefan Monnier, rms Michael Albinus <michael.albinus@gmx.de> writes: >>> This could conceivably be achieved by moving >>> tramp-register-file-name-handlers from after-init-hook to >>> before-init-hook. >> >> Why is it done so late? Why not do it at dump time? > > It was there initially. Then it was changed, because people didn't > want to get Tramp enabled mandatory for file name completion. Now the > registration is done only in case `partial-completion-mode' is > active, which must be checked. In that case, I suggest documenting this in PROBLEMS: if you want to use Tramp in your site-start file, run tramp-register-file-name-handlers first (and remove it from after-init-hook). ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 14:16 ` Chong Yidong @ 2007-03-26 14:44 ` Michael Albinus 2007-03-27 20:59 ` Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Michael Albinus @ 2007-03-26 14:44 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel, Stefan Monnier, rms Chong Yidong <cyd@stupidchicken.com> writes: >> It was there initially. Then it was changed, because people didn't >> want to get Tramp enabled mandatory for file name completion. Now the >> registration is done only in case `partial-completion-mode' is >> active, which must be checked. > > In that case, I suggest documenting this in PROBLEMS: if you want to > use Tramp in your site-start file, run tramp-register-file-name-handlers > first (and remove it from after-init-hook). I haven't a better idea. Maybe one should argue that it isn't a good idea to access remote files in site-init files. Note that removing tramp-register-file-name-handlers from after-init-hook is not necessary, the registration is re-entrant. OTOH, the OP gave as practical example recentf-mode problems with remote files (handled in site-init). It would require changes in recentf at least. Best regards, Michael. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-26 14:44 ` Michael Albinus @ 2007-03-27 20:59 ` Chong Yidong 2007-03-31 18:47 ` Michael Albinus 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2007-03-27 20:59 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel, Stefan Monnier, rms Michael Albinus <michael.albinus@gmx.de> writes: >> In that case, I suggest documenting this in PROBLEMS: if you want to >> use Tramp in your site-start file, run tramp-register-file-name-handlers >> first (and remove it from after-init-hook). > > I haven't a better idea. Maybe one should argue that it isn't a good > idea to access remote files in site-init files. OK, I documented it in PROBLEMS. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-27 20:59 ` Chong Yidong @ 2007-03-31 18:47 ` Michael Albinus 2007-03-31 19:41 ` David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Michael Albinus @ 2007-03-31 18:47 UTC (permalink / raw) To: Chong Yidong; +Cc: David Reitter, emacs-devel, Stefan Monnier, rms Chong Yidong <cyd@stupidchicken.com> writes: > Michael Albinus <michael.albinus@gmx.de> writes: > >> I haven't a better idea. Maybe one should argue that it isn't a good >> idea to access remote files in site-init files. > > OK, I documented it in PROBLEMS. Finally, I've divided `tramp-register-file-name-handlers' into two parts, which are evaluated at different startup places. This should solve the problem. Best regards, Michael. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] 2007-03-31 18:47 ` Michael Albinus @ 2007-03-31 19:41 ` David Kastrup 2007-03-31 20:02 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2007-03-31 19:41 UTC (permalink / raw) To: Michael Albinus Cc: David Reitter, Chong Yidong, Stefan Monnier, rms, emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > Chong Yidong <cyd@stupidchicken.com> writes: > >> Michael Albinus <michael.albinus@gmx.de> writes: >> >>> I haven't a better idea. Maybe one should argue that it isn't a good >>> idea to access remote files in site-init files. >> >> OK, I documented it in PROBLEMS. > > Finally, I've divided `tramp-register-file-name-handlers' into two > parts, which are evaluated at different startup places. This should > solve the problem. Tramp is a central part of the file access infrastructure. So I think this change warrants another pretest, preferably when the HPUX problems have been sorted out (or are they already?). If this can be achieved this weekend and nothing else intervenes, next weekend could be our final target. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Pretest 2007-03-31 19:41 ` David Kastrup @ 2007-03-31 20:02 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-31 20:02 UTC (permalink / raw) To: David Kastrup Cc: David Reitter, Michael Albinus, Stefan Monnier, rms, emacs-devel > I think this change warrants another pretest, preferably when the > HPUX problems have been sorted out (or are they already?). If this > can be achieved this weekend... This weekend is probably too soon; let's make that Tuesday, April 3. If there are no objections, I'll roll a new pretest tarball on that date. > ... and nothing else intervenes, next weekend could be our final > target. I would like that, but this is dependent on Kevin Rodger's papers arriving (I guess RMS will inform us about that). ^ permalink raw reply [flat|nested] 317+ messages in thread
* Pretest @ 2007-03-18 4:28 Chong Yidong 2007-03-18 4:31 ` Pretest Juanma Barranquero 2007-03-20 1:34 ` Pretest Chong Yidong 0 siblings, 2 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-18 4:28 UTC (permalink / raw) To: emacs-devel This week's pretest didn't take place due to the savannah crash; unless there are any serious objections, I'll roll a new pretest tarball this coming Monday, the 19th. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-18 4:28 Pretest Chong Yidong @ 2007-03-18 4:31 ` Juanma Barranquero 2007-03-20 1:34 ` Pretest Chong Yidong 1 sibling, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-18 4:31 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 18 Mar 2007 00:28:17 -0400, Chong Yidong <cyd@mit.edu> wrote: > This week's pretest didn't take place due to the savannah crash; > unless there are any serious objections, I'll roll a new pretest > tarball this coming Monday, the 19th. No objections, but the server.el issue is still unresolved / undecided. Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-18 4:28 Pretest Chong Yidong 2007-03-18 4:31 ` Pretest Juanma Barranquero @ 2007-03-20 1:34 ` Chong Yidong 2007-03-20 2:05 ` Pretest Juanma Barranquero ` (2 more replies) 1 sibling, 3 replies; 317+ messages in thread From: Chong Yidong @ 2007-03-20 1:34 UTC (permalink / raw) To: emacs-devel I have rolled the 22.0.96 pretest tarball. It is available at the usual location: http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 1:34 ` Pretest Chong Yidong @ 2007-03-20 2:05 ` Juanma Barranquero 2007-03-20 4:40 ` Pretest dhruva 2007-03-21 22:47 ` Pretest Lennart Borgman (gmail) 2 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2007-03-20 2:05 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote: > I have rolled the 22.0.96 pretest tarball. Builds and works fine with gcc (GCC) 3.4.5 (mingw special) on Windows XP Home Edition: GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-20 on LEKTU Juanma ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 1:34 ` Pretest Chong Yidong 2007-03-20 2:05 ` Pretest Juanma Barranquero @ 2007-03-20 4:40 ` dhruva 2007-03-20 12:07 ` Pretest AriT93 2007-03-21 22:47 ` Pretest Lennart Borgman (gmail) 2 siblings, 1 reply; 317+ messages in thread From: dhruva @ 2007-03-20 4:40 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel Hi, Builds and works (typical usage) fine on Windows Server 2003 (Enterprise edition) using Microsoft Visual Studio .NET 2003. On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote: > I have rolled the 22.0.96 pretest tarball. It is available at the > usual location: > > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel > -- Dhruva Krishnamurthy Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 4:40 ` Pretest dhruva @ 2007-03-20 12:07 ` AriT93 2007-03-20 12:36 ` Pretest dhruva 0 siblings, 1 reply; 317+ messages in thread From: AriT93 @ 2007-03-20 12:07 UTC (permalink / raw) To: dhruva; +Cc: Chong Yidong, emacs-devel dhruva writes: > Hi, > Builds and works (typical usage) fine on Windows Server 2003 > (Enterprise edition) using Microsoft Visual Studio .NET 2003. > > On 3/20/07, Chong Yidong <cyd@stupidchicken.com> wrote: > > I have rolled the 22.0.96 pretest tarball. It is available at the > > usual location: > > > > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz > > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta > > > > > -- > Dhruva Krishnamurthy > Contents reflect my personal views only! > Just out of curiosity what steps did you take to get VS.NET 2003 to compile it. I have been unable in the past to get that to work. I have always use GnuWin32 but would like to be able to use VS.NET as that environment is a bit easier to maintain on my current workstation. Is it on the Wiki page? -- enjoy every sandwich -- W. Zevon ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 12:07 ` Pretest AriT93 @ 2007-03-20 12:36 ` dhruva 2007-03-20 13:14 ` Pretest AriT93 0 siblings, 1 reply; 317+ messages in thread From: dhruva @ 2007-03-20 12:36 UTC (permalink / raw) To: AriT93; +Cc: Chong Yidong, emacs-devel Hi, On 3/20/07, AriT93 <arit93@yahoo.com> wrote: > dhruva writes: > > Hi, > > Builds and works (typical usage) fine on Windows Server 2003 > > (Enterprise edition) using Microsoft Visual Studio .NET 2003. > > Just out of curiosity what steps did you take to get VS.NET 2003 to compile it. > I have been unable in the past to get that to work. I have always use GnuWin32 > but would like to be able to use VS.NET as that environment is a bit easier to > maintain on my current workstation. Is it on the Wiki page? - I have some of the basic GNU utils needed for build on WIN32 in my PATH (like cp, rm, ls and a few others from GNUWIN32 project). - I open the command shell "cmd.exe" and run a batch file "E:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\VCVARS32.BAT" (the path will vary based on the drive/folder you have installed VS.NET). - Go to the emacs/nt folder and "configure --prefix=somedir --with-msvc" - "nmake" and "namek install" It is the batch file that you might have missed executing to get all the compiler/linker paths set (VCVARS32.BAT). Let me know if you need the env output resulting from VCVARS32.bat if you have any problems. -dky -- Dhruva Krishnamurthy Contents reflect my personal views only! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 12:36 ` Pretest dhruva @ 2007-03-20 13:14 ` AriT93 0 siblings, 0 replies; 317+ messages in thread From: AriT93 @ 2007-03-20 13:14 UTC (permalink / raw) To: dhruva; +Cc: Chong Yidong, AriT93, emacs-devel dhruva writes: > Hi, > > On 3/20/07, AriT93 <arit93@yahoo.com> wrote: > > dhruva writes: > > > Hi, > > > Builds and works (typical usage) fine on Windows Server 2003 > > > (Enterprise edition) using Microsoft Visual Studio .NET 2003. > > > > Just out of curiosity what steps did you take to get VS.NET 2003 to compile it. > > I have been unable in the past to get that to work. I have always use GnuWin32 > > but would like to be able to use VS.NET as that environment is a bit easier to > > maintain on my current workstation. Is it on the Wiki page? > > - I have some of the basic GNU utils needed for build on WIN32 in my > PATH (like cp, rm, ls and a few others from GNUWIN32 project). > - I open the command shell "cmd.exe" and run a batch file "E:\Program > Files\Microsoft Visual Studio .NET 2003\Vc7\bin\VCVARS32.BAT" (the > path will vary based on the drive/folder you have installed VS.NET). > - Go to the emacs/nt folder and "configure --prefix=somedir --with-msvc" > - "nmake" and "namek install" > > It is the batch file that you might have missed executing to get all > the compiler/linker paths set (VCVARS32.BAT). Let me know if you need > the env output resulting from VCVARS32.bat if you have any problems. > > -dky > > -- > Dhruva Krishnamurthy > Contents reflect my personal views only! > Excellent! Thank you. Compiling now. -- enjoy every sandwich -- W. Zevon ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2007-03-20 1:34 ` Pretest Chong Yidong 2007-03-20 2:05 ` Pretest Juanma Barranquero 2007-03-20 4:40 ` Pretest dhruva @ 2007-03-21 22:47 ` Lennart Borgman (gmail) 2 siblings, 0 replies; 317+ messages in thread From: Lennart Borgman (gmail) @ 2007-03-21 22:47 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel Chong Yidong wrote: > I have rolled the 22.0.96 pretest tarball. It is available at the > usual location: > > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.96.tar.gz > http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.95-22.0.96.xdelta I have some hours ago uploaded precompiled (unpatched) binaries to http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl ^ permalink raw reply [flat|nested] 317+ messages in thread
* Pretest @ 2006-11-18 22:14 Chong Yidong 2006-11-18 22:58 ` Pretest Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 317+ messages in thread From: Chong Yidong @ 2006-11-18 22:14 UTC (permalink / raw) I've rolled a new pretest tarball, which is available at ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz The various build problems in 22.0.90 should be resolved. We should now make the pretest announcement, if Richard has finished updating the pretesters list. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 22:14 Pretest Chong Yidong @ 2006-11-18 22:58 ` Lennart Borgman 2006-11-18 23:32 ` Pretest Chong Yidong 2006-11-19 0:56 ` Pretest Nick Roberts 2006-11-19 12:48 ` Pretest Richard Stallman 2006-11-19 19:59 ` Pretest Eli Zaretskii 2 siblings, 2 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-18 22:58 UTC (permalink / raw) Cc: emacs-devel Chong Yidong wrote: > I've rolled a new pretest tarball, which is available at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz > > The various build problems in 22.0.90 should be resolved. We should > now make the pretest announcement, if Richard has finished updating > the pretesters list. We are currently working with emacsclient. It would be very good if our changes in emacsclient were included in the pretest. We need a little bit more time for resolving some issues and for testing. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 22:58 ` Pretest Lennart Borgman @ 2006-11-18 23:32 ` Chong Yidong 2006-11-19 0:53 ` Pretest Juanma Barranquero 2006-11-19 0:56 ` Pretest Nick Roberts 1 sibling, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-11-18 23:32 UTC (permalink / raw) Cc: emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > Chong Yidong wrote: >> I've rolled a new pretest tarball, which is available at >> >> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz >> >> The various build problems in 22.0.90 should be resolved. We should >> now make the pretest announcement, if Richard has finished updating >> the pretesters list. > > We are currently working with emacsclient. It would be very good if > our changes in emacsclient were included in the pretest. We need a > little bit more time for resolving some issues and for testing. I didn't know there were still outstanding issues with emacsclient. (I haven't been following the thread closely, but it's been a month since the first batch of emacsclient changes were checked in, and there hasn't been any email traffic on this issue lately, so I assume the initial batch of bugs that surfaced has been fixed. Or haven't they?) As for needing more time for testing... well, that's the whole point of a preTEST. In any case, there will be more pretests, so I think we should go ahead and make the pretest announcement anyway. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 23:32 ` Pretest Chong Yidong @ 2006-11-19 0:53 ` Juanma Barranquero 0 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 0:53 UTC (permalink / raw) Cc: Lennart Borgman, emacs-devel On 11/19/06, Chong Yidong <cyd@stupidchicken.com> wrote: > I didn't know there were still outstanding issues with emacsclient. > (I haven't been following the thread closely, but it's been a month > since the first batch of emacsclient changes were checked in, and > there hasn't been any email traffic on this issue lately, so I assume > the initial batch of bugs that surfaced has been fixed. Or haven't > they?) Yes. There are no outstanding problems with emacsclient. Lennart is trying to add functionality to allow emacsclient to start Emacs and retry communication if Emacs is not running when emacsclient runs. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 22:58 ` Pretest Lennart Borgman 2006-11-18 23:32 ` Pretest Chong Yidong @ 2006-11-19 0:56 ` Nick Roberts 2006-11-19 1:01 ` Pretest Juanma Barranquero 2006-11-19 8:45 ` Pretest David Kastrup 1 sibling, 2 replies; 317+ messages in thread From: Nick Roberts @ 2006-11-19 0:56 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel > > I've rolled a new pretest tarball, which is available at > > > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz > > > > The various build problems in 22.0.90 should be resolved. We should > > now make the pretest announcement, if Richard has finished updating > > the pretesters list. > > > We are currently working with emacsclient. It would be very good if our > changes in emacsclient were included in the pretest. We need a little > bit more time for resolving some issues and for testing. It sounds like it's too late. If the issues can't be resolved quickly perhaps the changes should be reverted. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 0:56 ` Pretest Nick Roberts @ 2006-11-19 1:01 ` Juanma Barranquero 2006-11-19 1:56 ` Pretest Nick Roberts 2006-11-19 8:45 ` Pretest David Kastrup 1 sibling, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 1:01 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > It sounds like it's too late. If the issues can't be resolved quickly perhaps > the changes should be reverted. What issues? What changes should be reverted? /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 1:01 ` Pretest Juanma Barranquero @ 2006-11-19 1:56 ` Nick Roberts 2006-11-19 2:04 ` Pretest Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: Nick Roberts @ 2006-11-19 1:56 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel > > It sounds like it's too late. If the issues can't be resolved quickly > > perhaps the changes should be reverted. > > What issues? You should ask Lennart that question. > What changes should be reverted? The ones which are causing the issues. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 1:56 ` Pretest Nick Roberts @ 2006-11-19 2:04 ` Juanma Barranquero 2006-11-19 3:29 ` Pretest Nick Roberts 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 2:04 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > > What issues? > > You should ask Lennart that question. I ask you because Lennart's changes aren't committed yet. > > What changes should be reverted? > > The ones which are causing the issues. What issues? /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 2:04 ` Pretest Juanma Barranquero @ 2006-11-19 3:29 ` Nick Roberts 0 siblings, 0 replies; 317+ messages in thread From: Nick Roberts @ 2006-11-19 3:29 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel Juanma Barranquero writes: > On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > > > > What issues? > > > > You should ask Lennart that question. > > I ask you because Lennart's changes aren't committed yet. Well I don't know. He stated that there were issues. > > > What changes should be reverted? > > > > The ones which are causing the issues. > > What issues? You remind me of a man. What man? A man with a power? What power? The power of hoodoo. Who do?! You do! Do what? Remind me of a man... -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 0:56 ` Pretest Nick Roberts 2006-11-19 1:01 ` Pretest Juanma Barranquero @ 2006-11-19 8:45 ` David Kastrup 2006-11-19 10:03 ` Pretest Nick Roberts 1 sibling, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-19 8:45 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > > I've rolled a new pretest tarball, which is available at > > > > > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz > > > > > > The various build problems in 22.0.90 should be resolved. We should > > > now make the pretest announcement, if Richard has finished updating > > > the pretesters list. > > > > > > We are currently working with emacsclient. It would be very good if our > > changes in emacsclient were included in the pretest. We need a little > > bit more time for resolving some issues and for testing. > > It sounds like it's too late. If the issues can't be resolved > quickly perhaps the changes should be reverted. What sense is in reverting changes if it is too late? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 8:45 ` Pretest David Kastrup @ 2006-11-19 10:03 ` Nick Roberts 2006-11-19 10:18 ` Pretest David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Nick Roberts @ 2006-11-19 10:03 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel > > > We are currently working with emacsclient. It would be very good if our > > > changes in emacsclient were included in the pretest. We need a little > > > bit more time for resolving some issues and for testing. > > > > It sounds like it's too late. If the issues can't be resolved > > quickly perhaps the changes should be reverted. > > What sense is in reverting changes if it is too late? Too late to include changes in a pretest that is already out! The changes were made after the first pretest for a bug that was deemed non-critical by Richard. It seems a bit rich to ask for more time a month later. If it's quicker to revert them than to resolve then that seems to make sense to me. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 10:03 ` Pretest Nick Roberts @ 2006-11-19 10:18 ` David Kastrup 2006-11-19 11:44 ` Pretest Nick Roberts 2006-11-20 1:37 ` Pretest Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: David Kastrup @ 2006-11-19 10:18 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel Nick Roberts <nickrob@snap.net.nz> writes: > > > > We are currently working with emacsclient. It would be very > > > > good if our changes in emacsclient were included in the > > > > pretest. We need a little bit more time for resolving some > > > > issues and for testing. > > > > > > It sounds like it's too late. If the issues can't be resolved > > > quickly perhaps the changes should be reverted. > > > > What sense is in reverting changes if it is too late? > > Too late to include changes in a pretest that is already out! The > changes were made after the first pretest for a bug that was deemed > non-critical by Richard. It seems a bit rich to ask for more time a > month later. If it's quicker to revert them than to resolve then > that seems to make sense to me. It seems like we have completely different recollections of events. As far as I remember, Richard oked getting emacsclient to work on Windows even after the first pretest (where emacsclient was not yet a part of Emacs). There is no point whatsoever in reverting to the state of the first pretest, namely "non-working". Whether there is sense to reverting to a later point of development has not been discussed yet: up to now the developers tried getting the functionality to do the right thing. Telling them that they should stop doing so and revert to some earlier stage would require agreement on just what this earlier state should be. "non-working" is what you demand. Up to now there has been no discussion about where we should exactly draw the line with regard to emacsclient (work is still going on), but I don't think that "non-working" would get much support. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 10:18 ` Pretest David Kastrup @ 2006-11-19 11:44 ` Nick Roberts 2006-11-19 14:13 ` Pretest Juanma Barranquero 2006-11-19 14:19 ` Pretest Juanma Barranquero 2006-11-20 1:37 ` Pretest Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: Nick Roberts @ 2006-11-19 11:44 UTC (permalink / raw) Cc: Lennart Borgman, Chong Yidong, emacs-devel Telling them that they should stop doing so and revert to some earlier stage would require agreement on just what this earlier state should be. "non-working" is what you demand. I'm not telling people what to do, or demanding anything. I'm just saying that I don't it is appropriate to delay things for further improvements to emacsclient on Windows. If you're going to sum up, at least do it accurately. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 11:44 ` Pretest Nick Roberts @ 2006-11-19 14:13 ` Juanma Barranquero 2006-11-19 14:24 ` Pretest David Kastrup 2006-11-20 12:59 ` Pretest Richard Stallman 2006-11-19 14:19 ` Pretest Juanma Barranquero 1 sibling, 2 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 14:13 UTC (permalink / raw) Cc: emacs-devel On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > I'm not telling people what to do, or demanding anything. I'm just saying that > I don't it is appropriate to delay things for further improvements to > emacsclient on Windows. If you're going to sum up, at least do it accurately. Well, if you're going to propose something, you should try to be accurate too. Reading the relevant threads (or even reading this one with a bit of attention to details) should suffice. emacsclient's TCP support is working, and there are no issues. Removing it now would be absurd. Lennart is *proposing* changes that would allow emacsclient to automatically start Emacs if it is not running already. Did you read "Windows" in the previous sentence? I bet you didn't, because it *was not* here. What Lennart's trying to do is not Windows-specific. Whether it is too late to include it or not is another matter altogether, but that can be discussed without the need to remove working code. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:13 ` Pretest Juanma Barranquero @ 2006-11-19 14:24 ` David Kastrup 2006-11-19 14:42 ` Pretest Juanma Barranquero 2006-11-19 14:45 ` Pretest Lennart Borgman 2006-11-20 12:59 ` Pretest Richard Stallman 1 sibling, 2 replies; 317+ messages in thread From: David Kastrup @ 2006-11-19 14:24 UTC (permalink / raw) Cc: Nick Roberts, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > >> I'm not telling people what to do, or demanding anything. I'm just >> saying that I don't it is appropriate to delay things for further >> improvements to emacsclient on Windows. If you're going to sum up, >> at least do it accurately. > > Lennart is *proposing* changes that would allow emacsclient to > automatically start Emacs if it is not running already. Could anybody summarize what is missing in order to make emacsclient --alternate-editor "emacs --eval '(server-start)'" work for this purpose? That seems simple enough, but I could be likely missing some part of the picture. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:24 ` Pretest David Kastrup @ 2006-11-19 14:42 ` Juanma Barranquero 2006-11-19 14:45 ` Pretest Lennart Borgman 1 sibling, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 14:42 UTC (permalink / raw) Cc: Nick Roberts, emacs-devel On 11/19/06, David Kastrup <dak@gnu.org> wrote: > Could anybody summarize what is missing in order to make > > emacsclient --alternate-editor "emacs --eval '(server-start)'" > > work for this purpose? If you do emacsclient -a "emacs --eval '(server-start)'" my-file.txt and Emacs is running, Emacs will edit my-file.txt and emacsclient will wait. If Emacs is not running, emacsclient will start Emacs (with the server active) and pass it my-file.txt, but emacsclient won't have a connection with Emacs so it won't wait for Emacs to finish. emacsclient does not know (it never knew) how to start Emacs, then wait for a while, then retry connection with it (which gnuclient/gnuserv does, for example). That is relevant if you're using emacsclient from a shortcut, or from inside a program (for example, if you've set SVN_EDITOR to use Emacs to edit Subversion commit logs, as I do). There are a few related issues (quoting on the command line on Windows, passing the server-name and server-file to Emacs if started by emacsclient, not starting Emacs if the connection is not local, etc.), but they're minor. As it stands now, emacsclient is no less functional that it was before the TCP changes. The behavior Lennart's trying to fix would happen before. It is new (and very useful) functionality. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:24 ` Pretest David Kastrup 2006-11-19 14:42 ` Pretest Juanma Barranquero @ 2006-11-19 14:45 ` Lennart Borgman 2006-11-19 15:58 ` Pretest David Kastrup 2006-11-19 17:54 ` Pretest Jason Rumney 1 sibling, 2 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 14:45 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel David Kastrup wrote: > "Juanma Barranquero" <lekktu@gmail.com> writes: > >> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: >> >>> I'm not telling people what to do, or demanding anything. I'm just >>> saying that I don't it is appropriate to delay things for further >>> improvements to emacsclient on Windows. If you're going to sum up, >>> at least do it accurately. >> Lennart is *proposing* changes that would allow emacsclient to >> automatically start Emacs if it is not running already. > > Could anybody summarize what is missing in order to make > > emacsclient --alternate-editor "emacs --eval '(server-start)'" > > work for this purpose? That seems simple enough, but I could be > likely missing some part of the picture. Perhaps I could answer ;-) What is missing is something that allows you to just use emacsclient -n myfile without doing any setup whatever, without having to start Emacs before. It should in my opinion work right out of the box. The reason? The threshold is already high to start to use Emacs. For new users it is very important to be able to start immediately right after installing Emacs. Otherwise a lot of potential user might never start using Emacs. The possibility to do something like the line you propose should still be there, but with my patch you should be able to just use emacsclient --alternative-editor="whateveryoulike" myfile instead. I have previously added similar functionality to gnuclient on w32. I have waited for a working emacsclient on w32 so that I could try to implement that feature there instead in a platform independent manner. I have done that now - I believe. The code is working on w32 and most of it is the same on other platforms. Starting a new process is however platform dependent. I think there are three different platform dependent ways: - fork() - CreateProcess() on w32 - system() -- needs a helper program to avoid wait To be clear the code is there for all three ways (but it is not yet submitted to the CVS). For those that does not want to use the new functionality to start Emacs automatically everything will work as before. When I started to distribute binaries for Emacs on w32 Richard expressed that he wanted the official release of Emacs to have all functionality it included working on GNU/Linux. My proposal above is not exactly in line with that, but rather close. On w32 this functionality actually have been available for quite some time now. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:45 ` Pretest Lennart Borgman @ 2006-11-19 15:58 ` David Kastrup 2006-11-19 19:13 ` Pretest Lennart Borgman 2006-11-19 17:54 ` Pretest Jason Rumney 1 sibling, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-19 15:58 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: >> "Juanma Barranquero" <lekktu@gmail.com> writes: >> >>> On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: >>> >>>> I'm not telling people what to do, or demanding anything. I'm just >>>> saying that I don't it is appropriate to delay things for further >>>> improvements to emacsclient on Windows. If you're going to sum up, >>>> at least do it accurately. >>> Lennart is *proposing* changes that would allow emacsclient to >>> automatically start Emacs if it is not running already. >> >> Could anybody summarize what is missing in order to make >> >> emacsclient --alternate-editor "emacs --eval '(server-start)'" >> >> work for this purpose? That seems simple enough, but I could be >> likely missing some part of the picture. > > > Perhaps I could answer ;-) > > What is missing is something that allows you to just use > > emacsclient -n myfile > > without doing any setup whatever, without having to start Emacs > before. It should in my opinion work right out of the box. Are there really typical use cases which require -n? If so, is there a need for them to wait for --alternate-editor? > The reason? The threshold is already high to start to use Emacs. For > new users it is very important to be able to start immediately right > after installing Emacs. Otherwise a lot of potential user might > never start using Emacs. What is the problem with the invocation I gave? The _technical_ problem? If a shorthand option for that invocation would be desirable, it would be possible to implement this in about three lines of code, so why is something different required? > The possibility to do something like the line you propose should still > be there, but with my patch you should be able to just use > > emacsclient --alternative-editor="whateveryoulike" myfile > > instead. Why would that not work with the existing code? It did work up to now, didn't it? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 15:58 ` Pretest David Kastrup @ 2006-11-19 19:13 ` Lennart Borgman 2006-11-19 19:27 ` Pretest David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 19:13 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel David Kastrup wrote: > Lennart Borgman <lennart.borgman.073@student.lu.se> writes: >> What is missing is something that allows you to just use >> >> emacsclient -n myfile >> >> without doing any setup whatever, without having to start Emacs >> before. It should in my opinion work right out of the box. > > Are there really typical use cases which require -n? If so, is there > a need for them to wait for --alternate-editor? Sorry, I did not mean that emacsclient myfile is not equally important. There are of course many typical use cases both with and without -n. >> The reason? The threshold is already high to start to use Emacs. For >> new users it is very important to be able to start immediately right >> after installing Emacs. Otherwise a lot of potential user might >> never start using Emacs. > > What is the problem with the invocation I gave? The _technical_ > problem? If a shorthand option for that invocation would be > desirable, it would be possible to implement this in about three lines > of code, so why is something different required? Are you saying that you could implement this in a general way so that a new user right after installation can just type something like emacsclient myfile or emacsclient -n myfile in just three lines of code? I did actually not add many lines to do this (most was restructuring of existing code), but I added quite a bit more than tree lines. >> The possibility to do something like the line you propose should still >> be there, but with my patch you should be able to just use >> >> emacsclient --alternative-editor="whateveryoulike" myfile >> >> instead. > > Why would that not work with the existing code? It did work up to > now, didn't it? I think Juanma gave you a reason before. It seems impossible to implement the wait this way. (And I am sure you can see the details yourself.) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 19:13 ` Pretest Lennart Borgman @ 2006-11-19 19:27 ` David Kastrup 2006-11-20 1:15 ` Pretest Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-19 19:27 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: >> Lennart Borgman <lennart.borgman.073@student.lu.se> writes: >>> What is missing is something that allows you to just use >>> >>> emacsclient -n myfile >>> >>> without doing any setup whatever, without having to start Emacs >>> before. It should in my opinion work right out of the box. >> >> Are there really typical use cases which require -n? If so, is there >> a need for them to wait for --alternate-editor? > > > Sorry, I did not mean that > > emacsclient myfile > > is not equally important. There are of course many typical use cases > both with and without -n. > >>> The reason? The threshold is already high to start to use Emacs. For >>> new users it is very important to be able to start immediately right >>> after installing Emacs. Otherwise a lot of potential user might >>> never start using Emacs. >> >> What is the problem with the invocation I gave? The _technical_ >> problem? If a shorthand option for that invocation would be >> desirable, it would be possible to implement this in about three lines >> of code, so why is something different required? > > > Are you saying that you could implement this in a general way so that > a new user right after installation can just type something like > > emacsclient myfile > or > emacsclient -n myfile > > in just three lines of code? I did actually not add many lines to do > this (most was restructuring of existing code), but I added quite a > bit more than tree lines. Again: what is the problem with emacsclient -a 'emacs --eval (server-start)' ? If there is no problem with that, I don't see why implement a shorthand option that does nothing but that would not do the trick. >>> The possibility to do something like the line you propose should >>> still be there, but with my patch you should be able to just use >>> >>> emacsclient --alternative-editor="whateveryoulike" myfile >>> >>> instead. >> >> Why would that not work with the existing code? It did work up to >> now, didn't it? > > I think Juanma gave you a reason before. I must be dense. > It seems impossible to implement the wait this way. (And I am sure > you can see the details yourself.) Which wait? Could you explain a use case where the invocation emacsclient -a 'emacs --eval (server-start)' would not work? That was my question and I still don't see that it has been answered. Maybe I am too stupid to get it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 19:27 ` Pretest David Kastrup @ 2006-11-20 1:15 ` Stefan Monnier 0 siblings, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2006-11-20 1:15 UTC (permalink / raw) Cc: Lennart Borgman, Nick Roberts, emacs-devel, Juanma Barranquero > Again: what is the problem with > emacsclient -a 'emacs --eval (server-start)' > ? Depends what you intend this to solve. What they want is to be able to say "emacsclient <maybesomeoptionshere> <file>" and it should always work the same way, whether Emacs was already started or not. Your above invocation has no <file>, so it doesn't directly solve their problem. If you intended something like emacsclient -a 'emacs --eval (server-start)' <file> then it suffers from the problem that this command will only exit after the Emacs server exits, rather than after you finish editing <file>. So instead they intend to do something like emacsclient -a 'emacs --eval (server-start) & emacsclient' <file> but then they need to deal with the fact that the server is only accessible after some amount of time, so the emacsclient after the "&" needs to be able to deal with temporary connection failures. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:45 ` Pretest Lennart Borgman 2006-11-19 15:58 ` Pretest David Kastrup @ 2006-11-19 17:54 ` Jason Rumney 2006-11-19 19:14 ` Pretest Lennart Borgman 2006-11-19 19:50 ` Pretest Jason Rumney 1 sibling, 2 replies; 317+ messages in thread From: Jason Rumney @ 2006-11-19 17:54 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel Lennart Borgman wrote: > > - system() -- needs a helper program to avoid wait > In the most important use case, we don't want to wait. Everything else is handled by ALTERNATE_EDITOR already. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 17:54 ` Pretest Jason Rumney @ 2006-11-19 19:14 ` Lennart Borgman 2006-11-19 19:50 ` Pretest Jason Rumney 1 sibling, 0 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 19:14 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel Jason Rumney wrote: > Lennart Borgman wrote: >> >> - system() -- needs a helper program to avoid wait >> > In the most important use case, we don't want to wait. Everything else > is handled by ALTERNATE_EDITOR already. > Yes, that is true. But we do have a wait flag (-n) for a reason. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 17:54 ` Pretest Jason Rumney 2006-11-19 19:14 ` Pretest Lennart Borgman @ 2006-11-19 19:50 ` Jason Rumney 2006-11-19 20:48 ` Pretest David Kastrup 1 sibling, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-11-19 19:50 UTC (permalink / raw) Cc: Lennart Borgman, Nick Roberts, emacs-devel, Juanma Barranquero Jason Rumney wrote: > In the most important use case, we don't want to wait. I meant we DO want to wait here. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 19:50 ` Pretest Jason Rumney @ 2006-11-19 20:48 ` David Kastrup 2006-11-19 21:33 ` Pretest Lennart Borgman ` (3 more replies) 0 siblings, 4 replies; 317+ messages in thread From: David Kastrup @ 2006-11-19 20:48 UTC (permalink / raw) Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > Jason Rumney wrote: >> In the most important use case, we don't want to wait. > I meant we DO want to wait here. Why? The most important case would be a file association or GUI button I would guess, and there waiting or not waiting does not tend to make a difference, does it? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 20:48 ` Pretest David Kastrup @ 2006-11-19 21:33 ` Lennart Borgman 2006-11-19 21:33 ` Pretest Jason Rumney ` (2 subsequent siblings) 3 siblings, 0 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 21:33 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > >> Jason Rumney wrote: >>> In the most important use case, we don't want to wait. >> I meant we DO want to wait here. > > Why? The most important case would be a file association or GUI > button I would guess, and there waiting or not waiting does not tend > to make a difference, does it? I got complaints before about processes hanging around when gnuclient was waiting on w32. (It was actually quite comical since each gnuclient had its own command window (console window) on w32. I did not notice since I always had quite a lot of windows.) That was actually why I started looking into the problem with waiting and non-waiting clients and automatical start of Emacs ;-) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 20:48 ` Pretest David Kastrup 2006-11-19 21:33 ` Pretest Lennart Borgman @ 2006-11-19 21:33 ` Jason Rumney 2006-11-19 21:49 ` Pretest David Kastrup 2006-11-19 21:34 ` Pretest Lennart Borgman 2006-11-19 21:38 ` Pretest Lennart Borgman 3 siblings, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-11-19 21:33 UTC (permalink / raw) Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > >>> In the most important use case, we DO want to wait. >>> > > Why? Because most programs that launch an editor as a subprocess need to know when editing has finished. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 21:33 ` Pretest Jason Rumney @ 2006-11-19 21:49 ` David Kastrup 2006-11-19 22:04 ` Pretest Jason Rumney ` (2 more replies) 0 siblings, 3 replies; 317+ messages in thread From: David Kastrup @ 2006-11-19 21:49 UTC (permalink / raw) Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel Jason Rumney <jasonr@gnu.org> writes: > David Kastrup wrote: >> Jason Rumney <jasonr@gnu.org> writes: >> >>>> In the most important use case, we DO want to wait. >>>> >> >> Why? > > Because most programs that launch an editor as a subprocess need to > know when editing has finished. So the "most important use case" according to you is basically a command line call, not a GUI call. That was not obvious to me. And we are talking about an emacsclient connection on Windows. When Emacs is already running, emacsclient will connect to Emacs and block while Emacs in its existing frame is working on a file. When one is finished working this file, Emacs would then get emacsclient to exit by telling it it quit. In order to mimic this behavior when Emacs is not already running, you want to have it started in a detached manner, then have emacsclient attach to it once its server is running, and have it exit when the Emacs server tells it to. Wouldn't it be saner if emacsclient just started Emacs (probably with a specific command line option), and when Emacs was finished with editing the respective buffer, it would detach itself from emacsclient which would then exit? That would obliterate all the waiting for server-start issues. It would just mean that server-buffers initiated from the command line instead of emacsclient would exit by detaching themselves from the controlling terminal instead of talking to emacsclient on a socket. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 21:49 ` Pretest David Kastrup @ 2006-11-19 22:04 ` Jason Rumney 2006-11-19 22:06 ` Pretest Lennart Borgman 2006-11-20 1:20 ` Pretest Stefan Monnier 2 siblings, 0 replies; 317+ messages in thread From: Jason Rumney @ 2006-11-19 22:04 UTC (permalink / raw) Cc: Juanma Barranquero, Lennart Borgman, Nick Roberts, emacs-devel David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > > >> Because most programs that launch an editor as a subprocess need to >> know when editing has finished. >> > > So the "most important use case" according to you is basically a > command line call, not a GUI call. I'm not sure where this distinction between "GUI calls" and "command line calls" comes from. I'm talking about ANY program that wants to use an external editor here. They either require emacsclient to wait until editing is done, or they don't care. So it worries me that the focus is on the --no-wait case for this, since that is already handled, and isn't a lot of use except for command-line use where the user wants their interactive shell back immediately. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 21:49 ` Pretest David Kastrup 2006-11-19 22:04 ` Pretest Jason Rumney @ 2006-11-19 22:06 ` Lennart Borgman 2006-11-19 22:44 ` Pretest David Kastrup 2006-11-20 1:20 ` Pretest Stefan Monnier 2 siblings, 1 reply; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 22:06 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > >> David Kastrup wrote: >>> Jason Rumney <jasonr@gnu.org> writes: >>> >>>>> In the most important use case, we DO want to wait. >>>>> >>> Why? >> Because most programs that launch an editor as a subprocess need to >> know when editing has finished. > > So the "most important use case" according to you is basically a > command line call, not a GUI call. That was not obvious to me. And > we are talking about an emacsclient connection on Windows. When Emacs > is already running, emacsclient will connect to Emacs and block while > Emacs in its existing frame is working on a file. When one is > finished working this file, Emacs would then get emacsclient to exit > by telling it it quit. > > In order to mimic this behavior when Emacs is not already running, you > want to have it started in a detached manner, then have emacsclient > attach to it once its server is running, and have it exit when the > Emacs server tells it to. > > Wouldn't it be saner if emacsclient just started Emacs (probably with > a specific command line option), and when Emacs was finished with > editing the respective buffer, it would detach itself from emacsclient > which would then exit? > > That would obliterate all the waiting for server-start issues. It > would just mean that server-buffers initiated from the command line > instead of emacsclient would exit by detaching themselves from the > controlling terminal instead of talking to emacsclient on a socket. I am trying to understand what you mean here, but I fail. Is this perhaps something that can be done with X Windows? And what issues do you mean when you write "waiting for server-start issues"? Is it perhaps those I hope I have solved in my code? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 22:06 ` Pretest Lennart Borgman @ 2006-11-19 22:44 ` David Kastrup 2006-11-19 23:02 ` Pretest Lennart Borgman 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-19 22:44 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: >> Jason Rumney <jasonr@gnu.org> writes: >> >>> David Kastrup wrote: >>>> Jason Rumney <jasonr@gnu.org> writes: >>>> >>>>>> In the most important use case, we DO want to wait. >>>>>> >>>> Why? >>> Because most programs that launch an editor as a subprocess need to >>> know when editing has finished. >> >> So the "most important use case" according to you is basically a >> command line call, not a GUI call. That was not obvious to me. >> And we are talking about an emacsclient connection on Windows. >> When Emacs is already running, emacsclient will connect to Emacs >> and block while Emacs in its existing frame is working on a file. >> When one is finished working this file, Emacs would then get >> emacsclient to exit by telling it it quit. >> >> In order to mimic this behavior when Emacs is not already running, >> you want to have it started in a detached manner, then have >> emacsclient attach to it once its server is running, and have it >> exit when the Emacs server tells it to. >> >> Wouldn't it be saner if emacsclient just started Emacs (probably >> with a specific command line option), and when Emacs was finished >> with editing the respective buffer, it would detach itself from >> emacsclient which would then exit? >> >> That would obliterate all the waiting for server-start issues. It >> would just mean that server-buffers initiated from the command line >> instead of emacsclient would exit by detaching themselves from the >> controlling terminal instead of talking to emacsclient on a socket. > > > I am trying to understand what you mean here, but I fail. Is this > perhaps something that can be done with X Windows? Nothing to do with X11. > And what issues do you mean when you write "waiting for server-start > issues"? Is it perhaps those I hope I have solved in my code? You want to start an Emacs if it is not present, detach it so that its life time does not depend on emacsserver, wait until it has started a server (if it does so in the first place), then connect to it, tell it what buffer to edit, and ask it to tell you when this is done. I am proposing that instead one uses something like emacsclient -a "emacs -delayed-detach" where emacsclient does not actually have a clue that it has started an Emacs, and does not try talking to it. Instead it waits until emacs dies. What emacs does instead would, in Unixspeak, be to fork. The child would then detach itself from the controlling terminal, take the command line options and start an almost normal Emacs life. When the user executed a "server-done", however, the child would kill its parent which would then exit. Now under Windows this forking stuff does not work IIRC. Once one starts a big process like Emacs, it is not cheap to start another copy from inside. So instead of "emacs -delayed-detach" one would rather start something like "emacsproxy" with the command line arguments. emacsproxy would then start the proper Emacs process with its command line, and the proper Emacs process would, upon getting "server-done" executed by the user, kill the emacsproxy process. So the invocation for emacsclient would be something like emacsclient -a emacsproxy -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 22:44 ` Pretest David Kastrup @ 2006-11-19 23:02 ` Lennart Borgman 2006-11-19 23:31 ` Pretest David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 23:02 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney David Kastrup wrote: > Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > >> David Kastrup wrote: >>> Jason Rumney <jasonr@gnu.org> writes: >>> >>>> David Kastrup wrote: >>>>> Jason Rumney <jasonr@gnu.org> writes: >>>>> >>>>>>> In the most important use case, we DO want to wait. >>>>>>> >>>>> Why? >>>> Because most programs that launch an editor as a subprocess need to >>>> know when editing has finished. >>> So the "most important use case" according to you is basically a >>> command line call, not a GUI call. That was not obvious to me. >>> And we are talking about an emacsclient connection on Windows. >>> When Emacs is already running, emacsclient will connect to Emacs >>> and block while Emacs in its existing frame is working on a file. >>> When one is finished working this file, Emacs would then get >>> emacsclient to exit by telling it it quit. >>> >>> In order to mimic this behavior when Emacs is not already running, >>> you want to have it started in a detached manner, then have >>> emacsclient attach to it once its server is running, and have it >>> exit when the Emacs server tells it to. >>> >>> Wouldn't it be saner if emacsclient just started Emacs (probably >>> with a specific command line option), and when Emacs was finished >>> with editing the respective buffer, it would detach itself from >>> emacsclient which would then exit? >>> >>> That would obliterate all the waiting for server-start issues. It >>> would just mean that server-buffers initiated from the command line >>> instead of emacsclient would exit by detaching themselves from the >>> controlling terminal instead of talking to emacsclient on a socket. >> >> I am trying to understand what you mean here, but I fail. Is this >> perhaps something that can be done with X Windows? > > Nothing to do with X11. Thanks. >> And what issues do you mean when you write "waiting for server-start >> issues"? Is it perhaps those I hope I have solved in my code? > > You want to start an Emacs if it is not present, detach it so that its > life time does not depend on emacsserver, wait until it has started a > server (if it does so in the first place), then connect to it, tell it > what buffer to edit, and ask it to tell you when this is done. > > I am proposing that instead one uses something like > > emacsclient -a "emacs -delayed-detach" > > where emacsclient does not actually have a clue that it has started an > Emacs, and does not try talking to it. Instead it waits until emacs > dies. What emacs does instead would, in Unixspeak, be to fork. The > child would then detach itself from the controlling terminal, take the > command line options and start an almost normal Emacs life. When the > user executed a "server-done", however, the child would kill its > parent which would then exit. But would not the fork used in this way mean that we during "waited editing" has two emacs processes (or more)? Would not that defeat some of the benefits of emacs server? > Now under Windows this forking stuff does not work IIRC. Once one > starts a big process like Emacs, it is not cheap to start another copy > from inside. > > So instead of "emacs -delayed-detach" one would rather start something > like "emacsproxy" with the command line arguments. > > emacsproxy would then start the proper Emacs process with its command > line, and the proper Emacs process would, upon getting "server-done" > executed by the user, kill the emacsproxy process. > > So the invocation for emacsclient would be something like > > emacsclient -a emacsproxy Thanks, I believe I understand this part, but it is quite a bit more complicated than what I actually have implemented. For what reason do you want to avoid the wait for the server process to start the way I have implemented it? Doing it that way means that emacsclient always communicates with emacs server in the same way and I think that is very important from a code complexity point of view. One drawback I can see is that you can not know for sure if the server ever starts. Therefore I have added a simple timeout for how long emacsclient waits for emacs server to start. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 23:02 ` Pretest Lennart Borgman @ 2006-11-19 23:31 ` David Kastrup 2006-11-20 0:59 ` Pretest Lennart Borgman 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-19 23:31 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: >> You want to start an Emacs if it is not present, detach it so that >> its life time does not depend on emacsserver, wait until it has >> started a server (if it does so in the first place), then connect >> to it, tell it what buffer to edit, and ask it to tell you when >> this is done. >> >> I am proposing that instead one uses something like >> >> emacsclient -a "emacs -delayed-detach" >> >> where emacsclient does not actually have a clue that it has started >> an Emacs, and does not try talking to it. Instead it waits until >> emacs dies. What emacs does instead would, in Unixspeak, be to >> fork. The child would then detach itself from the controlling >> terminal, take the command line options and start an almost normal >> Emacs life. When the user executed a "server-done", however, the >> child would kill its parent which would then exit. > > But would not the fork used in this way mean that we during "waited > editing" has two emacs processes (or more)? Would not that defeat > some of the benefits of emacs server? In Unix, fork is cheap. The processes share the same code, and the data starts out shared (the MMU sets it to read-only, and only when one of the processes writes to it, a copy is created on which it then works). If the fork is done early in the life time of the process and one of the forked processes touches only small amounts of data (which would be the case here), the cost is negligible. Similarly if after the fork one of the processes does nothing much except change programs by virtue of an exec call. I am aware that Windows does not have fork with similar semantics, which is why I then made a different proposal: >> Now under Windows this forking stuff does not work IIRC. Once one >> starts a big process like Emacs, it is not cheap to start another copy >> from inside. >> >> So instead of "emacs -delayed-detach" one would rather start something >> like "emacsproxy" with the command line arguments. >> >> emacsproxy would then start the proper Emacs process with its command >> line, and the proper Emacs process would, upon getting "server-done" >> executed by the user, kill the emacsproxy process. >> >> So the invocation for emacsclient would be something like >> >> emacsclient -a emacsproxy > > Thanks, I believe I understand this part, but it is quite a bit more > complicated than what I actually have implemented. It has the advantage that it does not need to wait around, does not need to rely on "server-start" getting fired up eventually and so on. It bypasses the complete emacsserver business, and thus would be a _reliable_ way to start an Emacs that can stay around even when the socket stuff fails to work for some reason (permissions, file names, whatever). In addition, it would provide a separate "start Emacs, and simulate finishing it when the user wants so" command which could conceivably be useful in situations outside of the emacsclient/emacsserver setting. > For what reason do you want to avoid the wait for the server process > to start the way I have implemented it? Because it is not reliable. It depends on actions in the started Emacs that are not under the control of emacsclient, and it requires a separate mechanism not transparent to the user apart from --alternate-editor. > Doing it that way means that emacsclient always communicates with > emacs server in the same way and I think that is very important from > a code complexity point of view. >From code complexity, emacsclient would just pass its options on to the alternate editor, whether that is called emacsproxy or vi. > One drawback I can see is that you can not know for sure if the > server ever starts. Therefore I have added a simple timeout for how > long emacsclient waits for emacs server to start. I'd prefer the approach where emacsclient does not depend on Emacs server to start. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 23:31 ` Pretest David Kastrup @ 2006-11-20 0:59 ` Lennart Borgman 2006-11-20 1:20 ` Pretest David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Lennart Borgman @ 2006-11-20 0:59 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, Jason Rumney, emacs-devel David Kastrup wrote: > In Unix, fork is cheap. The processes share the same code, and the ... > I am aware that Windows does not have fork with similar semantics, > which is why I then made a different proposal: Thanks. I did actually misunderstand you quite a bit before and was going to correct myself before I read this. We are using different language. >> For what reason do you want to avoid the wait for the server process >> to start the way I have implemented it? > > Because it is not reliable. It depends on actions in the started > Emacs that are not under the control of emacsclient, and it requires a > separate mechanism not transparent to the user apart from > --alternate-editor. You are right. >> Doing it that way means that emacsclient always communicates with >> emacs server in the same way and I think that is very important from >> a code complexity point of view. > >>From code complexity, emacsclient would just pass its options on to > the alternate editor, whether that is called emacsproxy or vi. > >> One drawback I can see is that you can not know for sure if the >> server ever starts. Therefore I have added a simple timeout for how >> long emacsclient waits for emacs server to start. > > I'd prefer the approach where emacsclient does not depend on Emacs > server to start. With a little twist your suggestion would be very similar to mine. The main part of your suggestion as I see it is that emacsclient wait on an intermediate process. This has the advantage that emacs could communicate with it and tell emacsclient about errors. That is good. Something like this would have the benefits of both yours and my suggestion: 1) If emacsclient could not contact emacs server then it create the intermediate process. This then starts emacs and tells emacs to start emacs server with the required arguments. 2) Emacsclient then wait for the intermediate process to disappear. After that it checks for errors. 3) If there are errors then it tries to connect to the server again. This is very similar to my current approach but better I believe. My approach looks like this: 1) If emacsclient can not contact emacs server then it starts emacs and tells emacs to start emacs server with the required arguments. 2) Emacsclient then loops and tries to connect to the server again. If it takes too long then emacsclient assumes there is an error. If it can connect that step is the same as 3 above. I think this would be better. From a user perspective the main differenc is better error handling. However it requires some changes to the emacs executable and I do not believe it should be implemented now. My proposal does not require any changes to emacs executable. And the code is ready for testing now (except for some details I have asked for comments on off the list, I am waiting for answers). However I would like to have it tested here by people on emacs devel list before going further. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 0:59 ` Pretest Lennart Borgman @ 2006-11-20 1:20 ` David Kastrup [not found] ` <45616414.2080802@student.lu.se> 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-20 1:20 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, Jason Rumney, emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: > >> I'd prefer the approach where emacsclient does not depend on Emacs >> server to start. > > With a little twist your suggestion would be very similar to mine. Uh, you twist my proposal and then complain about the consequences of the twist... > The main part of your suggestion as I see it is that emacsclient > wait on an intermediate process. This has the advantage that emacs > could communicate with it and tell emacsclient about errors. Uh no, it doesn't. The whole point was that emacsproxy behaves just like a blackbox that can be used instead of --alternate-editor. > That is good. Something like this would have the benefits of both > yours and my suggestion: > > 1) If emacsclient could not contact emacs server then it create the > intermediate process. This then starts emacs and tells emacs to > start emacs server with the required arguments. My proposal was all about _not_ needing to start Emacs server in the first place. Instead, Emacs is set up such that server-quit will _not_ attempt talking to some emacsclient, but will rather kill the emacsproxy it was started from. > 2) Emacsclient then wait for the intermediate process to > disappear. After that it checks for errors. My proposal was all about emacsclient starting the "emacsproxy" like an editor, waiting for it to finish, and then considering the file edited. > 3) If there are errors then it tries to connect to the server again. It does not need to connect to the server "again" since it never connected to the server anyhow. > However it requires some changes to the emacs executable and I do > not believe it should be implemented now. Hm. It requires emacsproxy to call Emacs with something like --eval '(setq server-proxy-process 54321)' or probably something like -f server-proxy-setup 54321 and server-quit to do something like (signal-process server-proxy-process 'INT) in an appropriate place. That's not really "requiring changes to the Emacs executable" in my book. There is one utterly unrelated problem I see here: I don't see how `signal-process' could work reliably on 32bit systems with 32bit process ids. Similarly, how would `process-id' work in that case? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
[parent not found: <45616414.2080802@student.lu.se>]
* Re: Pretest [not found] ` <45616414.2080802@student.lu.se> @ 2006-11-20 9:55 ` David Kastrup 0 siblings, 0 replies; 317+ messages in thread From: David Kastrup @ 2006-11-20 9:55 UTC (permalink / raw) Cc: emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > David Kastrup wrote: >> Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > > I am asking you off list not to clutter the list. I believe I still do > not understand you. I don't think it makes sense to take this off-list since we are talking about how to implement something that affects all users, and since there must be a consensus how to get there eventually. And if my explanations are deficient, you are not the only person who should get a better version of them. So I am taking the liberty of including the list again. >> My proposal was all about _not_ needing to start Emacs server in >> the first place. Instead, Emacs is set up such that server-quit >> will _not_ attempt talking to some emacsclient, but will rather >> kill the emacsproxy it was started from. > > Maybe I understand now. But does not your proposal mean that you > have several emacsen running if you are waiting for sever files or > have emacs running as a server at the same time, or? > > Does it not also mean that for each file you want to edit this way > emacs have to start itself and then run the init files? Only if a user indeed does not have (server-start) in his .emacs file or the communication fails. If that is found dissatisfactory as a default, it would be possible to let server-proxy-start (or whatever emacsproxy would cause its Emacs copy to execute in order to inform it what process to kill on server-done) also start the Emacs server by default. But it would be something which would not concern the operation of the _currently_ executing emacsclient/emacsproxy/emacs trio. _This_ emacsclient has already decided not to try the socket again and _replaced_ itself via exec with emacsproxy as an alternative editor, and emacsproxy does not talk via a socket, anyway, since its whole purpose is just to be an Emacs replacement that exits in proxy when server-done is executed in its Emacs, without going through the socket. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 21:49 ` Pretest David Kastrup 2006-11-19 22:04 ` Pretest Jason Rumney 2006-11-19 22:06 ` Pretest Lennart Borgman @ 2006-11-20 1:20 ` Stefan Monnier 2 siblings, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2006-11-20 1:20 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Lennart Borgman, Jason Rumney > So the "most important use case" according to you is basically a command > line call, not a GUI call. That was not obvious to me. And we are > talking about an emacsclient connection on Windows. AFAIK this has nothing to do with w32-vs-theworld. The same issue exists everywhere. > Wouldn't it be saner if emacsclient just started Emacs (probably with > a specific command line option), and when Emacs was finished with > editing the respective buffer, it would detach itself from emacsclient > which would then exit? Sure. Patch welcome. Maybe you can find a neat wait to do the "detach" part, but off-the-top-of-my-head I can't think of a simple way to do it. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 20:48 ` Pretest David Kastrup 2006-11-19 21:33 ` Pretest Lennart Borgman 2006-11-19 21:33 ` Pretest Jason Rumney @ 2006-11-19 21:34 ` Lennart Borgman 2006-11-19 21:38 ` Pretest Lennart Borgman 3 siblings, 0 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 21:34 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > >> Jason Rumney wrote: >>> In the most important use case, we don't want to wait. >> I meant we DO want to wait here. > > Why? The most important case would be a file association or GUI > button I would guess, and there waiting or not waiting does not tend > to make a difference, does it? I got complaints before about processes hanging around when gnuclient was waiting on w32. (It was actually quite comical since each gnuclient had its own command window (console window) on w32. I did not notice since I always had quite a lot of windows.) That was actually why I started looking into the problem with waiting and non-waiting clients and automatical start of Emacs ;-) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 20:48 ` Pretest David Kastrup ` (2 preceding siblings ...) 2006-11-19 21:34 ` Pretest Lennart Borgman @ 2006-11-19 21:38 ` Lennart Borgman 3 siblings, 0 replies; 317+ messages in thread From: Lennart Borgman @ 2006-11-19 21:38 UTC (permalink / raw) Cc: Juanma Barranquero, Nick Roberts, emacs-devel, Jason Rumney David Kastrup wrote: > Jason Rumney <jasonr@gnu.org> writes: > >> Jason Rumney wrote: >>> In the most important use case, we don't want to wait. >> I meant we DO want to wait here. > > Why? The most important case would be a file association or GUI > button I would guess, and there waiting or not waiting does not tend > to make a difference, does it? I got complaints before about processes hanging around when gnuclient was waiting on w32. (It was actually quite comical since each gnuclient had its own command window (console window) on w32. I did not notice since I always had quite a lot of windows.) That was actually why I started looking into the problem with waiting and non-waiting clients and automatical start of Emacs ;-) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 14:13 ` Pretest Juanma Barranquero 2006-11-19 14:24 ` Pretest David Kastrup @ 2006-11-20 12:59 ` Richard Stallman 1 sibling, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-20 12:59 UTC (permalink / raw) Cc: nickrob, emacs-devel Lennart is *proposing* changes that would allow emacsclient to automatically start Emacs if it is not running already. Now is the wrong time. Please leave this for after the release! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 11:44 ` Pretest Nick Roberts 2006-11-19 14:13 ` Pretest Juanma Barranquero @ 2006-11-19 14:19 ` Juanma Barranquero 1 sibling, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-19 14:19 UTC (permalink / raw) Cc: emacs-devel On 11/19/06, Nick Roberts <nickrob@snap.net.nz> wrote: > I'm not telling people what to do, or demanding anything. I'm just saying that > I don't it is appropriate to delay things for further improvements to > emacsclient on Windows. If you're going to sum up, at least do it accurately. Well, if you're going to propose something, you should try to be accurate too. Reading the relevant threads (or even reading this one with a bit of attention to details) should suffice. emacsclient's TCP support is working, and there are no issues. Removing it now would be absurd. Lennart is *proposing* changes that would allow emacsclient to automatically start Emacs if it is not running already. Did you read "Windows" in the previous sentence? I bet you didn't, because it *was not* here. What Lennart's trying to do is not Windows-specific. Whether it is too late to include it or not is another matter altogether, but that can be discussed without the need to remove working code. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 10:18 ` Pretest David Kastrup 2006-11-19 11:44 ` Pretest Nick Roberts @ 2006-11-20 1:37 ` Richard Stallman 2006-11-20 3:00 ` Pretest Stefan Monnier 2006-11-20 9:01 ` Pretest Juanma Barranquero 1 sibling, 2 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-20 1:37 UTC (permalink / raw) Cc: lennart.borgman.073, nickrob, cyd, emacs-devel It seems like we have completely different recollections of events. As far as I remember, Richard oked getting emacsclient to work on Windows even after the first pretest (where emacsclient was not yet a part of Emacs). These changes were installed without properly asking me, and they should not have been. However, later I was told they had been made to work correctly, and decided it was ok to leave them installed. Are there any problems with the _current_ code? If so, what are they? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 1:37 ` Pretest Richard Stallman @ 2006-11-20 3:00 ` Stefan Monnier 2006-11-20 9:01 ` Pretest Juanma Barranquero 1 sibling, 0 replies; 317+ messages in thread From: Stefan Monnier @ 2006-11-20 3:00 UTC (permalink / raw) Cc: lennart.borgman.073, nickrob, cyd, emacs-devel > It seems like we have completely different recollections of events. > As far as I remember, Richard oked getting emacsclient to work on > Windows even after the first pretest (where emacsclient was not yet a > part of Emacs). > These changes were installed without properly asking me, and they > should not have been. However, later I was told they had been made to > work correctly, and decided it was ok to leave them installed. > Are there any problems with the _current_ code? > If so, what are they? No, there is no known problem with the current code. What is being discussed is work on some additional feature which some people would want to include, but I don't think it's ever been decided whether that should be accepted for Emacs-22 or not. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 1:37 ` Pretest Richard Stallman 2006-11-20 3:00 ` Pretest Stefan Monnier @ 2006-11-20 9:01 ` Juanma Barranquero 2006-11-20 9:37 ` Pretest Jason Rumney ` (2 more replies) 1 sibling, 3 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-20 9:01 UTC (permalink / raw) Cc: emacs-devel On 11/20/06, Richard Stallman <rms@gnu.org> wrote: > These changes were installed without properly asking me, and they > should not have been. As I demonstrated in a previous thread, I repeatedly asked on the list. Excuse me for not knowing that some things should be asked by private e-mail. Perhaps you could write down the exact procedures. > Are there any problems with the _current_ code? No. We're talking about extending functionality so emacsclient can totally replace gnuclient/gnuserv. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 9:01 ` Pretest Juanma Barranquero @ 2006-11-20 9:37 ` Jason Rumney 2006-11-20 10:06 ` Pretest Juanma Barranquero 2006-11-20 10:01 ` Pretest David Kastrup 2006-11-20 23:58 ` Pretest Richard Stallman 2 siblings, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-11-20 9:37 UTC (permalink / raw) Cc: rms, emacs-devel Juanma Barranquero wrote: > No. We're talking about extending functionality so emacsclient can > totally replace gnuclient/gnuserv. Can't it do that now, with --alternate-editor and emacsclientw.exe on Windows? The only thing left is fixing the edge case where "emacsclient --alternate-editor emacs" exits immediately, which causes problems for programs that use emacsclient as an external editor. AFAICT gnuclient also has this same problem. IMHO this should wait until after release, because there are significant changes needed, see David Kastrup's most recent posts. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 9:37 ` Pretest Jason Rumney @ 2006-11-20 10:06 ` Juanma Barranquero 2006-11-20 10:50 ` Pretest David Kastrup 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2006-11-20 10:06 UTC (permalink / raw) Cc: emacs-devel On 11/20/06, Jason Rumney <jasonr@gnu.org> wrote: > Can't it do that now, with --alternate-editor and emacsclientw.exe on Windows? Most, except... > The only thing left is fixing the edge case where "emacsclient > --alternate-editor emacs" exits immediately, which causes problems for > programs that use emacsclient as an external editor. ...this. > AFAICT gnuclient also has this same problem. There are quite a few gnuclient versions out there. The one from Lennart's page does not present this problem. > IMHO this should wait until after release, > because there are significant changes needed, see David Kastrup's most > recent posts. In all truth, I took just a cursory look on David's "fix", but it seemed a bit of handwaving to me, particularly (as Stefan as already said) on the "detach" part, which is the biggest difficulty in Lennart's work so far. So: patches welcome. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 10:06 ` Pretest Juanma Barranquero @ 2006-11-20 10:50 ` David Kastrup 2006-11-20 10:58 ` Pretest Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: David Kastrup @ 2006-11-20 10:50 UTC (permalink / raw) Cc: emacs-devel, Jason Rumney "Juanma Barranquero" <lekktu@gmail.com> writes: > On 11/20/06, Jason Rumney <jasonr@gnu.org> wrote: > >> IMHO this should wait until after release, because there are >> significant changes needed, see David Kastrup's most recent posts. > > In all truth, I took just a cursory look on David's "fix", but it > seemed a bit of handwaving to me, particularly (as Stefan as already > said) on the "detach" part, which is the biggest difficulty in > Lennart's work so far. So: patches welcome. Well, the "detach" stuff certainly had a bit of handwaving to it, but I fleshed it out in later posts by proposing an additional "emacsproxy" which would work without "fork" and similar niceties. I do agree that while the approach that I fleshed out seems to me like a more robust and transparent approach to the problem Lennart tries to tackle, either approach would be a feature extension. Lennart's would be easier to sneak in under the "we are in pretest, no new features" reign, but personally I don't feel it is the most robust way to tackle the problem, and it also would require updating manual pages and documentation and stuff. So my personal feeling is that for 22.1, we should bring emacsclient under Windows merely up to what we already have under POSIX systems, and leave the design and testing of further improvements to 23.1, in particular since folding multi-tty support will make emacsclient a whole different game, anyway, since it will then presumably be able to open an editor in the current text tty, too (emacsclient -nw ...). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 10:50 ` Pretest David Kastrup @ 2006-11-20 10:58 ` Juanma Barranquero 2006-11-20 15:30 ` Pretest Stefan Monnier 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2006-11-20 10:58 UTC (permalink / raw) Cc: emacs-devel On 11/20/06, David Kastrup <dak@gnu.org> wrote: > Well, the "detach" stuff certainly had a bit of handwaving to it, but > I fleshed it out in later posts by proposing an additional > "emacsproxy" which would work without "fork" and similar niceties. Yes, you're right. > Lennart's would be easier to sneak in under the "we are in pretest, no > new features" reign, but personally I don't feel it is the most robust > way to tackle the problem FWIW, I agree. That's not to say that Lennart's not done a good job and has put quite a lot of time or thought on it. He has. But I think the fix is not very mature yet. > and it also would require updating manual > pages and documentation and stuff. Documentation still requires updating wrt the TCP stuff. I haven't done it because I'm waiting for the dust to settle regarding this additional matter. > So my personal feeling is that for 22.1, we should bring emacsclient > under Windows merely up to what we already have under POSIX systems, > and leave the design and testing of further improvements to 23.1 Agreed, again. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 10:58 ` Pretest Juanma Barranquero @ 2006-11-20 15:30 ` Stefan Monnier 2006-11-20 16:48 ` Pretest Juanma Barranquero 0 siblings, 1 reply; 317+ messages in thread From: Stefan Monnier @ 2006-11-20 15:30 UTC (permalink / raw) Cc: emacs-devel >> and it also would require updating manual >> pages and documentation and stuff. > Documentation still requires updating wrt the TCP stuff. I haven't > done it because I'm waiting for the dust to settle regarding this > additional matter. Don't wait: the two are unrelated. Stefan ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 15:30 ` Pretest Stefan Monnier @ 2006-11-20 16:48 ` Juanma Barranquero 0 siblings, 0 replies; 317+ messages in thread From: Juanma Barranquero @ 2006-11-20 16:48 UTC (permalink / raw) Cc: emacs-devel On 11/20/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Don't wait: the two are unrelated. Lennart's changes would require adding new command-line options to emacsclient, and I already have to document one (--server-file), so not *totally* unrelated. But I will try to find a bit of time to update the docs. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 9:01 ` Pretest Juanma Barranquero 2006-11-20 9:37 ` Pretest Jason Rumney @ 2006-11-20 10:01 ` David Kastrup 2006-11-20 23:58 ` Pretest Richard Stallman 2 siblings, 0 replies; 317+ messages in thread From: David Kastrup @ 2006-11-20 10:01 UTC (permalink / raw) Cc: rms, emacs-devel "Juanma Barranquero" <lekktu@gmail.com> writes: > On 11/20/06, Richard Stallman <rms@gnu.org> wrote: > >> These changes were installed without properly asking me, and they >> should not have been. > > As I demonstrated in a previous thread, I repeatedly asked on the > list. Excuse me for not knowing that some things should be asked by > private e-mail. Perhaps you could write down the exact procedures. > >> Are there any problems with the _current_ code? > > No. We're talking about extending functionality so emacsclient can > totally replace gnuclient/gnuserv. That is not possible without the multi-tty branch, anyway, since gnuclient, called from a text console, will open a text mode tty in it. emacsserver, in contrast, always lets Emacs open on the console/tty/window where it was started. What we are currently trying to do, if I understand correctly, is rather making emacsclient something which will "do the right thing (TM)" without the need of additional customization, regardless of whether an Emacs session did or did not exist at the point of time when emacsclient is called. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 9:01 ` Pretest Juanma Barranquero 2006-11-20 9:37 ` Pretest Jason Rumney 2006-11-20 10:01 ` Pretest David Kastrup @ 2006-11-20 23:58 ` Richard Stallman 2006-11-21 0:05 ` Pretest Juanma Barranquero 2 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-11-20 23:58 UTC (permalink / raw) Cc: emacs-devel As I demonstrated in a previous thread, I repeatedly asked on the list. But I never said to install it. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-20 23:58 ` Pretest Richard Stallman @ 2006-11-21 0:05 ` Juanma Barranquero 2006-11-22 13:15 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Juanma Barranquero @ 2006-11-21 0:05 UTC (permalink / raw) On 11/21/06, Richard Stallman <rms@gnu.org> wrote: > But I never said to install it. As for most other things installed. /L/e/k/t/u ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-21 0:05 ` Pretest Juanma Barranquero @ 2006-11-22 13:15 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-22 13:15 UTC (permalink / raw) Cc: emacs-devel > But I never said to install it. As for most other things installed. That is often the case for small bug fixes because there is no doubt that fixing the bugs is desirable. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 22:14 Pretest Chong Yidong 2006-11-18 22:58 ` Pretest Lennart Borgman @ 2006-11-19 12:48 ` Richard Stallman 2006-11-19 20:08 ` Pretest Eli Zaretskii 2006-11-19 21:50 ` Pretest Reiner Steib 2006-11-19 19:59 ` Pretest Eli Zaretskii 2 siblings, 2 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-19 12:48 UTC (permalink / raw) Cc: emacs-devel I have updated the emacs-pretesters mailing list and I will now send out a pretest announcement. I think someone suggested using Reply-to to avoid encouraging people to send all their replies to the emacs-pretesters list. That would do the job if someone were doing "reply to sender", but if someone does "reply all" it will still go to the list. Would Mail-followup-to do the job? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 12:48 ` Pretest Richard Stallman @ 2006-11-19 20:08 ` Eli Zaretskii 2006-11-19 21:50 ` Pretest Reiner Steib 1 sibling, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-11-19 20:08 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Sun, 19 Nov 2006 07:48:44 -0500 > Cc: emacs-devel@gnu.org > > I think someone suggested using Reply-to to avoid encouraging people > to send all their replies to the emacs-pretesters list. That would > do the job if someone were doing "reply to sender", but if someone > does "reply all" it will still go to the list. > > Would Mail-followup-to do the job? I guess it depends on the MUA. We could use both these headers, just to be sure. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 12:48 ` Pretest Richard Stallman 2006-11-19 20:08 ` Pretest Eli Zaretskii @ 2006-11-19 21:50 ` Reiner Steib 2006-11-20 12:59 ` Pretest Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Reiner Steib @ 2006-11-19 21:50 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel On Sun, Nov 19 2006, Richard Stallman wrote: > I think someone suggested using Reply-to to avoid encouraging people > to send all their replies to the emacs-pretesters list. That would > do the job if someone were doing "reply to sender", but if someone > does "reply all" it will still go to the list. > > Would Mail-followup-to do the job? Yes, that's the purpose of Mail-Followup-To. But only some MUAs (Gnus, MH-E, mutt, ...) support it. But adding it Mail-Followup-To won't hurt. Additionally I'd suggest to say it in the message body. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-19 21:50 ` Pretest Reiner Steib @ 2006-11-20 12:59 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-20 12:59 UTC (permalink / raw) Cc: cyd, emacs-devel Yes, that's the purpose of Mail-Followup-To. But only some MUAs (Gnus, MH-E, mutt, ...) support it. Alas, that probably means Mail-Followup-To isn't sufficient for this purpose. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-18 22:14 Pretest Chong Yidong 2006-11-18 22:58 ` Pretest Lennart Borgman 2006-11-19 12:48 ` Pretest Richard Stallman @ 2006-11-19 19:59 ` Eli Zaretskii 2 siblings, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-11-19 19:59 UTC (permalink / raw) Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sat, 18 Nov 2006 17:14:48 -0500 > > I've rolled a new pretest tarball, which is available at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz Thanks. This builds okay on Windows XP with the MinGW port of GCC. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest
@ 2006-11-07 20:13 Nick Roberts
2006-11-07 22:48 ` Pretest Miles Bader
0 siblings, 1 reply; 317+ messages in thread
From: Nick Roberts @ 2006-11-07 20:13 UTC (permalink / raw)
Cc: Chong Yidong, Bill Wohler, emacs-devel
> With Richard's agreement, I've bumped the version number to 22.0.90
> and rolled a pretest tarball.
>
>
> Cool, thanks. I don't see a branch, so was it decided to branch closer
> to the release?
>
>
> The time to branch would be just before the emacs-unicode-2 branch is merged
> to the trunk. I'd expect this to happen shortly after the release.
Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the case,
won't emacs-unicode-2 just become the new trunk?
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-07 20:13 Pretest Nick Roberts @ 2006-11-07 22:48 ` Miles Bader 2006-11-08 1:17 ` Pretest Nick Roberts 0 siblings, 1 reply; 317+ messages in thread From: Miles Bader @ 2006-11-07 22:48 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney Nick Roberts <nickrob@snap.net.nz> writes: >> The time to branch would be just before the emacs-unicode-2 branch is merged >> to the trunk. I'd expect this to happen shortly after the release. > > Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the case, > won't emacs-unicode-2 just become the new trunk? That's not how CVS works though, CVS has a distinguished trunk. To make emacs-unicode-2 the trunk we have to merge it to the existing trunk -- of course this should be almost trivial because conflicts are resolved regularly these days. -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-07 22:48 ` Pretest Miles Bader @ 2006-11-08 1:17 ` Nick Roberts 2006-11-08 1:41 ` Pretest Miles Bader 0 siblings, 1 reply; 317+ messages in thread From: Nick Roberts @ 2006-11-08 1:17 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney > > Doesn't the emacs-unicode-2 branch sync with the trunk. If that's the > > case, won't emacs-unicode-2 just become the new trunk? > > That's not how CVS works though, CVS has a distinguished trunk. > To make emacs-unicode-2 the trunk we have to merge it to the existing > trunk -- of course this should be almost trivial because conflicts are > resolved regularly these days. OK, but the merging is already being done on the emacs-unicode-2 branch. Presumably if Bill (Wohler) has a new (untested) version of MH-E, say, for Emacs 23, he could commit it now to emacs-unicode-2 i.e he doesn't need to wait till after the release. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-08 1:17 ` Pretest Nick Roberts @ 2006-11-08 1:41 ` Miles Bader 0 siblings, 0 replies; 317+ messages in thread From: Miles Bader @ 2006-11-08 1:41 UTC (permalink / raw) Cc: Chong Yidong, emacs-devel, Bill Wohler, Jason Rumney Nick Roberts <nickrob@snap.net.nz> writes: > OK, but the merging is already being done on the emacs-unicode-2 > branch. Presumably if Bill (Wohler) has a new (untested) version of > MH-E, say, for Emacs 23, he could commit it now to emacs-unicode-2 i.e > he doesn't need to wait till after the release. He could indeed do that, though I don't think Richard wants people generally to all move over to a branch for their hacking -- the trunk is where the focus should be (and I gather this is one of the reasons for not branching before the release actually happens). I'd also think it would be polite to ask Kenichi before doing any kind of big change on the unicode branch. -Miles -- "Though they may have different meanings, the cries of 'Yeeeee-haw!' and 'Allahu akbar!' are, in spirit, not actually all that different." ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest
@ 2006-10-28 20:33 Mikko Huhtala
0 siblings, 0 replies; 317+ messages in thread
From: Mikko Huhtala @ 2006-10-28 20:33 UTC (permalink / raw)
Chong Yidong schrieb:
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz
>
> Since this is the first Emacs 22 pretest tarball, it would be nice
> if people could take a look and make sure there are no problems
> building from, before we think about making any pretest
> announcement.
Seems to build and work just fine. I'm using gtk2 on the following system:
Fedora Core release 6 (Zod)
Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 i686 i386 GNU/Linux
glibc-2.5-3
gcc-4.1.1-30
gtk2-2.10.4-4.fc6
xorg-x11-server-Xorg-1.1.1-47.fc6
I'm posting this from Emacs 22.0.90 and I used VM 7.19 to read mail,
which seems to work without problems.
Mikko
^ permalink raw reply [flat|nested] 317+ messages in thread
* Pretest @ 2006-10-27 17:59 Chong Yidong 2006-10-27 18:52 ` Pretest Paul Pogonyshev ` (17 more replies) 0 siblings, 18 replies; 317+ messages in thread From: Chong Yidong @ 2006-10-27 17:59 UTC (permalink / raw) With Richard's agreement, I've bumped the version number to 22.0.90 and rolled a pretest tarball. The tarball can be found at ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Since Leim has been merged into Emacs, there is no separate leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect this). Since this is the first Emacs 22 pretest tarball, it would be nice if people could take a look and make sure there are no problems building from, before we think about making any pretest announcement. If no problems are found, I guess we can proceed with the pretest. According to admin/make-tarball, RMS is supposed to announce it to the list of emacs pretesters; here is the canned announcement generated by admin/make-announcement: There is a new pretest available in ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Please report results from compiling and running the pretest to <emacs-pretest-bug@gnu.org>. Your feedback is necessary for us to know on which platforms the pretest has been tried. (I took out some additional info about xdelta's between this tarball and the previous pretest tarball, because there is no previous tarball). The question is, who do we announce the pretest to? Is the emacs pretesters mailing list still extant? If not, I think we should just make a public announcement about the availability of the pretest tarball on the Gnu Emacs webpage. We could also contact distributions such as Debian, which package occasional CVS snapshots of Emacs 22, to switch to tracking the numbered pretest tarballs for those packages instead. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong @ 2006-10-27 18:52 ` Paul Pogonyshev 2006-10-27 19:12 ` Pretest David Hansen ` (16 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Paul Pogonyshev @ 2006-10-27 18:52 UTC (permalink / raw) Chong Yidong wrote: > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. [...] At last! Thanks. Paul ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong 2006-10-27 18:52 ` Pretest Paul Pogonyshev @ 2006-10-27 19:12 ` David Hansen 2006-10-28 11:31 ` Pretest Eli Zaretskii 2006-10-27 19:38 ` Pretest Kim F. Storm ` (15 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: David Hansen @ 2006-10-27 19:12 UTC (permalink / raw) On Fri, 27 Oct 2006 13:59:36 -0400 Chong Yidong wrote: > The question is, who do we announce the pretest to? Is the emacs > pretesters mailing list still extant? If not, I think we should just > make a public announcement about the availability of the pretest > tarball on the Gnu Emacs webpage. As there are already a lot of "normal" users out there who use Emacs 22 for daily work why not gnu.emacs.help? David ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 19:12 ` Pretest David Hansen @ 2006-10-28 11:31 ` Eli Zaretskii 2006-11-15 21:35 ` Pretest Reiner Steib 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 11:31 UTC (permalink / raw) Cc: emacs-devel > From: David Hansen <david.hansen@gmx.net> > Date: Fri, 27 Oct 2006 21:12:03 +0200 > > As there are already a lot of "normal" users out there who use > Emacs 22 for daily work why not gnu.emacs.help? If they already use the CVS code, they don't need the announcement, do they? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 11:31 ` Pretest Eli Zaretskii @ 2006-11-15 21:35 ` Reiner Steib 2006-11-15 22:51 ` Pretest Nick Roberts 0 siblings, 1 reply; 317+ messages in thread From: Reiner Steib @ 2006-11-15 21:35 UTC (permalink / raw) Cc: David Hansen, emacs-devel On Sat, Oct 28 2006, Eli Zaretskii wrote: >> From: David Hansen <david.hansen@gmx.net> >> Date: Fri, 27 Oct 2006 21:12:03 +0200 >> >> As there are already a lot of "normal" users out there who use >> Emacs 22 for daily work why not gnu.emacs.help? > > If they already use the CVS code, they don't need the announcement, do > they? Probably some of them don't update from CVS frequently. The availability of a pretest might encourage those to upgrade to the pretest. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-15 21:35 ` Pretest Reiner Steib @ 2006-11-15 22:51 ` Nick Roberts 0 siblings, 0 replies; 317+ messages in thread From: Nick Roberts @ 2006-11-15 22:51 UTC (permalink / raw) Cc: Eli Zaretskii, David Hansen, emacs-devel Reiner Steib writes: > >> As there are already a lot of "normal" users out there who use > >> Emacs 22 for daily work why not gnu.emacs.help? > > > > If they already use the CVS code, they don't need the announcement, do > > they? > > Probably some of them don't update from CVS frequently. The > availability of a pretest might encourage those to upgrade to the > pretest. Also if there are build problems with the tarball (the main purpose of the pretest tarball?) then they won't be noticed just by using the CVS code. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong 2006-10-27 18:52 ` Pretest Paul Pogonyshev 2006-10-27 19:12 ` Pretest David Hansen @ 2006-10-27 19:38 ` Kim F. Storm 2006-10-28 11:17 ` Pretest Eli Zaretskii 2006-10-27 20:01 ` Pretest joakim ` (14 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: Kim F. Storm @ 2006-10-27 19:38 UTC (permalink / raw) Cc: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Thanks Chong! This is excellent news!!! It builds and runs on my GNU/Linux (redhat 9.0) laptop. > (I took out some additional info about xdelta's between this tarball > and the previous pretest tarball, because there is no previous > tarball). I wonder if we really need to provide xdeltas anymore. For most people there days, the time it takes to get them working (I remember having problems with the last pretest ...) compared to the time it takes to simply download a new tarball doesn't warrent the time needed to make them... > The question is, who do we announce the pretest to? Is the emacs > pretesters mailing list still extant? I think so. > If not, I think we should just > make a public announcement about the availability of the pretest > tarball on the Gnu Emacs webpage. comp.emacs, gnu.announce, and gnu.emacs.announce seem to be good places... > We could also contact distributions > such as Debian, which package occasional CVS snapshots of Emacs 22, to > switch to tracking the numbered pretest tarballs for those packages > instead. I don't know what's best here, but I'd wait until we have have another pretest or the final release. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 19:38 ` Pretest Kim F. Storm @ 2006-10-28 11:17 ` Eli Zaretskii 2006-10-29 18:45 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 11:17 UTC (permalink / raw) Cc: cyd, emacs-devel > From: storm@cua.dk (Kim F. Storm) > Date: Fri, 27 Oct 2006 21:38:01 +0200 > Cc: emacs-devel@gnu.org > > I wonder if we really need to provide xdeltas anymore. Why not? The Emacs tarball is significantly larger now than in previous versions (because Calc, Leim, ELisp, and Lisp Intro are now parts of it), so downloading a full tarball might be a pain. > For most people there days, the time it takes to get them working (I > remember having problems with the last pretest ...) compared to the > time it takes to simply download a new tarball doesn't warrent the > time needed to make them... If you have a fast connection, yes. But not everyone has it. > > If not, I think we should just > > make a public announcement about the availability of the pretest > > tarball on the Gnu Emacs webpage. > > comp.emacs, gnu.announce, and gnu.emacs.announce seem to be good places... We never published pretests on those fori, only the official releases. Why should we change the policy now, that everyone who is interested can read emacs-devel anyway? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 11:17 ` Pretest Eli Zaretskii @ 2006-10-29 18:45 ` Richard Stallman 2006-10-29 20:20 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-10-29 18:45 UTC (permalink / raw) Cc: cyd, emacs-devel, storm It makes no sense to post a delta for the first pretest, because that would be almost as big as the sources. However, we should post deltas for subsequent pretests from the first pretest. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 18:45 ` Pretest Richard Stallman @ 2006-10-29 20:20 ` Eli Zaretskii 0 siblings, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-10-29 20:20 UTC (permalink / raw) Cc: cyd, emacs-devel, storm > From: Richard Stallman <rms@gnu.org> > CC: storm@cua.dk, cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Sun, 29 Oct 2006 13:45:56 -0500 > > It makes no sense to post a delta for the first pretest, > because that would be almost as big as the sources. > However, we should post deltas for subsequent pretests > from the first pretest. I agree. I never meant to suggest that we make an xdelta for the first pretest, sorry if that wasn't clear. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (2 preceding siblings ...) 2006-10-27 19:38 ` Pretest Kim F. Storm @ 2006-10-27 20:01 ` joakim 2006-10-27 21:11 ` Pretest Giorgos Keramidas ` (13 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: joakim @ 2006-10-27 20:01 UTC (permalink / raw) Chong Yidong <cyd@stupidchicken.com> writes: builds and runs ok on the following plattform: Linux kurono.home 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:06 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz > > Since Leim has been merged into Emacs, there is no separate > leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect > this). > > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. > > > If no problems are found, I guess we can proceed with the pretest. > According to admin/make-tarball, RMS is supposed to announce it to the > list of emacs pretesters; here is the canned announcement generated by > admin/make-announcement: > > There is a new pretest available in > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz > > Please report results from compiling and running the pretest to > <emacs-pretest-bug@gnu.org>. Your feedback is necessary for us > to know on which platforms the pretest has been tried. > > (I took out some additional info about xdelta's between this tarball > and the previous pretest tarball, because there is no previous > tarball). > > > The question is, who do we announce the pretest to? Is the emacs > pretesters mailing list still extant? If not, I think we should just > make a public announcement about the availability of the pretest > tarball on the Gnu Emacs webpage. We could also contact distributions > such as Debian, which package occasional CVS snapshots of Emacs 22, to > switch to tracking the numbered pretest tarballs for those packages > instead. -- Joakim Verona http://www.verona.se ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (3 preceding siblings ...) 2006-10-27 20:01 ` Pretest joakim @ 2006-10-27 21:11 ` Giorgos Keramidas 2006-10-28 2:30 ` Pretest Andrew M. Scott ` (12 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Giorgos Keramidas @ 2006-10-27 21:11 UTC (permalink / raw) Cc: emacs-devel On 2006-10-27 13:59, Chong Yidong <cyd@stupidchicken.com> wrote: > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz > > Since Leim has been merged into Emacs, there is no separate > leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect > this). > > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. Compiled successfully, installed and running fine as my editor for this message and as another, X11 instance (with Lucid widgets) on: $ uname -a FreeBSD gothmog.pc 7.0-CURRENT FreeBSD 7.0-CURRENT #1: \ Mon Oct 23 13:35:35 EEST 2006 \ build@gothmog.pc:/home/build/obj/home/build/src/sys/GOTHMOG i386 $ I haven't tried a GTK+-enabled build yet. It should be easy to do this early tomorrow morning too. Thanks again, to all the people who brought this Emacs version to us :) - Giorgos ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (4 preceding siblings ...) 2006-10-27 21:11 ` Pretest Giorgos Keramidas @ 2006-10-28 2:30 ` Andrew M. Scott 2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell ` (11 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Andrew M. Scott @ 2006-10-28 2:30 UTC (permalink / raw) Thanks! Chong> With Richard's agreement, I've bumped the version number to Chong> 22.0.90 and rolled a pretest tarball. The tarball can be Chong> found at Chong> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Chong> Since this is the first Emacs 22 pretest tarball, it would Chong> be nice if people could take a look and make sure there are Chong> no problems building from, before we think about making any Chong> pretest announcement. It builds fine for me: In GNU Emacs 22.0.90.1 (x86_64-unknown-linux-gnu, X toolkit) of 2006-10-27 on chlr6708 SUSE LINUX Enterprise Server 9 (x86_64) VERSION = 9 PATCHLEVEL = 3 FYI, I had to recompile the ancillary package emacs-w3m and its associated APEL and FLIM libraries due to the the emacs numerical incremention, e.g.: Old: <installation path>/share/emacs/22.0.50/site-lisp/emu/ New: <installation path>/share/emacs/22.0.90/site-lisp/emu/ Andy Scott ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (5 preceding siblings ...) 2006-10-28 2:30 ` Pretest Andrew M. Scott @ 2006-10-28 8:11 ` Yoni Rabkin Katzenell 2006-10-28 8:46 ` Pretest Andreas Roehler ` (10 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Yoni Rabkin Katzenell @ 2006-10-28 8:11 UTC (permalink / raw) Chong Yidong <cyd@stupidchicken.com> writes: > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. Compiles and seems to be working: GNU Emacs 22.0.90.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux Linux 2.6.17-10-386 #2 Fri Oct 13 18:41:40 UTC 2006 i686 GNU/Linux -- "Cut your own wood and it will warm you twice" ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (6 preceding siblings ...) 2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell @ 2006-10-28 8:46 ` Andreas Roehler 2006-10-28 11:01 ` Pretest Jason Rumney ` (9 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Andreas Roehler @ 2006-10-28 8:46 UTC (permalink / raw) Cc: emacs-devel Thanks a lot. Everything seems fine at SuSE linux 10.0 GNU Emacs 22.0.90.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) BTW: emacs-w3m runs out of the box. __ Andreas Roehler Chong Yidong schrieb: > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz > > Since Leim has been merged into Emacs, there is no separate > leim-22.0.90.tar.gz (I'll update admin/make-announcement to reflect > this). > > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. > > > If no problems are found, I guess we can proceed with the pretest. > According to admin/make-tarball, RMS is supposed to announce it to the > list of emacs pretesters; here is the canned announcement generated by > admin/make-announcement: > > There is a new pretest available in > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz > > Please report results from compiling and running the pretest to > <emacs-pretest-bug@gnu.org>. Your feedback is necessary for us > to know on which platforms the pretest has been tried. > > (I took out some additional info about xdelta's between this tarball > and the previous pretest tarball, because there is no previous > tarball). > > > The question is, who do we announce the pretest to? Is the emacs > pretesters mailing list still extant? If not, I think we should just > make a public announcement about the availability of the pretest > tarball on the Gnu Emacs webpage. We could also contact distributions > such as Debian, which package occasional CVS snapshots of Emacs 22, to > switch to tracking the numbered pretest tarballs for those packages > instead. > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel > > ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (7 preceding siblings ...) 2006-10-28 8:46 ` Pretest Andreas Roehler @ 2006-10-28 11:01 ` Jason Rumney 2006-10-28 13:14 ` Pretest Eli Zaretskii 2006-10-28 11:13 ` Pretest Eli Zaretskii ` (8 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-10-28 11:01 UTC (permalink / raw) Cc: emacs-devel On a fresh install with w32, I got the following error: gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c -gstabs+ -g3 -mtune=pentium4 -O2 -Di386 -D_CRTAPI1=_cdecl -DWINDOWSNT -DDOS_NT -DSTDC_HEADERS=1 -DNO_LDAV=1 -DNO_ARCHIVES=1 -DHAVE_CONFIG_H=1 -I../nt/inc -I../src -o oo-spd/i386/digest-doc.o digest-doc.c gcc -o oo-spd/i386/digest-doc.exe -gstabs+ -g3 oo-spd/i386/digest-doc.o -ladvapi32 mingw32-make[1]: *** No rule to make target `../src/oo-spd/i386/temacs.exe', needed by `DOC'. Stop. mingw32-make[1]: Leaving directory `C:/emacs-22.0.90/lib-src' mingw32-make: *** [all-other-dirs-gmake] Error 2 I'll look into it, and see if it is a configuration problem with this PC, or a problem with the makefiles that has gone undetected. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 11:01 ` Pretest Jason Rumney @ 2006-10-28 13:14 ` Eli Zaretskii 2006-10-28 21:47 ` Pretest Jason Rumney 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 13:14 UTC (permalink / raw) Cc: cyd, emacs-devel > Date: Sat, 28 Oct 2006 12:01:50 +0100 > From: Jason Rumney <jasonr@gnu.org> > Cc: emacs-devel@gnu.org > > On a fresh install with w32, I got the following error: > > > gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c > -gstabs+ -g3 -mtune=pentium4 -O2 -Di386 -D_CRTAPI1=_cdecl > -DWINDOWSNT -DDOS_NT -DSTDC_HEADERS=1 -DNO_LDAV=1 -DNO_ARCHIVES=1 > -DHAVE_CONFIG_H=1 -I../nt/inc -I../src -o oo-spd/i386/digest-doc.o > digest-doc.c > gcc -o oo-spd/i386/digest-doc.exe -gstabs+ -g3 > oo-spd/i386/digest-doc.o -ladvapi32 > mingw32-make[1]: *** No rule to make target > `../src/oo-spd/i386/temacs.exe', needed by `DOC'. Stop. > mingw32-make[1]: Leaving directory `C:/emacs-22.0.90/lib-src' > mingw32-make: *** [all-other-dirs-gmake] Error 2 > > > I'll look into it, and see if it is a configuration problem with this > PC, or a problem with the makefiles that has gone undetected. It's a real bug, it happens the first time a source tree is compiled. Please try the patch below. I will check it in if there are no objections. diff -u "emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in~" "emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in" --- emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in~ 2006-10-10 21:01:30.000000000 +0200 +++ emacs-pretest/emacs-22.0.90/lib-src/makefile.w32-in 2006-10-28 15:08:33.420500000 +0200 @@ -263,6 +263,13 @@ $(lispsource)window.elc \ $(lispsource)version.el +# This is needed the first time we build the tree, since temacs.exe +# does not exist yet, and the DOC rule needs it to rebuild DOC whenever +# Emacs is rebuilt. +../src/$(BLD)/temacs.exe: + - mkdir "../src/$(OBJDIR)" + - mkdir "../src/$(BLD)" + @echo temacs > $@ DOC = DOC $(DOC): $(BLD) $(BLD)/make-docfile.exe ../src/$(BLD)/temacs.exe $(lisp1) $(lisp2) Diff finished. Sat Oct 28 15:11:59 2006 ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 13:14 ` Pretest Eli Zaretskii @ 2006-10-28 21:47 ` Jason Rumney 2006-10-29 4:30 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-10-28 21:47 UTC (permalink / raw) Cc: cyd, emacs-devel Eli Zaretskii wrote: > It's a real bug, it happens the first time a source tree is compiled. > > Please try the patch below. I will check it in if there are no > objections. > This fixes the problem for me. But if temacs.exe is not needed to produce the DOC file, why do we depend on it in the first place? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 21:47 ` Pretest Jason Rumney @ 2006-10-29 4:30 ` Eli Zaretskii 2006-10-29 11:17 ` Pretest Jason Rumney 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-29 4:30 UTC (permalink / raw) Cc: cyd, emacs-devel > Date: Sat, 28 Oct 2006 22:47:11 +0100 > From: Jason Rumney <jasonr@gnu.org> > Cc: cyd@stupidchicken.com, emacs-devel@gnu.org > > This fixes the problem for me. Do you have some sh.exe on your PATH, or did you use CMD? I think my patch would not work with CMD, due to forward slashes in the redirection. I think I'd replace that with some cp command. > But if temacs.exe is not needed to produce the DOC file, why do we > depend on it in the first place? So that, whenever temacs.exe is rebuilt (meaning that some C file has changed), DOC is regenerated by "make install". ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 4:30 ` Pretest Eli Zaretskii @ 2006-10-29 11:17 ` Jason Rumney 2006-10-29 11:47 ` Pretest Eli Zaretskii 2006-11-04 12:15 ` Pretest Eli Zaretskii 0 siblings, 2 replies; 317+ messages in thread From: Jason Rumney @ 2006-10-29 11:17 UTC (permalink / raw) Cc: cyd, emacs-devel Eli Zaretskii wrote: > Do you have some sh.exe on your PATH, or did you use CMD? I think my > patch would not work with CMD, due to forward slashes in the > redirection. I think I'd replace that with some cp command. > There is no sh.exe in my path, so I think it would have used cmd.exe. Perhaps mingw32-make converted the path before passing to cmd.exe? But cp would be safer. >> But if temacs.exe is not needed to produce the DOC file, why do we >> depend on it in the first place? >> > > So that, whenever temacs.exe is rebuilt (meaning that some C file has > changed), DOC is regenerated by "make install". > Then wouldn't it be better to build DOC after temacs? Otherwise we lag behind by one build, since temacs does not get modified until after the DOC file is generated. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 11:17 ` Pretest Jason Rumney @ 2006-10-29 11:47 ` Eli Zaretskii 2006-10-30 13:33 ` Pretest Richard Stallman 2006-11-04 12:15 ` Pretest Eli Zaretskii 1 sibling, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-29 11:47 UTC (permalink / raw) Cc: cyd, emacs-devel > Date: Sun, 29 Oct 2006 11:17:05 +0000 > From: Jason Rumney <jasonr@gnu.org> > Cc: cyd@stupidchicken.com, emacs-devel@gnu.org > > > > So that, whenever temacs.exe is rebuilt (meaning that some C file has > > changed), DOC is regenerated by "make install". > > > Then wouldn't it be better to build DOC after temacs? Yes (that's what the Unix build does), but I'm reluctant to do that now, since it would be a major change in the Windows build procedure. > Otherwise we lag behind by one build, since temacs does not get > modified until after the DOC file is generated. Why does it have to be modified? What kind of information about DOC is recorded in temacs? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 11:47 ` Pretest Eli Zaretskii @ 2006-10-30 13:33 ` Richard Stallman 2006-10-30 21:12 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-10-30 13:33 UTC (permalink / raw) Cc: cyd, emacs-devel, jasonr Yes (that's what the Unix build does), but I'm reluctant to do that now, since it would be a major change in the Windows build procedure. I don't know the Windows build code, but I'd expect this to be a fairly small change. And since it only has to run on one system, once it is working for one of you, there's not a big chance it will fail elsewhere. Anyway, keeping things similar from system to system tends to be cleaner. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 13:33 ` Pretest Richard Stallman @ 2006-10-30 21:12 ` Eli Zaretskii 2006-11-01 2:12 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-30 21:12 UTC (permalink / raw) Cc: cyd, emacs-devel, jasonr > From: Richard Stallman <rms@gnu.org> > CC: jasonr@gnu.org, cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Mon, 30 Oct 2006 08:33:15 -0500 > > I don't know the Windows build code, but I'd expect this to be a > fairly small change. And since it only has to run on one system, once > it is working for one of you, there's not a big chance it will fail > elsewhere. It is not a small change. It requires to move portions of lib-src/makefile.w32-in to src/makefile.w32-in, and then making corresponding changes in nt/makefile.w32-in. The moved portions should work both for normal build and for bootstrap. The Windows build is generally quite fragile, since it needs to support a variety of Windows versions and shells, both stock Windows shells (some of which are very stupid) and ported Unix shells, and also a variety of ports of cp, mv, etc. Some Windows versions are not in use by the Emacs developers, so we have no good way of testing such non-trivial changes. That is why I think we can live with the few minor problems until after the release. > Anyway, keeping things similar from system to system tends to be cleaner. I agree. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 21:12 ` Pretest Eli Zaretskii @ 2006-11-01 2:12 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw) Cc: cyd, emacs-devel, jasonr It is not a small change. It requires to move portions of lib-src/makefile.w32-in to src/makefile.w32-in, and then making corresponding changes in nt/makefile.w32-in. The moved portions should work both for normal build and for bootstrap. In that case, I trust your judgment that we shouldn't do this now. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 11:17 ` Pretest Jason Rumney 2006-10-29 11:47 ` Pretest Eli Zaretskii @ 2006-11-04 12:15 ` Eli Zaretskii 2006-11-04 22:23 ` Pretest Jason Rumney 1 sibling, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-11-04 12:15 UTC (permalink / raw) Cc: emacs-devel > Date: Sun, 29 Oct 2006 11:17:05 +0000 > From: Jason Rumney <jasonr@gnu.org> > Cc: cyd@stupidchicken.com, emacs-devel@gnu.org > > Eli Zaretskii wrote: > > Do you have some sh.exe on your PATH, or did you use CMD? I think my > > patch would not work with CMD, due to forward slashes in the > > redirection. I think I'd replace that with some cp command. > > > There is no sh.exe in my path, so I think it would have used cmd.exe. > Perhaps mingw32-make converted the path before passing to cmd.exe? It turns out that cmd.exe does grok redirection with forward slashes. But command.com from Windows 9x won't. > But cp would be safer. I committed a change to use cp. > >> But if temacs.exe is not needed to produce the DOC file, why do we > >> depend on it in the first place? > >> > > > > So that, whenever temacs.exe is rebuilt (meaning that some C file has > > changed), DOC is regenerated by "make install". > > > Then wouldn't it be better to build DOC after temacs? Otherwise we lag > behind by one build, since temacs does not get modified until after the > DOC file is generated. I asked why does temacs need to be modified when DOC is changed. Do you know whether there's any need for that, and why? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-04 12:15 ` Pretest Eli Zaretskii @ 2006-11-04 22:23 ` Jason Rumney 2006-11-05 6:15 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Jason Rumney @ 2006-11-04 22:23 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: > I asked why does temacs need to be modified when DOC is changed. Do > you know whether there's any need for that, and why? > Isn't it the other way around? When temacs is changed, DOC needs to be rebuilt? The correct fix would seem to be to move building the DOC file from lib-src/Makefile.w32-in to src/Makefile.w32-in like it is in the main build, and build it after temacs.exe but before emacs.exe is dumped. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-04 22:23 ` Pretest Jason Rumney @ 2006-11-05 6:15 ` Eli Zaretskii 2006-11-05 12:39 ` Pretest Jason Rumney 2006-11-05 12:41 ` Pretest Jason Rumney 0 siblings, 2 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-11-05 6:15 UTC (permalink / raw) Cc: emacs-devel > Date: Sat, 04 Nov 2006 22:23:52 +0000 > From: Jason Rumney <jasonr@gnu.org> > Cc: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > I asked why does temacs need to be modified when DOC is changed. Do > > you know whether there's any need for that, and why? > > Isn't it the other way around? When temacs is changed, DOC needs to be > rebuilt? That we already do: this is why DOC depends on temacs.exe. Once temacs.exe is rebuilt, "make install" will rebuild DOC. But you seemed to say that this arrangement causes us to lag one step, and I don't understand why. > The correct fix would seem to be to move building the DOC file from > lib-src/Makefile.w32-in to src/Makefile.w32-in like it is in the main > build, and build it after temacs.exe but before emacs.exe is dumped. Yes, but that's a non-trivial change that I'd rather not do before the release, especially since there's no actual problem we need to solve. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-05 6:15 ` Pretest Eli Zaretskii @ 2006-11-05 12:39 ` Jason Rumney 2006-11-05 12:41 ` Pretest Jason Rumney 1 sibling, 0 replies; 317+ messages in thread From: Jason Rumney @ 2006-11-05 12:39 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: > That we already do: this is why DOC depends on temacs.exe. Once > temacs.exe is rebuilt, "make install" will rebuild DOC. > > But you seemed to say that this arrangement causes us to lag one step, > and I don't understand why. > It lags behind in the case where the user does not "make install" after every make. I'm not arguing with your desire to hold off on making any changes until after the release though. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-05 6:15 ` Pretest Eli Zaretskii 2006-11-05 12:39 ` Pretest Jason Rumney @ 2006-11-05 12:41 ` Jason Rumney 1 sibling, 0 replies; 317+ messages in thread From: Jason Rumney @ 2006-11-05 12:41 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii wrote: > That we already do: this is why DOC depends on temacs.exe. Once > temacs.exe is rebuilt, "make install" will rebuild DOC. > > But you seemed to say that this arrangement causes us to lag one step, > and I don't understand why. > It lags behind in the case where the user does not "make install" after every make. I'm not arguing with your desire to hold off on making any changes until after the release though. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (8 preceding siblings ...) 2006-10-28 11:01 ` Pretest Jason Rumney @ 2006-10-28 11:13 ` Eli Zaretskii 2006-10-28 13:30 ` Pretest Benjamin Riefenstahl ` (7 subsequent siblings) 17 siblings, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 11:13 UTC (permalink / raw) Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Fri, 27 Oct 2006 13:59:36 -0400 > > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Thanks! Downloading it as we speak. > The question is, who do we announce the pretest to? To the Emacs pretesters. > Is the emacs pretesters mailing list still extant? Yes. I think the announcement should also go to emacs-devel. > If not, I think we should just make a public announcement about the > availability of the pretest tarball on the Gnu Emacs webpage. We > could also contact distributions such as Debian, which package > occasional CVS snapshots of Emacs 22, to switch to tracking the > numbered pretest tarballs for those packages instead. These should all be tracking emacs-devel and emacs-pretest-bug anyway, if they want to be up-to-date with Emacs development and known bugs. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (9 preceding siblings ...) 2006-10-28 11:13 ` Pretest Eli Zaretskii @ 2006-10-28 13:30 ` Benjamin Riefenstahl 2006-10-28 15:25 ` Pretest Chong Yidong 2006-10-28 13:38 ` Pretest Eli Zaretskii ` (6 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: Benjamin Riefenstahl @ 2006-10-28 13:30 UTC (permalink / raw) Cc: emacs-devel Hi, Chong Yidong writes: > I've bumped the version number to 22.0.90 and rolled a pretest > tarball. Cool. > it would be nice if people could take a look and make sure there are > no problems building from, Building on Mac OS X (10.3), "make" fails with (last lines only): Writing LC_UNIXTHREAD command 26524 unused bytes follow Mach-O header 1099612 pure bytes used ./emacs -q -batch -f list-load-path-shadows make[1]: *** No rule to make target `/Users/benny/Projects/emacs-22.0.90/src/../mac/Emacs.app/Contents/Resources/Emacs.icns', needed by `macosx-bundle'. Stop. make: *** [src] Error 2 It seems that mac/Emacs.app/Contents/Resources/Emacs.icns is missing. After I copy the file from a CVS checkout, "make" proceeds and the result of "make install" seems to work fine. benny ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 13:30 ` Pretest Benjamin Riefenstahl @ 2006-10-28 15:25 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2006-10-28 15:25 UTC (permalink / raw) Cc: emacs-devel Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> writes: > Hi, > > > Chong Yidong writes: >> I've bumped the version number to 22.0.90 and rolled a pretest >> tarball. > > Cool. > >> it would be nice if people could take a look and make sure there are >> no problems building from, > > Building on Mac OS X (10.3), "make" fails with (last lines only): > > Writing LC_UNIXTHREAD command > 26524 unused bytes follow Mach-O header > 1099612 pure bytes used > ./emacs -q -batch -f list-load-path-shadows > make[1]: *** No rule to make target `/Users/benny/Projects/emacs-22.0.90/src/../mac/Emacs.app/Contents/Resources/Emacs.icns', needed by `macosx-bundle'. Stop. > make: *** [src] Error 2 > > It seems that mac/Emacs.app/Contents/Resources/Emacs.icns is missing. > > After I copy the file from a CVS checkout, "make" proceeds and the > result of "make install" seems to work fine. Yamamoto Mitsuharu has fixed this bug, and the files required to compile on Macs should be included in the next pretest tarball. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (10 preceding siblings ...) 2006-10-28 13:30 ` Pretest Benjamin Riefenstahl @ 2006-10-28 13:38 ` Eli Zaretskii 2006-10-28 15:53 ` Pretest Chong Yidong 2006-10-28 14:28 ` Pretest Eli Zaretskii ` (5 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 13:38 UTC (permalink / raw) Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Fri, 27 Oct 2006 13:59:36 -0400 > > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. With the exception of the single bug reported by Jason (to which I posted a suggested solution), this pretest builds on Windows XP and identifies itself as follows: GNU Emacs 22.0.90.1 (i386-mingw-nt5.1.2600) of 2006-10-28 I found two (possibly related) problems in the Info files included in this pretest: . The first line of some of the Info file cites its full absolute file name on your machine, like this: This is /home/cyd/emacs/lispintro/../info/eintr, produced by makeinfo version 4.8 from /home/cyd/emacs/lispintro/emacs-lisp-intro.texi. I'm sure you didn't want to publish the directory tree of your machine ;-) I don't know how this happened, especially since some of the files have the correct text: This is ../info/emacs, produced by makeinfo version 4.8 from emacs.texi. . The file info/emacs-xtra was produced incorrectly: it includes all the stuff that should only be in the printed version, and is therefore conditioned by @iftex. I have no other clue to this mystery except that the fact that it was somehow produced by a different version of Makeinfo: This is ../info/emacs-xtra, produced by makeinfo version 4.7 from emacs-xtra.texi. (A few other files are built by makeinfo 4.7 as well.) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 13:38 ` Pretest Eli Zaretskii @ 2006-10-28 15:53 ` Chong Yidong 2006-10-28 19:05 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-28 15:53 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > . The first line of some of the Info file cites its full absolute > file name on your machine, like this: > > This is /home/cyd/emacs/lispintro/../info/eintr, produced by makeinfo > version 4.8 from /home/cyd/emacs/lispintro/emacs-lisp-intro.texi. > > I don't know how this happened, especially since some of the files > have the correct text: > > This is ../info/emacs, produced by makeinfo version 4.8 from emacs.texi. Good catch. This seems to be due to a difference in the man and lispref/lispintro Makefiles. The way man does it is INFO_TARGETS = ../info/emacs ../info/ccmode ....[etc] info: $(top_srcdir)/info $(INFO_TARGETS) ../info/emacs: ${EMACSSOURCES} cd $(srcdir); $(MAKEINFO) emacs.texi whereas lispref does it like this: srcs = $(srcdir)/abbrevs.texi ....[etc] info: $(infodir)/elisp $(infodir)/elisp: $(srcs) $(MAKEINFO) -I. -I$(srcdir) $(srcdir)/elisp.texi -o $(infodir)/elisp By analogy, this last line should be replaced by cd $(srcdir); $(MAKEINFO) elisp.texi > . The file info/emacs-xtra was produced incorrectly: it includes all > the stuff that should only be in the printed version, and is > therefore conditioned by @iftex. I have no other clue to this > mystery except that the fact that it was somehow produced by a > different version of Makeinfo: > > This is ../info/emacs-xtra, produced by makeinfo version 4.7 from > emacs-xtra.texi. > > (A few other files are built by makeinfo 4.7 as well.) There were probably stale info files in my CVS info directory. I just cleaned it out; this problem should go away in the next pretest tarball. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 15:53 ` Pretest Chong Yidong @ 2006-10-28 19:05 ` Eli Zaretskii 2006-10-29 21:36 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 19:05 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sat, 28 Oct 2006 11:53:29 -0400 > > Good catch. This seems to be due to a difference in the man and > lispref/lispintro Makefiles. The way man does it is > > INFO_TARGETS = ../info/emacs ../info/ccmode ....[etc] > > info: $(top_srcdir)/info $(INFO_TARGETS) > > ../info/emacs: ${EMACSSOURCES} > cd $(srcdir); $(MAKEINFO) emacs.texi > > whereas lispref does it like this: > > srcs = $(srcdir)/abbrevs.texi ....[etc] > > info: $(infodir)/elisp > > $(infodir)/elisp: $(srcs) > $(MAKEINFO) -I. -I$(srcdir) $(srcdir)/elisp.texi -o $(infodir)/elisp > > By analogy, this last line should be replaced by > > cd $(srcdir); $(MAKEINFO) elisp.texi I have no objections to such a change, but note that $(MAKEINFO) doesn't include the -I switches in lispref/Makefile.in, so if we want to make such a change, we should probably add them to the macro. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 19:05 ` Pretest Eli Zaretskii @ 2006-10-29 21:36 ` Chong Yidong 2006-10-30 4:25 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-29 21:36 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> By analogy, this last line should be replaced by >> >> cd $(srcdir); $(MAKEINFO) elisp.texi > > I have no objections to such a change, but note that $(MAKEINFO) > doesn't include the -I switches in lispref/Makefile.in, so if we want > to make such a change, we should probably add them to the macro. I've checked such a change. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 21:36 ` Pretest Chong Yidong @ 2006-10-30 4:25 ` Eli Zaretskii 2006-10-30 14:21 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-30 4:25 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sun, 29 Oct 2006 16:36:41 -0500 > > >> cd $(srcdir); $(MAKEINFO) elisp.texi > > > > I have no objections to such a change, but note that $(MAKEINFO) > > doesn't include the -I switches in lispref/Makefile.in, so if we want > > to make such a change, we should probably add them to the macro. > > I've checked such a change. Yes, but you also changed makefile.w32-in, which breaks the Windows build because the stock Windows shell doesn't support the `cmd1; cmd2' method of having several commands on the same line. Please revert that; the Windows build doesn't need that change, since it sets srcdir to . anyway. Btw, while looking at this, I found that several directories in the tarball lack the makefile.w32-in file. These are: man, lispref, and lispintro. Please modify make-dist to include them. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 4:25 ` Pretest Eli Zaretskii @ 2006-10-30 14:21 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2006-10-30 14:21 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> I've checked such a change. > > Yes, but you also changed makefile.w32-in, which breaks the Windows > build because the stock Windows shell doesn't support the `cmd1; cmd2' > method of having several commands on the same line. Please revert > that; the Windows build doesn't need that change, since it sets srcdir > to . anyway. OK done; sorry for the inconvenience. > Btw, while looking at this, I found that several directories in the > tarball lack the makefile.w32-in file. These are: man, lispref, and > lispintro. Please modify make-dist to include them. Done. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (11 preceding siblings ...) 2006-10-28 13:38 ` Pretest Eli Zaretskii @ 2006-10-28 14:28 ` Eli Zaretskii 2006-10-28 15:01 ` Pretest Chong Yidong [not found] ` <cyd@stupidchicken.com> ` (4 subsequent siblings) 17 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 14:28 UTC (permalink / raw) > From: Chong Yidong <cyd@stupidchicken.com> > Date: Fri, 27 Oct 2006 13:59:36 -0400 > > Since this is the first Emacs 22 pretest tarball, it would be nice if > people could take a look and make sure there are no problems building > from, before we think about making any pretest announcement. On this system: Linux fencepost 2.6.12-fencepost #1 SMP Wed Jul 19 10:55:11 EDT 2006 i686 GNU/Linux I cannot build the pretest: it fails while linking temacs. Here's the last portion of the build transcript: gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 terminfo.c gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 lastfile.c gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 vm-limit.c gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 mktime.c gcc -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src -D_BSD_SOURCE -g -O2 -Wl,-znocombreloc /home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src/prefix-args.c -o prefix-args echo "dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o vm-limit.o mktime.o " > buildobj.lst gcc -nostdlib `./prefix-args -Xlinker -z nocombreloc` -Wl,-znocombreloc -o temacs pre-crt0.o /usr/lib/crt1.o /usr/lib/crti.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o vm-limit.o mktime.o -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtn.o collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make[1]: Leaving directory `/home/e/eliz/emacs.cvs/pretest/emacs-22.0.90/src' make: *** [src] Error 2 It seems ld fails with no message to explain the failure. I tried to add various verbosity switches, like -t and --verbose, to LDFLAGS, but couldn't see anything that'd explain the problem. Does anyone know how to get ld to tell more? This machine uses GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2.1) and ld version 2.15. Interestingly, the same machine builds the CVS version just fine (and has been doing that for a very long time). FWIW, here are the results of configure (the fact that it doesn't find X headers and libraries is expected, due to the way this machine is configured): Configured for `i686-pc-linux-gnu'. Where should the build process find the source code? /home/e/eliz/emacs.cvs /pretest/emacs-22.0.90 What operating system and machine description files should Emacs use? `s/gnu-linux.h' and `m/intel386.h' What compiler should emacs be built with? gcc -g -O2 Should Emacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should Emacs use a relocating allocator for buffers? yes Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use? none What toolkit should Emacs use? none Where do we find X Windows header files? NONE Where do we find X Windows libraries? NONE Does Emacs use -lXaw3d? no Does Emacs use -lXpm? no Does Emacs use -ljpeg? no Does Emacs use -ltiff? no Does Emacs use -lungif? no Does Emacs use -lpng? no Does Emacs use X toolkit scroll bars? no ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 14:28 ` Pretest Eli Zaretskii @ 2006-10-28 15:01 ` Chong Yidong 2006-10-28 19:28 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-28 15:01 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Chong Yidong <cyd@stupidchicken.com> >> Date: Fri, 27 Oct 2006 13:59:36 -0400 >> >> Since this is the first Emacs 22 pretest tarball, it would be nice if >> people could take a look and make sure there are no problems building >> from, before we think about making any pretest announcement. > > On this system: > > Linux fencepost 2.6.12-fencepost #1 SMP Wed Jul 19 10:55:11 EDT > 2006 i686 GNU/Linux > > I cannot build the pretest: it fails while linking temacs. > > Interestingly, the same machine builds the CVS version just fine (and > has been doing that for a very long time). That's pretty strange. If you generate a tarball from CVS yourself, using emacs/make-dist, does that tarball fail to build? Try also deleting configure and doing `make bootstrap' to generate a new configure file (in case there's some bug in the version of autoconf I'm using). Does it work in that case? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 15:01 ` Pretest Chong Yidong @ 2006-10-28 19:28 ` Eli Zaretskii 2006-10-28 20:47 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 19:28 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sat, 28 Oct 2006 11:01:08 -0400 > > > > I cannot build the pretest: it fails while linking temacs. > > > > Interestingly, the same machine builds the CVS version just fine (and > > has been doing that for a very long time). > > > That's pretty strange. If you generate a tarball from CVS yourself, > using emacs/make-dist, does that tarball fail to build? > > Try also deleting configure and doing `make bootstrap' to generate a > new configure file (in case there's some bug in the version of > autoconf I'm using). Does it work in that case? The latter method worked. The version of Autoconf installed on fencepost is 2.59. I see that the one you used also identifies itself as 2.59, but they produce a different configure script(!); the diffs are attached below. Do you see anything in the diffs that could explain the failure? I don't. (The file src/config.in produced by autoheader is identical to what you included in the tarball, so config.h is not the culprit. The produced src/Makefile files are also identical.) I'd still like to understand what failed `ld'. --- bad/emacs-22.0.90/configure 2006-10-27 11:17:48.000000000 -0400 +++ good/emacs-22.0.90/configure 2006-10-28 15:06:50.000000000 -0400 @@ -988,7 +988,7 @@ else echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2 fi - cd "$ac_popdir" + cd $ac_popdir done fi @@ -3283,7 +3283,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3341,7 +3342,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3457,7 +3459,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3511,7 +3514,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3556,7 +3560,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3600,7 +3605,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -3988,7 +3994,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -4616,7 +4623,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -4842,7 +4850,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -4871,7 +4880,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -4941,7 +4951,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -4993,7 +5004,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5064,7 +5076,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5116,7 +5129,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5190,7 +5204,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5360,7 +5375,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5429,7 +5445,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5583,7 +5600,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5790,7 +5808,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -5932,7 +5951,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6051,7 +6071,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6216,7 +6237,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6279,7 +6301,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6352,7 +6375,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6438,7 +6462,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6511,7 +6536,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6581,7 +6607,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6640,7 +6667,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6709,7 +6737,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6770,7 +6799,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6836,7 +6866,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -6982,7 +7013,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7046,7 +7078,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7111,7 +7144,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7157,7 +7191,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7231,7 +7266,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7296,7 +7332,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7340,7 +7377,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7411,7 +7449,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7461,7 +7500,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7532,7 +7572,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7582,7 +7623,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7653,7 +7695,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7703,7 +7746,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7774,7 +7818,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7824,7 +7869,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7895,7 +7941,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -7945,7 +7992,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8032,7 +8080,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8138,7 +8187,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8198,7 +8248,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8322,7 +8373,6 @@ echo "$as_me:$LINENO: checking for X" >&5 echo $ECHO_N "checking for X... $ECHO_C" >&6 -ac_path_x_has_been_run=yes # Check whether --with-x or --without-x was given. if test "${with_x+set}" = set; then @@ -8415,7 +8465,7 @@ /usr/openwin/share/include' if test "$ac_x_includes" = no; then - # Guess where to find include files, by looking for a specified header file. + # Guess where to find include files, by looking for Intrinsic.h. # First, try using that file with no special directory specified. cat >conftest.$ac_ext <<_ACEOF /* confdefs.h. */ @@ -8423,7 +8473,7 @@ cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ -#include <X11/Xlib.h> +#include <X11/Intrinsic.h> _ACEOF if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5 (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1 @@ -8450,7 +8500,7 @@ sed 's/^/| /' conftest.$ac_ext >&5 for ac_dir in $ac_x_header_dirs; do - if test -r "$ac_dir/X11/Xlib.h"; then + if test -r "$ac_dir/X11/Intrinsic.h"; then ac_x_includes=$ac_dir break fi @@ -8464,18 +8514,18 @@ # See if we find them without any special options. # Don't add to $LIBS permanently. ac_save_LIBS=$LIBS - LIBS="-lX11 $LIBS" + LIBS="-lXt $LIBS" cat >conftest.$ac_ext <<_ACEOF /* confdefs.h. */ _ACEOF cat confdefs.h >>conftest.$ac_ext cat >>conftest.$ac_ext <<_ACEOF /* end confdefs.h. */ -#include <X11/Xlib.h> +#include <X11/Intrinsic.h> int main () { -XrmInitialize () +XtMalloc (0) ; return 0; } @@ -8489,7 +8539,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8513,7 +8564,7 @@ do # Don't even attempt the hair of trying to link an X program! for ac_extension in a so sl; do - if test -r $ac_dir/libX11.$ac_extension; then + if test -r $ac_dir/libXt.$ac_extension; then ac_x_libraries=$ac_dir break 2 fi @@ -8549,12 +8600,8 @@ # Update the cache value to reflect the command line values. ac_cv_have_x="have_x=yes \ ac_x_includes=$x_includes ac_x_libraries=$x_libraries" - # It might be that x_includes is empty (headers are found in the - # standard search path. Then output the corresponding message - ac_out_x_includes=$x_includes - test "x$x_includes" = x && ac_out_x_includes="in standard search path" - echo "$as_me:$LINENO: result: libraries $x_libraries, headers $ac_out_x_includes" >&5 -echo "${ECHO_T}libraries $x_libraries, headers $ac_out_x_includes" >&6 + echo "$as_me:$LINENO: result: libraries $x_libraries, headers $x_includes" >&5 +echo "${ECHO_T}libraries $x_libraries, headers $x_includes" >&6 fi if test "$no_x" = yes; then @@ -8643,7 +8690,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8879,7 +8927,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -8974,7 +9023,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9033,7 +9083,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9117,7 +9168,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9301,7 +9353,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9553,7 +9606,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9620,7 +9674,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9689,7 +9744,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9774,7 +9830,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9851,7 +9908,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9905,7 +9963,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -9974,7 +10033,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10078,7 +10138,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10145,7 +10206,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10215,7 +10277,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10456,7 +10519,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10565,7 +10629,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10668,7 +10733,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10746,7 +10812,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10900,7 +10967,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -10974,7 +11042,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11046,7 +11115,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11128,7 +11198,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11207,7 +11278,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11278,7 +11350,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11347,7 +11420,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11420,7 +11494,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11543,7 +11618,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11645,7 +11721,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11725,7 +11802,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11793,7 +11871,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -11938,7 +12017,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12047,7 +12127,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12192,7 +12273,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12299,7 +12381,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12453,7 +12536,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12528,7 +12612,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12676,7 +12761,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12753,7 +12839,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12900,7 +12987,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -12973,7 +13061,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13174,7 +13263,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13247,7 +13337,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13392,7 +13483,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13468,7 +13560,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13531,7 +13624,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13612,7 +13706,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13753,7 +13848,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13898,7 +13994,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -13974,7 +14071,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14047,7 +14145,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14202,7 +14301,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14268,7 +14368,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14528,7 +14629,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14595,7 +14697,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14747,7 +14850,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -14931,7 +15035,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15258,7 +15363,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15359,7 +15465,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15432,7 +15539,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15511,7 +15619,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15580,7 +15689,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15648,7 +15758,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15722,7 +15833,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15826,7 +15938,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -15901,7 +16014,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16053,7 +16167,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16121,7 +16236,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16298,7 +16414,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16374,7 +16491,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16528,7 +16646,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16679,7 +16798,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16830,7 +16950,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -16972,7 +17093,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17016,7 +17138,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17162,7 +17285,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17206,7 +17330,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17271,7 +17396,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17361,7 +17487,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17548,7 +17675,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17618,7 +17746,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17687,7 +17816,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17819,7 +17949,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17921,7 +18052,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -17990,7 +18122,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18097,7 +18230,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18200,7 +18334,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18276,7 +18411,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18380,7 +18516,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18472,7 +18609,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18537,7 +18675,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18603,7 +18742,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18713,7 +18853,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18778,7 +18919,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18858,7 +19000,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -18931,7 +19074,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19004,7 +19148,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19077,7 +19222,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19151,7 +19297,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19223,7 +19370,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19298,7 +19446,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19370,7 +19519,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19443,7 +19593,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19593,7 +19744,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19739,7 +19891,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -19885,7 +20038,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20042,7 +20196,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20188,7 +20343,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20334,7 +20490,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20492,7 +20649,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20650,7 +20808,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20839,7 +20998,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20912,7 +21072,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -20980,7 +21141,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21026,7 +21188,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21100,7 +21263,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21164,7 +21328,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21302,7 +21467,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21363,7 +21529,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21508,7 +21675,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21664,7 +21832,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21835,7 +22004,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -21903,7 +22073,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22088,7 +22259,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22130,24 +22302,18 @@ ac_cv_func_fork_works=cross else cat >conftest.$ac_ext <<_ACEOF -/* confdefs.h. */ -_ACEOF -cat confdefs.h >>conftest.$ac_ext -cat >>conftest.$ac_ext <<_ACEOF -/* end confdefs.h. */ -$ac_includes_default -int -main () -{ - - /* By Ruediger Kuhlmann. */ - if (fork() < 0) - exit (1); - exit (0); - - ; - return 0; -} +/* By Ruediger Kuhlmann. */ + #include <sys/types.h> + #if HAVE_UNISTD_H + # include <unistd.h> + #endif + /* Some systems only have a dummy stub for fork() */ + int main () + { + if (fork() < 0) + exit (1); + exit (0); + } _ACEOF rm -f conftest$ac_exeext if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 @@ -22387,7 +22553,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22452,7 +22619,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22515,7 +22683,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22581,7 +22750,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22622,7 +22792,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -22689,7 +22860,8 @@ cat conftest.err >&5 echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } && - { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 (eval $ac_try) 2>&5 ac_status=$? @@ -23809,6 +23981,11 @@ *) ac_INSTALL=$ac_top_builddir$INSTALL ;; esac + if test x"$ac_file" != x-; then + { echo "$as_me:$LINENO: creating $ac_file" >&5 +echo "$as_me: creating $ac_file" >&6;} + rm -f "$ac_file" + fi # Let's still pretend it is `configure' which instantiates (i.e., don't # use $as_me), people would be surprised to read: # /* config.h. Generated by config.status. */ @@ -23847,12 +24024,6 @@ fi;; esac done` || { (exit 1); exit 1; } - - if test x"$ac_file" != x-; then - { echo "$as_me:$LINENO: creating $ac_file" >&5 -echo "$as_me: creating $ac_file" >&6;} - rm -f "$ac_file" - fi _ACEOF cat >>$CONFIG_STATUS <<_ACEOF sed "$ac_vpsub ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 19:28 ` Pretest Eli Zaretskii @ 2006-10-28 20:47 ` Chong Yidong 2006-10-29 7:43 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-28 20:47 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Try also deleting configure and doing `make bootstrap' to generate a >> new configure file (in case there's some bug in the version of >> autoconf I'm using). Does it work in that case? > > The latter method worked. The version of Autoconf installed on > fencepost is 2.59. I see that the one you used also identifies itself > as 2.59, but they produce a different configure script(!) Maybe it's due to some Debian-specific patch to autoconf (I'm using the version shipped with Ubuntu Dapper, version 2.59a-7). We could revert configure to the last version used, and stick with the configure script for the rest of the pretest. > Do you see anything in the diffs that could explain the failure? I > don't. (The file src/config.in produced by autoheader is identical > to what you included in the tarball, so config.h is not the culprit. > The produced src/Makefile files are also identical.) > > I'd still like to understand what failed `ld'. I think the easiest thing to do is to apply the hunks of the diff until you find which part causes compilation to fail for you. It shouldn't take that long with a binary-search. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 20:47 ` Pretest Chong Yidong @ 2006-10-29 7:43 ` Eli Zaretskii 2006-10-29 22:11 ` Pretest Chong Yidong 2006-10-30 13:33 ` Pretest Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-10-29 7:43 UTC (permalink / raw) Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sat, 28 Oct 2006 16:47:07 -0400 > Cc: emacs-devel@gnu.org > > I'm using the version shipped with Ubuntu Dapper, version 2.59a-7 This version sounds like it's some kind of development snapshot. Can you try to find out? Maybe we shouldn't be using this version. > We could revert configure to the last version used, and stick with > the configure script for the rest of the pretest. That's not a good solution, IMO, since some bugs reported during the pretest might require to regenerate the script. > > I'd still like to understand what failed `ld'. > > I think the easiest thing to do is to apply the hunks of the diff > until you find which part causes compilation to fail for you. It > shouldn't take that long with a binary-search. I don't know when I'll have time to do that; fencepost.gnu.org is not my main machine. Even if I do find the portion of the diffs that causes the problem, then what? We don't have a version of Autoconf that would have the effect of applying only part of the diffs, so once again we will be in a position where regenerating the configure script would be difficult of impossible. And on top of that, I still have trouble understanding how any change in the configure script _alone_ could have anything to do with this. Unless I'm missing something, there are only 2 ways Autoconf can affect the temacs build: either through config.in/config.h, or through src/Makefile. These are the only two things I know off that affect compilation and linking of the C sources. However, in this case, config.in and config.h are identical to the ones you included in the tarball, and so is src/Makefile.in. Am I missing something? So I'm still thinking the `ld' failure was some real problem, and the changes in the configure script are only indirectly related to it. If someone knows how to investigate the `ld' failure (short of rebuilding Binutils with debug info and running `ld' under a debugger), I'd appreciate any ideas. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 7:43 ` Pretest Eli Zaretskii @ 2006-10-29 22:11 ` Chong Yidong 2006-10-30 21:50 ` Pretest Eli Zaretskii 2006-10-30 13:33 ` Pretest Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-29 22:11 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> I'm using the version shipped with Ubuntu Dapper, version 2.59a-7 > > This version sounds like it's some kind of development snapshot. Can > you try to find out? Maybe we shouldn't be using this version. You may be right. I downgraded autoconf to version 2.59-5, and regenerated configure in CVS. Can you try with this version and see if compilation works? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 22:11 ` Pretest Chong Yidong @ 2006-10-30 21:50 ` Eli Zaretskii 2006-10-30 22:04 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-30 21:50 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sun, 29 Oct 2006 17:11:56 -0500 > > You may be right. I downgraded autoconf to version 2.59-5, and > regenerated configure in CVS. Can you try with this version and see > if compilation works? Something very strange is going on here: I unpacked the pretest tarball in a different directory, and it builds there even with the original configure script. So I think the configure script is not the problem here. I will try to look deeper when I have time; in the meantime, let's continue the pretest as if this problem never happened. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 21:50 ` Pretest Eli Zaretskii @ 2006-10-30 22:04 ` Chong Yidong 2006-10-31 4:09 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-30 22:04 UTC (permalink / raw) Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Something very strange is going on here: I unpacked the pretest > tarball in a different directory, and it builds there even with the > original configure script. > > So I think the configure script is not the problem here. I will try > to look deeper when I have time; in the meantime, let's continue the > pretest as if this problem never happened. I wonder if this is related to the problem reported by Martin Ebourne <lists@ebourne.me.uk> in the thread "Small fix to configure.in in CVS". He said: > > The problem I had was that I was building to a prefix directory that > > included the word 'linux'. The emacs configure was preprocessing the > > Makefile through the C preprocessor, and this was substituting > > 'linux' to 1, thus making all the paths invalid. I haven't checked in the patch he supplied yet, since I was trying to figure out whether the problem really exists. However, if the patch fixes the problem for you, I guess we should check it in. --- emacs/configure.in~ 2006-09-28 06:47:26.000000000 +0100 +++ emacs/configure.in 2006-10-25 13:50:29.000000000 +0100 @@ -3230,7 +3230,7 @@ # the C preprocessor to some helpful value like 1, or maybe the empty # string. Needless to say consequent macro substitutions are less # than conducive to the makefile finding the correct directory. -[undefs="`echo $top_srcdir $configuration $canonical | +[undefs="`echo $ac_top_srcdir $configuration $canonical | sed -e 's/[^a-zA-Z0-9_]/ /g' -e 's/^/ /' -e 's/ *$//' \ -e 's/ */ -U/g' -e 's/-U[0-9][^ ]*//g' \ `"] ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 22:04 ` Pretest Chong Yidong @ 2006-10-31 4:09 ` Eli Zaretskii 0 siblings, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-10-31 4:09 UTC (permalink / raw) Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: Chong Yidong <cyd@stupidchicken.com> > Date: Mon, 30 Oct 2006 17:04:50 -0500 > > I wonder if this is related to the problem reported by Martin Ebourne > <lists@ebourne.me.uk> in the thread "Small fix to configure.in in > CVS". He said: > > > > The problem I had was that I was building to a prefix directory that > > > included the word 'linux'. The emacs configure was preprocessing the > > > Makefile through the C preprocessor, and this was substituting > > > 'linux' to 1, thus making all the paths invalid. But in my case, there's no `linux' in the directory's prefix, and I don't think any of the paths are invalid, or I'd see a much more noisy failures. > I haven't checked in the patch he supplied yet, since I was trying to > figure out whether the problem really exists. However, if the patch > fixes the problem for you, I guess we should check it in. I think I need to understand exactly why ld fails, because this looks like a Heisenbug: seemingly innocent changes make it disappear. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 7:43 ` Pretest Eli Zaretskii 2006-10-29 22:11 ` Pretest Chong Yidong @ 2006-10-30 13:33 ` Richard Stallman 2006-10-30 21:02 ` Pretest Eli Zaretskii 1 sibling, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-10-30 13:33 UTC (permalink / raw) Cc: cyd, emacs-devel I don't know when I'll have time to do that; fencepost.gnu.org is not my main machine. Even if I do find the portion of the diffs that causes the problem, then what? We don't have a version of Autoconf that would have the effect of applying only part of the diffs, so once again we will be in a position where regenerating the configure script would be difficult of impossible. I have not followed the whole thread, and I am not certain I understand the issue. Is the problem is that a certain snapshot of Autoconf gives an incorrect configure file? if so, we should never use that version of Autoconf to generate the configure file, and we should report the bug to the Autoconf developers. Yidong, can you install a released Autoconf on your machine and use that from now on? However, in this case, config.in and config.h are identical to the ones you included in the tarball, and so is src/Makefile.in. Am I missing something? That puzzles me, too. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 13:33 ` Pretest Richard Stallman @ 2006-10-30 21:02 ` Eli Zaretskii 2006-11-01 2:12 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-30 21:02 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Mon, 30 Oct 2006 08:33:04 -0500 > > I have not followed the whole thread, and I am not certain I understand > the issue. Is the problem is that a certain snapshot of Autoconf > gives an incorrect configure file? The problem was that ld failed to link temacs without any error message, and regenerating the configure script with a slightly different version of Autoconf mysteriously solved the problem, although I see no changes whatsoever except a few insignificant ones in the configure script itself. > if so, we should never use that version of Autoconf to generate the > configure file, and we should report the bug to the Autoconf > developers. I'd like first to understand how come this caused ld to fail. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 21:02 ` Pretest Eli Zaretskii @ 2006-11-01 2:12 ` Richard Stallman 2006-11-01 4:14 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw) Cc: cyd, emacs-devel The problem was that ld failed to link temacs without any error message, and regenerating the configure script with a slightly different version of Autoconf mysteriously solved the problem, although I see no changes whatsoever except a few insignificant ones in the configure script itself. It is quite mysterious, so I would suggest adding some echo statements just before the ld command (in both cases), to verify the arguments and environment. plus echo's to ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-01 2:12 ` Pretest Richard Stallman @ 2006-11-01 4:14 ` Eli Zaretskii 2006-11-02 4:42 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-11-01 4:14 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Tue, 31 Oct 2006 21:12:57 -0500 > > The problem was that ld failed to link temacs without any error > message, and regenerating the configure script with a slightly > different version of Autoconf mysteriously solved the problem, > although I see no changes whatsoever except a few insignificant ones > in the configure script itself. > > It is quite mysterious, so I would suggest adding some echo statements > just before the ld command (in both cases), to verify the arguments > and environment. The arguments are displayed by Make, and they are identical in both cases. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-01 4:14 ` Pretest Eli Zaretskii @ 2006-11-02 4:42 ` Richard Stallman 2006-11-02 19:54 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-11-02 4:42 UTC (permalink / raw) Cc: cyd, emacs-devel > It is quite mysterious, so I would suggest adding some echo statements > just before the ld command (in both cases), to verify the arguments > and environment. The arguments are displayed by Make, and they are identical in both cases. What about the environment? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-02 4:42 ` Pretest Richard Stallman @ 2006-11-02 19:54 ` Eli Zaretskii 2006-11-03 7:08 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-11-02 19:54 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Wed, 01 Nov 2006 23:42:24 -0500 > > > It is quite mysterious, so I would suggest adding some echo statements > > just before the ld command (in both cases), to verify the arguments > > and environment. > > The arguments are displayed by Make, and they are identical in both > cases. > > What about the environment? It's identical: I did both builds from the same account, just mkdir'ed a subdirectory, chdir'ed there, unpacked the archive and built it. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-02 19:54 ` Pretest Eli Zaretskii @ 2006-11-03 7:08 ` Richard Stallman 2006-11-04 13:50 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-11-03 7:08 UTC (permalink / raw) Cc: cyd, emacs-devel It's identical: I did both builds from the same account, just mkdir'ed a subdirectory, chdir'ed there, unpacked the archive and built it. We hope it is identical, but it would be useful to verify that by adding printenv statements just before the invocations of ld. If the difference isn't due to arguments and isn't due to the environment, it must be due to something in the file system. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-03 7:08 ` Pretest Richard Stallman @ 2006-11-04 13:50 ` Eli Zaretskii 2006-11-05 7:08 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-11-04 13:50 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Fri, 03 Nov 2006 02:08:20 -0500 > > It's identical: I did both builds from the same account, just mkdir'ed > a subdirectory, chdir'ed there, unpacked the archive and built it. > > We hope it is identical, but it would be useful to verify that > by adding printenv statements just before the invocations of ld. > > If the difference isn't due to arguments and isn't due to the environment, > it must be due to something in the file system. As of now, I cannot even reproduce the original problem: with a fresh source tree from the original tarball of the pretest, Emacs builds without any problems on that machine. So I can only conclude that the failure was due to some transient problem, perhaps indeed some screwup in the file system that got fixed in the meantime. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-04 13:50 ` Pretest Eli Zaretskii @ 2006-11-05 7:08 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-05 7:08 UTC (permalink / raw) Cc: cyd, emacs-devel As of now, I cannot even reproduce the original problem: with a fresh source tree from the original tarball of the pretest, Emacs builds without any problems on that machine. So I can only conclude that the failure was due to some transient problem, perhaps indeed some screwup in the file system that got fixed in the meantime. Ok, we can stop worrying about this. ^ permalink raw reply [flat|nested] 317+ messages in thread
[parent not found: <cyd@stupidchicken.com>]
* Re: Pretest [not found] ` <cyd@stupidchicken.com> @ 2006-10-28 15:08 ` Alfred M. Szmidt 2006-10-28 20:52 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-28 15:08 UTC (permalink / raw) Cc: emacs-devel It doesn't build on OpenBSD: | OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 The strange thing is that tiff is found correctly, and that all goes well up to the point of linking: | ... | checking for TIFFGetVersion in -ltiff... yes | ... Here is the relevant part of the build log: gcc -nostartfiles `echo -R/usr/X11R6/lib | sed -e 's/-R/-Wl,-rpath,/'` -Z -Wl,-znocombreloc -L/usr/X11R6/lib -o temacs pre-crt0.o /usr/lib/crt0.o /usr/lib/crtbegin.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o widget.o ../lwlib/liblw.a -L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXext -ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11 -lossaudio -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/bin/ld: cannot find -ltiff collect2: ld returned 1 exit status ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 15:08 ` Pretest Alfred M. Szmidt @ 2006-10-28 20:52 ` Chong Yidong 2006-10-28 21:11 ` Pretest Alfred M. Szmidt 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-28 20:52 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > It doesn't build on OpenBSD: Is this x86-64 OpenBSD? A patch was recently sent to this list that fixes compilation on that platform, but it seems not to have been checked in by the time I rolled the tarball. Someone should check it into CVS; then it'll show up in the next tarball. > | OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 > > The strange thing is that tiff is found correctly, and that all goes > well up to the point of linking: > > | ... > | checking for TIFFGetVersion in -ltiff... yes > | ... > > Here is the relevant part of the build log: > > gcc -nostartfiles `echo -R/usr/X11R6/lib | sed -e 's/-R/-Wl,-rpath,/'` -Z -Wl,-znocombreloc -L/usr/X11R6/lib -o temacs pre-crt0.o /usr/lib/crt0.o /usr/lib/crtbegin.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.o terminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o widget.o ../lwlib/liblw.a -L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXe xt -ltiff -ljpeg -lpng -lz -lm -lungif -lXpm -lX11 -lossaudio -lncurses -lm -lgcc -lc -! lgc > c /usr/lib/crtend.o > /usr/bin/ld: cannot find -ltiff > collect2: ld returned 1 exit status ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 20:52 ` Pretest Chong Yidong @ 2006-10-28 21:11 ` Alfred M. Szmidt 2006-10-28 22:09 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-28 21:11 UTC (permalink / raw) Cc: emacs-devel > It doesn't build on OpenBSD: Is this x86-64 OpenBSD? No, this is plain 8x86 OpenBSD. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 21:11 ` Pretest Alfred M. Szmidt @ 2006-10-28 22:09 ` Chong Yidong 2006-10-28 22:30 ` Pretest Alfred M. Szmidt 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-28 22:09 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > > It doesn't build on OpenBSD: > > Is this x86-64 OpenBSD? > > No, this is plain 8x86 OpenBSD. Could you try regenerating configure by running autoconf in the emacs-22.0.90, then running ./configure && make? Does compilation work then? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 22:09 ` Pretest Chong Yidong @ 2006-10-28 22:30 ` Alfred M. Szmidt 2006-10-29 23:40 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-28 22:30 UTC (permalink / raw) Cc: emacs-devel > > It doesn't build on OpenBSD: > > Is this x86-64 OpenBSD? > > No, this is plain 8x86 OpenBSD. Could you try regenerating configure by running autoconf in the emacs-22.0.90, then running ./configure && make? Does compilation work then? I tried this, it didn't work. The reason from the looks is that the library search path is not propagated correctly. This is what config.log contains (tiff is installed in /usr/local): | configure:12641: checking for TIFFGetVersion in -ltiff | configure:12671: gcc -o conftest -I/usr/X11R6/include -g -O2 -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm -lXext -lXmu -lXt -lSM -lICE -lX11 >&5 -Z But at linking, none of the search paths are passed, and hence the missing library error. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 22:30 ` Pretest Alfred M. Szmidt @ 2006-10-29 23:40 ` Chong Yidong 2006-10-30 0:33 ` Pretest Alfred M. Szmidt 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-29 23:40 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > The reason from the looks is that the library search path is not > propagated correctly. This is what config.log contains (tiff is > installed in /usr/local): > > But at linking, none of the search paths are passed, and hence the > missing library error. I'm guessing you're passing an LDFLAGS envvar to configure. Seems like LDFLAGS isn't getting passed to X11_LDFLAGS. Try applying the following patch, run autoconf, run configure, and compile again. Does compilation work now? (Can others check that this patch makes sense?) *** emacs/configure.in.~1.414.~ 2006-10-28 16:35:50.000000000 -0400 --- emacs/configure.in 2006-10-29 18:23:16.000000000 -0500 *************** *** 1315,1320 **** --- 1315,1322 ---- dnl Treat GCC specially since it just gives a non-fatal `unrecognized option' dnl if not built to support GNU ld. + SPECIFIED_LDFLAGS=$LDFLAGS + AC_SUBST(SPECIFIED_LDFLAGS) late_LDFLAGS=$LDFLAGS if test "$GCC" = yes; then LDFLAGS="$LDFLAGS -Wl,-znocombreloc" *** emacs/src/Makefile.in.~1.331.~ 2006-09-16 09:28:06.000000000 -0400 --- emacs/src/Makefile.in 2006-10-29 18:24:35.000000000 -0500 *************** *** 444,450 **** #ifdef HAVE_X11 /* LD_SWITCH_X_DEFAULT comes after everything else that specifies options for where to find X libraries, but before those libraries. */ ! X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM #else /* not HAVE_X11 */ LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM --- 444,450 ---- #ifdef HAVE_X11 /* LD_SWITCH_X_DEFAULT comes after everything else that specifies options for where to find X libraries, but before those libraries. */ ! X11_LDFLAGS = @SPECIFIED_LDFLAGS@ LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM #else /* not HAVE_X11 */ LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 23:40 ` Pretest Chong Yidong @ 2006-10-30 0:33 ` Alfred M. Szmidt 2006-10-30 14:12 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-30 0:33 UTC (permalink / raw) Cc: emacs-devel > The reason from the looks is that the library search path is not > propagated correctly. This is what config.log contains (tiff is > installed in /usr/local): > > But at linking, none of the search paths are passed, and hence the > missing library error. I'm guessing you're passing an LDFLAGS envvar to configure. Seems like LDFLAGS isn't getting passed to X11_LDFLAGS. I'm not passing any flags to configure, it is a simple `./configure && make' deal. Does compilation work now? No, it doesn't. The value of X11_LDFLAGS is `-L/usr/X11R6/lib'. Sorry that I can't be of much use fixing this, to much on my own plate. :-( ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 0:33 ` Pretest Alfred M. Szmidt @ 2006-10-30 14:12 ` Chong Yidong 2006-10-30 19:57 ` Pretest Alfred M. Szmidt 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-30 14:12 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > I'm guessing you're passing an LDFLAGS envvar to configure. Seems > like LDFLAGS isn't getting passed to X11_LDFLAGS. > > I'm not passing any flags to configure, it is a simple `./configure && > make' deal. Then how did configure know to use -L/usr/pkg/lib and -L/usr/local/lib in the excerpt you sent earlier? configure:12671: gcc -o conftest -I/usr/X11R6/include -g -O2 -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm -lXext -lXmu -lXt -lSM -lICE -lX11 >&5 -Z In contrast, I have configure:12672: gcc -o conftest -g -O2 -Wno-pointer-sign -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_BSD_SOURCE -Wl,-znocombreloc -L/usr/X11R6/lib conftest.c -ltiff -ljpeg -lz -lm -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lX11 >&5 where only -L/usr/X11R6/lib is used. What is the value of LDFLAGS in your default shell? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 14:12 ` Pretest Chong Yidong @ 2006-10-30 19:57 ` Alfred M. Szmidt 2006-10-30 20:18 ` Pretest Chong Yidong 0 siblings, 1 reply; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-30 19:57 UTC (permalink / raw) Cc: emacs-devel What is the value of LDFLAGS in your default shell? It is not set. I did some digging, the values are from `libsrc_libs' in configure.in (they get pulled in from C_SWITCH_SYSTEM which is defined in netbsd.h; which OpenBSD uses). The following patch works for me. diff -up /home/ams/emacs-22.0.90/src/Makefile.in.\~2\~ /home/ams/emacs-22.0.90/src/Makefile.in --- /home/ams/emacs-22.0.90/src/Makefile.in.~2~ 2006-10-30 03:03:56.000000000 +0100 +++ /home/ams/emacs-22.0.90/src/Makefile.in 2006-10-30 22:34:30.000000000 +0100 @@ -444,7 +444,7 @@ LIBXT=$(LIBW) #ifdef HAVE_X11 /* LD_SWITCH_X_DEFAULT comes after everything else that specifies options for where to find X libraries, but before those libraries. */ -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT LIBX= $(LIBXMENU) $(X11_LDFLAGS) $(LIBXT) LIBTIFF LIBJPEG LIBPNG LIBGIF LIBXPM LIB_X11_LIB LIBX11_MACHINE LIBX11_SYSTEM #else /* not HAVE_X11 */ LIBX= $(LIBXMENU) LD_SWITCH_X_SITE -lX10 LIBX10_MACHINE LIBX10_SYSTEM Diff finished. Mon Oct 30 22:38:54 2006 ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 19:57 ` Pretest Alfred M. Szmidt @ 2006-10-30 20:18 ` Chong Yidong 2006-10-30 20:34 ` Pretest Alfred M. Szmidt 0 siblings, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-30 20:18 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > I did some digging, the values are from `libsrc_libs' in configure.in > (they get pulled in from C_SWITCH_SYSTEM which is defined in netbsd.h; > which OpenBSD uses). The following patch works for me. > > -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT > +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does using LD_SWITCH_SYSTEM instead work? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 20:18 ` Pretest Chong Yidong @ 2006-10-30 20:34 ` Alfred M. Szmidt 2006-10-30 22:18 ` Pretest Chong Yidong 2006-11-01 2:12 ` Pretest Richard Stallman 0 siblings, 2 replies; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-30 20:34 UTC (permalink / raw) Cc: emacs-devel > I did some digging, the values are from `libsrc_libs' in > configure.in (they get pulled in from C_SWITCH_SYSTEM which is > defined in netbsd.h; which OpenBSD uses). The following patch > works for me. > > -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT > +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does using LD_SWITCH_SYSTEM instead work? No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD. >From src/s/openbsd.h: | ... | #undef LD_SWITCH_SYSTEM_TEMACS | #undef LD_SWITCH_SYSTEM | ... ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 20:34 ` Pretest Alfred M. Szmidt @ 2006-10-30 22:18 ` Chong Yidong 2006-10-30 23:00 ` Pretest Alfred M. Szmidt 2006-11-01 2:12 ` Pretest Richard Stallman 1 sibling, 1 reply; 317+ messages in thread From: Chong Yidong @ 2006-10-30 22:18 UTC (permalink / raw) Cc: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > > -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT > > +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT > > I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does > using LD_SWITCH_SYSTEM instead work? > > No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD. In that case, does the following change work? *** emacs/src/s/openbsd.h.~1.6.~ 2005-03-21 12:33:04.000000000 -0500 --- emacs/src/s/openbsd.h 2006-10-30 17:12:53.000000000 -0500 *************** *** 23,29 **** /* Han Boetes <han@mijncomputer.nl> says this is necessary, otherwise Emacs dumps core on elf systems. */ ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z #else --- 23,29 ---- /* Han Boetes <han@mijncomputer.nl> says this is necessary, otherwise Emacs dumps core on elf systems. */ ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z -L/usr/pkg/lib -L/usr/local/lib #else ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 22:18 ` Pretest Chong Yidong @ 2006-10-30 23:00 ` Alfred M. Szmidt 0 siblings, 0 replies; 317+ messages in thread From: Alfred M. Szmidt @ 2006-10-30 23:00 UTC (permalink / raw) Cc: emacs-devel In that case, does the following change work? Yeah, this seems to work. It should probobly be added in the non-ELF case too. Thanks! ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 20:34 ` Pretest Alfred M. Szmidt 2006-10-30 22:18 ` Pretest Chong Yidong @ 2006-11-01 2:12 ` Richard Stallman 2006-11-02 14:10 ` Pretest Alfred M. Szmidt 1 sibling, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-11-01 2:12 UTC (permalink / raw) Cc: cyd, emacs-devel > -X11_LDFLAGS = LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT > +X11_LDFLAGS = C_SWITCH_SYSTEM LD_SWITCH_X_SITE LD_SWITCH_X_DEFAULT I think it should be LD_SWITCH_SYSTEM, not C_SWITCH_SYSTEM. Does using LD_SWITCH_SYSTEM instead work? No. LD_SWITCH_SYSTEM won't work because it isn't set on OpenBSD. Neither one belongs in X11_LDFLAGS. X11_LDFLAGS is supposed to be the _additional_ flags needed before the X libraries. Changing it on an ad hoc basis just because it makes one bug disappear is the wrong way to maintain Makefile.in. The right thing to do is to change LD_SWITCH_X_DEFAULT. (Changing LD_SWITCH_SYSTEM might also be an ok approach.) ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-01 2:12 ` Pretest Richard Stallman @ 2006-11-02 14:10 ` Alfred M. Szmidt 0 siblings, 0 replies; 317+ messages in thread From: Alfred M. Szmidt @ 2006-11-02 14:10 UTC (permalink / raw) Cc: cyd, emacs-devel Would the following be OK? I haven't had a chance to test it but I see no reason why it should not work. 2006-11-02 Alfred M. Szmidt <ams@gnu.org> (tiny change) * s/openbsd.h (LD_SWITCH_SYSTEM): Remove /usr/pkg/lib and /usr/pkg/lib from the library search path. (LD_SWITCH_X_DEFAULT): New macro. Index: openbsd.h =================================================================== RCS file: /cvsroot/emacs/emacs/src/s/openbsd.h,v retrieving revision 1.8 diff -u -p -r1.8 src/s/openbsd.h *** src/s/openbsd.h 30 Oct 2006 23:05:35 -0000 1.8 --- src/s/openbsd.h 2 Nov 2006 14:05:03 -0000 *************** *** 23,33 **** /* Han Boetes <han@mijncomputer.nl> says this is necessary, otherwise Emacs dumps core on elf systems. */ ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z -L/usr/pkg/lib -L/usr/local/lib #else ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -L/usr/pkg/lib -L/usr/local/lib #endif --- 24,40 ---- /* Han Boetes <han@mijncomputer.nl> says this is necessary, otherwise Emacs dumps core on elf systems. */ ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp -Z ! ! /* The version of gcc on OpenBSD doesn't search /usr/local/lib by ! default. */ ! #define LD_SWITCH_X_DEFAULT -L/usr/local/lib #else ! #define LD_SWITCH_SYSTEM LD_SWITCH_SYSTEM_tmp ! ! #define LD_SWITCH_X_DEFAULT -L/usr/local/lib #endif ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (13 preceding siblings ...) [not found] ` <cyd@stupidchicken.com> @ 2006-10-28 18:13 ` Richard Stallman 2006-10-28 19:02 ` Pretest Eli Zaretskii 2006-11-03 15:39 ` Pretest Drew Adams 2006-10-30 20:04 ` Pretest Paul Jarc ` (2 subsequent siblings) 17 siblings, 2 replies; 317+ messages in thread From: Richard Stallman @ 2006-10-28 18:13 UTC (permalink / raw) Cc: emacs-devel The question is, who do we announce the pretest to? I have a list of pretesters that I send the announcement to. I keep it in sync with emacs-pretesters, but I don't send the announcement _to_ that mailing list, because that would tend to lead everyone to mail all their statements of success or failure to the list as well. People should use that list only when they have a specific reason to do so. I have not updated the list for a few years. I should do it now, but we can announce the first pretest before updating it. If not, I think we should just make a public announcement about the availability of the pretest tarball on the Gnu Emacs webpage. We can do that too. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 18:13 ` Pretest Richard Stallman @ 2006-10-28 19:02 ` Eli Zaretskii 2006-10-29 18:49 ` Pretest Richard Stallman 2006-11-03 15:39 ` Pretest Drew Adams 1 sibling, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-28 19:02 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Sat, 28 Oct 2006 14:13:36 -0400 > Cc: emacs-devel@gnu.org > > I have a list of pretesters that I send the announcement to. I keep > it in sync with emacs-pretesters, but I don't send the announcement > _to_ that mailing list, because that would tend to lead everyone to > mail all their statements of success or failure to the list as well. Won't `Reply-to' solve this more conveniently? > People should use that list only when they have a specific reason to > do so. The usual reasons were, IIRC, to inform the pretesters about known problems and their solutions/workarounds. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-28 19:02 ` Pretest Eli Zaretskii @ 2006-10-29 18:49 ` Richard Stallman 2006-10-29 20:22 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Richard Stallman @ 2006-10-29 18:49 UTC (permalink / raw) Cc: cyd, emacs-devel > I have a list of pretesters that I send the announcement to. I keep > it in sync with emacs-pretesters, but I don't send the announcement > _to_ that mailing list, because that would tend to lead everyone to > mail all their statements of success or failure to the list as well. Won't `Reply-to' solve this more conveniently? I am not sure. What would we put in the Reply-to field? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 18:49 ` Pretest Richard Stallman @ 2006-10-29 20:22 ` Eli Zaretskii 2006-10-30 19:16 ` Pretest Richard Stallman 0 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-10-29 20:22 UTC (permalink / raw) Cc: cyd, emacs-devel > From: Richard Stallman <rms@gnu.org> > CC: cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Sun, 29 Oct 2006 13:49:43 -0500 > > > I have a list of pretesters that I send the announcement to. I keep > > it in sync with emacs-pretesters, but I don't send the announcement > > _to_ that mailing list, because that would tend to lead everyone to > > mail all their statements of success or failure to the list as well. > > Won't `Reply-to' solve this more conveniently? > > I am not sure. What would we put in the Reply-to field? I think emacs-pretest-bug@gnu.org is the right address to put there. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-29 20:22 ` Pretest Eli Zaretskii @ 2006-10-30 19:16 ` Richard Stallman 0 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-10-30 19:16 UTC (permalink / raw) Cc: cyd, emacs-devel I think emacs-pretest-bug@gnu.org is the right address to put there. Ok, that makes sense. ^ permalink raw reply [flat|nested] 317+ messages in thread
* RE: Pretest 2006-10-28 18:13 ` Pretest Richard Stallman 2006-10-28 19:02 ` Pretest Eli Zaretskii @ 2006-11-03 15:39 ` Drew Adams 2006-11-03 19:22 ` Pretest Eli Zaretskii ` (2 more replies) 1 sibling, 3 replies; 317+ messages in thread From: Drew Adams @ 2006-11-03 15:39 UTC (permalink / raw) Not sure how the pretest works. Will binary versions be posted somewhere, or will people need to roll their own? ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-03 15:39 ` Pretest Drew Adams @ 2006-11-03 19:22 ` Eli Zaretskii 2006-11-03 19:51 ` Pretest Lennart Borgman 2006-11-03 20:48 ` Pretest Nick Roberts 2006-11-04 15:26 ` Pretest Richard Stallman 2 siblings, 1 reply; 317+ messages in thread From: Eli Zaretskii @ 2006-11-03 19:22 UTC (permalink / raw) Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Fri, 3 Nov 2006 07:39:51 -0800 > > Not sure how the pretest works. Will binary versions be posted somewhere, or > will people need to roll their own? The pretest includes only the source tarballs. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-03 19:22 ` Pretest Eli Zaretskii @ 2006-11-03 19:51 ` Lennart Borgman 2006-11-03 20:02 ` Pretest Eli Zaretskii 0 siblings, 1 reply; 317+ messages in thread From: Lennart Borgman @ 2006-11-03 19:51 UTC (permalink / raw) Cc: Drew Adams, emacs-devel Eli Zaretskii wrote: >> From: "Drew Adams" <drew.adams@oracle.com> >> Date: Fri, 3 Nov 2006 07:39:51 -0800 >> >> Not sure how the pretest works. Will binary versions be posted somewhere, or >> will people need to roll their own? >> > > The pretest includes only the source tarballs. > Is there any reason not to provide official binaries for those used to that? At least for w32 I believe that would be an advantage. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-03 19:51 ` Pretest Lennart Borgman @ 2006-11-03 20:02 ` Eli Zaretskii 0 siblings, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-11-03 20:02 UTC (permalink / raw) Cc: drew.adams, emacs-devel > Date: Fri, 03 Nov 2006 20:51:35 +0100 > From: Lennart Borgman <lennart.borgman.073@student.lu.se> > CC: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org > > Is there any reason not to provide official binaries for those used to > that? At least for w32 I believe that would be an advantage. The only reason is, as always, the need for someone to volunteer to do that job. It's not part of the job description of the person who is responsible for the pretest to do that. For example, for MS-Windows, all that is needed is for you to prepare a new binary on your site whenever a new pretest is rolled out. ^ permalink raw reply [flat|nested] 317+ messages in thread
* RE: Pretest 2006-11-03 15:39 ` Pretest Drew Adams 2006-11-03 19:22 ` Pretest Eli Zaretskii @ 2006-11-03 20:48 ` Nick Roberts 2006-11-04 15:26 ` Pretest Richard Stallman 2 siblings, 0 replies; 317+ messages in thread From: Nick Roberts @ 2006-11-03 20:48 UTC (permalink / raw) Cc: emacs-devel Drew Adams writes: > Not sure how the pretest works. Will binary versions be posted somewhere, or > will people need to roll their own? AFAIK the pretest is a source tarball and hopefully most bug reports will just be about its failure to build. The executable itself having been extensively tested over the years from CVS. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-03 15:39 ` Pretest Drew Adams 2006-11-03 19:22 ` Pretest Eli Zaretskii 2006-11-03 20:48 ` Pretest Nick Roberts @ 2006-11-04 15:26 ` Richard Stallman 2 siblings, 0 replies; 317+ messages in thread From: Richard Stallman @ 2006-11-04 15:26 UTC (permalink / raw) Cc: emacs-devel Not sure how the pretest works. Will binary versions be posted somewhere, or will people need to roll their own? We distribute pretests as source; we want pretesters to test the build. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (14 preceding siblings ...) 2006-10-28 18:13 ` Pretest Richard Stallman @ 2006-10-30 20:04 ` Paul Jarc 2006-10-30 23:13 ` Pretest Chong Yidong 2006-10-31 9:44 ` Pretest Jim Thompson 2006-11-05 23:30 ` Pretest Bill Wohler 17 siblings, 1 reply; 317+ messages in thread From: Paul Jarc @ 2006-10-30 20:04 UTC (permalink / raw) Chong Yidong <cyd@stupidchicken.com> wrote: > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz I had one problem building from this tarball. I have some headers installed in unusual places, so I pass the appropriate -I flags in CPPFLAGS. But lwlib/Makefile.in does not use CPPFLAGS in the rule for lwlib.o, so I had some missing-header errors. When I added CPPFLAGS to that rule, everything worked. paul ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-30 20:04 ` Pretest Paul Jarc @ 2006-10-30 23:13 ` Chong Yidong 0 siblings, 0 replies; 317+ messages in thread From: Chong Yidong @ 2006-10-30 23:13 UTC (permalink / raw) Cc: prj prj@po.cwru.edu (Paul Jarc) writes: > I had one problem building from this tarball. I have some headers > installed in unusual places, so I pass the appropriate -I flags in > CPPFLAGS. But lwlib/Makefile.in does not use CPPFLAGS in the rule for > lwlib.o, so I had some missing-header errors. When I added CPPFLAGS > to that rule, everything worked. I've checked in a fix to CVS. Thanks. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (15 preceding siblings ...) 2006-10-30 20:04 ` Pretest Paul Jarc @ 2006-10-31 9:44 ` Jim Thompson 2006-11-05 23:30 ` Pretest Bill Wohler 17 siblings, 0 replies; 317+ messages in thread From: Jim Thompson @ 2006-10-31 9:44 UTC (permalink / raw) Chong Yidong <cyd <at> stupidchicken.com> writes: > > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. The tarball can be found at > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.90.tar.gz Building on MacOS X fails. The target ../mac/Emacs.app/Contents/Resources/Emacs.icns referenced by the target 'macos-bund' can't be resolved. I used the file found here: http://www2.ing.unipi.it/~d9615/homepage/mac/myemacs.icns copied to mac/Emacs.app/Contents/Resources/Emacs.icns and the build completed. I then re-ran 'configure', passing it --enable-carbon-app' (I'd left out '--enable-carbon-app' on the first run), followed by 'make install', and all that seemed to work. You might want to populate .../mac/Emacs.app/Contents/Resource/Emacs.icns mac/ChangeLog says it should be there: --- 2002-07-01 Andrew Choi <akochoi@shaw.ca> * Emacs.app/Contents/Resources/Emacs.icns: New file. --- Thanks! Jim ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-10-27 17:59 Pretest Chong Yidong ` (16 preceding siblings ...) 2006-10-31 9:44 ` Pretest Jim Thompson @ 2006-11-05 23:30 ` Bill Wohler 2006-11-06 0:01 ` Pretest Jason Rumney 2006-11-06 4:22 ` Pretest Eli Zaretskii 17 siblings, 2 replies; 317+ messages in thread From: Bill Wohler @ 2006-11-05 23:30 UTC (permalink / raw) Chong Yidong <cyd@stupidchicken.com> writes: > With Richard's agreement, I've bumped the version number to 22.0.90 > and rolled a pretest tarball. Cool, thanks. I don't see a branch, so was it decided to branch closer to the release? -- Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-05 23:30 ` Pretest Bill Wohler @ 2006-11-06 0:01 ` Jason Rumney 2006-11-06 4:22 ` Pretest Eli Zaretskii 1 sibling, 0 replies; 317+ messages in thread From: Jason Rumney @ 2006-11-06 0:01 UTC (permalink / raw) Cc: emacs-devel Bill Wohler wrote: >> With Richard's agreement, I've bumped the version number to 22.0.90 >> and rolled a pretest tarball. >> > > Cool, thanks. I don't see a branch, so was it decided to branch closer > to the release? > The time to branch would be just before the emacs-unicode-2 branch is merged to the trunk. I'd expect this to happen shortly after the release. ^ permalink raw reply [flat|nested] 317+ messages in thread
* Re: Pretest 2006-11-05 23:30 ` Pretest Bill Wohler 2006-11-06 0:01 ` Pretest Jason Rumney @ 2006-11-06 4:22 ` Eli Zaretskii 1 sibling, 0 replies; 317+ messages in thread From: Eli Zaretskii @ 2006-11-06 4:22 UTC (permalink / raw) Cc: emacs-devel > From: Bill Wohler <wohler@newt.com> > Date: Sun, 05 Nov 2006 15:30:35 -0800 > > Chong Yidong <cyd@stupidchicken.com> writes: > > > With Richard's agreement, I've bumped the version number to 22.0.90 > > and rolled a pretest tarball. > > Cool, thanks. I don't see a branch, so was it decided to branch closer > to the release? I think we branch _after_ the release. ^ permalink raw reply [flat|nested] 317+ messages in thread
end of thread, other threads:[~2011-09-21 2:11 UTC | newest] Thread overview: 317+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-12-16 9:29 On the rebasing problem of Emacs on Cygwin Angelo Graziosi 2006-12-16 14:01 ` Eli Zaretskii 2006-12-26 9:43 ` WARNING from config.status " Angelo Graziosi 2006-12-26 11:38 ` Andreas Schwab 2007-01-15 9:02 ` Problems building recent Emacs-CVS " Angelo Graziosi 2007-02-23 13:07 ` cygwin succesfull straight build Angelo Graziosi 2007-02-23 18:15 ` Eli Zaretskii 2007-03-07 1:26 ` Pretest? Angelo Graziosi 2007-03-08 19:40 ` Pretest? Chong Yidong 2007-03-09 13:59 ` Pretest? Giorgos Keramidas 2007-03-09 14:44 ` Pretest? Chong Yidong 2007-03-09 17:07 ` Pretest? Christian Faulhammer 2007-03-09 17:35 ` Pretest? Juanma Barranquero 2007-03-09 18:33 ` Pretest? Chong Yidong 2007-03-09 17:49 ` Pretest? Eli Zaretskii 2007-03-09 18:07 ` Pretest? Giorgos Keramidas 2007-03-09 21:26 ` Pretest? Richard Stallman 2007-03-12 10:39 ` Pretest? Juanma Barranquero 2007-03-12 10:42 ` Pretest? David Kastrup 2007-03-12 11:46 ` Pretest? Juanma Barranquero 2007-03-12 14:53 ` Pretest? Stefan Monnier 2007-03-12 15:46 ` Pretest? Juanma Barranquero 2007-03-12 15:53 ` Pretest? David Kastrup 2007-03-12 20:55 ` Pretest? Chong Yidong 2007-03-12 21:32 ` Pretest? Juanma Barranquero 2007-03-13 1:03 ` Pretest? Chong Yidong 2007-03-13 9:37 ` Pretest? Juanma Barranquero 2007-03-13 2:43 ` Pretest? Richard Stallman 2007-03-13 9:43 ` Pretest? Juanma Barranquero 2007-03-13 9:52 ` Pretest? Andreas Schwab 2007-03-13 10:09 ` Pretest? David Kastrup 2007-03-13 10:23 ` Pretest? Juanma Barranquero 2007-03-19 5:15 ` Pretest? Richard Stallman 2007-03-14 3:24 ` Pretest? Richard Stallman 2007-03-14 7:10 ` Pretest? David Kastrup 2007-03-14 13:39 ` Pretest? Stefan Monnier 2007-03-14 14:04 ` Pretest? David Kastrup 2007-03-14 14:19 ` Pretest? Stefan Monnier 2007-03-14 9:18 ` Pretest? Juanma Barranquero 2007-03-14 9:32 ` Pretest? David Kastrup 2007-03-14 9:44 ` Pretest? Juanma Barranquero 2007-03-14 10:07 ` Pretest? David Kastrup 2007-03-14 10:17 ` Pretest? Juanma Barranquero 2007-03-14 13:56 ` Pretest? Chong Yidong 2007-03-14 14:24 ` Pretest? Stefan Monnier 2007-03-15 1:38 ` Pretest? Richard Stallman 2007-03-15 10:04 ` Pretest? Juanma Barranquero 2007-03-16 5:20 ` Pretest? Richard Stallman 2007-03-15 15:44 ` Pretest? Chong Yidong 2007-03-16 5:21 ` Pretest? Richard Stallman 2007-03-16 7:36 ` Pretest? David Kastrup 2007-03-07 13:37 ` Help: build emacs in cygwin Angelo Graziosi 2007-03-09 1:06 ` Killing buffers with mouse Angelo Graziosi 2007-03-09 14:56 ` Chong Yidong 2007-03-09 15:15 ` Jan Djärv 2007-03-09 15:55 ` Stefan Monnier 2007-03-09 17:43 ` Jan Djärv 2007-03-09 23:19 ` Kim F. Storm 2007-03-10 9:35 ` Jan Djärv 2007-03-13 14:24 ` Emacs and GTK Angelo Graziosi 2007-03-13 14:41 ` David Kastrup 2007-03-14 1:21 ` Angelo Graziosi 2007-03-13 14:45 ` Tassilo Horn 2007-03-10 16:00 ` Killing buffers with mouse Stefan Monnier 2007-03-10 23:07 ` Kim F. Storm 2007-03-11 1:32 ` Stefan Monnier 2007-03-09 15:41 ` Eli Zaretskii 2007-03-09 16:46 ` Angelo Graziosi 2007-03-09 17:46 ` Eli Zaretskii 2007-03-14 9:02 ` Connection to emacs CVS broken ? Angelo Graziosi 2007-03-14 9:09 ` David Kastrup 2007-03-14 17:42 ` Glenn Morris 2007-03-15 15:17 ` Kim F. Storm 2007-03-15 17:34 ` Glenn Morris 2007-03-15 20:00 ` Glenn Morris 2007-03-15 20:18 ` Eli Zaretskii 2007-03-16 3:28 ` Giorgos Keramidas 2007-03-16 5:21 ` Richard Stallman 2007-03-16 11:58 ` ttn 2007-03-16 15:07 ` James Cloos 2007-03-15 20:27 ` Chong Yidong 2007-03-15 20:49 ` Nick Roberts 2007-03-15 22:17 ` Jason Rumney 2007-03-15 23:15 ` Miles Bader 2007-03-15 23:34 ` NIIMI Satoshi 2007-03-16 4:55 ` Vinicius Jose Latorre 2007-03-16 5:25 ` Miles Bader 2007-03-16 5:47 ` Kenichi Handa 2007-03-16 6:28 ` Herbert Euler 2007-03-15 23:47 ` [DIFFS] " Kim F. Storm 2007-03-16 0:41 ` Nick Roberts 2007-03-16 1:14 ` Miles Bader 2007-03-16 1:52 ` Glenn Morris 2007-03-16 2:47 ` Miles Bader 2007-03-16 17:31 ` Richard Stallman 2007-03-16 2:56 ` NIIMI Satoshi 2007-03-16 17:31 ` Richard Stallman 2007-03-16 19:24 ` NIIMI Satoshi 2007-03-16 4:08 ` Chong Yidong 2007-03-16 9:38 ` Juanma Barranquero 2007-03-16 9:51 ` Juanma Barranquero 2007-03-16 10:08 ` Kim F. Storm 2007-03-16 15:48 ` Chong Yidong 2007-03-16 16:14 ` Kim F. Storm 2007-03-16 18:54 ` Chong Yidong 2007-03-16 19:22 ` Glenn Morris 2007-03-17 1:32 ` Herbert Euler 2007-03-17 2:19 ` Glenn Morris 2007-03-17 6:28 ` Leo 2007-03-16 16:56 ` Jason Rumney 2007-03-17 2:44 ` Glenn Morris 2007-03-17 17:26 ` Chong Yidong 2007-03-17 19:31 ` Chong Yidong 2007-03-17 23:08 ` Miles Bader 2007-03-17 23:52 ` Kim F. Storm 2007-03-18 0:01 ` Andreas Schwab 2007-03-18 0:25 ` Kim F. Storm 2007-03-18 0:14 ` Lennart Borgman (gmail) 2007-03-18 1:16 ` Chong Yidong 2007-03-18 2:11 ` Lennart Borgman (gmail) 2007-03-18 8:30 ` martin rudalics 2007-03-19 15:45 ` Chong Yidong 2007-03-18 15:56 ` Richard Stallman 2007-03-18 12:19 ` Richard Stallman 2007-03-19 18:28 ` Glenn Morris 2007-03-19 19:46 ` Stefan Monnier 2007-03-16 17:31 ` Richard Stallman 2007-03-17 0:12 ` Nick Roberts 2007-03-17 0:33 ` Miles Bader 2007-03-17 5:00 ` Nick Roberts 2007-03-17 6:02 ` Miles Bader 2007-03-18 12:18 ` Richard Stallman 2007-03-17 15:46 ` Richard Stallman 2007-03-15 23:04 ` Vinicius Jose Latorre 2007-03-16 5:21 ` Richard Stallman 2007-03-15 21:06 ` Glenn Morris 2007-03-15 20:26 ` NIIMI Satoshi 2007-03-15 20:43 ` Nick Roberts 2007-03-15 21:05 ` NIIMI Satoshi 2007-03-14 9:09 ` Davi Leal 2007-03-14 9:39 ` Angelo Graziosi 2007-03-14 10:06 ` Andreas Schwab 2007-03-15 23:35 ` Angelo Graziosi 2007-03-15 23:54 ` Vinicius Jose Latorre 2007-03-20 13:04 ` Pretest Angelo Graziosi 2007-03-10 15:50 ` Killing buffers with mouse Richard Stallman -- strict thread matches above, loose matches on Subject: below -- 2011-09-19 18:52 Pretest Chong Yidong 2011-09-19 21:13 ` Pretest Drew Adams 2011-09-20 15:27 ` Pretest Chong Yidong 2011-09-20 21:13 ` Pretest Andy Moreton 2011-09-20 21:33 ` Pretest Chong Yidong 2011-09-21 1:27 ` Pretest Stefan Monnier 2011-09-21 2:11 ` Pretest Drew Adams 2011-09-19 22:29 ` Pretest Lars Magne Ingebrigtsen 2011-09-20 15:27 ` Pretest Chong Yidong 2007-03-26 3:52 [david.reitter@gmail.com: file-remote-p malfunctions at site-start (file-name-handler-alist init)] Richard Stallman 2007-03-26 4:40 ` Chong Yidong 2007-03-26 13:14 ` Stefan Monnier 2007-03-26 13:37 ` Michael Albinus 2007-03-26 14:16 ` Chong Yidong 2007-03-26 14:44 ` Michael Albinus 2007-03-27 20:59 ` Chong Yidong 2007-03-31 18:47 ` Michael Albinus 2007-03-31 19:41 ` David Kastrup 2007-03-31 20:02 ` Pretest Chong Yidong 2007-03-18 4:28 Pretest Chong Yidong 2007-03-18 4:31 ` Pretest Juanma Barranquero 2007-03-20 1:34 ` Pretest Chong Yidong 2007-03-20 2:05 ` Pretest Juanma Barranquero 2007-03-20 4:40 ` Pretest dhruva 2007-03-20 12:07 ` Pretest AriT93 2007-03-20 12:36 ` Pretest dhruva 2007-03-20 13:14 ` Pretest AriT93 2007-03-21 22:47 ` Pretest Lennart Borgman (gmail) 2006-11-18 22:14 Pretest Chong Yidong 2006-11-18 22:58 ` Pretest Lennart Borgman 2006-11-18 23:32 ` Pretest Chong Yidong 2006-11-19 0:53 ` Pretest Juanma Barranquero 2006-11-19 0:56 ` Pretest Nick Roberts 2006-11-19 1:01 ` Pretest Juanma Barranquero 2006-11-19 1:56 ` Pretest Nick Roberts 2006-11-19 2:04 ` Pretest Juanma Barranquero 2006-11-19 3:29 ` Pretest Nick Roberts 2006-11-19 8:45 ` Pretest David Kastrup 2006-11-19 10:03 ` Pretest Nick Roberts 2006-11-19 10:18 ` Pretest David Kastrup 2006-11-19 11:44 ` Pretest Nick Roberts 2006-11-19 14:13 ` Pretest Juanma Barranquero 2006-11-19 14:24 ` Pretest David Kastrup 2006-11-19 14:42 ` Pretest Juanma Barranquero 2006-11-19 14:45 ` Pretest Lennart Borgman 2006-11-19 15:58 ` Pretest David Kastrup 2006-11-19 19:13 ` Pretest Lennart Borgman 2006-11-19 19:27 ` Pretest David Kastrup 2006-11-20 1:15 ` Pretest Stefan Monnier 2006-11-19 17:54 ` Pretest Jason Rumney 2006-11-19 19:14 ` Pretest Lennart Borgman 2006-11-19 19:50 ` Pretest Jason Rumney 2006-11-19 20:48 ` Pretest David Kastrup 2006-11-19 21:33 ` Pretest Lennart Borgman 2006-11-19 21:33 ` Pretest Jason Rumney 2006-11-19 21:49 ` Pretest David Kastrup 2006-11-19 22:04 ` Pretest Jason Rumney 2006-11-19 22:06 ` Pretest Lennart Borgman 2006-11-19 22:44 ` Pretest David Kastrup 2006-11-19 23:02 ` Pretest Lennart Borgman 2006-11-19 23:31 ` Pretest David Kastrup 2006-11-20 0:59 ` Pretest Lennart Borgman 2006-11-20 1:20 ` Pretest David Kastrup [not found] ` <45616414.2080802@student.lu.se> 2006-11-20 9:55 ` Pretest David Kastrup 2006-11-20 1:20 ` Pretest Stefan Monnier 2006-11-19 21:34 ` Pretest Lennart Borgman 2006-11-19 21:38 ` Pretest Lennart Borgman 2006-11-20 12:59 ` Pretest Richard Stallman 2006-11-19 14:19 ` Pretest Juanma Barranquero 2006-11-20 1:37 ` Pretest Richard Stallman 2006-11-20 3:00 ` Pretest Stefan Monnier 2006-11-20 9:01 ` Pretest Juanma Barranquero 2006-11-20 9:37 ` Pretest Jason Rumney 2006-11-20 10:06 ` Pretest Juanma Barranquero 2006-11-20 10:50 ` Pretest David Kastrup 2006-11-20 10:58 ` Pretest Juanma Barranquero 2006-11-20 15:30 ` Pretest Stefan Monnier 2006-11-20 16:48 ` Pretest Juanma Barranquero 2006-11-20 10:01 ` Pretest David Kastrup 2006-11-20 23:58 ` Pretest Richard Stallman 2006-11-21 0:05 ` Pretest Juanma Barranquero 2006-11-22 13:15 ` Pretest Richard Stallman 2006-11-19 12:48 ` Pretest Richard Stallman 2006-11-19 20:08 ` Pretest Eli Zaretskii 2006-11-19 21:50 ` Pretest Reiner Steib 2006-11-20 12:59 ` Pretest Richard Stallman 2006-11-19 19:59 ` Pretest Eli Zaretskii 2006-11-07 20:13 Pretest Nick Roberts 2006-11-07 22:48 ` Pretest Miles Bader 2006-11-08 1:17 ` Pretest Nick Roberts 2006-11-08 1:41 ` Pretest Miles Bader 2006-10-28 20:33 Pretest Mikko Huhtala 2006-10-27 17:59 Pretest Chong Yidong 2006-10-27 18:52 ` Pretest Paul Pogonyshev 2006-10-27 19:12 ` Pretest David Hansen 2006-10-28 11:31 ` Pretest Eli Zaretskii 2006-11-15 21:35 ` Pretest Reiner Steib 2006-11-15 22:51 ` Pretest Nick Roberts 2006-10-27 19:38 ` Pretest Kim F. Storm 2006-10-28 11:17 ` Pretest Eli Zaretskii 2006-10-29 18:45 ` Pretest Richard Stallman 2006-10-29 20:20 ` Pretest Eli Zaretskii 2006-10-27 20:01 ` Pretest joakim 2006-10-27 21:11 ` Pretest Giorgos Keramidas 2006-10-28 2:30 ` Pretest Andrew M. Scott 2006-10-28 8:11 ` Pretest Yoni Rabkin Katzenell 2006-10-28 8:46 ` Pretest Andreas Roehler 2006-10-28 11:01 ` Pretest Jason Rumney 2006-10-28 13:14 ` Pretest Eli Zaretskii 2006-10-28 21:47 ` Pretest Jason Rumney 2006-10-29 4:30 ` Pretest Eli Zaretskii 2006-10-29 11:17 ` Pretest Jason Rumney 2006-10-29 11:47 ` Pretest Eli Zaretskii 2006-10-30 13:33 ` Pretest Richard Stallman 2006-10-30 21:12 ` Pretest Eli Zaretskii 2006-11-01 2:12 ` Pretest Richard Stallman 2006-11-04 12:15 ` Pretest Eli Zaretskii 2006-11-04 22:23 ` Pretest Jason Rumney 2006-11-05 6:15 ` Pretest Eli Zaretskii 2006-11-05 12:39 ` Pretest Jason Rumney 2006-11-05 12:41 ` Pretest Jason Rumney 2006-10-28 11:13 ` Pretest Eli Zaretskii 2006-10-28 13:30 ` Pretest Benjamin Riefenstahl 2006-10-28 15:25 ` Pretest Chong Yidong 2006-10-28 13:38 ` Pretest Eli Zaretskii 2006-10-28 15:53 ` Pretest Chong Yidong 2006-10-28 19:05 ` Pretest Eli Zaretskii 2006-10-29 21:36 ` Pretest Chong Yidong 2006-10-30 4:25 ` Pretest Eli Zaretskii 2006-10-30 14:21 ` Pretest Chong Yidong 2006-10-28 14:28 ` Pretest Eli Zaretskii 2006-10-28 15:01 ` Pretest Chong Yidong 2006-10-28 19:28 ` Pretest Eli Zaretskii 2006-10-28 20:47 ` Pretest Chong Yidong 2006-10-29 7:43 ` Pretest Eli Zaretskii 2006-10-29 22:11 ` Pretest Chong Yidong 2006-10-30 21:50 ` Pretest Eli Zaretskii 2006-10-30 22:04 ` Pretest Chong Yidong 2006-10-31 4:09 ` Pretest Eli Zaretskii 2006-10-30 13:33 ` Pretest Richard Stallman 2006-10-30 21:02 ` Pretest Eli Zaretskii 2006-11-01 2:12 ` Pretest Richard Stallman 2006-11-01 4:14 ` Pretest Eli Zaretskii 2006-11-02 4:42 ` Pretest Richard Stallman 2006-11-02 19:54 ` Pretest Eli Zaretskii 2006-11-03 7:08 ` Pretest Richard Stallman 2006-11-04 13:50 ` Pretest Eli Zaretskii 2006-11-05 7:08 ` Pretest Richard Stallman [not found] ` <cyd@stupidchicken.com> 2006-10-28 15:08 ` Pretest Alfred M. Szmidt 2006-10-28 20:52 ` Pretest Chong Yidong 2006-10-28 21:11 ` Pretest Alfred M. Szmidt 2006-10-28 22:09 ` Pretest Chong Yidong 2006-10-28 22:30 ` Pretest Alfred M. Szmidt 2006-10-29 23:40 ` Pretest Chong Yidong 2006-10-30 0:33 ` Pretest Alfred M. Szmidt 2006-10-30 14:12 ` Pretest Chong Yidong 2006-10-30 19:57 ` Pretest Alfred M. Szmidt 2006-10-30 20:18 ` Pretest Chong Yidong 2006-10-30 20:34 ` Pretest Alfred M. Szmidt 2006-10-30 22:18 ` Pretest Chong Yidong 2006-10-30 23:00 ` Pretest Alfred M. Szmidt 2006-11-01 2:12 ` Pretest Richard Stallman 2006-11-02 14:10 ` Pretest Alfred M. Szmidt 2006-10-28 18:13 ` Pretest Richard Stallman 2006-10-28 19:02 ` Pretest Eli Zaretskii 2006-10-29 18:49 ` Pretest Richard Stallman 2006-10-29 20:22 ` Pretest Eli Zaretskii 2006-10-30 19:16 ` Pretest Richard Stallman 2006-11-03 15:39 ` Pretest Drew Adams 2006-11-03 19:22 ` Pretest Eli Zaretskii 2006-11-03 19:51 ` Pretest Lennart Borgman 2006-11-03 20:02 ` Pretest Eli Zaretskii 2006-11-03 20:48 ` Pretest Nick Roberts 2006-11-04 15:26 ` Pretest Richard Stallman 2006-10-30 20:04 ` Pretest Paul Jarc 2006-10-30 23:13 ` Pretest Chong Yidong 2006-10-31 9:44 ` Pretest Jim Thompson 2006-11-05 23:30 ` Pretest Bill Wohler 2006-11-06 0:01 ` Pretest Jason Rumney 2006-11-06 4:22 ` Pretest 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.