23.0.50; vc: missing done in progress message

23.0.50; vc: missing done in progress message

[Ulrich Neumerkel]

--text follows this line--

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I do C-x v = expecting a long run, the message

Finding changes in /opt/gupu/src/pl-gitp/pl/boot/syspred.pl...

appears, but no done is shown. So I have the impression that
git is still working.


From ca95ee0ca2448ee2a83ea06ef2dad14acb65f823 Mon Sep 17 00:00:00 2001
From: Ulrich Neumerkel <ulrich@complang.tuwien.ac.at>
Date: Mon, 28 Jan 2008 00:06:00 +0100
Subject: [PATCH] Added ... done to progress message

---
 lisp/vc.el |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lisp/vc.el b/lisp/vc.el
index ffe38a6..8ddbdce 100644
--- a/lisp/vc.el
+++ b/lisp/vc.el
@@ -2005,6 +2005,7 @@ returns t if the buffer had changes, nil otherwise."
     (let ((vc-disable-async-diff (not async)))
       (vc-call diff files rev1 rev2 "*vc-diff*"))
     (set-buffer "*vc-diff*")
+    (message "Finding changes in %s... done" filenames)
     (if (and (zerop (buffer-size))
              (not (get-buffer-process (current-buffer))))
         ;; Treat this case specially so as not to pop the buffer.
-- 
1.5.3.6

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Ulrich Neumerkel <ulrich@complang.tuwien.ac.at>
() Mon, 28 Jan 2008 00:12:50 +0100

   I do C-x v = expecting a long run, the message

   Finding changes in /opt/gupu/src/pl-gitp/pl/boot/syspred.pl...

   appears, but no done is shown. So I have the impression that
   git is still working.

Perhaps there is some indication in the *Messages* buffer.
For example, i see:

| Running git diff-index [...] -- configure.ac in foreground...
| Running git diff-index [...] -- configure.ac...OK = 0
| No changes between working revision and workfile

(The [...] indicates irrelevant stuff removed to shorten the line.)

thi

Re: 23.0.50; vc: missing done in progress message

[Ulrich Neumerkel]

> Perhaps there is some indication in the *Messages* buffer.
> For example, i see:

No, I do not see that. Just modified a file to get:

Mark set
Wrote /opt/gupu/src/pl-gitp/pl/library/apply_macros.pl [2 times]
Finding changes in /opt/gupu/src/pl-gitp/pl/library/apply_macros.pl... done


So, there is no OK message (with git)

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Ulrich Neumerkel <ulrich@complang.tuwien.ac.at>
() Mon, 28 Jan 2008 08:57:04 +0100

   No, I do not see that. Just modified a file to get:

   Mark set
   Wrote /opt/gupu/src/pl-gitp/pl/library/apply_macros.pl [2 times]
   Finding changes in /opt/gupu/src/pl-gitp/pl/library/apply_macros.pl... done


   So, there is no OK message (with git)

Emacs' vc-git.el is still settling down[0], plus Git has some
diff-related peculiarities[1], plus it's possible my setup[2] has
inured me to the travails of avoiding "stock" systems.

This means basically, i don't know where the difference may be
creeping in!  So lets start over to try to find common debugging
pov.  (Sorry, i should have suggested the following, initially.)
Could you do a "cvs update", build Emacs, start it with "-Q", and
let me know what you see?  I will do the same, here.  Also, i see
1.5.3.6 at the bottom of a previous mail; is that the version
number of a stock (w/o modifications) git release?

thi


[0] http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/vc-git.el?view=log  
[1] http://lists.gnu.org/archive/html/bug-gnulib/2007-12/msg00179.html
[2] http://www.gnuvola.org/wip/  (see vc-git-hacking)

Re: 23.0.50; vc: missing done in progress message

[Ulrich Neumerkel]

> This means basically, i don't know where the difference may be
> creeping in!  So lets start over to try to find common debugging
I had the most recent version from git.
 
Before debugging do:
 
grep 'Finding changes in' vc.el
 
to see that there is only one place with this message
+ my addition.

-*- mode: grep; default-directory: "/opt/gupu/src/emacs/lisp/" -*-
Grep started at Mon Jan 28 10:57:25

grep -nH -e 'Finding changes in' vc.el
vc.el:1978:    (message "Finding changes in %s..." filenames)
vc.el:2008:    (message "Finding changes in %s... done" filenames)

Grep finished (matches found) at Mon Jan 28 10:57:25

So there is no place anywhere that could acknowledge the
end of the operation.

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Ulrich Neumerkel <ulrich@complang.tuwien.ac.at>
() Mon, 28 Jan 2008 11:00:44 +0100

   grep 'Finding changes in' vc.el

   [...]

   So there is no place anywhere that could acknowledge the
   end of the operation.

In my *Messages* buffer i see such an acknowledgement.

Your patch doesn't find the true end of the operation, which has two
cases: synchronous and asynchronous.  These are crossed with whether
or not the backend program detected differences (which may or may
not coincide w/ an empty output buffer, my point in the bug-gnulib
thread), resulting in (at least) four cases.  Furthermore, if we
take into account the VERBOSE arg, which on quick analysis seems to
have suffered bit-rot from the late-2007 revamp, there are now (at
least) eight tails to the "Finding changes" head.

Some of these cases can be (and are) coalesced, but not all.  If you
want "acknowledgement of end", you need to figure out *which* end
you are interested in, and DTRT there, not before.  Applying your
patch would cause Emacs to lie (more than it does now), and we see
how that turned out for HAL9000!

thi

Re: 23.0.50; vc: missing done in progress message

[Glenn Morris]

Thien-Thi Nguyen wrote:

> | Running git diff-index [...] -- configure.ac...OK = 0

"OK = 0" is pretty uninformative IMO. Is it good or bad?

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Tue, 29 Jan 2008 03:35:15 -0500

   > | Running git diff-index [...] -- configure.ac...OK = 0

   "OK = 0" is pretty uninformative IMO. Is it good or bad?

It depends on what you consider good or bad.  For diff(1)-like
programs, exit value of zero means no differences detected.

thi

Re: 23.0.50; vc: missing done in progress message

[Glenn Morris]

Thien-Thi Nguyen wrote:

>    "OK = 0" is pretty uninformative IMO. Is it good or bad?
>
> It depends on what you consider good or bad.  For diff(1)-like
> programs, exit value of zero means no differences detected.

By experiment, this is not what Emacs is using it to mean.

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Tue, 29 Jan 2008 15:04:58 -0500

   By experiment, this is not what Emacs is using it to mean.

Please post the experiment so that it can be reproduced.
Start w/ "emacs -Q".

thi

Re: 23.0.50; vc: missing done in progress message

[Glenn Morris]

Thien-Thi Nguyen wrote:

> Please post the experiment so that it can be reproduced.
> Start w/ "emacs -Q".

 emacs -Q --eval '(setq vc-command-messages t)' file/under/svn
 modify file
 C-x v =

-> buffer with differences and message: "Running svn diff filename...OK = 0"


Anyway, the only point I'm trying to make is that "OK = 0" is useless
as a status message, because it could mean anything:

1) The diff command completed succesfully (exit status 0 in a shell
command sense). There may or may not be differences.

