Re: special-display-buffer-names and vc-diff displays wrong result

Re: special-display-buffer-names and vc-diff displays wrong result

[Richard M. Stallman]

    I am using `special-display-buffer-names' for the *vc-diff* buffer.
    If the special-display-buffer frame does not exist then the *vc-diff*
    buffer reports sometimes "No differences found.". This seems to due
    the fact that the 'vc-diff-internal' function has not written yet any
    bytes into the *vc-diff* buffer.

How would the fact that the buffer is empty have such an effect?
Can you work out the chain of events?

     The strange part is that this only
    happens if the background process ends up very fast. For example a
    diff with the cvs.gnu.org server finishes always successfully, but a
    diff with the local cvs server fails.

    I don't know how to fix this. As a workaround I put after the
    vc-diff-internal function a (sit-for 1) statement. Then it seems to
    work.

If you can deduce how this change has the effect of preventing the
problem, then we would understand the problem, and then we could look
for the right fix.

Re: special-display-buffer-names and vc-diff displays wrong result

[Stefan Monnier]

>     I am using `special-display-buffer-names' for the *vc-diff* buffer.
>     If the special-display-buffer frame does not exist then the *vc-diff*
>     buffer reports sometimes "No differences found.". This seems to due
>     the fact that the 'vc-diff-internal' function has not written yet any
>     bytes into the *vc-diff* buffer.

> How would the fact that the buffer is empty have such an effect?
> Can you work out the chain of events?

To figure out whether there's been diffs or not, the sentinel function
checks whether the resulting buffer is empty.

>      The strange part is that this only
>     happens if the background process ends up very fast. For example a
>     diff with the cvs.gnu.org server finishes always successfully, but a
>     diff with the local cvs server fails.

>     I don't know how to fix this. As a workaround I put after the
>     vc-diff-internal function a (sit-for 1) statement. Then it seems to
>     work.

> If you can deduce how this change has the effect of preventing the
> problem, then we would understand the problem, and then we could look
> for the right fix.

Given his description of the problem, my guess is that somehow the sentinel
is run before all the process's output has been processed.


        Stefan

Re: special-display-buffer-names and vc-diff displays wrong result

[Richard M. Stallman]

    To figure out whether there's been diffs or not, the sentinel function
    checks whether the resulting buffer is empty.

I think that is a mistake.  The reliable way for it to tell
whether there are differences is to look at the exit status from diff.

    Given his description of the problem, my guess is that somehow the sentinel
    is run before all the process's output has been processed.

That can happen.  Two different signals indicate (1) the process is dead
and (2) there is output.  I think they can arrive in any order.
Does anyone know for certain?

Also, wait_reading_process_output runs sentinels before it
reads output.  So if the signals arrive at the same time,
Emacs will run the sentinel first.  That is arguably a bug,
but I think it is really risky to change that.

I will document this.

Re: special-display-buffer-names and vc-diff displays wrong result

[Stefan Monnier]

>     To figure out whether there's been diffs or not, the sentinel function
>     checks whether the resulting buffer is empty.

> I think that is a mistake.  The reliable way for it to tell
> whether there are differences is to look at the exit status from diff.

That's beside the point.

>     Given his description of the problem, my guess is that somehow the
>     sentinel is run before all the process's output has been processed.

> That can happen.  Two different signals indicate (1) the process is dead
> and (2) there is output.  I think they can arrive in any order.
> Does anyone know for certain?

> Also, wait_reading_process_output runs sentinels before it
> reads output.  So if the signals arrive at the same time,
> Emacs will run the sentinel first.

If the sentinel happens to run first, is the output still processed
afterwards or is it just discarded?

> That is arguably a bug, but I think it is really risky to change that.

It does sound like a bug, indeed.  But maybe not: maybe the sentinel
processing code first reads the process's output?


        Stefan


PS: As for why VC doesn't check the output status of diff:
- it doesn't run diff, it runs cvs diff, rcsdiff, sccs-diff, tla file-diffs,
  mcvs diff, svn diff, ... which do not all report the absence of changes in
  the same way.
- it doesn't actually care whether there were diffs or not: the code is just
  trying to make sure that the buffer doesn't stay empty, leaving the user
  to wonder whether the command got frozen or just didn't produce
  any output.  So it also makes sense to check the buffer's emptiness.

Re: special-display-buffer-names and vc-diff displays wrong result

[Richard M. Stallman]

    > Also, wait_reading_process_output runs sentinels before it
    > reads output.  So if the signals arrive at the same time,
    > Emacs will run the sentinel first.

    If the sentinel happens to run first, is the output still processed
    afterwards or is it just discarded?

I think the output is still processed, but I am not certain.  It would
definitely be a bug if the output is lost when the termination signal
is handled first.  I think there is no such bug, since nobodyt is
reporting it.

    - it doesn't actually care whether there were diffs or not: the code is just
      trying to make sure that the buffer doesn't stay empty, leaving the user
      to wonder whether the command got frozen or just didn't produce
      any output.  So it also makes sense to check the buffer's emptiness.

The easiest way to do this is to program the sentinel to insert some
text at the end of the buffer.

Re: special-display-buffer-names and vc-diff displays wrong result

[Harald Maier]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I am using `special-display-buffer-names' for the *vc-diff* buffer.
>     If the special-display-buffer frame does not exist then the *vc-diff*
>     buffer reports sometimes "No differences found.". This seems to due
>     the fact that the 'vc-diff-internal' function has not written yet any
>     bytes into the *vc-diff* buffer.
>
> How would the fact that the buffer is empty have such an effect?
> Can you work out the chain of events?

First the problem happens only if the emacs-produced version file
(e.g. some-version-file.~1.9.~) doesn't exist and the vc-diff function
executes very fast (e.g. cvs server local). It happens always whether
'special-display-buffer-names' is set.

Here is the process chain in the function vc-version-diff:

- after processing 'vc-diff-internal' the buffer *vc-diff* is empty
- afterwards 'vc-exec-after asks' for the 'process-status' and this
  status is 'exit' and the function buffer-size still reports zero.
- It calls again the vc-exec-after function with the given code. This
  code tests the buffer-size and this value is still zero. So the
  result is 'No difference found.'.

>     I don't know how to fix this. As a workaround I put after the
>     vc-diff-internal function a (sit-for 1) statement. Then it seems to
>     work.
>
> If you can deduce how this change has the effect of preventing the
> problem, then we would understand the problem, and then we could look
> for the right fix.

I verified this change but it has definitely no effect. Please forget
it.

Harald