1
0
mirror of https://git.savannah.gnu.org/git/emacs/org-mode.git synced 2024-11-22 07:09:47 +00:00

Updating o-b.org, including a couple of new bugs.

This commit is contained in:
Dan Davison 2009-07-18 19:11:14 -04:00
parent ef6668df61
commit 1c5ac55881
2 changed files with 58 additions and 27 deletions

View File

@ -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)

View File

@ -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