I use org mode for reproducible research and literate programming, mainly using R for computations. I'm new to emacs.
If I'm starting a new R session or my session is interrupted, I will have to rerun a number of code chunks. This is very easy with the speed commands (typing "e" to evaluate the chunk, then "n" to move to the next). I love this feature, the only problem is that my headers and subtrees are then expanded and I have to close them again to keep the page tidy.
Is there an existing feature or lisp expression to evaluate all code chunks below a header? And is it possible to do this without expanding the content below?
many thanks
For example, if the cursor were at the start of header 1, could you evaluate the code chunks under header 2 and 3 with a single command?
* header 1
** header 2
#+BEGIN_SRC R
print("hello")
#+END_SRC
** header 3
#+BEGIN_SRC R
print("world")
#+END_SRC
It sounds like you want org-babel-execute-buffer or org-babel-execute-subtree (C-c C-v s).
Related
Launch Emacs with emacs -q and write in org-mode:
#+BEGIN_SRC C
/*
* This is a comment line
*/
#+END_SRC
Press TAB inside the block. It becomes:
#+BEGIN_SRC C
/*
,* This is a comment line
,*/
#+END_SRC
Is there any way to get rid of this behevior?
This is a quoting mechanism to make sure that the asterisks are not interpreted as headline markers and throwing off Org mode's parser. See Literal Examples in the manual.
There is no way to turn it off and you shouldn't anyway because Org mode will be very confused otherwise. The commas do not affect the exporting of the document or the evaluation of a source block: they are properly stripped at the appropriate time.
I would like to accomplish the following behaviour in Emacs and was wondering if there's an existing package that already does what I want.
I want my buffer to display only lines 30 to 60 in file myfile.txt, and simply hide the rest of the file from me.
When I scroll up to the top, I should be at line 30.
When I scroll down to the bottom, I should be at line 60.
If I edit this region, these edits should be reflected in the original file.
The region should grow/shrink as I insert/delete lines.
I should be able to open multiple regions to the same file in different buffers.
This is very close to my ideal workflow. Thanks very much for your help!
The Narrowing,you can Narrow down to between point and mark with C-x n n,then what you edit will be restricted in this region,after that you just Widen to make the entire buffer accessible again C-x n w.Perhaps this is what you are looking for
Try library Narrow Indirect (narrow-indirect.el)
It provides simple commands to create an indirect buffer that is a clone of the current buffer and that is narrowed to a particular portion of it. By default, it helps you distinguish such indirect buffers from non-indirect buffers, by using a buffer-name prefix (default I-) and by using a different face for the buffer name in the mode line.
To complement the other answers, if you are working on an org file specifically, you also have the following commands :
C-x n s (org-narrow-to-subtree) : Narrow buffer to current subtree.
C-x n w (widen) : Widen buffer to remove narrowing.
And if you are using blocks (‘#+BEGIN’ … ‘#+END) :
C-x n b (org-narrow-to-block) : Narrow buffer to current block.
I really like the org-babel that enables me to organize my scripts in org-mode, however, i found there are some issues with the org src buffer when i edit the source code in a separate buffer (using keybinding C-c ').
first thing is, even i explicitly run write-file, and then specifies the file path and name to save, the buffer is not saved to that file, but the source code block in the .org file gets updated and the .org -file is saved.
second thing is, whenever i run save-buffer in org src buffer, the buffer screen will automatically scroll down till current mouse position is the last line in the buffer. this is annoying because sometimes i lose tracking my scripts.
i am not so familiar with elisp, and can only do simple work like define-key or add-hook, i hope i can get help from here. thanks
Org-babel is not meant for organizing scripts, but for including source code as part of your document.
You may be interested in tangling, which allows to join and extract source code blocks from your orgmode document into separate files.
The following example will merge 2 source code fragments into the file test.m when tangling (org-babel-tangle, bound to C-c C-v t):
* Tangling example
Set up a vector:
#+begin_src octave :tangle test.m
a = 1:10;
#+end_src
Then find out squares
#+begin_src octave :tangle test.m
b = a.^2
#+end_src
I'm running R code blocks in a session in an org-mode file, and I can usually get them to execute by C-c C-c, as expected.
I think the pertinent PROPERTY lines I've put at the top of my file are
#+PROPERTY: session *R*
#+PROPERTY: cache yes
#+PROPERTY: exports both
#+PROPERTY: tangle yes
Sometimes, nothing happens when I press C-c C-c. AFAICT, that's a seemingly random event; the same code block may work one time and fail another time.
When such a block fails, I do see the results echoed to the minibuffer, but I don't see any results (e.g., a new data frame, as I would have expected in many cases) in the R session.
If I press C-' to edit the code block and then press C-j on each line (or C-r on each region), the code does execute, and the results get echoed appropriately to the org file and show up in the R session.
Here are some sample code block begin lines:
#+begin_src R :results silent :exports code
#+begin_src R :results value :colnames yes :exports both
I tested both just now by doing rm(list=ls()), running the code blocks, and doing ls() in the session to see if the results were there.
The first block is simple:
#+begin_src R :results silent :exports code
require(stringr)
require(ggplot2)
require(scales)
require(arm)
require(YaleToolkit)
require(stinepack)
require(mixtools)
require(lubridate)
source("utilities.R")
pf <- function (x,y) {
z <- sqrt(x * x + y * y)
return(x/z)
}
#+end_src
In two tests, it worked once and failed once, as detected by looking for pf in the R session.
If important, I can try to produce an ECM that fails frequently enough to be useful, but I suspect this may be a common setup or version problem that someone has seen and solved. It seems related to Org-mode code block evaluation, but the solution there seems to have been to :export results. In most cases, I use :exports both, which would seem to cover that case, and, in at least some cases, I care about setting up the environment in the session and not exporting to the org file. I'm never passing data through org-mode; I'm only using the session for that.
BTW, I'm running org-mode 7.8.03 on GNU Emacs 23.3.1 on XP Pro 64.
Several times I see ^L in (mostly Emacs Lisp) source codes that looks like are separators of larger logical groups. Is it their real purpose? And if so, how can I use them? Is there a built-in Emacs functionality that utilize it?
The Emacs commands backward-page and forward-page (C-x [ and C-x ]), among others, take advantage of ^Ls placed in the code as separators.
The habit did not propagate much to languages other than Emacs-lisp, but most languages treat ^L as a blank, so you can use these separators in your favorite language if you like the idea. You can type your own ^Ls with C-q C-l.
This is a page break.
[...]
A page break can also be used for a logical separation of source-code
sections. Emacs has commands and key bindings that use page breaks, such
as ‘forward-page’ (C-x ] or C-]), ‘backward-page’
(C-x [ or C-[), and 'narrow-to-page' (C-x n p). Other functions, such as
‘mark-page’, operate on the content of a page. See also PageMode.
When exploring a big file with multiple of such "pages" the function "narrow-to-page" (C-x n p) is handy: it hides everything not in the current page. Then for example searching for a function name to see the callers only leads to matches in that section, so you can really focus on understanding the narrowed region.
Use widen (C-x n w) to see the whole file again.
See also Pretty Control-L if you want to change how Control-l characters appear -- e.g., use a highlighted line instead of just ^L.
That is indeed a page break character, which on older line printers skipped to the next page or paper. Code-wise, it does nothing; it is only there to split the code into larger sections. There are convenient Emacs commands to jump to the next and previous "page", and inserting these characters takes advantage of that.