org mode with babel source: execute all source blocks, don't export them to latex
Hi
I have a org file with has a lot source blocks of the form
#+begin_src matlab :results output raw :exports code :eval never-export
close all
N = 3; % number of chebyshev nodes
n = 1; % polytropic index
iters = 1; % iterations
j=[0 1 2 3];
z=cos((pi*j)/3);
y=1-(0.5*(z+1)).^2;
a=n*(8);
a2=eye(3+1)*a;
disp('\begin{align*}')
disp('A_{1,k-1}&=')
disp('\begin{pmatrix}')
fprintf('%g &%g &%g &%g\n',a2')
disp('\end{pmatrix}=OK\\')
disp('\end{align*}')
#+end_src
#+RESULTS:
\begin{align*}
A_{1,k-1}&=
\begin{pmatrix}
8 &0 &0 &0\\
0 &8 &0 &0\\
0 &0 &8 &0\\
0 &0 &0 &8\\
\end{pmatrix}=OK\\
\end{align*}
Two questions.
1. Is there any equivalent to org-update-all-dblocks for the source blocks?
2. I want to export the org file to latex, in the current setting
the source blocks are also exported. I tried
#+begin_src matlab :results output raw :eval never-export
but it did not help.
Thanks
Uwe Brauer
Re: buffer name of Org Src...
Eric, > But that's what git etc. are for! ;-) yes, but. the first time i 'C-c C-v t' in the base file onto a changed-but-uncommitted tangled file, even git will provide me no succor. cheers, Greg
Re: Bug: ODT exporter permission issue on functional distros (eg, Guix) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/cwebber/.guix-profile/share/emacs/26.3/lisp/org/)]
Christopher Lemmer Webber writes: > Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) > Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ > /home/cwebber/.guix-profile/share/emacs/26.3/lisp/org/) [...] > Subject: [PATCH] ox-odt: Fix read-only error with styles.xml. > > On systems where the source file is read-only, it's possible that > the destination styles.xml could end up read-only as well, resulting > in an error when modified or deleted by us. > > * lisp/ox-odt.el (org-odt-template): Explicitly set permissions of > styles.xml to read-write for the current user. Thanks for the patch. I believe the issue should already be fixed by 6315e1e76 (ox-odt: Get write permissions on styles.xml, 2019-12-20), which was a part of the 9.3.1 release. It makes the same set-file-modes call as your patch, but a bit downstream of the spot you chose.
Org-mode macros with variable argument number
Hi folks,
For a while, I have been bugged by the fact that org-mode macros need to
hardcode the arguments. Among other things, this prevents, macros with a
variable number of arguments (arguably most useful for “(eval”-style lisp
macros). Today, I finally implemented this feature (see attached patch). It
simply substitutes $arg with a list of the macro arguments.
It allows macros like this one:
#+MACRO: no-op (eval (string-join $args ","))
Which simple outputs its arguments but does not require calls to the macro to
escape commas.
{{{no-op(Hi there, this macro does nothing)}}} -> Hi there, this macro does
nothing
Can you have a look to see if this can be included in the org-mode distribution?
many thanks and best regards,
holger
0001-add-args-placeholder-to-macros-to-capture-all-argume.patch
Description: 0001-add-args-placeholder-to-macros-to-capture-all-argume.patch
Re: buffer name of Org Src...
Eric S Fraga writes: > On Monday, 12 Oct 2020 at 18:33, Dr. Arne Babenhauserheide wrote: >> That’s also when I tangle — but I often don’t move the code back into >> org afterwards, because once I needed this support once, I know I’ll >> need it again. > > Interesting. I guess my needs are different: I need these support tools > when doing the initial code development but not much after > that. Subsequently, most of my time is spent with documentation, > dissemination, and bug fixes. Doing most of this is easier in org mode. Do you use org-mode to document stuff after you wrote it? I often use it to start small tools that I need right now — for example some data extraction — and I would prefer to keep them in org, because I then have one single reference. And I often write the code while I’m writing the text around it. When then something does not work, I need debugging and exploration to find out how to fix it. > But whatever works best for you is what you should do! There are a lot of great ways to use org-mode :-) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: buffer name of Org Src...
On Monday, 12 Oct 2020 at 18:33, Dr. Arne Babenhauserheide wrote: > That’s also when I tangle — but I often don’t move the code back into > org afterwards, because once I needed this support once, I know I’ll > need it again. Interesting. I guess my needs are different: I need these support tools when doing the initial code development but not much after that. Subsequently, most of my time is spent with documentation, dissemination, and bug fixes. Doing most of this is easier in org mode. But whatever works best for you is what you should do! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-57-g8402c4
Re: buffer name of Org Src...
Eric S Fraga writes: > On Monday, 12 Oct 2020 at 15:39, Dr. Arne Babenhauserheide wrote: >> Did you find a way to make flycheck or flymake work in the src-buffers? > > This is an example of when I use tangling/detangling: when I need this > kind of support to develop my code. That’s also when I tangle — but I often don’t move the code back into org afterwards, because once I needed this support once, I know I’ll need it again. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: buffer name of Org Src...
On Monday, 12 Oct 2020 at 17:17, Greg Minshall wrote: > making changes in both the base file source block and in the Org > Src... buffer (which i assume the de-tangling solution can't?). Yes, de-tangling cannot handle such simultaneous changes so you do need to be careful. But that's what git etc. are for! ;-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-57-g8402c4
Re: buffer name of Org Src...
On Monday, 12 Oct 2020 at 15:39, Dr. Arne Babenhauserheide wrote: > Did you find a way to make flycheck or flymake work in the src-buffers? This is an example of when I use tangling/detangling: when I need this kind of support to develop my code. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-57-g8402c4
Re: buffer name of Org Src...
Eric, thanks. de-tangling sounds like a possible solution. though, at least with Org Src ... buffers, org/emacs mostly keep me from messing up by, e.g., making changes in both the base file source block and in the Org Src... buffer (which i assume the de-tangling solution can't?). given my aging brain, such protection is probably vital for me. cheers, Greg
Re: buffer name of Org Src...
Arne, no, sorry, i don't use either flymake or flycheck. cheers, Greg
Re: buffer name of Org Src...
Greg Minshall writes: > ps -- in case it's of interest: possibly i'm frustrated now, and wasn't > so much in the past, as i recently got annoyed by having to go back to > the base file to save and tangle (part of my work flow, to test whatever > i'm working on), and, so, wrote a few lines of emacs lisp so that a 'C-x > s' save from the Org Src ... file causes a save of the base file > followed by a tangle. so, i can basically live long periods of time > just in the Org Src ... buffers; if only i could find my way around. > cheers! Did you find a way to make flycheck or flymake work in the src-buffers? I get problems with these, because the buffers are not associated to real files. That’s what’s preventing me from using Org Src for anything larger than a dozen simple lines. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: buffer name of Org Src...
On Monday, 12 Oct 2020 at 15:44, Greg Minshall wrote: > in *my* case (with the project i'm currently working on), each source > block in the .org file is a separately tangled file, and each source > block could be tagged with a distinct '#+name:' value. Using the name of the src block would be a nice enhancement. > ps -- in case it's of interest: possibly i'm frustrated now, and wasn't I understand your frustration but I've found the solution that works in my case, when tangling a large number of blocks all to the same code file. The solution is to work on the code file directly, having tangled with :comments on, and then detangle (org-bable-detangle) to get the src blocks back in the original org file. I do this particularly in the early stages of code development when I'm continually running and editing the code. HTH, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-57-g8402c4
buffer name of Org Src...
hi, all. i often write my version of (il)literate programs using one .org file, from which four or five (typically) files are tangled. and, generally, i'm very happy with this. but, when i have multiple Org Src ... buffers open, all from the same language, i am at a loss on how to determine to which buffer i should 'C-x b', as the only distinguishing characteristic is a (possible) trailing '', for some small integer N. in *my* case (with the project i'm currently working on), each source block in the .org file is a separately tangled file, and each source block could be tagged with a distinct '#+name:' value. is there a way to customize the buffer name? or, an easy hack? (given a choice, i'd probably have some function of [src block name; language; tangled-to file name], prefixed, clearly, by Org Src... and optionally suffixed with "".) cheers, Greg ps -- in case it's of interest: possibly i'm frustrated now, and wasn't so much in the past, as i recently got annoyed by having to go back to the base file to save and tangle (part of my work flow, to test whatever i'm working on), and, so, wrote a few lines of emacs lisp so that a 'C-x s' save from the Org Src ... file causes a save of the base file followed by a tangle. so, i can basically live long periods of time just in the Org Src ... buffers; if only i could find my way around. cheers!
[PATCH] Review face for export dispatcher highlighted keys
The export dispatcher's active keys are highlighted using the 'org-warning' face. That face is applied in various contexts, including the agenda. Users who have difficulty reading the active keys of the export dispatcher are therefore forced to modify 'org-warning' throughout their setup, even though their problem is present only while viewing the dispatch UI (because highlighted keys are one or a few characters long). The attached patch is an attempt to address this issue by creating a new face that is specifically designed for the dispatch UI. For the background+foreground combinations, the selected values conform with the highest accessibility standard for colour contrast (WCAG AAA, else a minimum contrast ratio of 7:1). I limited my options to what 'M-x list-colors-display' provides. Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com >From 317eecf00b8c7d7112706b2438796f2aa4c48ecd Mon Sep 17 00:00:00 2001 From: Protesilaos Stavrou Date: Mon, 12 Oct 2020 12:41:31 +0300 Subject: [PATCH] Review face for export dispatcher highlighted keys * lisp/org-faces.el (org-dispatcher-highlight): Define new face. * lisp/ox.el (org-export--dispatch-ui): Apply org-dispatcher-highlight face. The intent is to decouple the dispatcher's interface from the generic org-warning face. The dispatcher's active keys are thus made easier to tell apart, without interfering with other applications of org-warning. --- lisp/org-faces.el | 14 ++ lisp/ox.el| 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index c0556b8bb..94b283ad6 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -45,6 +45,20 @@ The foreground color of this face should be equal to the background color of the frame." :group 'org-faces) +(defface org-dispatcher-highlight + '((default :weight bold) +(((class color) (min-colors 88) (background dark)) + :background "gray20" :foreground "gold1") +(((class color) (min-colors 88) (background light)) + :background "SlateGray1" :foreground "DarkBlue") +(((class color) (min-colors 16) (background dark)) + :foreground "yellow") +(((class color) (min-colors 16) (background light)) + :foreground "blue") +(t :inverse-video t)) + "Face for highlighted keys in the dispatcher." + :group 'org-faces) + (defface org-level-1 '((t :inherit outline-1)) "Face used for level 1 headlines." :group 'org-faces) diff --git a/lisp/ox.el b/lisp/ox.el index 6dd2cd4a0..5ffd66816 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -6706,7 +6706,7 @@ back to standard interface." ;; on the first key, if any. A nil value means KEY will ;; only be activated at first level. (if (or (eq access-key t) (eq access-key first-key)) - (propertize key 'face 'org-warning) + (propertize key 'face 'org-dispatcher-highlight) key))) (fontify-value (lambda (value) -- 2.28.0
Re: org-tables with monetary amounts
On Monday, 12 Oct 2020 at 10:22, Christian Moe wrote: > I think I was thinking about adding mode flags for unit computations, > like in the imagined example above (`$3=$2+$1;u'), similar to what has > been done for duration computations. This would be very useful, actually. I use embedded calc all the time with units; being able to use some of the same expressions in a table would be highly welcome. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-38-g16f505
Re: org-tables with monetary amounts
Hi, Daniele, Good that it's working for you. I'll try to explain the unclear parts. Daniele Nicolodi writes: > On 24/09/2020 11:17, Christian Moe wrote: > >> Now, with the Calc command to simplify units, you can add dollars to >> euros and get the result in whichever currency comes first in the >> algebraic expression >> >> | 3 USD | 4 EUR | 6.58 EUR | >> #+tblfm: $3=usimplify($2+$1) >> >> | 3 USD | 4 EUR | 7.6511628 USD | >> #+tblfm: $3=usimplify($1+$2) > > Having to explicitly use usimplify() is a bit too verbose. It would be > ideal if this could be somehow be implicit. Yes, or at least with a less obtrusive syntax, like a mode flag, something like $3=$2+$1;u (here using "u" for "units" -- unfortunately, capital "U" is already taken) >> I don't use this functionality, so I don't have answers to all the >> questions you'll now have -- including how to get the desired precision >> without lopping off the currency unit in the last example! > > Having the desired fixed precision is quite important for this to be > useful. In y recent tests I had to drop the units (currencies) to > achieve this. It would be nice to find a way to avoid it. [...] >> Apart from `usimplify', most Calc functions on units appear (?) to be >> missing corresponding algebraic versions that you can use in Calc >> expressions in Org tables, which limits the usefulness. I may be missing something, but it looks like handy Calc commands like simple unit conversion currently can't be used in an Org spreadsheet, making Calc units less useful in the spreadsheet. And that this is due to a lacuna in Calc, not in Org. When using Calc directly, there are two ways to enter calculations. The default is reverse Polish notation on the stack (like an old HP calculator), with various keys bound to all the available commands. The alternative is algebraic notation. For example, the command for square root is `calc-sqrt', entered with the `Q' key. To get the square root of two, you would enter `2 Q' or `2 RET Q'. The corresponding function to use in algebraic notation is `sqrt'. To use it, you would press apostrophe for algebraic notation, and enter `sqrt(2) RET'. But while all Calc commands have keys assigned, it seems not all have corresponding algebraic notation (?). The Calc manual says that the command `u s' (`calc-simplify-units') has the algebraic expression `usimplify'. But it does not list such expressions for other handy Calc commands, like the `u c' (`calc-convert-units') command, the `u r' (`calc-remove-units') command or the `u x' (`calc-extract-units') command. The Org spreadsheet can also use Lisp formulas, so I've tried to use calc-simplify-units directly, but this leads to #ERROR. >> Org tables don't seem to have any specific formula syntax for leveraging >> Calc unit operations apart from what happens to work out of the >> box. This might be an area for improvement, though I'm not sure what to >> ask for. I think I was thinking about adding mode flags for unit computations, like in the imagined example above (`$3=$2+$1;u'), similar to what has been done for duration computations. See the manual, 3.5.2 Formula syntax for Calc. Might be useful, but I'm not sure how to specify a request. > I don't understand what you mean in the two paragraphs above. Can you > please clarify, maybe with examples? Hope this helps. Yours, Christian
