mirror of
https://git.savannah.gnu.org/git/emacs/org-mode.git
synced 2024-08-26 04:32:52 +00:00
Discussion of new TODOs. Couple of additions and a couple of questions
This commit is contained in:
parent
2ecd87c787
commit
578a7b9574
101
rorg.org
101
rorg.org
|
@ -3,7 +3,7 @@
|
||||||
#+SEQ_TODO: TODO OPEN | DONE RESOLVED
|
#+SEQ_TODO: TODO OPEN | DONE RESOLVED
|
||||||
#+STARTUP: oddeven
|
#+STARTUP: oddeven
|
||||||
|
|
||||||
* Tasks [4/9]
|
* Tasks [5/10]
|
||||||
** TODO selective export of text, code, figures
|
** TODO selective export of text, code, figures
|
||||||
[DED] The litorgy buffer contains everything (code, headings and
|
[DED] The litorgy buffer contains everything (code, headings and
|
||||||
notes/prose describing what you're up to, textual/numeric/graphical
|
notes/prose describing what you're up to, textual/numeric/graphical
|
||||||
|
@ -11,18 +11,66 @@
|
||||||
to include only a subset of that content. For example you might
|
to include only a subset of that content. For example you might
|
||||||
want to create a presentation of what you've done which omits the
|
want to create a presentation of what you've done which omits the
|
||||||
code.
|
code.
|
||||||
** TODO folding of code blocks?
|
|
||||||
[DED] In similar way to using outline-minor-mode for folding function
|
[EMS] So I think this should be implemented as a property which can
|
||||||
bodies, can we fold code blocks? #+begin whatever statements are
|
be set globally or on the outline header level (I need to review
|
||||||
pretty ugly, and in any case when you're thinking about the overall
|
the mechanics of org-mode properties). And then as a source block
|
||||||
game plan you don't necessarily want to see the code for each step.
|
header argument which will apply only to a specific source code
|
||||||
** TODO conversion of output from interactive shell, R (and python) sessions to litorgy buffers
|
block. A header argument of =:export= with values of
|
||||||
[DED] This would be a nice feature I think. Although a litorgy purist
|
|
||||||
would say that it's working the wrong way round... After some
|
- =code= :: just show the code in the source code block
|
||||||
interactive work in a *R* buffer, you save the buffer, maybe edit
|
- =none= :: don't show the code or the results of the evaluation
|
||||||
out some lines, and then convert it to litorgy format for
|
- =results= :: just show the results of the code evaluation (don't
|
||||||
posterity. Same for a shell session either in a *shell* buffer, or
|
show the actual code)
|
||||||
pasted from another terminal emulator. And python of course.
|
- =both= :: show both the source code, and the results
|
||||||
|
|
||||||
|
Thinking there should be *two types* of source code blocks. The
|
||||||
|
first should be the *large blocks* we're used to, and these should
|
||||||
|
default to just showing the code on export (suggestions?). The
|
||||||
|
other source code block should be smaller *inline blocks*, like the
|
||||||
|
=\R{ code }= blocks. I'm not sure what the format for these blocks
|
||||||
|
should be, but I think I'll give them their own [[* inline source code blocks][TODO]].
|
||||||
|
|
||||||
|
Then we can pre-process the blocks using org-exp-blocks. Which I
|
||||||
|
suppose should be added as a requirement.
|
||||||
|
|
||||||
|
In terms of implementation I think I'll get things working first
|
||||||
|
just on the sourc code block header arguments, and then later add
|
||||||
|
support for reading file/outline-level wide properties.
|
||||||
|
|
||||||
|
** TODO inline source code blocks
|
||||||
|
Like the =\R{ code }= blocks
|
||||||
|
|
||||||
|
not sure what the format should be, maybe just something simple
|
||||||
|
like =src_lang{}= where lang is the name of the source code
|
||||||
|
language to be evaluated.
|
||||||
|
|
||||||
|
The biggest problem I see with these is that their main use would
|
||||||
|
be to show the value of a variable, but the variable would need to
|
||||||
|
be assigned through a header argument (aside from in languages like
|
||||||
|
R in which all execution takes place in a session). Requiring a
|
||||||
|
header argument for a inline blocks defeats the purpose of a small,
|
||||||
|
concise inline-able block.
|
||||||
|
|
||||||
|
Maybe this makes a good case for all source code having the option
|
||||||
|
of specifying a session. I'll add that to the [[ability to select which of multiple sessions is being used][session TODO]].
|
||||||
|
|
||||||
|
** TODO ability to select which of multiple sessions is being used
|
||||||
|
Increasingly it is looking like we're going to want to run all
|
||||||
|
source code blocks in comint buffer (sessions). Which will have
|
||||||
|
the benefits of
|
||||||
|
1) allowing background execution
|
||||||
|
2) maintaining state between source-blocks
|
||||||
|
- allowing inline blocks w/o header arguments
|
||||||
|
|
||||||
|
*** R sessions
|
||||||
|
(like ess-switch-process in .R buffers)
|
||||||
|
|
||||||
|
Maybe this could be packaged into a header argument, something
|
||||||
|
like =:R_session= which could accept either the name of the
|
||||||
|
session to use, or the string =prompt=, in which case we could use
|
||||||
|
the =ess-switch-process= command to select a new process.
|
||||||
|
|
||||||
** TODO evaluation of shell code as background process?
|
** TODO evaluation of shell code as background process?
|
||||||
After C-c C-c on an R code block, the process may appear to
|
After C-c C-c on an R code block, the process may appear to
|
||||||
block, but C-g can be used to reclaim control of the .org buffer,
|
block, but C-g can be used to reclaim control of the .org buffer,
|
||||||
|
@ -55,13 +103,23 @@
|
||||||
It may be nice and not too difficult to place a spinner on/near the
|
It may be nice and not too difficult to place a spinner on/near the
|
||||||
evaluating source code block
|
evaluating source code block
|
||||||
|
|
||||||
** TODO ability to select which of multiple R sessions is being used
|
** TODO conversion of output from interactive shell, R (and python) sessions to litorgy buffers
|
||||||
(like ess-switch-process in .R buffers)
|
[DED] This would be a nice feature I think. Although a litorgy purist
|
||||||
|
would say that it's working the wrong way round... After some
|
||||||
|
interactive work in a *R* buffer, you save the buffer, maybe edit
|
||||||
|
out some lines, and then convert it to litorgy format for
|
||||||
|
posterity. Same for a shell session either in a *shell* buffer, or
|
||||||
|
pasted from another terminal emulator. And python of course.
|
||||||
|
|
||||||
Maybe this could be packaged into a header argument, something
|
** DONE folding of code blocks?
|
||||||
like =:R_session= which could accept either the name of the
|
[DED] In similar way to using outline-minor-mode for folding function
|
||||||
session to use, or the string =prompt=, in which case we could use
|
bodies, can we fold code blocks? #+begin whatever statements are
|
||||||
the =ess-switch-process= command to select a new process.
|
pretty ugly, and in any case when you're thinking about the overall
|
||||||
|
game plan you don't necessarily want to see the code for each Step.
|
||||||
|
|
||||||
|
Sounds good, and wasn't too hard to implement. Code blocks should
|
||||||
|
now be fold-able in the same manner as headlines (by pressing TAB
|
||||||
|
on the first line).
|
||||||
|
|
||||||
** DONE a header argument specifying silent evaluation (no output)
|
** DONE a header argument specifying silent evaluation (no output)
|
||||||
This would be useful across all types of source block. Currently
|
This would be useful across all types of source block. Currently
|
||||||
|
@ -910,6 +968,11 @@ Maybe we could do this by allowing the arguments to be specified?
|
||||||
This block export evaluation will be aware of the target format
|
This block export evaluation will be aware of the target format
|
||||||
through the htmlp and latexp variables, and can then create quoted
|
through the htmlp and latexp variables, and can then create quoted
|
||||||
=#+begin_html= and =#+begin_latex= blocks appropriately.
|
=#+begin_html= and =#+begin_latex= blocks appropriately.
|
||||||
|
|
||||||
|
There will also need to be a set of header arguments related to
|
||||||
|
code export. These would be similar to the results header
|
||||||
|
arguments but would apply to how to handle execution and results
|
||||||
|
during export.
|
||||||
|
|
||||||
|
|
||||||
* Notes
|
* Notes
|
||||||
|
|
Loading…
Reference in a new issue