Re: [O] [babel] VC-Log does not run correctly

[Sebastien Vauban]

Hi Eric and all,

Eric Schulte wrote:
>> When calling =C-c C-e b= on this buffer, I get asked by Emacs:
>>
>>     "Buffer has a running process; kill it? (yes or no)"
>>
>> - If I don't say anything, the export process is just hanging in the blue...
>>
>> - If I say yes, the export process really begins, but there is no vc log
>>   inserted where I expect it.
>>
>> - Exactly the same (as if I say yes) happens if I say no: export goes on, but
>>   no vc log!
>>
>> What could go wrong here?
>>
>> * Org Source
>>
>> #+source: vc-log
>> #+headers: :var limit=-1
>> #+headers: :var buf=(buffer-name (current-buffer))
>> #+begin_src emacs-lisp :exports none
>>   ;; Most of this code is copied from vc.el vc-print-log
>>   (require 'vc)
>>   (when (vc-find-backend-function
>>          (vc-backend (buffer-file-name (get-buffer buf))) 'print-log)
>>     (let ((limit -1)
>>           (vc-fileset nil)
>>           (backend nil)
>>           (files nil))
>>       (with-current-buffer (get-buffer buf)
>>         (setq vc-fileset (vc-deduce-fileset t)) ; FIXME: Why t? --Stef
>>         (setq backend (car vc-fileset))
>>         (setq files (cadr vc-fileset)))
>>       (with-temp-buffer 
>>         (let ((status (vc-call-backend
>>                        backend 'print-log files (current-buffer))))
>>           (when (and (processp status)   ; Make sure status is a process
>>                      (= 0 (process-exit-status status))) ; which has not 
>> terminated
>>             (while (not (eq 'exit (process-status status)))
>>               (sit-for 1 t)))
>>           (buffer-string)))))
>> #+end_src
>
> Off the top of my head I would recommend

Thanks for this clear TODO list, which has giving me some interesting
returns...

> first running the vc-log code block interactively to see how it behaves,

As previously said, that worked OK.

> then possibly expanding the code block with C-c C-v v,

The values in the preamble of the expanded block do look OK (see next
section).

> copying the results to your scratch buffer, evaluating the resulting elisp
> with edebug (C-M-x with a prefix argument), which will then allow you to
> step through the code execution statement by statement.

Did this on the following contents in the scratch buffer:

#+begin_src emacs-lisp
(let ((buf (quote "ecm-vc-log.txt"))
      (limit (quote -1)))
  ;; Most of this code is copied from vc.el vc-print-log
  (require 'vc)
  (when (vc-find-backend-function
         (vc-backend (buffer-file-name (get-buffer buf))) 'print-log)
    (let ((limit -1)
          (vc-fileset nil)
          (backend nil)
          (files nil))
      (with-current-buffer (get-buffer buf)
        (setq vc-fileset (vc-deduce-fileset t)) ; FIXME: Why t? --Stef
        (setq backend (car vc-fileset))
        (setq files (cadr vc-fileset)))
      (with-temp-buffer 
        (let ((status (vc-call-backend
                       backend 'print-log files (current-buffer))))
          (when (and (processp status)   ; Make sure status is a process
                     (= 0 (process-exit-status status))) ; which has not 
terminated
            (while (not (eq 'exit (process-status status)))
              (sit-for 1 t)))
          (buffer-string))))))
#+end_src

... and it works OK as well. I mean: when I trace the code manually (with
SPC), I do get the correct (thus, full) log history printed in the echo area,
when I arrive at the last lines of this block's execution.

All the vars were as well correctly resolved:
- backend is SVN
- file is a full path to the right location
- etc.

So, there is a difference between:
- executing this code in the scratch buffer, step by step, versus
- executing it in a #+call line

However, these instructions helped me a lot. For example, I've observed that,
in the scratch buffer, C-x C-e doesn't run in the intended way: I also have
the question arising, about the running process.

And this is somehow related to the process returning something, or being still
alive. ...Here begins my point of incompetence...

But, by playing around, I've managed to fix the code so that it now works OK
in my Org buffer.

Working code:

#+source: vc-log
#+headers: :var limit=-1
#+headers: :var buf=(buffer-name (current-buffer))
#+begin_src emacs-lisp :exports none
  ;; Most of this code is copied from vc.el vc-print-log
  (require 'vc)
  (when (vc-find-backend-function
         (vc-backend (buffer-file-name (get-buffer buf))) 'print-log)
    (let ((limit -1)
          (vc-fileset nil)
          (backend nil)
          (files nil))
      (with-current-buffer (get-buffer buf)
        (setq vc-fileset (vc-deduce-fileset t)) ; FIXME: Why t? --Stef
        (setq backend (car vc-fileset))
        (setq files (cadr vc-fileset)))
      (with-temp-buffer 
        (let ((status (vc-call-backend
                       backend 'print-log files (current-buffer))))
          (when (and t ; (processp status)   ; Make sure status is a process
                     ;; (= 0 (process-exit-status status)) ; which has not 
terminated
                     )
             ;; (while (not (eq 'exit (process-status status)))
              (sit-for 1 t)
               ;; )
            )
          (buffer-string)))))
#+end_src

To get it working, I have had to fix 2 things (to the original version of
vc-log, in the LOB):

1. comment the `and' condition: the lines with `processp status' and
   `process-exit-status' (adding a `t' value to make it success)

   If I don't do that, I do have the question "Buffer has a running process"
   arising... and no results displayed.

2. comment the `while' condition: the line with `process-status'

   If I don't do that, I've the error "edebug-signal: Buffer *temp*<1> has no
   process", and no results displayed.

Finally, to be complete, I've played with the value of the wait timer
(`sit-for'):

- greater or equal to 1 works OK, but delays the execution for that amount of
  time, of course.

- equal to 0, gets me back to the question arising, about "Buffer has a
  running process".

Voilà, there it is. I can't say more about the strange things appearing here.
But I'm willing to answer any question to further test this.

I'm happy to have a workaround, but would be glad someone could help into
making this code chunk robust on all Org platforms, as I guess what I've done
is quite fragile...

Best regards,
  Seb

-- 
Sebastien Vauban