On the rebasing problem of Emacs on Cygwin

On the rebasing problem of Emacs on Cygwin

[Angelo Graziosi]

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.

Re: On the rebasing problem of Emacs on Cygwin

[Eli Zaretskii]

> 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.

WARNING from config.status on Cygwin

[Angelo Graziosi]

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. 

Re: WARNING from config.status on Cygwin

[Andreas Schwab]

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."

Problems building recent Emacs-CVS on Cygwin

[Angelo Graziosi]

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.

Re: cygwin succesfull straight build

[Angelo Graziosi]

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.

Re: cygwin succesfull straight build

[Eli Zaretskii]

> 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.

Re: Pretest?

[Angelo Graziosi]

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.

Re: Pretest?

[Chong Yidong]

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.

Re: Pretest?

[Giorgos Keramidas]

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?

Re: Pretest?

[Chong Yidong]

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?

Re: Pretest?

[Christian Faulhammer]

[-- 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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Chong Yidong]

"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).

Re: Pretest?

[Eli Zaretskii]

> 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.

Re: Pretest?

[Giorgos Keramidas]

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 :)

Re: Pretest?

[Richard Stallman]

    I would like to suggest issuing a pretest on Monday the 12th.  What do
    people think?

Sounds good to me.

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[David Kastrup]

"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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Stefan Monnier]

> 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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[David Kastrup]

"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

Re: Pretest?

[Chong Yidong]

"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).

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Chong Yidong]

"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.

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Richard Stallman]

    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.

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Andreas Schwab]

"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."

Re: Pretest?

[David Kastrup]

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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Richard Stallman]

	;; 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.

Re: Pretest?

[Richard Stallman]

    > 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.

Re: Pretest?

[David Kastrup]

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

Re: Pretest?

[Stefan Monnier]

> 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.

Re: Pretest?

[David Kastrup]

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

Re: Pretest?

[Stefan Monnier]

>>> 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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[David Kastrup]

"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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[David Kastrup]

"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

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Chong Yidong]

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.

Re: Pretest?

[Stefan Monnier]

> 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

Re: Pretest?

[Richard Stallman]

    > 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.

Re: Pretest?

[Juanma Barranquero]

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

Re: Pretest?

[Richard Stallman]

    (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.

Re: Pretest?

[Chong Yidong]

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.

Re: Pretest?

[Richard Stallman]

    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.

Re: Pretest?

[David Kastrup]

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

Re: Help: build emacs in cygwin

[Angelo Graziosi]

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.

Killing buffers with mouse

[Angelo Graziosi]

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.

Re: Killing buffers with mouse

[Chong Yidong]

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.

Re: Killing buffers with mouse

[Jan Djärv]

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.

Re: Killing buffers with mouse

[Stefan Monnier]

> 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.

Re: Killing buffers with mouse

[Jan Djärv]

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.

Re: Killing buffers with mouse

[Kim F. Storm]

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

Re: Killing buffers with mouse

[Jan Djärv]

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.

Emacs and GTK

[Angelo Graziosi]

[-- 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

Re: Emacs and GTK

[David Kastrup]

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

Re: Emacs and GTK

[Angelo Graziosi]

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.

Re: Emacs and GTK

[Tassilo Horn]

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.

Re: Killing buffers with mouse

[Stefan Monnier]

>> 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

Re: Killing buffers with mouse

[Kim F. Storm]

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

Re: Killing buffers with mouse

[Stefan Monnier]

> 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

Re: Killing buffers with mouse

[Eli Zaretskii]

> 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".)

Re: Killing buffers with mouse

[Angelo Graziosi]

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.

Re: Killing buffers with mouse

[Eli Zaretskii]

> 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.

Connection to emacs CVS broken ?

[Angelo Graziosi]

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.

Re: Connection to emacs CVS broken ?

[David Kastrup]

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

Re: Connection to emacs CVS broken ?

[Glenn Morris]

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)

Re: Connection to emacs CVS broken ?

[Kim F. Storm]

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

Re: Connection to emacs CVS broken ?

[Glenn Morris]

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.

Re: Connection to emacs CVS broken ?

[Glenn Morris]

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.

Re: Connection to emacs CVS broken ?

[Eli Zaretskii]

> 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"?

Re: Connection to emacs CVS broken ?

[Giorgos Keramidas]

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

Re: Connection to emacs CVS broken ?

[Richard Stallman]

    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!

Re: Connection to emacs CVS broken ?

[ttn]

   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 ""))))))

