From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [babel] VC-Log does not run correctly
Date: Mon, 12 Sep 2011 14:18:39 +0200 [thread overview]
Message-ID: <80litugdi8.fsf@somewhere.org> (raw)
In-Reply-To: 87sjo76p52.fsf@gmail.com
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
next prev parent reply other threads:[~2011-09-12 12:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 14:16 [babel] VC-Log does not run correctly Sebastien Vauban
2011-09-08 15:04 ` Eric Schulte
2011-09-09 14:50 ` Sebastien Vauban
2011-09-12 12:18 ` Sebastien Vauban [this message]
2011-09-09 15:08 ` suvayu ali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80litugdi8.fsf@somewhere.org \
--to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).