From 1c5ac55881d163296e38dcf8c406eef6395e01d7 Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Sat, 18 Jul 2009 19:11:14 -0400 Subject: [PATCH] Updating o-b.org, including a couple of new bugs. --- library-of-babel.org | 3 +- org-babel.org | 82 ++++++++++++++++++++++++++++++-------------- 2 files changed, 58 insertions(+), 27 deletions(-) diff --git a/library-of-babel.org b/library-of-babel.org index c219b69a4..2de8bad4d 100644 --- a/library-of-babel.org +++ b/library-of-babel.org @@ -11,7 +11,6 @@ #+srcname: R-plot(data=R-plot-example-data) #+begin_src R :session *R* plot(data) -"R plot complete" #+end_src #+tblname: R-plot-example-data @@ -24,7 +23,7 @@ plot(data) #+lob: R-plot(data=R-plot-example-data) #+resname: R-plot(data=R-plot-example-data) -: R plot complete +: nil * Etc #+srcname: python-identity(a=1) diff --git a/org-babel.org b/org-babel.org index 87cc40875..1b78c0d0e 100644 --- a/org-babel.org +++ b/org-babel.org @@ -204,13 +204,13 @@ would then be [[#sandbox][the sandbox]]. #+end_src -* Tasks [31/51] +* Tasks [32/51] ** PROPOSED optional timestamp for output Add option to place an (inactive) timestamp at the #+resname, to record when that output was generated. *** source code block timestamps (optional addition) - If we did this would we then want to place a timestamp on the + [Eric] If we did this would we then want to place a timestamp on the source-code block, so that we would know if the results are current or out of date? This would have the effect of caching the results of calculations and then only re-running if the @@ -219,28 +219,17 @@ would then be [[#sandbox][the sandbox]]. timestamps of any tables or source-code blocks referenced by the original source-code block. + [Dan] I do remember getting frustrated by Sweave always having to + re-do everything, so this could be desirable, as long as it's easy + to over-ride of course. I'm not sure it should be the default + behaviour unless we are very confident that it works well. + **** maintaining source-code block timestamps It may make sense to add a hook to `org-edit-special' which could update the source-code blocks timestamp. If the user edits the contents of a source-code block directly I can think of no efficient way of maintaining the timestamp. -** TODO use example block for large amounts of stdout output? - We're currently `examplizing' with : at the beginning of the line, - but should larger amounts of output be in a - \#+begin_example...\#+end_example block? What's the cutoff? > 1 - line? This would be nice as it would allow folding of lengthy - output. Sometimes one will want to see stdout just to check - everything looks OK, and then fold it away. - - I'm addressing this in branch 'examplizing-output'. - - Yea, that makes sense. (either that or allow folding of large - blocks escaped with =:=). - - Proposed cutoff of 10 lines, we can save this value in a user - customizable variable. - ** TODO make tangle files read-only? With a file-local variable setting, yea that makes sense. Maybe the header should reference the related org-mode file. @@ -889,6 +878,22 @@ $0 [[file:snippets/org-mode/sb][sb -- snippet]] waiting for guidance from those more familiar with yasnippets + +** DONE use example block for large amounts of stdout output? + We're currently `examplizing' with : at the beginning of the line, + but should larger amounts of output be in a + \#+begin_example...\#+end_example block? What's the cutoff? > 1 + line? This would be nice as it would allow folding of lengthy + output. Sometimes one will want to see stdout just to check + everything looks OK, and then fold it away. + + I'm addressing this in branch 'examplizing-output'. + Yea, that makes sense. (either that or allow folding of large + blocks escaped with =:=). + + Proposed cutoff of 10 lines, we can save this value in a user + customizable variable. +*** DONE add ability to remove such results ** DONE exclusive =exports= params #+srcname: implement-export-exclusivity @@ -2075,8 +2080,15 @@ plot "data" using 1:2 with lines (see [[* file result types][file result types]]) -* Bugs [20/32] +* Bugs [21/34] ** TODO avoid stripping whitespace from output when :results output +** TODO problem with newlines in output when :results value +#+begin_src python :results value +'\n'.join(map(str, range(4))) +#+end_src + +#+resname: +: 0 ** TODO prompt characters appearing in output with R #+begin_src R :session *R* :results output x <- 6 @@ -2156,12 +2168,6 @@ the same for the other languages. [Dan] #+end_src ** TODO use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]? And at other occurrences of org-combine-plists? -** TODO LoB: with output to buffer, not working in buffers other than library-of-babel.org - I haven't fixed this yet. org-babel-ref-resolve-reference moves - point around, inside a save-excursion. Somehow when it comes to - inserting the results (after possible further recursive calls to - org-babel-ref-resolve-reference), point hasn't gone back to the - lob line. ** TODO creeping blank lines There's still inappropriate addition of blank lines in some circumstances. E.g. @@ -2169,6 +2175,7 @@ the same for the other languages. [Dan] b=5 #+end_src + Compare the results of #+lob: python-add(a=5, b=17) @@ -2188,6 +2195,9 @@ b=5 LoB removes the entire (#+resname and result) and starts from scratch, whereas #+begin_src only removes the result. I haven't worked out what the correct fix is yet. +** TODO LoB is not populated on startup + org-babel-library-of-babel is nil for me on startup. I have to + evaluate the [[file:lisp/org-babel-lob.el::][org-babel-lob-ingest]] line manually. ** DEFERRED weird escaped characters in shell prompt break shell evaluation E.g. this doesn't work. Should the shell sessions set a sane prompt when they start up? Or is it a question of altering @@ -2216,6 +2226,28 @@ b=5 the user's regular emacs init. I can't think of a way for us to set this automatically, and we are SOL without a regexp to match the prompt. +** DONE LoB: with output to buffer, not working in buffers other than library-of-babel.org +*** Initial report + I haven't fixed this yet. org-babel-ref-resolve-reference moves + point around, inside a save-excursion. Somehow when it comes to + inserting the results (after possible further recursive calls to + org-babel-ref-resolve-reference), point hasn't gone back to the + lob line. + +#+tblname: test-data +| 1 | 1 | +| 2 | .5 | +| 3 | .333 | + +#+lob: R-plot(data=test-data) + +#+lob: python-add(a=2, b=9) + +#+resname: python-add(a=2, b=9) +: 11 + +*** Now + I think this got fixed in the bugfixes before merging results into master. ** DONE cursor movement when evaluating source blocks E.g. the pie chart example. Despite the save-window-excursion in