* 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 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 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-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 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-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: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-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-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-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
[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 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-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-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 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 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 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
* 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 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 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: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 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-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 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-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-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: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-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-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 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-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-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-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-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 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 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-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-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-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 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 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 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-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 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: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-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-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-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-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-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-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-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-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-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-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-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-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-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-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
* 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
` (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
* 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 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
* 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-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 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 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 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 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 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 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 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 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-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-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 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 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 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 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: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-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-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
* 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 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
[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-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: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-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 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-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 ` 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
* 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: 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
* 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
* 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: 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: 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 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: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: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: 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: 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 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
* 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 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 ` 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: 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
* 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
* 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: 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-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 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-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
* 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: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: 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: 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
* 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: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: 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: 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: 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: 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: 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 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 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: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 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: 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: 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: 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: 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: 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 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: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: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: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: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-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 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 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 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-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
* [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: 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: [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 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: 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: [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: 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: 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 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: 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-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-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
* 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: [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: 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: [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 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 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 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 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 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 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 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-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-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 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 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-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: [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-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-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 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
* 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: [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-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 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 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: 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: [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 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: 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-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: 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
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
@ 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 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
* 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
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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).