2) The diff command failed (0 is false in a C sense).

3) There were no differences (the GNU diff exit status convention).


Something like "...done" or "...failed" would be a lot clearer IMO.
I supposed I should either just change it myself or forget about it.

Re: 23.0.50; vc: missing done in progress message

[Thien-Thi Nguyen]

() Glenn Morris <rgm@gnu.org>
() Wed, 30 Jan 2008 19:56:46 -0500

   [recipe] and message: "Running svn diff filename...OK = 0"

   Anyway, the only point I'm trying to make is that "OK = 0" is useless
   as a status message, because it could mean anything:

   1) The diff command completed succesfully (exit status 0 in a shell
   command sense). There may or may not be differences.

   2) The diff command failed (0 is false in a C sense).

   3) There were no differences (the GNU diff exit status convention).

Now I'm confused.  Before, i was moderately sure that the
convention (case 3) was universal.  Here is a quick survey of a
the documentation for the "diff" functionality for a subset of the
backends:

* RCS rcsdiff(1)
  Exit status is 0 for no differences during any comparison, 1 for
  some differences, 2 for trouble.

* CVS "(cvs) Exit status"
  It will return a successful status if it found no differences,
  or a failure status if there were differences or if there was an
  error.  Because this behavior provides no good way to detect
  errors, in the future it is possible that `cvs diff' will be
  changed to behave like the other CVS commands.

* Git git-diff(1)
  --exit-code
  Make the program exit with codes similar to diff(1).  That is,
  it exits with 1 if there were differences and 0 means no
  differences.
  [An option, but one that vc-git.el uses unconditionally. --ttn]

* SVN "svn diff help" output
  [no mention of exit value]

* HG http://www.selenic.com/mercurial/hg.1.html
  [no mention of exit value]

* Bzr http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#diff
  Exit values:
  1 - changed 2 - unrepresentable changes 3 - error 0 - no change

I suppose SVN follows CVS, and HG and others follow the rest, and
would be very surprised to learn of a backend that deliberately
(by design) did not follow this convention.

   Something like "...done" or "...failed" would be a lot clearer IMO.

Agreed.  Up-thread, i mentioned all the branches in the vc-diff
code path.  I think a good approach is to coalesce all paths to
end up in vc-diff-finish and add the human-friendly notification
there.  If no one beats me to it, i'll look into it in a week.

thi

Re: 23.0.50; vc: missing done in progress message

[Stefan Monnier]

> Now I'm confused.  Before, i was moderately sure that the
> convention (case 3) was universal.  Here is a quick survey of a

I'm not sure I understand the context of the discussion, but w.r.t user
messages, even if this convention is agreed upon, it's not a convention
about which the user would want to care.


        Stefan