Need help with ad-do-it, it loops

Need help with ad-do-it, it loops

[Lennart Borgman]

I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
this problem on Debian. This happens after starting from "emacs -Q"
and just loading nXhtml and pressing RET in the scratch buffer. The
output from the debugger says

Debugger entered--Lisp error: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")
  ad-Orig-syntax-ppss-flush-cache(192 192)
  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
  ...
  ad-Orig-syntax-ppss-flush-cache(192 192)
  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
  syntax-ppss-flush-cache(192 192)
  self-insert-command(1)
  newline(nil)
  call-interactively(newline nil nil)



When Rémi set max-lisp-eval-depth to 100000 it loops a bit different:

Debugger entered--Lisp error: (error "Variable binding depth exceeds
max-specpdl-size")
  ad-Orig-syntax-ppss-flush-cache(270 270)
  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
  ...
  ad-Orig-syntax-ppss-flush-cache(270 270)
  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
  syntax-ppss-flush-cache(270 270)
  self-insert-command(1)
  newline(nil)
  call-interactively(newline nil nil)



**** I have this defadvise in mumamo.el (in buffer *Scratch*
mumamo-multi-major-mode is nil):

(defadvice syntax-ppss-flush-cache (around
                                    mumamo-advice-syntax-ppss-flush-cache
                                    activate
                                    compile
                                    )
  "Support for mumamo.
See the defadvice for `syntax-ppss' for an explanation."
  (if (not mumamo-multi-major-mode)
      ad-do-it
    (let ((pos (ad-get-arg 0)))
      (let* ((chunk-at-pos (when (and (boundp 'mumamo-multi-major-mode)
                                      mumamo-multi-major-mode)
                             (mumamo-find-chunks pos
"syntax-ppss-flush-cache"))))
        (if chunk-at-pos
            (let* ((syntax-ppss-last  (overlay-get chunk-at-pos
'syntax-ppss-last))
                   (syntax-ppss-cache (overlay-get chunk-at-pos
'syntax-ppss-cache)))
              (setq ad-return-value ad-do-it)
              (overlay-put chunk-at-pos 'syntax-ppss-last syntax-ppss-last)
              (overlay-put chunk-at-pos 'syntax-ppss-cache syntax-ppss-cache))
          (setq ad-return-value ad-do-it))))))



I can't understand how this can loop. Any suggestions? Am I perhaps
using ad-do-it incorrectly? The manual does not explicitly say it
returns the value from the original function, but my understanding is
that it does.

(For more information see https://bugs.launchpad.net/nxhtml/+bug/369800)

AW: Need help with ad-do-it, it loops

[klaus.berndl]

Just an assumption:

I think that ad-do-it already sets the return argument (must be because otherwise advices which do jst ad-do-it would not work) and maybe your construction

(setq ad-return-value ad-do-it)

causes the loop...at least i never saw such a combination)

Klaus



-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [mailto:emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] Im Auftrag von Lennart Borgman
Gesendet: Freitag, 8. Mai 2009 00:16
An: Emacs-Devel devel
Betreff: Need help with ad-do-it, it loops

I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has this problem on Debian. This happens after starting from "emacs -Q"
and just loading nXhtml and pressing RET in the scratch buffer. The output from the debugger says

Debugger entered--Lisp error: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")
  ad-Orig-syntax-ppss-flush-cache(192 192)
  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
  ...
  ad-Orig-syntax-ppss-flush-cache(192 192)
  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
  syntax-ppss-flush-cache(192 192)
  self-insert-command(1)
  newline(nil)
  call-interactively(newline nil nil)



When Rémi set max-lisp-eval-depth to 100000 it loops a bit different:

Debugger entered--Lisp error: (error "Variable binding depth exceeds
max-specpdl-size")
  ad-Orig-syntax-ppss-flush-cache(270 270)
  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
  ...
  ad-Orig-syntax-ppss-flush-cache(270 270)
  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
  syntax-ppss-flush-cache(270 270)
  self-insert-command(1)
  newline(nil)
  call-interactively(newline nil nil)



**** I have this defadvise in mumamo.el (in buffer *Scratch* mumamo-multi-major-mode is nil):

(defadvice syntax-ppss-flush-cache (around
                                    mumamo-advice-syntax-ppss-flush-cache
                                    activate
                                    compile
                                    )
  "Support for mumamo.
See the defadvice for `syntax-ppss' for an explanation."
  (if (not mumamo-multi-major-mode)
      ad-do-it
    (let ((pos (ad-get-arg 0)))
      (let* ((chunk-at-pos (when (and (boundp 'mumamo-multi-major-mode)
                                      mumamo-multi-major-mode)
                             (mumamo-find-chunks pos
"syntax-ppss-flush-cache"))))
        (if chunk-at-pos
            (let* ((syntax-ppss-last  (overlay-get chunk-at-pos
'syntax-ppss-last))
                   (syntax-ppss-cache (overlay-get chunk-at-pos
'syntax-ppss-cache)))
              (setq ad-return-value ad-do-it)
              (overlay-put chunk-at-pos 'syntax-ppss-last syntax-ppss-last)
              (overlay-put chunk-at-pos 'syntax-ppss-cache syntax-ppss-cache))
          (setq ad-return-value ad-do-it))))))



I can't understand how this can loop. Any suggestions? Am I perhaps using ad-do-it incorrectly? The manual does not explicitly say it returns the value from the original function, but my understanding is that it does.

(For more information see https://bugs.launchpad.net/nxhtml/+bug/369800)

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

Thanks Klaus, yes, ad-return-value should already hold the value from
the original function at that point. I will replace it with just

    ad-do-it

and see if it fixes the problem for Debian users.


On Fri, May 8, 2009 at 11:01 AM,  <klaus.berndl@capgemini-sdm.com> wrote:
> Just an assumption:
>
> I think that ad-do-it already sets the return argument (must be because otherwise advices which do jst ad-do-it would not work) and maybe your construction
>
> (setq ad-return-value ad-do-it)
>
> causes the loop...at least i never saw such a combination)
>
> Klaus
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [mailto:emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] Im Auftrag von Lennart Borgman
> Gesendet: Freitag, 8. Mai 2009 00:16
> An: Emacs-Devel devel
> Betreff: Need help with ad-do-it, it loops
>
> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has this problem on Debian. This happens after starting from "emacs -Q"
> and just loading nXhtml and pressing RET in the scratch buffer. The output from the debugger says
>
> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>  ad-Orig-syntax-ppss-flush-cache(192 192)
>  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>  ...
>  ad-Orig-syntax-ppss-flush-cache(192 192)
>  apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>  syntax-ppss-flush-cache(192 192)
>  self-insert-command(1)
>  newline(nil)
>  call-interactively(newline nil nil)
>
>
>
> When Rémi set max-lisp-eval-depth to 100000 it loops a bit different:
>
> Debugger entered--Lisp error: (error "Variable binding depth exceeds
> max-specpdl-size")
>  ad-Orig-syntax-ppss-flush-cache(270 270)
>  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
>  ...
>  ad-Orig-syntax-ppss-flush-cache(270 270)
>  apply(ad-Orig-syntax-ppss-flush-cache 270 270)
>  syntax-ppss-flush-cache(270 270)
>  self-insert-command(1)
>  newline(nil)
>  call-interactively(newline nil nil)
>
>
>
> **** I have this defadvise in mumamo.el (in buffer *Scratch* mumamo-multi-major-mode is nil):
>
> (defadvice syntax-ppss-flush-cache (around
>                                    mumamo-advice-syntax-ppss-flush-cache
>                                    activate
>                                    compile
>                                    )
>  "Support for mumamo.
> See the defadvice for `syntax-ppss' for an explanation."
>  (if (not mumamo-multi-major-mode)
>      ad-do-it
>    (let ((pos (ad-get-arg 0)))
>      (let* ((chunk-at-pos (when (and (boundp 'mumamo-multi-major-mode)
>                                      mumamo-multi-major-mode)
>                             (mumamo-find-chunks pos
> "syntax-ppss-flush-cache"))))
>        (if chunk-at-pos
>            (let* ((syntax-ppss-last  (overlay-get chunk-at-pos
> 'syntax-ppss-last))
>                   (syntax-ppss-cache (overlay-get chunk-at-pos
> 'syntax-ppss-cache)))
>              (setq ad-return-value ad-do-it)
>              (overlay-put chunk-at-pos 'syntax-ppss-last syntax-ppss-last)
>              (overlay-put chunk-at-pos 'syntax-ppss-cache syntax-ppss-cache))
>          (setq ad-return-value ad-do-it))))))
>
>
>
> I can't understand how this can loop. Any suggestions? Am I perhaps using ad-do-it incorrectly? The manual does not explicitly say it returns the value from the original function, but my understanding is that it does.
>
> (For more information see https://bugs.launchpad.net/nxhtml/+bug/369800)
>
>
>

Re: Need help with ad-do-it, it loops

[Stefan Monnier]

> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
> this problem on Debian. This happens after starting from "emacs -Q"
> and just loading nXhtml and pressing RET in the scratch buffer. The
> output from the debugger says

> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>   ad-Orig-syntax-ppss-flush-cache(192 192)
>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>   ...
>   ad-Orig-syntax-ppss-flush-cache(192 192)
>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>   syntax-ppss-flush-cache(192 192)
>   self-insert-command(1)
>   newline(nil)
>   call-interactively(newline nil nil)
[...]
> I can't understand how this can loop. Any suggestions?

Well, since you carefully hid the answer in "...", we can't
really answer.


        Stefan

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

On Fri, May 8, 2009 at 3:26 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
>> this problem on Debian. This happens after starting from "emacs -Q"
>> and just loading nXhtml and pressing RET in the scratch buffer. The
>> output from the debugger says
>
>> Debugger entered--Lisp error: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>   ...
>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>   syntax-ppss-flush-cache(192 192)
>>   self-insert-command(1)
>>   newline(nil)
>>   call-interactively(newline nil nil)
> [...]
>> I can't understand how this can loop. Any suggestions?
>
> Well, since you carefully hid the answer in "...", we can't
> really answer.

It just looping with the output

>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)

Re: Need help with ad-do-it, it loops

[Stefan Monnier]

>>> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
>>> this problem on Debian. This happens after starting from "emacs -Q"
>>> and just loading nXhtml and pressing RET in the scratch buffer. The
>>> output from the debugger says
>> 
>>> Debugger entered--Lisp error: (error "Lisp nesting exceeds
>>> `max-lisp-eval-depth'")
>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>   ...
>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>   syntax-ppss-flush-cache(192 192)
>>>   self-insert-command(1)
>>>   newline(nil)
>>>   call-interactively(newline nil nil)
>> [...]
>>> I can't understand how this can loop. Any suggestions?
>> 
>> Well, since you carefully hid the answer in "...", we can't
>> really answer.

> It just looping with the output

So ad-Orig-syntax-ppss-flush-cache is now a function that calls
ad-Orig-syntax-ppss-flush-cache rather than being the original function
bound to syntax-ppss-flush-cache.  This shouldn't happen.
To see it, try M-: (symbol-function 'ad-Orig-syntax-ppss-flush-cache).

It means that it's either a bug in advice.el or that the function was
manipulated in odd ways which confused advice, or something like that.


        Stefan

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

On Fri, May 8, 2009 at 9:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
>>>> this problem on Debian. This happens after starting from "emacs -Q"
>>>> and just loading nXhtml and pressing RET in the scratch buffer. The
>>>> output from the debugger says
>>>
>>>> Debugger entered--Lisp error: (error "Lisp nesting exceeds
>>>> `max-lisp-eval-depth'")
>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>   ...
>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>   syntax-ppss-flush-cache(192 192)
>>>>   self-insert-command(1)
>>>>   newline(nil)
>>>>   call-interactively(newline nil nil)
>>> [...]
>>>> I can't understand how this can loop. Any suggestions?
>>>
>>> Well, since you carefully hid the answer in "...", we can't
>>> really answer.
>
>> It just looping with the output
>
> So ad-Orig-syntax-ppss-flush-cache is now a function that calls
> ad-Orig-syntax-ppss-flush-cache rather than being the original function
> bound to syntax-ppss-flush-cache.  This shouldn't happen.
> To see it, try M-: (symbol-function 'ad-Orig-syntax-ppss-flush-cache).
>
> It means that it's either a bug in advice.el or that the function was
> manipulated in odd ways which confused advice, or something like that.

I have asked Rémi to check this. It looks like this problem disappears
when he compiles Emacs himself from CVS.

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

2009/5/8 Lennart Borgman <lennart.borgman@gmail.com>:
> On Fri, May 8, 2009 at 9:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
>>>>> this problem on Debian. This happens after starting from "emacs -Q"
>>>>> and just loading nXhtml and pressing RET in the scratch buffer. The
>>>>> output from the debugger says
>>>>
>>>>> Debugger entered--Lisp error: (error "Lisp nesting exceeds
>>>>> `max-lisp-eval-depth'")
>>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>>   ...
>>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>>   syntax-ppss-flush-cache(192 192)
>>>>>   self-insert-command(1)
>>>>>   newline(nil)
>>>>>   call-interactively(newline nil nil)
>>>> [...]
>>>>> I can't understand how this can loop. Any suggestions?
>>>>
>>>> Well, since you carefully hid the answer in "...", we can't
>>>> really answer.
>>
>>> It just looping with the output
>>
>> So ad-Orig-syntax-ppss-flush-cache is now a function that calls
>> ad-Orig-syntax-ppss-flush-cache rather than being the original function
>> bound to syntax-ppss-flush-cache.  This shouldn't happen.
>> To see it, try M-: (symbol-function 'ad-Orig-syntax-ppss-flush-cache).
>>
>> It means that it's either a bug in advice.el or that the function was
>> manipulated in odd ways which confused advice, or something like that.
>
> I have asked Rémi to check this. It looks like this problem disappears
> when he compiles Emacs himself from CVS.

Rémi has answered, please see
https://bugs.launchpad.net/nxhtml/+bug/369800. (I can not copy and
paste the answers here since the output contains "binary characters".)

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

2009/5/8 Lennart Borgman <lennart.borgman@gmail.com>:
> 2009/5/8 Lennart Borgman <lennart.borgman@gmail.com>:
>> On Fri, May 8, 2009 at 9:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>>> I have a strange case of looping in MuMaMo/nXhtml. One user (Rémi) has
>>>>>> this problem on Debian. This happens after starting from "emacs -Q"
>>>>>> and just loading nXhtml and pressing RET in the scratch buffer. The
>>>>>> output from the debugger says
>>>>>
>>>>>> Debugger entered--Lisp error: (error "Lisp nesting exceeds
>>>>>> `max-lisp-eval-depth'")
>>>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>>>   ...
>>>>>>   ad-Orig-syntax-ppss-flush-cache(192 192)
>>>>>>   apply(ad-Orig-syntax-ppss-flush-cache 192 192)
>>>>>>   syntax-ppss-flush-cache(192 192)
>>>>>>   self-insert-command(1)
>>>>>>   newline(nil)
>>>>>>   call-interactively(newline nil nil)
>>>>> [...]
>>>>>> I can't understand how this can loop. Any suggestions?
>>>>>
>>>>> Well, since you carefully hid the answer in "...", we can't
>>>>> really answer.
>>>
>>>> It just looping with the output
>>>
>>> So ad-Orig-syntax-ppss-flush-cache is now a function that calls
>>> ad-Orig-syntax-ppss-flush-cache rather than being the original function
>>> bound to syntax-ppss-flush-cache.  This shouldn't happen.
>>> To see it, try M-: (symbol-function 'ad-Orig-syntax-ppss-flush-cache).
>>>
>>> It means that it's either a bug in advice.el or that the function was
>>> manipulated in odd ways which confused advice, or something like that.
>>
>> I have asked Rémi to check this. It looks like this problem disappears
>> when he compiles Emacs himself from CVS.
>
> Rémi has answered, please see
> https://bugs.launchpad.net/nxhtml/+bug/369800. (I can not copy and
> paste the answers here since the output contains "binary characters".)

It looks like there is still some problem with the Emacs snap-shot on
Debian/Ubuntu. For example syntax-ppss-flush-cache shows up adviced in
the Emacs that Rémi built himself from CVS, but not in the snapshot
that Rémi have been using:

  "(Rémi's) version of emacs-snapshot is 1:20090501-1, taken on
http://emacs.orebokech.com/ for debian sid"

I do not know at all how this is organized. Romain and/or Sven, can
you please help us with this?

Re: Need help with ad-do-it, it loops

[Sven Joachim]

On 2009-05-09 12:53 +0200, Lennart Borgman wrote:

> It looks like there is still some problem with the Emacs snap-shot on
> Debian/Ubuntu. For example syntax-ppss-flush-cache shows up adviced in
> the Emacs that Rémi built himself from CVS, but not in the snapshot
> that Rémi have been using:
>
>   "(Rémi's) version of emacs-snapshot is 1:20090501-1, taken on
> http://emacs.orebokech.com/ for debian sid"
>
> I do not know at all how this is organized. Romain and/or Sven, can
> you please help us with this?

AIUI, when started with -Q, the biggest difference between
emacs-snapshot and an Emacs compiled from CVS is the value of load-path,
which includes all Debian add-on packages in emacs-snapshot.  But
autoloads for them are not set up in this case.

M-x list-load-path-shadows might tell whether emacs-snapshot loads some
incompatible library.

Sven

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

On Sat, May 9, 2009 at 7:06 PM, Sven Joachim <svenjoac@gmx.de> wrote:
> On 2009-05-09 12:53 +0200, Lennart Borgman wrote:
>
>> It looks like there is still some problem with the Emacs snap-shot on
>> Debian/Ubuntu. For example syntax-ppss-flush-cache shows up adviced in
>> the Emacs that Rémi built himself from CVS, but not in the snapshot
>> that Rémi have been using:
>>
>>   "(Rémi's) version of emacs-snapshot is 1:20090501-1, taken on
>> http://emacs.orebokech.com/ for debian sid"
>>
>> I do not know at all how this is organized. Romain and/or Sven, can
>> you please help us with this?
>
> AIUI, when started with -Q, the biggest difference between
> emacs-snapshot and an Emacs compiled from CVS is the value of load-path,
> which includes all Debian add-on packages in emacs-snapshot.  But
> autoloads for them are not set up in this case.
>
> M-x list-load-path-shadows might tell whether emacs-snapshot loads some
> incompatible library.

Thanks Sven, I have asked Rémi to check it.

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

After trying to fix some bugs in nXhtml I still get reports from
Debian/Ubuntu users that it does not work with the Emacs snap-shots,
but it does if they compile Emacs themselves from CVS. The only things
I can think of that differs are:

- Source code: date seems unimportant, the snap-shots are fairly new.

- load-path: The list-load-path-shadows command does not show anything
special (at least not for Rémi, see
https://bugs.launchpad.net/nxhtml/+bug/369800).

- Debian's special startup.el: Not sure, but was not this just about load-path?

Anyone who can think of something else?

I have asked Romain for a diff (see below), but I am unsure if that
could be non-zero. Can someone please help us with this? Does "cvs
update" ensure that the diff is zero (as Romain assumes below)?


On Sun, May 10, 2009 at 12:44 AM, Romain Francoise <romain@orebokech.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> I have noticed that CVS can get out of synch so to say. At the end
>> of fetching from CVS (which I do in a loop to make sure that
>> everything is up to date) I have something like this
>
>>     cvs diff -b -u 2>&1 > %diff-file%
>
>> Do you do something like this too?
>
> Nope, but I usually do a cvs up just after checking out the tree
> just to make sure.  CVS checkouts aren't atomic, but my connection
> to Savannah is fast enough that the chances of having an incomplete
> change are pretty slim.
>

Re: Need help with ad-do-it, it loops

[Romain Francoise]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> I have asked Romain for a diff (see below), but I am unsure if
> that could be non-zero.

?!

As I told you in private mail already, I do a clean checkout every
time, there is absolutely no chance that the tree can have local
changes right after checkout.

But since you don't seem to believe it, here's the output of `cvs
diff' in my last snapshot directory:

$ pwd
/home/romain/Work/Debian/emacs-snapshot/tarballs/emacs-snapshot-20090509
$ cvs diff
$

Happy now?

Also, note that it doesn't actually tell you anything since the
Debian packaging applies a few patches, see:

 http://git.orebokech.com/?p=debian/emacs-snapshot.git;a=tree;f=patches

> Can someone please help us with this? Does "cvs update" ensure
> that the diff is zero (as Romain assumes below)?

You don't understand.  I do a cvs up to make sure that if someone
was doing a checkin in the time I was doing the checkout, my local
checkout contains everything.  That's needed because 1) people
commit each file separately in Emacs and 2) I'm not sure if CVS
checkouts are atomic by nature (although nowadays, they could be).

Re: Need help with ad-do-it, it loops

[Lennart Borgman]

On Mon, May 11, 2009 at 4:51 PM, Romain Francoise <romain@orebokech.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> I have asked Romain for a diff (see below), but I am unsure if
>> that could be non-zero.
>
> ?!
>
> As I told you in private mail already, I do a clean checkout every
> time, there is absolutely no chance that the tree can have local
> changes right after checkout.

Ah, thanks. Sorry, I did not understand that you make a clean checkout
every time.


> But since you don't seem to believe it, here's the output of `cvs
> diff' in my last snapshot directory:
>
> $ pwd
> /home/romain/Work/Debian/emacs-snapshot/tarballs/emacs-snapshot-20090509
> $ cvs diff
> $
>
> Happy now?

Yes.


> Also, note that it doesn't actually tell you anything since the
> Debian packaging applies a few patches, see:
>
>  http://git.orebokech.com/?p=debian/emacs-snapshot.git;a=tree;f=patches

Thanks.

I would be glad if anyone could point to something there that could
possibly break Emacs' advice machinery. (I am not sure anything there
does, but as one can see in bug report
https://bugs.launchpad.net/nxhtml/+bug/369800 for nXhtml something
related to the snap-shots breaks it.)


>> Can someone please help us with this? Does "cvs update" ensure
>> that the diff is zero (as Romain assumes below)?
>
> You don't understand.  I do a cvs up to make sure that if someone
> was doing a checkin in the time I was doing the checkout, my local
> checkout contains everything.  That's needed because 1) people
> commit each file separately in Emacs and 2) I'm not sure if CVS
> checkouts are atomic by nature (although nowadays, they could be).

I see. Thanks.