Re: Connection to emacs CVS broken ?

[James Cloos]

>>>>> "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

Re: Connection to emacs CVS broken ?

[Chong Yidong]

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?

Re: Connection to emacs CVS broken ?

[Nick Roberts]

 > 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

Re: Connection to emacs CVS broken ?

[Jason Rumney]

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.

Re: Connection to emacs CVS broken ?

[Miles Bader]

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

Re: Connection to emacs CVS broken ?

[NIIMI Satoshi]

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

Re: Connection to emacs CVS broken ?

[Vinicius Jose Latorre]

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?

Re: Connection to emacs CVS broken ?

[Miles Bader]

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

Re: Connection to emacs CVS broken ?

[Kenichi Handa]

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

Re: Connection to emacs CVS broken ?

[Herbert Euler]

>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/

[DIFFS] Re: Connection to emacs CVS broken ?

[Kim F. Storm]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Nick Roberts]

 > > 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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Miles Bader]

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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Glenn Morris]

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...

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Miles Bader]

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]

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

    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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[NIIMI Satoshi]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

    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?

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[NIIMI Satoshi]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Juanma Barranquero]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Juanma Barranquero]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Kim F. Storm]

"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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Kim F. Storm]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

>> 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?

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Glenn Morris]

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).

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Herbert Euler]

>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/

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Glenn Morris]

"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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Leo]

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)

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Jason Rumney]

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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Glenn Morris]

"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>

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Miles Bader]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Kim F. Storm]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Andreas Schwab]

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."

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Kim F. Storm]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Lennart Borgman (gmail)]

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.)

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

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:

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Lennart Borgman (gmail)]

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?

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[martin rudalics]

[-- 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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> You probably want the attached one.

Thanks, I checked it in.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

    >                         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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

    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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Glenn Morris]

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?

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Stefan Monnier]

> 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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

Do not use a method that will lose the CVS logs.  That would be a
terrible mistake.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Nick Roberts]

 > 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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Miles Bader]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Nick Roberts]

 > > 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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Miles Bader]

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

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

     > 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.

Re: [DIFFS] Re: Connection to emacs CVS broken ?

[Richard Stallman]

     > 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?

Re: Connection to emacs CVS broken ?

[Vinicius Jose Latorre]

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.

Re: Connection to emacs CVS broken ?

[Richard Stallman]

    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!

Re: Connection to emacs CVS broken ?

[Glenn Morris]

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.

Re: Connection to emacs CVS broken ?

[NIIMI Satoshi]

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

Re: Connection to emacs CVS broken ?

[Nick Roberts]

 > > 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

Re: Connection to emacs CVS broken ?

[NIIMI Satoshi]

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

Re: Connection to emacs CVS broken ?

[Davi Leal]

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

Re: Connection to emacs CVS broken ?

[Angelo Graziosi]

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.

Re: Connection to emacs CVS broken ?

[Andreas Schwab]

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."

Re: Connection to emacs CVS broken ?

[Angelo Graziosi]

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.

Re: Connection to emacs CVS broken ?

[Vinicius Jose Latorre]

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.

Re: Pretest

[Angelo Graziosi]

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.

Re: Killing buffers with mouse

[Richard Stallman]

    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.

Re: Killing buffers with mouse

[Angelo Graziosi]

It seems that also the other icons on the toolbar are affected by the
wheel of the mouse, i.e. moving the wheel on the icons is equivalent to
click with MOUSE-1 on the same icon.

For example moving the wheel on the icon called 'Read a directory, to
operate on its file' causes in the minibuf.:

   Dired (directory): /tmp/


and similar behaviour for the other icons.


   Angelo.