From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: [babel] VC-Log does not run correctly Date: Mon, 12 Sep 2011 14:18:39 +0200 Message-ID: <80litugdi8.fsf@somewhere.org> References: <80pqjbce60.fsf@somewhere.org> <87sjo76p52.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Eric and all, Eric Schulte wrote: >> When calling =3DC-c C-e b=3D 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 blu= e... >> >> - 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=3D-1 >> #+headers: :var buf=3D(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=20 >> (let ((status (vc-call-backend >> backend 'print-log files (current-buffer)))) >> (when (and (processp status) ; Make sure status is a process >> (=3D 0 (process-exit-status status))) ; which has n= ot 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=20 (let ((status (vc-call-backend backend 'print-log files (current-buffer)))) (when (and (processp status) ; Make sure status is a process (=3D 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 are= a, 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 tha= t, 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 st= ill 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=3D-1 #+headers: :var buf=3D(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=20 (let ((status (vc-call-backend backend 'print-log files (current-buffer)))) (when (and t ; (processp status) ; Make sure status is a process ;; (=3D 0 (process-exit-status status)) ; which has no= t 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=C3=A0, there it is. I can't say more about the strange things appearin= g 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 do= ne is quite fragile... Best regards, Seb --=20 Sebastien Vauban