Re: [O] org babel before excute hook

2013-10-14 Thread Henning Redestig
if anyone is interested in this, a simple defadvice appears to be a good
option, I put

(defadvice org-babel-execute-maybe (around org-babel-stop-on-collision)
  stop execution of result file defined more than once
  (let ((info (org-babel-get-src-block-info)))
(setq result-file (cdr (assoc :file (nth 2 info
(if (save-excursion
  (goto-char 0)
  (re-search-forward (concat :file + result-file) nil t)
  (re-search-forward (concat :file + result-file) nil t))
(error (concat result-file  defined in more than one source
block))
  ad-do-it)))
(ad-activate 'org-babel-execute-maybe)


in my .emacs and appear to get the desired functionality




2013/10/13 Samuel Wales samolog...@gmail.com

 In case it helps, there is org-confirm-babel-evaluate.

 (But I have not found it to be useful, because it does not seem to
 place point in a place where you can check properties, etc.)

 Samuel

 --
 The Kafka Pandemic: http://thekafkapandemic.blogspot.com

 The disease DOES progress.  MANY people have died from it.  ANYBODY can
 get it.

 Denmark: free Karina Hansen NOW.



Re: [O] org babel before excute hook

2013-10-13 Thread Henning Redestig
Is it possible to add a function to org-ctrl-c-ctrl-c-hook without patching
ob-core.el? If I just add something like

(add-hook 'org-ctrl-c-ctrl-c-hook 'org-babel-stop-if-file-collision)

in my .emacs I notice that my addition gets overwritten later via the
autoloads (I think) that are defined in ob-core.el..



2013/10/12 Charles Berry ccbe...@ucsd.edu

 John Kitchin jkitchin at andrew.cmu.edu writes:

 
 
 
  I have a related kind of problem. When preparing notes
  for a class, I may end up with 70 code blocks in an org file, many of
  which create graphics. I am always worried about accidentally using the
  same filename and overwriting a graphic from an earlier block. A unique,
   but reproducible filename would be sufficient for my needs.
 

 Header arg values can be elisp calls. You can use `make-temp-file'.

 So every time this block is executed, a new file is created and the
 file link is added to the results.

 #+BEGIN_SRC R :results output append :file (make-temp-file temp)
 cat(date(),\n)
 #+END_SRC

 #+RESULTS:
 [[file:/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T/temp302IjV]]
 [[file:/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T/temp3028Lu]]

 See `temporary-file-directory', too, if you want to use this, as the
 default may not be what you intend.


 You might want to use this:

 #+BEGIN_SRC emacs-lisp
   (defun local-tfile (file)
 (let ((temporary-file-directory .))
   (make-temp-file file)))
 #+END_SRC

 Then the files go in the local directory when this is executed:

 #+BEGIN_SRC R :file (local-tfile tfile) :results output append
 cat(date(),\n)
 #+END_SRC

 You might not want `append' in this case.


 HTH,

 Chuck

 [rest deleted]







Re: [O] org babel before excute hook

2013-10-12 Thread Henning Redestig
I thought about temp files, but that makes the file names cryptic which is
inconvenient for communication without people outside org.. also, I tend
recompile figures many times which would cause a lot of cluttering files
that are hard to delete since you don't know which file is the one
currently linked in your org file...

Anyway, I made this instead which appears to work as I intended


(defun org-babel-about-to-overwrite-file ()
  (let ((info (org-babel-get-src-block-info)))
(setq result-file (cdr (assoc :file (nth 2 info
(if (save-excursion
  (goto-char 0)
  (re-search-forward (concat :file + result-file) nil t)
  (re-search-forward (concat :file + result-file) nil t))
(message (concat result-file  defined in more than one source block))
  (org-babel-execute-maybe

(add-hook 'org-ctrl-c-ctrl-c-hook 'org-babel-about-to-overwrite-file)





2013/10/12 Charles Berry ccbe...@ucsd.edu

 John Kitchin jkitchin at andrew.cmu.edu writes:

 
 
 
  I have a related kind of problem. When preparing notes
  for a class, I may end up with 70 code blocks in an org file, many of
  which create graphics. I am always worried about accidentally using the
  same filename and overwriting a graphic from an earlier block. A unique,
   but reproducible filename would be sufficient for my needs.
 

 Header arg values can be elisp calls. You can use `make-temp-file'.

 So every time this block is executed, a new file is created and the
 file link is added to the results.

 #+BEGIN_SRC R :results output append :file (make-temp-file temp)
 cat(date(),\n)
 #+END_SRC

 #+RESULTS:
 [[file:/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T/temp302IjV]]
 [[file:/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T/temp3028Lu]]

 See `temporary-file-directory', too, if you want to use this, as the
 default may not be what you intend.


 You might want to use this:

 #+BEGIN_SRC emacs-lisp
   (defun local-tfile (file)
 (let ((temporary-file-directory .))
   (make-temp-file file)))
 #+END_SRC

 Then the files go in the local directory when this is executed:

 #+BEGIN_SRC R :file (local-tfile tfile) :results output append
 cat(date(),\n)
 #+END_SRC

 You might not want `append' in this case.


 HTH,

 Chuck

 [rest deleted]







[O] org babel before excute hook

2013-10-11 Thread Henning Redestig
I collaborate with different people on the same orgfile which contains many
source blocks that generate graphics by e.g. :results graphics abc.pdf

It can happen that I or someone else accidentally create another
independent source block that overwrites my abc.pdf which is of course very
bad.

I would like to add functionality so that org-babel-execute-src-block
checks if in :results graphics FILE, FILE is already referred to by another
source block and if so refuse to evaluate.

However, I only see a org-babel-after-execute-hook but no
org-babel-before-execute-hook

any reason for this? I could try to write a patch but thought I'd ask
first.

or if there is an even better approach to avoid overwriting output from
different source blocks..

//Henning


[O] feature request: re-compute cache without evaluation

2012-04-12 Thread Henning Redestig
Hi,

I write many source blocks that take a fairly long time to execute
(several minutes). Sometimes I find myself wanting to do cosmetic
changes to the code, that I know (for sure) do not change the output,
after the first evaluation. Unfortunately, after having made these
changes the cache obviously does not match the code anymore and I have
to re-evaluate to update the cache. I know it goes against the strict
'reproducible research' idea but still I would like to be able to
re-compute the cache without actually evaluating the block as it is
not efficient to re-evaluate for the sole purpose of updating the
cache.

What do you think?


-- 
/Henning



Re: [O] feature request: re-compute cache without evaluation

2012-04-12 Thread Henning Redestig
ah, this was easy, thanks!

2012/4/12 Eric Schulte eric.schu...@gmx.com:
 Henning Redestig henning@googlemail.com writes:

 Hi,

 I write many source blocks that take a fairly long time to execute
 (several minutes). Sometimes I find myself wanting to do cosmetic
 changes to the code, that I know (for sure) do not change the output,
 after the first evaluation. Unfortunately, after having made these
 changes the cache obviously does not match the code anymore and I have
 to re-evaluate to update the cache. I know it goes against the strict
 'reproducible research' idea but still I would like to be able to
 re-compute the cache without actually evaluating the block as it is
 not efficient to re-evaluate for the sole purpose of updating the
 cache.

 What do you think?

 Press C-c C-v a (org-babel-sha1-hash) in the code block, then manually
 replace the original hash with the hash returned by that function.

 --
 Eric Schulte
 http://cs.unm.edu/~eschulte/



-- 
/Henning



Re: [O] org-mode fontification error [6 times]

2012-04-04 Thread Henning Redestig
Better now but still some issues here, now if I start a new org buffer and type

s [TAB]

to complete the source block, I get org-mode fontification error again.

2012/4/4 Bastien b...@gnu.org:
 Hi Nick,

 Nick Dokos nicholas.do...@hp.com writes:

 Confirmed. It only happens when you start typing into an empty buffer.
 Looks like an off-by-one error in org.el:org-fontify-meta-lines-and-blocks-1,
 aroung line 5487:

 ,
 |         ;; just any other in-buffer setting, but not indented
 |         (add-text-properties
 |          beg (1+ (match-end 0))
 |          '(font-lock-fontified t face org-meta-line))
 `

 The second arg should probably be just (match-end 0).

 That's correct.  I first thought (min (point-max) (1+ (match-end 0)))
 would have been safer, but I really don't see why the 1+.

 Please confirm this is fixed.

 Thanks,

 --
  Bastien



-- 
/Henning



Re: [O] org-mode fontification error [6 times]

2012-04-03 Thread Henning Redestig
+1 on this, I get 'org-mode fontification error' all the time after
having typed just

#+

in an org buffer. with org 7.8.08 and emacs 23.1.50.1 and running with emacs -Q

2011/8/18 Leo sdl@gmail.com:
 On 2011-08-18 15:22 +0800, Bastien wrote:
 Just a heads-up. I saw this in my *message* buffer. I don't know how
 it happened.

 Is this with emacs -Q?

 I am unable to reproduce this with emacs-23.3.1 and emacs-24.0.50.1.

 It is in my normal running emacs session. I haven't found a reproduction
 recipe. But I have been using the same org-mode setup for years.

 Leo




-- 
/Henning



[Orgmode] org babel and alternative output file when using +call

2010-10-27 Thread Henning Redestig
Dear list,

When I do

#+source: test(myarg=blabla)
#+begin_src R :session :file test.pdf
  plot(1:10, main=myarg)
#+end_src

I get the expected result:

#+results: test
[[file:test.pdf]]

but if I later do

#+call: test(myarg=hiho) :file test2.pdf

I still get a file named according to the header argument specified in
the original source block:

#+results: test(myarg=hiho)
[[file:test.pdf]]

instead of what I hoped for:

#+results: test(myarg=hiho)
[[file:test2.pdf]]

Is this intended? I think it would be very useful if I could change
the file name in '+calls' like this to get different plots for
different arguments.

Using:

GNU Emacs 23.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.0) of
2009-09-27 on crested, modified by Debian
Org-mode version 7.01trans

Best regards,

-- 
/Henning Redestig

Metabolome Informatics Unit | Yokohama RIKEN Plant Science Center

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode