Re: [O] [PATCH] Support for 'using namespace *' in ob-C.el

[Charles C. Berry]

On Mon, 31 Jul 2017, Jay Kamat wrote:


Hello!

Sorry for the late reply, I was pretty busy last week. An updated
patch is attached!



[snip]




Using `org-entry-get' is no longer supported. You can replace the `or'
with

  (cdr (assq :namespaces params))


Done, I also replaced the other uses of 'org-entry-get' around the one
I modified



I don't think Nicolas meant that `org-entry-get' is no longer supported 
literally. I think he was referring to using it to enable using Babel 
header arguments as property names (as it did in your code). See:


http://orgmode.org/Changes.html#org343de47


HTH,

Chuck

Re: [O] Different listing styles for same babel language?

[Charles C. Berry]

On Mon, 24 Jul 2017, Michael Gauland wrote:


My org documents include lots of source code blocks, in a variety of
languages. I use the listings package to give each language a
distinctive look.

Lately, my work has involved using shell commands on different machines,
as different users. I'd like to give each shell environment (e.g., local
user, normal user on remote host, root on remote host) a different look.
At the moment, I'm doing this by specifying different shells (bash,
dash, sh) for each. This works, especially since I'm not executing the
commands from emacs, so it doesn't matter which shell I specify.

Is there a better way to do this?



See

(info "(org) Advanced configuration")

and scroll down to "Extending an existing back-end" where you will find 
a template for modifying the output of a src-block.


Assuming you derive your exporter from the latex backend, you want to have 
something like


#+ATTR_LATEX: :lstyle basic
#+BEGIN_SRC shell
  echo "Hello World"
#+END_SRC

in your *.org file and use

(org-export-read-attribute :attr_latex src-block :lstyle)

to grab the "basic" or whatever in setting up the transcoded result.

HTH,

Chuck

Re: [O] org babel, ess, R

[Charles C. Berry]

On Wed, 5 Jul 2017, Vikas Rawal wrote:



"... I'd like Org to pick up the fact that there's a :session
argument with a custom name and use that for C-RET in the edit buffer;
otherwise it generates the default *R* session there, but if you C-c
C-c the block later it puts it into the custom session name."


This is what `org-babel-switch-to-session-with-code' does.  BTW, it 
also handles Vikas' original issue of displaying both the edit buffer 
and the process buffer during editing src blocks.


So you might want is to use `org-babel-switch-to-session-with-code' 
rather than `org-edit-src-code’.


Indeed this does what I was originally looking for. How does one exit 
from this neatly? What is the equivalent of org-edit-src-exit to use 
with this? Using org-edit-src-exit after 
org-babel-switch-to-session-with-code does not close the session window.




It doesn't do that now, but see below.

I do not think I'd want to replace `org-edit-src-code' in 
`org-edit-special' with that function by default, since it forces a 
session to start and displays the process buffer which is kind of 
annoying when all I want to do is browse code in an edit buffer.  It 
fails with an error when applied to a src block with no session, so 
that would need to be handled if `o-b-s-t-session-w-code' is supplied 
as an option.




Yes, that makes sense.



OTOH, maybe a call to `org-babel-switch-to-session-with-code' could 
replace the `(switch-to-buffer ...)' in `org-edit-special' so C-u C-c ' 
would display the process buffer (as it does now) and also the edit buffer 
and start a new process if necessary.


But there are a few things to fix. `org-babel-switch-to-session-with-code' 
needs to set `org-src--saved-temp-window-config' after the call to 
'org-edit-src-code' so `org-edit-src-exit' can restore the window setup.
Also, it might as well use 'info' which `org-edit-special' obtains for src 
blocks when ARG is set.



Chuck

Re: [O] org babel, ess, R

[Charles C. Berry]

On Wed, 5 Jul 2017, John Hendy wrote:


On Wed, Jul 5, 2017 at 4:22 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:

Hello,

Vikas Rawal <vikasli...@agrarianresearch.org> writes:


C-RET seems to be picking up the custom session name if it is already
there. But otherwise it generates the default *R* session there,


Is there a bug to fix? If so, could start a new thread about it, ideally
with an ECM demonstrating the issue?


I guess Vikas can speak for Vikas, but he was responding to my
observation of the same:

"... I'd like Org to pick up the fact that there's a :session
argument with a custom name and use that for C-RET in the edit buffer;
otherwise it generates the default *R* session there, but if you C-c
C-c the block later it puts it into the custom session name."


This is what `org-babel-switch-to-session-with-code' does.  BTW, it also 
handles Vikas' original issue of displaying both the edit buffer and the 
process buffer during editing src blocks.


So you might want is to use `org-babel-switch-to-session-with-code' rather 
than `org-edit-src-code'.


I do not think I'd want to replace `org-edit-src-code' in 
`org-edit-special' with that function by default, since it forces a 
session to start and displays the process buffer which is kind of annoying 
when all I want to do is browse code in an edit buffer.  It fails with an 
error when applied to a src block with no session, so that would need to 
be handled if `o-b-s-t-session-w-code' is supplied as an option.


HTH,

Chuck



Here's an ECM:

#+begin_example

* heading

#+name: x
#+begin_src R :session r

x <- 1:10

#+end_src

#+name: y
#+begin_src R :session r

y <- x^2

#+end_src

#+end_example

So, say I start working on a document for the day and enter the
editing buffer with C-c ' on block x. I then C-RET from the edit
buffer, which evaluates x and starts a new R session, *R*. Now I'm
done and go on to block y, but don't need to edit. Maybe I just want
to update a plot or other result in the document, so I C-c C-c:

Error: object 'x' not found

This really, really common for my work. I define a setup block
somewhere in which I load libraries, read in thousands of lines of
sensor code, and process things (moving averages, summary stats, etc.)
and create my sort of "master object." From there I have sections of a
report that subset the data, plot various things, but typically have
them all set to :eval no by default. If I pick up work on a file, edit
my setup code block, but only interactively because I forget I need to
C-c C-c something first to kick off the custom session, the work was
sort of for naught as everything is in the wrong session.

In this example, I realize the error and go back to block x and C-c
C-c after failing on block y. At that point, when I go to a block
interactively to do C-RET again, I get this in the minibuffer.

Process to load into: {r | *R* | *new* }

Then I switch to *R* to quit() and end the spurious session.

Really, it was a comment about how Org behaves, not necessarily a bug.
That said, speaking for myself, I would never want a default session
in interactive mode when I've defined one in the code heading. I'd
love if Org could pick up on that setting, such that the first C-RET
of the day dropped into the session named by the block I'm editing. At
present, interactive mode appears to ignore this.


Hope that helps clarify,
John






Regards,

--
Nicolas Goaziou





Charles C. Berry Dept of Family Medicine & Public Health
cberry at ucsd edu   UC San Diego / La Jolla, CA 92093-0901
http://biostat.ucsd.edu/ccberry.htm

Re: [O] org babel, ess, R

[Charles C. Berry]

On Tue, 4 Jul 2017, Vikas Rawal wrote:




On 04-Jul-2017, at 1:22 AM, John Hendy  wrote:

On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
 wrote:


Vikas Rawal  writes:


Isn’t is what most users need while editing the code block? The
possibility of evaluating the code to test and see what happens?


Often, but not always.  And it would be seriously annoying to have the 
session buffer pop up every time I wanted to browse the code in a src 
block while simultaneously viewing the results of a previous invocation 
in the org buffer.


As noted by others C-RET (or C-c C-n) on an empty line will make the 
session buffer visible.


So will C-c C-z C-c C-z if you are in an ESS[S] mode buffer (and it will 
do that without trying to eval anything).


There are any number of possibilities for customizing =org-edit-src-code= 
to your liking. For example, with this code C-c M-' will display the edit 
buffer and the session buffer as desired by Vikas:


#+BEGIN_SRC emacs-lisp
  (defun my-babel-edit-src ( code edit-buffer)
(interactive)
(org-edit-src-code code edit-buffer)
 (when (string= mode-name "ESS[S]")
   (let ((cb (current-buffer)))
 (ess-switch-to-ESS t)
 (switch-to-buffer-other-window cb
  (define-key org-mode-map (kbd "\C-c\M-'") 'my-babel-edit-src)
#+END_SRC

There are loads of possibilities. Just hack away at that function to add 
stops and whistles.


Personally, I find that the code in this thread:

From: Andrew Kirkpatrick 
Subject: Jumping between source blocks in a file
Archived-At: 

has done a lot to ease my browsing and manipulation of src blocks even 
though it displays the org buffer along with the edit buffer --- requiring 
me to key in C-c C-z C-c C-z to get the process buffer back in view.  I 
suppose I could replace =org-edit-src-code= at the end of Andrew 
Kirkpatrick's =my-babel-src-jump= with =my-babel-src-code= to fix that. 
Maybe tomorrow...


Best,

Chuck

Re: [O] Replace macros on tangle

[Charles C. Berry]

On Mon, 26 Jun 2017, Nicolas Goaziou wrote:


Hello,

Giacomo M  writes:


Dear all,
how can I add macro replacement support when a source block is being
tangled?


I don't think so. Macro replacement is an export feature.


If Giacomo's macros operate outside of src blocks, he could export using 
`org-org-export-to-org', then tangle the resulting file.


Giacomo, if you want something to operate inside of src blocks you can 
use noweb replacements that execute code as outlined in


(info "(org) Noweb reference syntax")

In a way these are like macros.

HTH,

Chuck

Re: [O] Asks user what to do with each tangle-file before overriding?

[Charles C. Berry]

On Sun, 18 Jun 2017, Chunyang Xu wrote:


Nicolas Goaziou  writes:

[...]


I don't think it is a good idea to have file that can be both edited
manually, and auto-generated (i.e., tangled). Or, to put it differently,
the idea behind tangling is that you only handle the code block, not the
file itself.


I still think overriding exist files is dangerous, user can lost data
because of it, so it should be safer if org-babel-tangle can let user
decide how to deal with it.

Besides, if a code block is not changed and I have already tangled it
before, I don't want org-babel-tangle to update the last modified
timestamp of the tangle-file every time I tangle, as along as there is
no actual changes. It is simply unnecessary to me and makes the last
modified timestamp more or less useless. So I would like
org-babel-tangle let me choose what I want.

[...]


It sounds like you are re-inventing version control and wanting it to be 
implemented in org-babel-tangle.


`org-babel-tangle' can do a lot of work to assemble the files that result 
from tangling.  Modifying `org-babel-tangle' to do what you ask would be 
far from trivial and make a complicated function even more tortuous.


IMHO, it is better to solve your problem as follows: Set up a separate 
directory into which files are tangled.  Use version control on that 
directory.  Inspect changes after each tangle using the version control 
system's diff tools, commit good changes, and revert unwanted ones.  Then 
run a script that uses the VC's data to identify changed files and copy 
those files to the location on your system where they will be used.


HTH,

Chuck

Re: [O] order of evaluation upon export: macros are evaluated too soon

[Charles C. Berry]

On Wed, 7 Jun 2017, Eric S Fraga wrote:


Hello all,

I have a document with this (ECM) structure:

#+begin_src org
 ,#+macro: item I{{{n(i)}}}@@latex:}%@@
 ,#+options: toc:nil num:nil

 ,* {{{item()}}} Some topic
 ,* {{{item()}}} Another topic  :noexport:
 ,* {{{item()}}} A final one
#+end_src

I would like the exported headings to be numbered Q1, Q2, ... but only
the exported ones.



Maybe implement somethng like this:


#+BEGIN_SRC emacs-lisp
  (defun n-noexport (x y)
(let ((tags (nth 5 (org-heading-components
  (unless (and tags
   (string-match ":noexport:" tags))
(org-macro--counter-increment x y
#+END_SRC

#+MACRO: n2 (eval (n-noexport "$1" "$2"))


* heading 1

{{{n2()}}}


* heading 2:noexport:notever:

{{{n2()}}}

* heading 3
{{{n2()}}}


HTH,

Chuck

Re: [O] exporting markdown with tables

[Charles C. Berry]

On Sun, 4 Jun 2017, Vicente Vera wrote:


Cool, you're welcome. It is not the most convenient solution, but
keeping your tables in Editorial Markdown syntax should work:

#+BEGIN_EXPORT md
Cat | Fur   |
--- | ---   |
A   | A lot |
B   | None  |
#+END_EXPORT



Except that the above is not recognized as a table, so all the nifty tools 
for table editing are lost.


IMO, a better solution is to create a filter for table-row that replaces 
the leading vertical with a space (or nothing) and bind that function to 
`org-export-filter-table-row-functions'. See


(info "(org) Advanced configuration")


---

However, those intimidated by filters can keep tables in org src blocks 
and convert them on export using a :post argument to clean the leading 
verticals.  That way the tables can be edited as usual via 
org-edit-src-code:


#+name: strip-leading-vertical
#+BEGIN_SRC emacs-lisp
(replace-regexp-in-string "^|" " " *this*)
#+END_SRC


#+header: :results replace :exports results
#+header: :post strip-leading-vertical() :wrap export md
#+BEGIN_SRC org
  | a | b |
  |---+---|
  | 1 | 2 |
  | 3 | 4 |
#+END_SRC

#+RESULTS:
#+BEGIN_export md
  a | b |
 ---+---|
  1 | 2 |
  3 | 4 |
#+END_export

A call to `(require 'ob-org)' or suitable customization is needed to 
enable the org src block to execute.


HTH,

Chuck

Re: [O] how to replace includegraphics?

[Charles C. Berry]

On Wed, 31 May 2017, ed...@openmail.cc wrote:


Hello dear list,

* Summary
I want to know if someone could tell me how to replace (the macro, function, 
string) includegraphics for something else when exporting to LaTeX. In my 
case, simplesvg.




This is what filters are for.  In your case `:filter-link' needs to have a 
function that changes `includegraphics' to `simplesvg', if I get what you 
want.


Check out the manual:

(info "(org) Advanced configuration")

maybe run the example here:

http://orgmode.org/worg/exporters/filter-markup.html

and consult the part about filters here:

http://orgmode.org/worg/dev/org-export-reference.html

There are examples in the ox-*.el files, too. So, grep these for 
`filters-alist' to see some examples.


HTH,

Chuck

Re: [O] [org] different key binding between GUI emacs and emacs -nw

[Charles C. Berry]

On Tue, 30 May 2017, Scott Randby wrote:


On 05/30/2017 08:29 AM, Jean-Christophe Helary wrote:

It is the opposite that's happening. Terminal works fine. It is the GUI
that does not accept the bindings. And as I wrote, it is not limited to
my macOS (Emacs.app and Aquamacs show the same behavior) but to other
people's GTK+ linux or Xubuntu. So it seems that's something that aught
to be investigated and eventually fixed.


Not by the org team, I think. As Scott reports:



I have no issues on Xubuntu with Org key bindings. I'm using Emacs
24.5.1 and Org 9.0.3 on Xubuntu 16.04.


I have no issues either on

macOS Sierra 10.12.5 Emacs.app 25.1.1 Org 9.0.7


AFAICS, the GUI Emacs.app runs as advertised and there is nothing wrong 
with Org.  There are a lot of us who use macOS and Org with no issues with 
M-, so it is hard to see how this is an org-mode issue.


Some additional data points:

M- promotes and M- demotes headlines using the usual GUI app.

The Terminal is tricky:

In the Terminal using Emacs.app, with Edit Menu - Use Option As Meta Key 
selected:


I get promote/demote if I use S-  or C- .

ESC  runs promote/demote regardless of Option as Meta setting.

- runs M-b/f regardless of Option as Meta setting.

Running C-h k  shows that the Terminal 
doesn't see Option as Meta in the way I would expect.


So, if there is a problem on my setup it lies in the Terminal.app or some 
plist that governs it.


HTH,

Chuck

Re: [O] Bug: begin_src org :results replace does not work

[Charles C. Berry]

On Mon, 29 May 2017, Vikas Rawal wrote:






The problem is that the results you generate is a table with affiliated
keywords NAME and CAPTION and ATTR_[backend].

`org-at-table-p' does not recognize that the keywords are followed by a
table.  Altering this function might be asking for trouble as it is used
outside babel.

So maybe the cond test should refer to `org-element-context' to better
sort this out and correctly identify the table end.



Thanks for the explanation.

Since this was meant for use in a tutorial, I wanted #+NAME, etc to be
there.

I will have to use some other work around. :wrap does not work for me, as
it does not remove the , escape characters.



Right. But that should export properly. If you just want to show what the 
src block yields on execution, perhaps:


#+NAME: one
#+BEGIN_SRC org  :results replace drawer
,#+NAME: table-yield
,#+CAPTION: Simple table created using latex tabular environment
,#+attr_latex: :environment tabular :width \textwidth :align lrr
| State | Variable one | Varia two |
|+---+|
| MP | 672 | 13000 |
| Har | 300 | 25000 |
| Pun | 260 | 35000 |
#+End_SRC


Chuck

Re: [O] Overriding org-html-headline or other export functions?

[Charles C. Berry]

On Mon, 29 May 2017, Brett Viren wrote:


"Charles C. Berry" <ccbe...@ucsd.edu> writes:


You do have that wrong.  This is exactly what export filters and
derived backends are for.  In fact, you can use both.  For an example,
see

http://orgmode.org/worg/exporters/filter-markup.html

You will want to change `latex' to `html' in the

`(org-export-define-derived-backend ...)'

call and delete all filters except for `:filter-headline'.  And revise
`ox-mrkup-filter-headline' accordingly.


Thanks for checking me on this, but I still don't see it.

If I understand, a derived HTML backend with my own filter-headline
would let me add my own extra HTML *outside* the "...",
"...", etc, HTML that is generated by the base
org-html-headline filter.  But for the output I want I need to add my
extra HTML *inside* the contents of the "..." tags.  And I
don't see an export filter for this "..." part.

Or, maybe you suggest I do direct "surgery" on the TEXT argument that
gets passed in to the filter and insert the "..." that way?  I guess it
could work to find the end of the "" opening tag and then insert
my "..." part.  I'll try this approach.


Yeah. You can use one or two `replace-regexp-in-string' calls I think.

You get that if the underlying code in ox-html changes in a way that is 
incompatible with your headline transcoder, you will have to start over. 
OTOH, since you only change one line it would not be the end of the world 
unless lots of others depend on that code and you were enjoying a 
wilderness vacation.  I would guess that such changes would be few at 
this late date.


If this is something you only use for personal work, then

#+BEGIN_SRC emacs-lisp
(org-export-define-derived-backend 'bv 'html
  :translate-alist '((headline . org-bv-headline)))
(defun org-bv-headline )
#+END_SRC

finishes the job without a lot of fuss.

HTH,

Chuck

Re: [O] Overriding org-html-headline or other export functions?

[Charles C. Berry]

On Mon, 29 May 2017, Brett Viren wrote:


Hi,

I am writing a manual in Org which gets exported/published to HTML and
styled with org-html-themes.  I want the HTML to include a little icon
next to each headline which is a direct link to the headline itself.
Basically, I want to rip off what GitHub does when it renders Org.

First, is there some way to achieve this headline link without
explicitly adding it in the Org text or diving into Org Elisp?

I couldn't find one so I took the latter route by copying out the whole
of org-html-headline into the Emacs init Elisp file I used for
publishing and fiddle with it until I got more or less what I wanted.
Here are the lines tweaked:

 https://github.com/WireCell/wire-cell-docs/blob/master/manuals/publish.el#L69

Here is an example of the result:

 http://www.phy.bnl.gov/~bviren/wirecell.github.io/manual.html

Is this copy+hack the proper way to tweak the exporting in this case?
In particular, I worry about my copy of org-html-headline diverging from
the real.


I read about export filters and extending an existing back-end, but I
think these do not apply, but maybe I have that wrong.



You do have that wrong.  This is exactly what export filters and derived 
backends are for.  In fact, you can use both.  For an example, see


http://orgmode.org/worg/exporters/filter-markup.html

You will want to change `latex' to `html' in the

`(org-export-define-derived-backend ...)'

call and delete all filters except for `:filter-headline'.  And revise 
`ox-mrkup-filter-headline' accordingly.


And of course, you will want to look at

http://orgmode.org/worg/dev/org-export-reference.html

HTH,

Chuck

Re: [O] Bug: begin_src org :results replace does not work

[Charles C. Berry]

On Mon, 29 May 2017, Vikas Rawal wrote:


Why does the replace keyword not work? It prepends the results. I have
tried both ":results value replace" and ":results output replace".

I am on org-version 9.0.7

Vikas




#+NAME: one
#+BEGIN_SRC org :results value replace export both
,#+NAME: table-yield
,#+CAPTION: Simple table created using latex tabular environment
,#+attr_latex: :environment tabular :width \textwidth :align lrr
   | State  | Variable one | Varia two |
   |+---+|
   | MP |   672 |  13000 |
   | Har|   300 |  25000 |
   | Pun|   260 |  35000 |
#+End_SRC



The problem is that the results you generate is a table with affiliated 
keywords NAME and CAPTION and ATTR_[backend].


`org-at-table-p' does not recognize that the keywords are followed by a 
table.  Altering this function might be asking for trouble as it is used 
outside babel.


So maybe the cond test should refer to `org-element-context' to better 
sort this out and correctly identify the table end.


Unless/until this happens you can use `:wrap org src'.

HTH,

Chuck

p.s. M-x org-lint RET shows you forgot the `:' before `export'

Re: [O] returning propertized strings

[Charles C. Berry]

On Sat, 20 May 2017, John Kitchin wrote:


If I run this block I get test as a result, but all its properties have
been stripped.

#+BEGIN_SRC emacs-lisp :results drawer
(propertize "test" 'font-lock-face '(:foreground "red") 'help-echo
"tooltip")
#+END_SRC

#+RESULTS:
:RESULTS:
test
:END:

Does anyone know where this happens and if it can be avoided?


Where?

Not sure, but late enough that `:results pp' will print them or `:post 
...' will receive them in `*this*'.


#+BEGIN_SRC emacs-lisp :results drawer pp
(propertize "test" 'font-lock-face '(:foreground "red") 'help-echo 
"tooltip")

#+END_SRC

#+RESULTS:
: #("test" 0 4
:   (help-echo "tooltip" font-lock-face
:(:foreground "red")))

also `*this*' will contain the propertized version if you use the :post 
header arg.


HTH,

Chuck

Re: [O] How to use :prologue with latex

[Charles C. Berry]

On Mon, 24 Apr 2017, Jeremie Juste wrote:




Hello,

I would like to use :prologue  and epilogue with latex output when using
R. Would it be possible to do something like the following?



[...]

#+BEGIN_SRC R :results output latex :prologue \\begin{table} :epilogue 
\\end{table} [...]


[...]


Sure. But you do not need to; see my comment at bottom.  Try this:

#+NAME: test1123
#+HEADER: :prologue cat("\\begin{table}\n")
#+HEADER: :epilogue cat("\\end{table}\n")
#+BEGIN_SRC R :results output latex  :session *R* :dir tmp :cache no
require(xtable)
print(xtable(data.frame(a=rnorm(10),b=letters[1:10])),floating.environment=FALSE)
#+END_SRC

You might be better off using the :post header arg.

Define a src block like this:

#+name: add-table-env
#+BEGIN_SRC emacs-lisp
(format "\\begin{table}\n%s\n\\end{table}\n" *this*)
#+END_SRC

Then use

#+HEADER: :post add-table-env()

in place of the two header lines above.  The advantage is that you can if 
you want do more complicated moidification of the result.




AFAIK, LaTeX has no FALSE environment.

I think what you actually wanted was *not* :prologue and :epilogue but 
this R code:


#+begin_src R
print(xtable(data.frame(a=rnorm(10),b=letters[1:10])),floating.environment="table")
#+end_src


HTH,

Chuck

Re: [O] ANN: org-sticky-header

[Charles C. Berry]

On Wed, 19 Apr 2017, Adam Porter wrote:


This should now be fixed.  Thanks!



I have encountered a bug when trying to export a subtree containing an 
inlinetask just after the headline/metadata and a src block further down.


Here is an ECM:

--8<---cut here---start->8---
* a Headline
*** my task

  Do this well!

*** END

#+NAME: my-model
#+BEGIN_src latex :results latex
  \begin{displaymath}
y = x + z
  \end{displaymath}
#+END_src
--8<---cut here---end--->8---

Put the cursor under the headline (at the end of buffer, say) then type

C-c C-e C-s l L y

and without org-sticky-header mode you get an exported buffer.

With org-sticky-header mode, it just hangs after the 'y' is typed.

Also, if you put point at the beginning of the second line (the start
of the inlinetask) and type

: M-: (narrow-to-region (point) (point-max))

it will narrow if o-s-h mode is off, but hang if it is on.

Adding a newline after the headline `cures' the export problem.
However, if point is at the start of an inlinetask, then emacs will
hang when running the narrow-to-region snippet above regardless of
newlines.

p.s. I am using commit b82b4f210e... (newest at this time)

Chuck

Re: [O] :noweb-ref property inheritance failure?

[Charles C. Berry]

On Tue, 18 Apr 2017, D Bro wrote:


Both 26.0 and 25.1 on OS X 10.12 via homebrew, using the Spacemacs 
configuration.



I recently tried the weaving technique from 
http://orgmode.org/manual/noweb_002dref.html#noweb_002dref 
 :


[snip]

Using M-x org-lint on your example gives

 3 high  Unknown header argument ":classname"
12 high  Incorrect location for PROPERTIES drawer

The latter is because the drawer is not immediately after a headline and 
is disregarded:



**Let's see what our code-weaving produces
:PROPERTIES:
:header-args: :noweb-ref testdemo2
:END:


If you put a space between `**' and `L[...]' the line becomes a valid 
headline. Then the TestDemo2 src block produces


 ,
  | public class Yo {
  | public static void main (Args[]) {
  | return "The test worked!";
  | //
  | }}
  | cat TestDemo2.java
  `

on ASCII export.

You can ignore the message about :classname, which comes from ob-java not 
defining it as a header-arg.


HTH,

Chuck

Re: [O] Bug: :session doesn't honor :verbatim [8.2.10 (release_8.2.10 @ /usr/local/share/emacs/26.0.50/lisp/org/)]

[Charles C. Berry]

On Sun, 16 Apr 2017, Michael Albinus wrote:


"Charles C. Berry" <ccbe...@ucsd.edu> writes:


Michael might get some relief by altering `shell-prompt-pattern' whose
default value is

"^[^#$%>\n]*[#$%>] *"

is tricked by the embedded `%' in the output lines

If you know the prompt will not contain `%', you could delete that.

Changing the asterisk to a plus might work (untested) or maybe adding
a blank in the first (negated) char class (also untested). Or if you
know what the prompt will be literally, use that: "^My-prompt-[$] *"


I've eval'ed (setq shell-prompt-pattern "^[^#$>\n]*[#$>] *") , this
helps. Thanks for the tip.

However, I don't want to change this globally. Is there an org mean to
change this locally just for the session?

Maybe the shell prompt could be customizable for a session in ob-sh.el?



That happens in the shell. You can do this to start your session:

#+BEGIN_SRC shell :session mysess
  PS1="MyPrompt-$ "
#+END_SRC

#+RESULTS:

and then tell emacs to locally set `comint-prompt-regexp' to a value
other than what was copied from `shell-prompt-pattern'

#+BEGIN_SRC emacs-lisp
  (save-excursion
(pop-to-buffer "mysess")
(setq-local comint-prompt-regexp "MyPrompt-$ "))
#+END_SRC

#+RESULTS:
: MyPrompt-$

and then it should work.

#+BEGIN_SRC shell :session mysess
  echo "a%b"
#+END_SRC

#+RESULTS:
: a%b

---

You might skip the second step and instead set `shell-prompt-pattern'
to "MyPrompt-$ ". If `comint-use-prompt-regexp' is nil, then the
`comint-prompt-regexp' is only consulted by ob-shell.el funs per the 
docstring of comint-use-prompt-regexp.




Chuck

Re: [O] Bug: :session doesn't honor :verbatim [8.2.10 (release_8.2.10 @ /usr/local/share/emacs/26.0.50/lisp/org/)]

[Charles C. Berry]

On Sun, 16 Apr 2017, Tilmann Singer wrote:


Let me add that when not specifying ":results verbatim", the presence of
the % sign in the output also triggers table formatting:

#+BEGIN_SRC sh :session *session*
echo "a%b"
#+END_SRC

#+RESULTS:
|   |
| b |



The extra line looks like a bug in babel. The session will show:

echo "a%b"
bash-3.2$ a%b

as the first two lines in the buffer.

--

Michael might get some relief by altering `shell-prompt-pattern' whose 
default value is


"^[^#$%>\n]*[#$%>] *"

is tricked by the embedded `%' in the output lines

If you know the prompt will not contain `%', you could delete that.

Changing the asterisk to a plus might work (untested) or maybe adding a 
blank in the first (negated) char class (also untested). Or if you know 
what the prompt will be literally, use that: "^My-prompt-[$] *"


[snip]

HTH,

Chuck

Re: [O] Trouble exporting inline code blocks

[Charles C. Berry]

On Mon, 10 Apr 2017, Richard Stanton wrote:


Here’s a very simple org file:



Some inline Python code: 2 plus 2 is src_python[:session]{2+2}

-

If I put the cursor on the code block and type C-c C-c, I get  nice results 
block containing the answer, 4. So far so good.

I’d like to export just the results to PDF via LaTeX. However, no matter 
what options I pass, the exported PDF file shows both the source and the 
output.



I get this

Some inline Python code: 2 plus 2 is \texttt{4}

in response to C-c C-e C-b l L

Org mode version 9.0.5


HTH,

Chuck

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Mon, 13 Mar 2017, Thomas S. Dye wrote:


Aloha Chuck,

Charles C. Berry writes:


On Fri, 10 Feb 2017, Thomas S. Dye wrote:


Aloha Chuck,

Charles C. Berry writes:


A look at the `slidify-example.org' file in the `org-9-plus' branch of my
(chasberry) `orgmode-accessories' github repo might be a good start with
.Rmd exports even if you do not want to use `slidify'.




{snip - discussion of how to export to R markdown]



Just a short note to let you know that ox-ravel was a terrific tool for
my project of producing a workable R Markdown file for an upcoming
conference.  I was dreading the requirement to provide .Rmd source for a
handout, but ox-ravel made it one of the easiest steps.



I just got back from two weeks offline and it was nice to find your note.

I am glad ox-ravel did the job for you!

Best,

Chuck

Re: [O] Bug report: export to HTML does not escape * in example

[Charles C. Berry]

On Wed, 1 Mar 2017, Nicolas Goaziou wrote:


Hello,

D M German  writes:


So the original issue (* not being escaped) will nonetheless appear when
the threshold is passed:



Fixed. Thank you.



Hmmm. Now I get

:FAILED  test-ob/org-babel-insert-result

for make test2, which appears to be from trying to match

",\\* Not an headline" "

to

#+RESULTS:
: * Not an headline

in test-ob/org-babel-insert-result

HTH,

Chuck

Re: [O] Strings converted to numbers in Org table?

[Charles C. Berry]

On Mon, 27 Feb 2017, Vicente Vera wrote:


Hello again, I'm sorry for being noisy.

OK yes, `org-babel-read' is indeed converting "number strings" to
numbers.



[proposed fix deleted]

I don't have a feeling as to whether the proposed fix is appropriate.

However, there are other ways to solve this issue. See below.



- In R every value is a string. "var2" contains no numbers (is a
  character vector).

- Upon conversion to a table Org removes the zero from "var2" last
  value.

--

#+BEGIN_SRC R :session *mwe* :results value table :colnames yes
  tst <- data.frame(var1 = c("a", "b", "c", "d", "e", "f", "g"),
var2 = c("150", "210", "140", "150", "192", "497",
"3.350"),
stringsAsFactors = FALSE)
  tst
#+END_SRC

#+RESULTS:
| var1 | var2 |
|--+--|
| a|  150 |
| b|  210 |
| c|  140 |
| d|  150 |
| e|  192 |
| f|  497 |
| g| 3.35 |

--

Here's the output as seen in R:

: > tst
:   var1  var2
: 1a   150
: 2b   210
: 3c   140
: 4d   150
: 5e   192
: 6f   497
: 7g 3.350

Details on the data frame:

: > str(tst)
: 'data.frame':7 obs. of  2 variables:
:  $ var1: chr  "a" "b" "c" "d" ...
:  $ var2: chr  "150" "210" "140" "150" ...

It seems Org knows that the values on column "var2" are numbers and
converts the strings to numbers, applying some obscure trimming on the
digits. The "3.350" value needs to be left as is.



IMHO, it is often best to handle formatting of output in the language of 
the src block.  There are some tools for doing this in R: the `ascii' 
package is one. `xtable' is another.


You can always do something like this:

#+BEGIN_SRC R :session *mwe* :results output
 tst <- data.frame(var1 = c("a", "b", "c", "d", "e", "f", "g"),
 var2 = c("150", "210", "140", "150", "192", "497", "3.350"),
 stringsAsFactors = FALSE)

 cat( capture.output( print(tst, row.names=FALSE)), sep="\n")

#+END_SRC


Or you can use `ox-ravel'[1] to convert to one of the knitr-like formats 
and let knitr or rmarkdown handle the output conversion.


Best,

Chuck

[1] https://github.com/chasberry/orgmode-accessories

Re: [O] Bug report: export to HTML does not escape * in example

[Charles C. Berry]

On Mon, 27 Feb 2017, dmg wrote:


On Sun, Feb 26, 2017 at 11:40 PM, Nicolas Goaziou 
wrote:



A star at the beginning of a line is always a headline.


[...]



​Thank you. I guess the issue is then with org-babel.

I am running a babel script that generates, as one of its line * in the
front:

​#+BEGIN_SRC sh
echo "* Hello"
#+END_SRC

#+RESULTS:
#+begin_example
* Hello
#+end_example

​In that case, should babel be the one escaping the * in the RESULTS block?


Is that *really* what it did?

When I run your example, I get:

#+RESULTS:
: * Hello

and this exports (with the `:exports results' header) to html wrapped 
in a  container:



* Hello


using Org 9.0.5.

Without that header the src code gets wrapped in a  container.

So there must be something in/about your setup you haven't mentioned.

HTH,

Chuck

Re: [O] Where to put dates on meeting headlines

[Charles C. Berry]

On Fri, 24 Feb 2017, John Kitchin wrote:


Suppose I use a heading to store notes on a meeting.

Is there a canonical location to put a date so I could search for them
later?

It seems like the date is not a deadline, or scheduled timestamp.  I
could see putting the date in the headline, but then I do not see an
obvious way to search for meetings that occurred in a time range.
Putting the date in the body is another location, but then I do not know
how it might be searched again.

Another option is a property, which might be searchable at least with a
function.

What do you do along these lines?

Here is a simple example of a headline I might have, and later I might
want a report of all meetings in the month of February.

* Group meeting <2017-02-24 Fri> :meeting:



That is a timestamp, albeit one with `:hour-start nil :minute-start nil'.

Isn't this good enough to search with?

#+BEGIN_SRC emacs-lisp
  (org-element-map
  (org-element-parse-buffer) 'timestamp
(lambda(x)
  (let
  ((beg (org-element-property :begin x))
   (month (org-element-property :month-start x))
   (year (org-element-property :year-start x)))
(format "Year %s Month %s Where %s" year month beg
#+END_SRC


#+RESULTS:
| Year 2017 Month 2 Where 18 |

HTH,

Chuck

Re: [O] Code block eval scope - subtree only option ignored

[Charles C. Berry]

On Fri, 24 Feb 2017, Jay Iyer wrote:


Hi, evaluating a simple elisp code block in a subtree, called with C-c C-v
C-s or just C-c C-C, evaluates the entire Org buffer.  Is this expected
behavior?


Not at all.

C-c C-v C-s on the headline evaluates just the subtree via the command 
org-babel-execute-subtree. (Org 9.0.5 and many prior versions.)


C-c C-c on the headline prompts for tags. In a src block, it evaluates the 
code.


Of course, if you wrote a Babel block that executes other Babel blocks, 
all bets are off.



How can I force the eval on the visible portion (with narrowing) of the
tree only?


Narrow, Then

M-x org-babel-execute-buffer RET


HTH,

Chuck

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

On Tue, 21 Feb 2017, Aaron Ecay wrote:


Hi Chuck,

2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen:

[...]




Allowing header args to be processed (as before) also allows for arbitrary
code to be executed.  The point of setting ‘org-export-use-babel’ or
`org-export-babel-evaluate' to nil was to prevent this.  For that reason
the former behavior was a bug.


Iʼm not sure I agree that itʼs so simple.  There are still ways to execute
arbitrary code on export independently of babel (e.g. eval macros).  The
advice to use o-e-babel-evaluate for security was never (IMO) correct –
the only properly secure wat to export untrusted documents would involve
some kind of sandboxing of the emacs executable.



Fair enough.

[snip]



Taking a step back, I would ask what justifies o-e-b-eʼs existence at
all.  This thread demonstrates that itʼs not the right way to prevent
babel blocks from executing on export.  Itʼs also not a good solution to
the security issue.  Given the potential for confusion, Iʼd be in favor
of deprecating it entirely unless thereʼs some compelling reason for it
to exist that Iʼve overlooked.


In view of your point above about `eval' macros, I do not disagree.

Chuck.

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

On Mon, 20 Feb 2017, Derek Feichtinger wrote:


Hi Chuck

On 21.02.2017 00:54, Charles C. Berry wrote:

On Mon, 20 Feb 2017, Derek Feichtinger wrote:

When org-export-babel-evaluate is set to nil, I see a different behavior 
now as compared to earlier versions of org.


Indeed.

It is now *obsolete* and its behavior has intentionally been changed as 
noted here:





So, I still feel that this is a very much needed functionality that has been 
lost on the way.


Nothing is lost here.

Reread the part of my post that you deleted in your reply:

: | ...  Users
: | who wish to avoid evaluating code on export should use the header
: | argument ‘:eval never-export’.
: |

which is how to do what you want.

And maybe review how to set header args buffer wide or system-wide.

HTH,

Chuck

Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

On Mon, 20 Feb 2017, Derek Feichtinger wrote:

When org-export-babel-evaluate is set to nil, I see a different behavior now 
as compared to earlier versions of org.


Indeed.

It is now *obsolete* and its behavior has intentionally been changed as 
noted here:


,[ C-h v org-export-babel-evaluate RET ]
| org-export-babel-evaluate is a variable defined in ‘org-compat.el’.
| Its value is t
|
|   This variable is an alias for ‘org-export-use-babel’.
|   This variable is obsolete since Org 9.1;
|   use ‘org-export-use-babel’ instead.
|
| Documentation:
| Switch controlling code evaluation and header processing during export.
| When set to nil no code will be evaluated as part of the export
| process and no header arguments will be obeyed.  When set to
| ‘inline-only’, only inline code blocks will be executed.  Users
| who wish to avoid evaluating code on export should use the header
| argument ‘:eval never-export’.
|
| You can customize this variable.
|
| [back]
`

and here

 (info "(org) Exporting code blocks")


I think that this should be considered a bug.


Allowing header args to be processed (as before) also allows for arbitrary 
code to be executed.  The point of setting ‘org-export-use-babel’ or 
`org-export-babel-evaluate' to nil was to prevent this.  For that reason 
the former behavior was a bug.



Chuck

Re: [O] Problems exporting simple LaTeX math to HTML

[Charles C. Berry]

On Tue, 14 Feb 2017, Richard Stanton wrote:


[My apologies if this is a repeat. I tried posting this 4 days ago and didn’t 
see if appear on the list.]

I created the following very simple org file:




#+TITLE: *Math example*

\[ w_j = \nu_j \prod_{l

Re: [O] Help checking orgcard.pdf

[Charles C. Berry]

On Sat, 11 Feb 2017, Kyle Meyer wrote:


"Charles C. Berry" <ccbe...@ucsd.edu> writes:



[snip]




Also AFAICS, this one is not current either:

\key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}


Hmm, C-c C-x \ is bound to org-toggle-pretty-entities, so the binding is
correct.  Is the description no longer accurate?



My bad. I *misread* the TeX as rendering =C-c C-x `=. Sorry.

The rest of that section looks good now.

Chuck

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Fri, 10 Feb 2017, Thomas S. Dye wrote:


Aloha Chuck,

Charles C. Berry writes:


A look at the `slidify-example.org' file in the `org-9-plus' branch of my
(chasberry) `orgmode-accessories' github repo might be a good start with
.Rmd exports even if you do not want to use `slidify'.


Your ox-ravel exporter is a pleasure to use.  I'm farther along than I
thought I'd be at this point.



Thanks. I am glad to hear this.



I'm new to much of the R ecosystem, including slidify, so forgive some
noob ignorance in the following three questions:

1) I've specified the properties EXPORT_TITLE and EXPORT_AUTHOR, but
they don't show up in the .Rmd file.  Is this a limitation of ox-ravel,
or do I need to learn how to insert them in the Org mode source?



Both, I guess.

Arguably, it is a limitation in the markdown backends available that
there isn't one that will create the yaml header from the export
options in the org buffer.  I think the long term fix is to create a
backend derived from 'md, but this is far down my todo list.  For now,
either hand tool a yaml header like that in

: slidify-example.org::#tds-headline

(If you are viewing that on my github repo, be sure to click 'raw' or the 
yaml header will not be visible!)


or create a src block that will pull the title, author, et cetera and wrap 
them as a yaml header in an md export block and put it at the top of the 
output. If you want to do the src block, I can provide a skeleton version.




2) How do I instruct ox-ravel to include the graphics output of a source
code block?  I tried :ravel fig=TRUE as a header to the source code
block, but no dice.  Most of my experience is with ox-latex, so that
colors my expectations here; i.e. I'm expecting a [[file:myfile.pdf]]
link to produce a graphic in the output.


Often it `just works', but it depends on the vignette engine. `fig=TRUE' 
is correct for Sweave. See


: demos.org::#36234656-157D-4F1D-B441-E727DFCC0251

for an example of that. For knitr, you usually do not need to include 
anything if there is just one plot produced, but there are loads of 
options. See


https://yihui.name/knitr/options/#plots


I find myself using ~:ravel fig.cap=my_caption~ (where `my_caption' is
an R string from an earlier src block) a lot. See

: demos.org::#C341969B-90F3-4C27-AA7F-5352A9669506

for an example of a lengthy caption done in latex.

There is a src block that produces a plot in the slidify-example.org file. 
No special header was needed for ~slidify()~ to render it.  But I cannot 
be sure whether the yaml block does something special for the graphics.




3) I've been knitting the .Rmd output using RStudio, which is also new
to me.  I don't mind doing this (it is what the session organizer is
going to do with the .Rmd file I send next week), but I'm wondering
if you have an emacs-only solution?



I don't know RStudio, but here is a start:

#+BEGIN_SRC R :exports none :results silent
require(rmarkdown)
render("my-file.Rmd")
#+END_SRC

If you look at the =demos.org= file, you will see examples and the src 
blocks used to run ~knitr::knit2pdf()~.  If you export some of the 
examples to *.Rmd files and run the equivalent ~render(...)~ on the .Rmd 
files, you will get html by default.


---

Let me know how it works out!

Best,

Chuck

Re: [O] Help checking orgcard.pdf

[Charles C. Berry]

On Thu, 9 Feb 2017, Kyle Meyer wrote:


Kyle Meyer  writes:



Sorry not to be sending a patch, but I figured I should at least mention 
that these are not current:



\key{export visible part only}{C-c C-e v}
\key{insert template of export options}{C-c C-e t}

Also `C-c C-e' brings up the export dispatcher menu (by default) where 
options to select the visible part or insert a template are revealed. So, 
mention of the correct incantations need not appear in the refcard.



Also AFAICS, this one is not current either:

\key{toggle pretty display of scripts, entities}{C-c C-x {\tt\char`\\}}

HTH,

Chuck

Re: [O] Exporting blocks of text completely verbatim

[Charles C. Berry]

On Thu, 9 Feb 2017, Vicente Vera wrote:


Hello. This discussion
https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00163.html
points out that Org tables are converted to HTML tables when exporting
through "ox-md". Leaving Markdown-related issues aside, I've stumbled
upon this problem a while back.

It is suggested that wrapping the table within a "#+(BEGIN|END)_EXPORT
md" should leave it as-is in the exported document but that is not the
case. The table gets converted to HTML anyway.



Not in recent versions of org. Here is an example of a table that is 
exported as a table without any html-ization:


#+BEGIN_SRC emacs-lisp :results raw
  (org-export-string-as
   "
  ,#+begin_export md
  | a |
  | b |
  ,#+end_export"
   'md t)

#+END_SRC

#+RESULTS:
| a |
| b |


Of course, the comma escapes are stripped before `org-export-string-as' 
sees the string.


HTH,

Chuck

Re: [O] backporting changes to exported results for collaborative editing

[Charles C. Berry]

On Tue, 7 Feb 2017, Marcin Borkowski wrote:



On 2017-02-07, at 02:15, Samuel Wales  wrote:


suppose you export a subtree to ascii or html, and then a bunch of
people want to help you edit it.  obviously you want the changes back
in org.

obviously the best would be if you could give them the source,
complete with comments.  but assume that they are not computer people,
and not org people, and you don't want to give them your irrelevant
comments.

also assume you also don't want to give them your irrelevant tasks and
you do not use org-export-with-tasks.

it might be that i already know the answer: just do the best you can
with diff, and request small sets of changes at a time, or request
manual instructions for changes.  but perhaps you have ideas?


Maybe this could be automated a bit?  Like, org -> markdown, then
people's edits, then diff generating a patch, then some tool existing
only in my dreams currently that converts the md patch to an org patch,
and then apply that patch to the original org?  For small enough
changes, that could actually work, no?



Maybe, but this sequence might be easier:

- export subtree to md =edit-me.md= (body-only not needed but cleaner)

- distribute to editor and retrieve as =editted.md=

- in a shell run ~pandoc -o editted.org editted.md~

- M-x ediff-regions RET
  - select all of =editted.org=
  - select original subtree
  - Use `##' to skip the whitespace only diffs.
  - resolve the differences as appropriate and/or save the diffs.


Babel blocks/results are *not* be handled seamlessly, so more would
need to be done if your editor wants to revise them. Otherwise, just
skip them.

I guess this might work with ascii or html, but I've not tried it.


Chuck

Re: [O] How to use .pdf images on Latex export, and .png images on ODT export

[Charles C. Berry]

On Tue, 31 Jan 2017, Giacomo M wrote:


Dear all,

I was wondering what is the best way to include pdf images on latex export 
and png images on odt export (assuming same path, only extension changes). A 
macro like this one:

#+MACRO: figext @@latex:.pdfodt:.png@@
doesn't seem to work.



No, it won't work as Babel runs before the exporter handles the snippets.

Something like this should do.

Run this block or put the code in your init file:

#+BEGIN_SRC emacs-lisp
  (defun org-pdf-if-latex ()
(if (eq (org-bound-and-true-p
org-export-current-backend)
   'latex) "pdf" "png"))
#+END_SRC


This generates pdf for latex and png for all other backends (or no backend 
at all).


#+name: pdf-or-png
#+BEGIN_SRC R :exports both :results graphics :file-ext (org-pdf-if-latex)
plot(rnorm(50))
#+END_SRC

See (info "(org) file-ext")

HTH,

Chuck

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Sat, 28 Jan 2017, Thomas S. Dye wrote:


Aloha Chuck,



[snip]



Thanks, too, for asking about export. I'm giving a demo at a conference
this spring and the organizer has asked for a .rmd file, which is new to
me. I hope to produce it with your ox-ravel, also new to me, so I might
be pestering the list again :)



Fair enough!

If you are running org-9.0 or later, please use the `org-9-plus' branch 
(the default, now) of ox-ravel.  It has a lot more capabilities than the 
old `master' branch.  The code is cleaner, too.  :-)


As far as .Rmd files go, =(require 'ox-ravel)= and (if not already done in 
your init) either =(require 'ox-md)= or selecting markdown from the 
customize menu should allow `C-c C-e r m' to export a buffer as .Rmd.


A look at the `slidify-example.org' file in the `org-9-plus' branch of my 
(chasberry) `orgmode-accessories' github repo might be a good start with 
.Rmd exports even if you do not want to use `slidify'.


Best,

Chuck

Re: [O] Babel R source blocks problem

[Charles C. Berry]

On Sat, 28 Jan 2017, Thomas S. Dye wrote:


Aloha all,

I've run into a problem running R code blocks in a new Spacemacs setup.
Results are not written to the Org mode buffer.

In *Messages* I see this the first time I evaluate the R source code
block:
Error during redisplay: (jit-lock-function 804) signaled (search-failed
"^> ")

If I run R in a :session, then I see that the source code block is
executing correctly.

Other languages don't seem to have a problem writing results to the Org
mode buffer.

Any ideas how I might debug this?


I hope somebody recognizes that message. If not, here are som suggestions:


#+NAME: alpha
#+BEGIN_SRC emacs-lisp
"abc"
#+END_SRC

produces

#+RESULTS: alpha
: abc

when you run `org-babel-execute-src-block'. Does changing "emacs-lisp"
to "R" and running again erase the result or fail to insert it if
you first run `org-babel-remove-result'?

You have already checked that C-c C-v C-i for both versions yields
identical results, right?

If so, I'd instrument `org-babel-execute-src-block', execute and then
type 'h' just before the `(org-babel-insert-result ... ' --- a couple
of lines from the bottom --- once you enter edebug. Then `e' and
`results' to see that it is what you suppose it should be. Then step
thru the next few lines to insert the result. Then check the buffer to
see what happened. If no result was inserted, then I'd instrument
`org-babel-insert-result' and work from there.

HTH,

Chuck

p.s. You are not trying to export this and depending on the exporter
to run babel, right? Because there is another trick lying in wait...

Re: [O] src block: 'C-c C-c can do nothing useful here' if cursor on blank line

[Charles C. Berry]

On Fri, 27 Jan 2017, Kyle Meyer wrote:


Eric S Fraga  writes:


On Friday, 27 Jan 2017 at 18:44, John Hendy wrote:

Perhaps this is the intended behavior, but I noticed that I go to
execute a code block and get the message "C-c C-c can do nothing
useful here" if I'm not on the actual src block definition or a line
of code. If I'm on a blank line inside it, it doesn't execute. Here
was my test:


I have noticed this recently as well.  Not sure if it was always the
case, mind you, but it would be nice if C-c C-c would work even when the
cursor is on a blank line (within a src block, that is).


I think this changed with 0b6a2e241 (C-c C-c does nothing when at a
blank line, 2013-02-15).  I wasn't able to figure out the motivation for
that change.


Nor I. Perhaps it was just an oversight.

FWIW, in `org-ctrl-c-ctrl-c'

:(looking-at-p "[ \t]*$")

could be

#+BEGIN_SRC emacs-lisp
  (and
   (looking-at-p "[ \t]*$")
   (not (eq 'src-block (org-element-type (org-element-context))
#+END_SRC

without causing a lot of grief. I think `src-block' is the only
relevant case.

Chuck

Re: [O] Is it possible to "properly" indent inside latex fragments?

[Charles C. Berry]

On Mon, 23 Jan 2017, alain.coch...@unistra.fr wrote:



Hello.

This is what I obtain if I type each line followed by  and then
 in an org file:

* foo
 \begin{displaymath}
 \begin{split}
 a &= b \\
 &+c
 \end{split}
 \end{displaymath}

If I highlight everything and use 'M-x indent-region' or 'M-x
org-indent-region', it does not change.

Instead, what I would like to get is:

* foo
 \begin{displaymath}
   \begin{split}
 a &= b \\
 &+c
   \end{split}
 \end{displaymath}

(That specific indentation for the latex instructions is what I obtain
within a .tex file.)

Is it possible?


With export blocks you can get close.

If you type =C-c '= inside the following export block, you will get the 
contents in a latex buffer. Then indentation and other LATEX/P mode 
operations are available. When you exit with another =C-c '= the 
indentation is preserved.


#+BEGIN_EXPORT latex
\begin{displaymath}
  \begin{split}
a &= b \\
&+c
  \end{split}
\end{displaymath}
#+END_EXPORT


HTH,

Chuck

Re: [O] How to pass table to SRC block as strings only?

[Charles C. Berry]

On Thu, 19 Jan 2017, Sébastien Brisard wrote:


Thanks Charles for this answer. Let me state the problem more clearly.
Number-like cells *are* converted to numbers (as best illustrated by
the example below (see the use of numberp), which might incur accuracy
loss (see below, the first row has a lot of significant digits).
I am not interested in the number representation of these cells, only
the string matters for my application. Due to this accuracy loss,
converting back the number to a string is not an option for me...

Any ideas? Thanks!


The usual resolution of table references will eventually use
`org-babel--string-to-number' to do what its name suggests.

You can write an elisp function to handle references as you wish and call 
them from :var arguments.


A hackish way to do this for your case is to quash the action of 
`org-babel--string-to-number':


#+BEGIN_SRC emacs-lisp
  (defun get-ref-strings-as-is (ref)
(cl-letf (((symbol-function 'org-babel--string-to-number)
   (lambda (x) x)))
  (org-babel-ref-resolve ref)))
#+END_SRC

#+header: :var table=(get-ref-strings-as-is "table20170119") 
#+BEGIN_SRC emacs-lisp :colnames yes :results pp

table
#+END_SRC

#+RESULTS:
: (("row1" "12345678901234567890")
:  ("row2" "a")
:  ("row3" "b")
:  ("row4" "c"))

You can look at `org-babel-ref-resolve' to get some ideas on how to do 
this more artfully.



Sébastien

= begin example =
#+NAME: table20170119
| col1 | col2 |
|--+--|
| row1 | 12345678901234567890 |
| row2 | a|
| row3 | b|
| row4 | c|



HTH,

Chuck

Re: [O] How to pass table to SRC block as strings only?

[Charles C. Berry]

On Thu, 19 Jan 2017, Sébastien Brisard wrote:


Hello all,
here is a MWE

=BEGIN MWE=

#+NAME: table20170119
| col1 | col2   |
|--+|
| row1 | 1234567890 |
| row2 | a  |
| row3 | b  |
| row4 | c  |

#+BEGIN_SRC emacs-lisp :var table=table20170119 :colnames yes :results output
 (print (map 'list (lambda (row) (nth 1 row)) table))
#+END_SRC

#+RESULTS:
:
: (1234567890.0 "a" "b" "c")

=END MWE=

As you can see, col #1, row #1 is parsed as a float.



Actually, it is not a float:

#+BEGIN_SRC emacs-lisp :var table=table20170119 :colnames yes :results pp
(number-to-string (nth 1 (car table)))
#+END_SRC

#+RESULTS:
: "1234567890"

Maybe this is what you want:

#+BEGIN_SRC emacs-lisp :var table=table20170119 :colnames yes :results pp
(map 'list (lambda (row) (format "%s" (nth 1 row))) table)
#+END_SRC

#+RESULTS:
: ("1234567890" "a" "b" "c")

HTH,

Chuck

Re: [O] Latex Preview Fragment is not working on org 9.0.3 from elpa

[Charles C. Berry]

On Wed, 18 Jan 2017, Young-whan wrote:


I've installed the emacs-app via port, and there was no problem with Latex
Preview Fragment in a buffer at all.

Now, using the M-x package-list-packages, I've installed the latest org
9.0.3, then the latex preview is not working at all.

It comes with following error:

org-create-formula--latex-header: Symbol’s function definition is void:
org-export-get-backendError during redisplay: (eval (mode-line-mode-name))
signaled (void-function mode-line-mode-name)


That is because `org-export-get-backend' is not loaded (nor autoloaded).

You can type C-c C-e q to force loading of the org-export-* functions. Or 
put (require 'ox) in your init file.


I don't see why `org-export-get-backend' is lacking an autoload directive.

Bug??

Chuck

Re: [O] speeding up Babel Gnuplot

[Charles C. Berry]

On Wed, 4 Jan 2017, Achim Gratz wrote:


Thierry Banel writes:

There is no way to ensure a single call to
(org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
want to do that because I would have to change a lot of babel backends.


But that is the right fix to apply, unless there is a reason for the
input vars to be processed multiple times.  I haven't looked at the
Babel code in the last two years, but generally I'd suggest that each
argument should only be processed once per Babel block since the second
processing could have unwanted side-effects.



I'm late to this party, but AFAICS input vars are processed just once.

Running this:

#+BEGIN_SRC emacs-lisp :var a=(setq runvar (+ 1 runvar))
a
#+END_SRC

increments runvar by one each time it is run.

So this seems not to be a general babel issue.

??

Chuck

Re: [O] org-babel-tangle ignores noweb-ref property

[Charles C. Berry]

On Tue, 3 Jan 2017, Joon Ro wrote:


Hi,


When I use org 8.3.6, it works correctly, but when I use org 9.0.3, it 
seems org-babel-tangle ignores noweb-ref property. For example, using 
the example from http://orgmode.org/manual/noweb_002dref.html:



#+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
   <>
 #+END_SRC
 * the mount point of the fullest disk
   :PROPERTIES:
   :noweb-ref: fullest-disk


:header-args: :noweb-ref fullest-disk

Is the new style.

See ORG-NEWS *** Old Babel header properties are no longer supported

I guess (info "(org) noweb-ref") needs an update.

Chuck

Re: [O] Something like #+BIND but for the destination buffer

[Charles C. Berry]

On Tue, 3 Jan 2017, Jonas Bernoulli wrote:


So here's the ECM:

* Node

#+BEGIN_SRC emacs-lisp
 (progn (progn foo
bar))
#+END_SRC



(info "(org) Literal examples") suggests this


#+BEGIN_SRC emacs-lisp -i
  (progn (progn foo
bar))
#+END_SRC

(16 spaces before bar)

which gives me


@lisp
  (progn (progn foo
bar))
@end lisp

(16 spaces before bar)

HTH,

Chuck

Re: [O] Referring to an Org Babel variable in the invocation arguments to another Org Babel code block

[Charles C. Berry]

On Sun, 1 Jan 2017, Zack Piper wrote:


Hi Nicolas,
I tried "c", and it gives me:


c <<<


as the result.

I would like it to use the _variable_ "c", not the literal string.
So the result should be ">>> test <<<"



You mean you want to use the `name' of one `:var name=assign' argument
in the `assign' part of another --- something like what `let*' does in 
lisp.


But you simply cannot do that.

`(info "(org) var")' tells us what you can do:

#+BEGIN_QUOTE

The following syntax is used to pass arguments to `src' code blocks
using the `:var' header argument.

 :var name=assign

The `assign' is a literal value, such as a string `"string"', a number
`9', a reference to a table, a list, a literal example, another code
block (with or without arguments), or the results from evaluating a
code block.

#+END_QUOTE

The `name' of one argument is none of these (regardless of its effect when 
the body of the src block is executed, which BTW depends on the src block 
language).


There are other approaches that might serve a purpose in babel src blocks 
like that served by `let*' in lisp:


- putting variables in a table (possibly invoking `org-sbe' in a
 formula) and then referencing table cells

- writing other src blocks to handle the preliminary processing and
  referncing them

- writing an elisp src block that does those preliminaries (perhaps
  using `org-babel-ref-resolve' to call other src blocks), then builds
  a string specifying a call to your shell src block and calls it
  using `org-babel-ref-resolve'.

- using a noweb reference that executes another src block (or blocks).

- setting property values and referencing them

You might have better luck getting guidance on a useful approach by
trying to describe what you want to accomplish.


HTH,

Chuck

Re: [O] function to select text of in a cell of a table

[Charles C. Berry]

On Fri, 30 Dec 2016, dmg wrote:


hi everybody,

has anybody written a function to select the text in a cell of a table?


If you mean like what ob-ref.el uses to support babel references, yes.

Also see org-table.el.

If you just want support for working with Babel src blocks, see

(info "(org) var")

HTH,

Chuck

Re: [O] org mode latex export excude title

[Charles C. Berry]

On Fri, 30 Dec 2016, Ken Mankoff wrote:


(setq-local org-latex-title-command "")

Can be set as a buffer local variable.



True, but not relevant to the OPs query:


Is there any way to excude the empty `\title{}` command?


And if you browse thru org-latex-template, you will see that

 "\\title{%s%s}\n"

is hard coded.  The value of org-latex-title-command has no effect on that 
part of the template.


So, the OP can either use a filter as I suggested or write a derived 
backend supplying a different template transcoder that drops the string 
quoted above.


Chuck

Re: [O] org mode latex export excude title

[Charles C. Berry]

On Fri, 30 Dec 2016, Fanpeng Kong wrote:


I am trying to use org mode to write a paper. The latex template of the
journal restricts the location of `\title{}` command to be after the
`\begin{document}`. While by leaving `#+TITLE:` empty and specify
`#+OPTIONS: title:nil` in my org file, I can remove the `\maketitle` command in 
the
latex export. However, and empty title `\title{}` is still exported
prior to the `\begin{document}`. And it causes problem for the template
I am using.

Following is an minimal example of the org mode latex export. Is there
any way to excude the empty `\title{}` command?


[example deleted]


Any suggestion will be appreciated. And of course, Happy New Year!


Use a filter to comment it out:



#+OPTIONS: title:nil toc:nil
#+BIND: org-export-filter-final-output-functions (comment-out-title-line)

#+BEGIN_SRC emacs-lisp :exports results :results none
  (defun comment-out-title-line (doc  bk info)
(replace-regexp-in-string "title" "%% \\title" doc nil t ))
  (setq-local org-export-allow-bind-keywords t)
#+END_SRC



* section 1

...

HTH,

Chuck

Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, Martin Gürtler wrote:


Am Donnerstag, 29. Dezember 2016, 09:07:40 CET schrieb Charles C. Berry:

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:

Dear list,
I am exporting the following org mode file:


[deleted]



But how would I control the (not-)inclusion of the src code during
export in that case?


As I wrote:

#+begin_quote

You might also note the advice in the docstring:

"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

#+end_quote


If that was not clear, review

(info "(org) Exporting code blocks")

particularly the paragraph that starts "Turning off evaluation..."


Chuck

Re: [O] src blocks: code is /always/ exported

[Charles C. Berry]

On Thu, 29 Dec 2016, "Martin Gürtler" wrote:


Dear list,
I am exporting the following org mode file:
8<
* doc
#+BEGIN_SRC shell :exports none
ls |wc
#+END_SRC
#+RESULTS:
: 20  20 199
8<
I'd expect org mode to honour the :exports none header argument and
create a document that contains only the result.
However, the exported document contains  both, code and results.
This seems to be independent of the type of SRC and independent of the
export type (I tried dot and shell for odt, latex and beamer exports).
How can I get rid of the src code in the exported document?


What does C-h v org-export-use-babel RET say?

If the result is not `t' that is the problem, and somewhere in your setup 
you have set that variable (or its predecessor org-export-babel-evaluate) 
to nil or something other than `t'.


If this is the problem, set org-export-use-babel to `t'. You might 
also note the advice in the docstring:


"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

HTH,

Chuck

Re: [O] Error when using :session :colnames yes :results graphics on an R code block

[Charles C. Berry]

On Wed, 28 Dec 2016, Kodi Arfer wrote:


If I run Emacs with


[snip]



   cons: Wrong type argument: listp, "x
   1"

If I remove ":colnames yes", the error doesn't happen and the
file is produced as expected.



Fixed on master.

Chuck

Re: [O] Bug: EXPORT_FILE_NAME error [9.0.3 (9.0.3-elpaplus @ /home/andrea/.emacs.d/elpa/org-plus-contrib-20161224/)]

[Charles C. Berry]

On Wed, 28 Dec 2016, Andrea wrote:



Hello,

thanks for org mode, it is great!
I am having a problem with the latest version of org: I really would
like to be able to export buffers in a different directory, and so far I
used the :EXPORT_FILE_NAME: property for this use case.

However, after upgrading to the latest release it seems that something
does not work anymore: the pdf file is generated but the output
directory is ignored!

You could reproduce this by:


I cannot reproduce this. I get files /tmp/bla.pdf /tmp/bla.tex and my
reader opens the former file.

FWIW, there have been some discussions in recent months about pdf export.

On my macbook, C-h v org-latex-pdf-process RET gives:

org-latex-pdf-process is a variable defined in ‘ox-latex.el’.
Its value is ("latexmk -g -pdf -pdflatex=\"%latex\" -outdir=%o %f")
Original value was
("%latex -interaction nonstopmode -output-directory %o %f" "%latex 
-interaction nonstopmode -output-directory %o %f" "%latex -interaction 
nonstopmode -output-directory %o %f")


[...]

which works for macOS Sierra. See the full docstring for details.

IIRC, the original value does not work for me to export to another
directory.

HTH,

Chuck

Re: [O] bug in orgmode parsing of results

[Charles C. Berry]

On Tue, 27 Dec 2016, daimrod wrote:


Hi,

I've found what I think is a bug in orgmode parsing.
When the following file is parsed :

* Test
#+BEGIN_SRC emacs-lisp :exports results :results raw drawer
(format "- Test2")
#+END_SRC

#+RESULTS:
:RESULTS:
- Test2
:END:



[snip]



That is, it generates a DRAWER, which seems correct.

However, when the following file is parsed :

* Test
#+BEGIN_SRC emacs-lisp :exports results :results raw drawer
(format "* Test2")
#+END_SRC

#+RESULTS:
:RESULTS:
* Test2
:END:



[deleted]


That is, it generates a PARAGRAPH which seems incorrect.

WDYT?



What I think is that you should run org-lint on your document. It will say 
something like this (but with different line numbers):


  Line Trust Warning
 2 low   Forbidden combination in header ":results": raw, drawer
12 low   Forbidden combination in header ":results": raw, drawer
17 low   Possible incomplete drawer ":RESULTS:"

The last one should catch your eye.

If you want to generate results that have lines that start with `*' you 
need to protect them. A good way to do this is to wrap them in a src block 
or export block like this:


#+BEGIN_SRC emacs-lisp :exports results :wrap export latex
(format "* Test2")
#+END_SRC

HTH,

Chuck

Re: [O] Referring to an Org Babel variable in the invocation arguments to another Org Babel code block

[Charles C. Berry]

On Tue, 27 Dec 2016, Zack Piper wrote:


Hi all,

Hopefully the below can explain better:


[deleted]

This is a workable idiom. C-c C-c on the second block produces the
output shown.


#+NAME: block-1
#+BEGIN_SRC shell :var x="X" 
echo ">>>" $x "<<<"

#+END_SRC


#+BEGIN_SRC shell :var y=block-1("input to this block")
echo $y
#+END_SRC

#+RESULTS:
: >>> input to this block <<<

HTH,

Chuck

Re: [O] Literate config and :tangle clauses

[Charles C. Berry]

On Sun, 25 Dec 2016, joa...@verona.se wrote:


aaermo...@gmail.com writes:


Hi all!

Recently I've experienced a kind of a problem - my literate Emacs config
stopped tangling correctly, only a subset of code blocks were found in
resulting .el file.
I've looked at it a bit closer and it seems now (not earlier than 9.0.2)
the :tangle clause became required. I've searched Org repo but failed to
find a respective commit or any reference to the relevant info.




I don't think the problem lies with any revision to org.

First, what `C-h v org-babel-default-header-args RET' shows below is
unchanged for at least a year:

--8<---cut here---start->8---

org-babel-default-header-args is a variable defined in ‘ob-core.el’.
Its value is ((:session . "none")
 (:results . "replace")
 (:exports . "code")
 (:cache . "no")
 (:noweb . "no")
 (:hlines . "no")
 (:tangle . "no"))

...
--8<---cut here---end--->8---

Note that `(:tangle . "no")' sets the default behavior.

Second, I have files that depend on the above. i.e. I set the header
on a few blocks to `:tangle yes' and leave the rest alone, relying on
the above default to keep them from being tangled.



I also experienced the same behaviour. :tangle became required, which it
wasn't previously.

My solution was just to add the ":tangle yes" tag everywhere.




Can anyone point me to the right direction?



Use

#+PROPERTY: header-args :tangle yes

(and type `C-c C-c' to reset the buffer the first time you type it)

and review

(info "(org) Using header arguments")

for tips on how to control the application of header args.

HTH,

Chuck

Re: [O] Defining macros globally

[Charles C. Berry]

On Mon, 19 Dec 2016, Nicolas Goaziou wrote:


Hello,

Arun Isaac  writes:


Is it possible to define macros globally, probably in the ~/.emacs init
file with some elisp, instead of on a per-file basis using the #+MACRO
keyword?


This is not possible ATM.


Perhaps the OP could do this?

#+BEGIN_SRC emacs-lisp
  (setq my-new-macros
'(("def" . "d $1 e $2 f")
  ("ghi" . "GHI only")))

  (defun add-my-macros ( x)
(nconc org-macro-templates my-new-macros))

  (advice-add 'org-macro-initialize-templates :filter-return
  #'add-my-macros)


#+END_SRC

Admittedly, this invites problems if `my-new-macros' is malformed. But 
there could be ways to impose a discipline that would assure that it is 
not.



HTH,

Chuck

Re: [O] Fwd: including external file in src block execution; ATTR_HTML on src blocks

[Charles C. Berry]

On Tue, 13 Dec 2016, Matt Price wrote:


(sent to Charles direcly by mistake. Charles, this resend gave me the
chance to modify my response)
On Mon, Dec 12, 2016 at 10:52 PM, Charles C. Berry <ccbe...@ucsd.edu> wrote:


[snipping throughout]



My questions are:

1. can I pass this html attribute to the  block somehow?




: (plist-get (cadr src-block) :attr_html)

in `org-html-src-block' ?






:-)  I think what I meant was, looks like (org-export-read-attribute
:attr_html src-block) RETURNS a plist.  But that doesn't seem to be quite
true, if I'm understanding properly what a plist is.



It looks to me like `org-export-read-attribute' reliably returns a
plist when used with three args.


Instead it returns a list of this form:
(:code_attribs data-external-libs="https://cdnjs.cloudflare.com/ajax/
libs/jquery/3.1.1/jquery.js" data-other="other" :class some class list)


That isn't a plist. I don't believe that `org-export-read-attribute'
gave you that. Maybe you dropped some quotes? Do you have an ECM that
shows that behavior?



Access to the :properties only seems reliable through
(org-export-read-attribute :attr_html src_plock :propname), which returns
what should be an odd list of symbols (?) as a string. Again, it seems
somewhat mysterious to me.


You lost me here. I don't know what `src_plock' contains, so I can't
really say whether what that returns makes sense or not.

Chuck

Re: [O] including external file in src block execution; ATTR_HTML on src blocks

[Charles C. Berry]

On Mon, 12 Dec 2016, Matt Price wrote:


On Mon, Dec 12, 2016 at 12:16 PM, Charles C. Berry <ccbe...@ucsd.edu> wrote:


On Mon, 12 Dec 2016, Matt Price wrote:


[snip]



My questions are:
1. can I pass this html attribute to the  block somehow?



Yes.

ATTR_HTML doesn't seem to work.  Is this a bug? If so, should I try to fix

it?



No and no.

Did you try

: (plist-get (cadr src-block) :attr_html)

in `org-html-src-block' ?



ah, ok.  Now I will reveal some of the depths of my ignorance.  Looks like
:attr_html is a plist (right?).


No, it is a property name. (cadr src-block) is the plist.

See (info "(elisp) Property Lists")



(a) what is the appropriate way to identify an attribute here.  should I
write, e.g.:

#+ATTR_HTML: :data-external-libs "http://underscorejs.org/underscore-min.js;
:class "list of classes"


Any could be made to work, but I'd use (a). Then

: (org-babel-parse-header-arguments
:  (car (plist-get (cadr src-block) :attr_html)))

will give you

: ((:data-external-libs . "http://underscorejs.org/underscore-min.js;) 
:   (:class . "list of classes"))



or:
#+ATTR_HTML: data-external-libs "http://underscorejs.org/underscore-min.js;
class "list of classes"
or
#+ATTR_HTML: "data-external-libs" "http://underscorejs.org/underscore-min.js;
"class" "list of classes"

And then, if I want to transform this into:

data-external-libs="http://underscorejs.org/underscore-min.js; class="list
of classes"

can I just do something like:
(let ((attributes (org-export-get-attribute :attr_html src-block))
 (cl-loop for (key value) in attributes
   (collect (concat key "=" "\"" value "\" " 

or do I need to transform the key into a string first?


Well, I'd just try it and see.


I'm sorry to be writing such basic lisp questions; obviously I need to read
a really good lisp introduction, but I haven't found one yet.



This is what I use:

* Elisp: (elisp).   The Emacs Lisp Reference Manual.
* Emacs Lisp Intro: (eintr).A simple introduction to Emacs Lisp programming.

and ample Googling, usually leading to StackOverflow, to get hints on 
stuff I am fuzzy on. And I read docstrings over and over and ...


Best,

Chuck

Re: [O] exporting # to latex?

[Charles C. Berry]

On Mon, 12 Dec 2016, Sharon Kimble wrote:



I'm trying to write an org-mode file that is being exported to latex,
and then built into a pdf file, of the MPD online manual.

I'm now trying to show the 'mpf.conf' file which is mostly with
commented out lines starting with a hash (#). But that breaks the
org-mode export, so how can I have it displayed and exported to latex
please?


[deleted]



So what I'm trying to get is a latex file which includes the .conf file
and all of its # in the right place and show as # on their own. But how
can I do it please?




One of these?


--8<---cut here---start->8---

#+BEGIN_EXAMPLE
  ## abc
  ## def
#+END_EXAMPLE

#+BEGIN_EXPORT latex
## abc
## def
#+END_EXPORT

--8<---cut here---end--->8---

Upon export to latex they yield:

--8<---cut here---start->8---

\begin{verbatim}
## abc
## def
\end{verbatim}

## abc
## def

--8<---cut here---end--->8---


HTH,

Chuck

Re: [O] including external file in src block execution; ATTR_HTML on src blocks

[Charles C. Berry]

On Mon, 12 Dec 2016, Matt Price wrote:


[snip]



My questions are:
1. can I pass this html attribute to the  block somehow?


Yes.


ATTR_HTML doesn't seem to work.  Is this a bug? If so, should I try to fix
it?


No and no.

Did you try

: (plist-get (cadr src-block) :attr_html)

in `org-html-src-block' ?



If not, is there a simple way to use header arguments to pass
information down?


The answer is still no. ;-)

There are complicated ways. See

https://github.com/chasberry/orgmode-accessories/blob/ravel-lang/ox-ravel.org

for one such. But for what you are doing ATTR_HTML is easiest.



I am already rewriting the exporter's src-block export
function, so I can try to accomplish what I need to in that context.


BTW, the cleanest way to do this is by writing a derived exporter:

:  (org-export-define-derived-backend 'reveal 'revealplus ...

In your case you only provide the src-block entry for the 
:translate-alist, :options-alist entries for any you redefine or 
introduce, and optionally a :menu-entry.


Also, you'll probably want to add a hook to 
`org-export-before-parsing-hook' (see below).



If you do this, then `#+ATTR_REVEALPLUS:' seems suitable.


2. I'd like to be able to test my code directly in org (since I'm a lousy
coder and a clumsy typist). Can I tell org to load other files before
executing a src block?


Yes. Depending on what you want one of these:

* Add this to `org-export-before-parsing-hook', perhaps in setting up a
  derived exporter.

* Or perhaps by using a local variable `eval' see

: (info "(emacs) Specifying File Variables")

* Or by executing a src-block that loads those files.

HTH,

Chuck

Re: [O] setting a custom flag for src blocks

[Charles C. Berry]

On Sat, 10 Dec 2016, Matt Price wrote:


On Sat, Dec 10, 2016 at 12:19 AM, Matt Price  wrote:




On Fri, Dec 9, 2016 at 12:19 PM, Eric S Fraga  wrote:


On Friday,  9 Dec 2016 at 16:42, Matt Price wrote:

I think I am getting closer, actually (details soon, when I have a
fully working  solution)).


[deleted]


I *think* that I'm looking for an export filter. From what I can see, it
has access to all the information that  the  initial export function does.


It does not. :-(

When `org-babel-exp-process-buffer' runs (under `org-export-as'), all the 
header info is dropped.


There might be a way to backtrack from the copy buffer to the original and 
remap the src blocks, but it seems like the wrong way to go. It would be a 
lot of work, I think.


More below ...


So now I'm wondering what the easiest way is to set a simple flag for a src
block, and make that flag available to the export filter.  For instance, if
I want a particular block to be renderd in klipse on export, could I
specify somehow:

#+HEADER: klipsify t
#+BEGIN_SRC: javascript
console.log("success");
#+END_SRC

or alternatively in a subtree:

* Lots of Examples
:PROPERTIES:
#+PROPERTY: header-args:javascript  :klipsify t
:END:

#+BEGIN_SRC: javascript
console.log("success");
#+END_SRC



I think the better way to go is to do all the formatting in babel. That 
is, make a babel src block handle the formatting for you and subvert the 
normal mechanisms.


To do this, write a src block that is given the name of another src
block, that grabs the body (and if you really need it the header
info), formats it as you need, and inserts it in final form wrapped
in an `export html' block.

So if you had a src block named `codeA' and one named `klipsify' which
has the code needed to render the output you desire depending on the
value of

: :var src-blk-name="my-codes"

then a

#+CALL:klipsify("codeA")

line will put the output in the exported document.

Something like this:

#+NAME: codeA
#+BEGIN_SRC: javascript :eval never-export :exports none
console.log("success");
#+END_SRC

#+NAME: klipsify
#+header: :var src-blk-name="my-code" :exports none
#+header: :results raw :wrap export html
#+BEGIN_SRC emacs-lisp
  (save-excursion
(org-babel-goto-named-src-block
 src-block-name)
(let ((body-code
   (org-babel-expand-src-block)))
  (klipsify-my-code body-code)))
#+END_SRC

Obviously, you need to defun `klipsify-my-code' or whatever.


All the code blocks would need to be named and have these headers:

:  :eval never-export :exports none

or maybe

:  :exports results

You would use the latter, if you want the results of evaluating the code 
to appear in the exported document. Put the #+CALL line just before the 
code block and then the code will appear first and the results next.


HTH,

Chuck

Re: [O] Include sections of org document in tangled files

[Charles C. Berry]

On Wed, 7 Dec 2016, David Dynerman wrote:


Dear Chuck,

Your suggestion worked fantastically - I got it working and am very excited.

Now, the next step is figuring out how to handle typesetting math in single way 
between org and python docstrings. Math in Python docstrings is usually done by 
RestructuredText markdown, e.g.:

:math:`f(x) = x^2`

while the org code should just be, for example,

\[
f(x) = x^2
\]



So the goal would be have noweb not only include a documentation block 
in the python code, but also call a translation function that identifies 
LaTeX fragments in the org source and converts them to ReST markdown.




This is do-able.

First, look at

(info "(org) Noweb reference syntax")

and note that the noweb reference

<>

will call `my-src-block' with the `x' var set to "value_for_x" and insert 
the output into the current src block.


Second, https://github.com/masayuko/ox-rst has a reStructuredText backend. 
So, you can install ox-rst.el, then write an emacs-lisp src block:



#+NAME: export-body
#+BEGIN_SRC emacs-lisp :var src-block-name="my-code" :results raw
  (save-excursion
(org-babel-goto-named-src-block
 src-block-name)
(org-export-string-as
 (org-babel-expand-src-block)
 'rst t))
#+END_SRC

and then a src-block like this

#+BEGIN_SRC emacs-lisp :noweb yes :tangle yes
<>
#+END_SRC

will insert the rst formatted text from the `my-code' src block when the 
latter src block is tangled.


p.s. Untested with 'rst.

HTH,

Chuck

Re: [O] Multiple underscores crash org latex export; other exporters survive

[Charles C. Berry]

On Sun, 4 Dec 2016, Nicolas Goaziou wrote:


Hello,

Scott Randby  writes:


There is an interesting issue here. I sometimes want to use ~ in a code
snippet, so I can't use ~code snippet~. Yet,


Indeed, this was discussed in this ML. We need some escape character in
Org. A general escape character is a bit ambitious, and not necessarily
useful, but we could introduce one specifically for verbatim and code
markers, much like in macros and verbatim blocks, e.g.

 ~some\~code\=with special\\ characters~

There is a design decision involved: what character can be escaped? It
could be anything, or limit to "~" for code and "=" for verbatim
markers. For example macros limit escape-able characters to "," and "\".
This makes the contents easier to read, but the rule is inconsistent.

Thoughts?


I do not think this is needed.

The existing markup is simple and useful and does not complicate the 
appearance of the org buffer nor editting it.


More complicated inline markups can be rendered with export snippets, 
macros, and/or inline src blocks. For example:


--
#+MACRO: code src_code[:eval no :exports code]{$1}

{{{code(y~x)}}}
--

will handle many situations.

If one needs to render something with embedded commas and/or backslashes 
like


: y~x(z,w)
: cat("here is a newline\n")

then

: src_code{ y~x(z,w) }
: src_code{ cat("here is a newline\n") }

works if `org-babel-default-header-args:code' is

: '((:eval . "no")(:exports . "code"))

HTH,

Chuck

Re: [O] Multiple underscores crash org latex export; other exporters survive

[Charles C. Berry]

On Sat, 3 Dec 2016, Scott Randby wrote:


On 12/03/2016 02:40 PM, Scott Otterson wrote:

When an org file contains a string with more than one underscore, the
orgmode export result will crash latex (example attached).   On the
other hand, the org html export does finish successfully, and while
result is odd, it's odd in a way that makes the problem visible and easy
to identify.


I exported your file using LaTeX export without trouble. The result does
look odd, but that is because the string you gave is missing the braces
needed to make it export properly. The output messages warn that the
string contains a double subscript, so the problem is with the string
and not Org's LaTeX export.

Your string: a_variable_deleteThisAndItWorks

Properly formed string: a_{variable_{deleteThisAndItWorks}}


I don't think the OP wanted double subscripts.  If the OP really wanted 
"heavily underscored code snippets", something like:


Code snippet:  ~a_variable_deleteThisAndItWorks~

seems like the way to go.

See (info "(org) Emphasis and monospace")

That way the latex is

: \texttt{a\_variable\_deleteThisAndItWorks}

and that idiom would properly render html as

: a_variable_deleteThisAndItWorks

rather than

: avariabledeleteThisAndItWorks

as in OPs case. The latter is valid html, but doesn't seem quite like the 
right thing to do for code snippets.


HTH,

Chuck



Scott Randby



Many people have orgfiles with heavily underscored code snippets buried
deep inside.  To them, the latex crashes are probably as mysterious as
they were to me.  So I'd like to suggest that the org latex exporter
adopt something like the org html exporter behavior.

Re: [O] Include sections of org document in tangled files

[Charles C. Berry]

On Fri, 2 Dec 2016, David Dynerman wrote:


Dear list,

Is it possible to include sections of an org document while tangling.

I have in mind something like the following:

* Some section


[David's version deleted]

#+NAME: doc
#+BEGIN_SRC org :exports results :results replace
  This is an introduction. We're going to write some code that
  implements (a finite version of) the formula

  \[
  f(x) = 1 + x + \frac{x^2}{2} + \frac{x^3}{6} + \ldots +
  \frac{x^n}{n!} + \ldots
  \]

  Here's some background about the exponential function.

#+END_SRC

#+header: :noweb (unless org-export-current-backend "yes")
#+BEGIN_SRC python :tangle myfunction.py
  from math import factorial

  def f(x,n):
  """
  <>
  """

  y = 0
  for i in range(n+1):
  y = y + x**i/factorial(i)

  return y
#+END_SRC



The idea would be that when I export this to HTML, I get a nice literate
programming math jax'd section introduction that explains what the
function is doing.


Right. The above does that.

You need `org' as a babel language. Eval'ing `(require 'ob-org)' is good 
enough for just trying to export this, but customizing 
`org-babel-load-languages' to include `org' is better if you use this 
regularly.




Then, when I tangle to generate the python file, the
org section introduction would be included as the python docstring of
the function.



And it does that.

---

There is an issue you might want to address if you use this approach. 
First, the first triple quotes must not be on the same line as the 
included src block reference. That is because """>""" will 
prepend the quotes to every line in `src-blk-ref'.


If you do not want the newlines between the quotes and the docstring, I 
think there is a post-tangle hook you can use to clean the tangled version 
by removing those newlines.


Also, you can use an export filter to remove the quotes and the noweb 
reference for a cleaner looking exported doc.


Note that you need to use a unique name for each src-block.

HTH,

Chuck

Re: [O] passing entry property to a source code block?

[Charles C. Berry]

On Fri, 2 Dec 2016, Piter wrote:


Hi everybody.

I would like to get a property of org-mode entry and pass it as a string 
variable to a python source code.


Is it possible to do? I have been looking into attach screensshot code but 
since my elisp experience is very limited I can not figure  it out.


Any tips about it? may be I can use inline ellisp function in python source 
header?




That's about right:


# Refresh the `property' line with C-c C-c the first time you use it.

#+PROPERTY: my-string "Hello everyone!"

#+header: :var ms=(org-entry-get (point) "my-string" t)
#+BEGIN_SRC python :results output
print ms
#+END_SRC

#+RESULTS:
: "Hello everyone!"

HTH,

Chuck

p.s. do not forget to

Re: [O] fuzzy matching of parameters

[Charles C. Berry]

On Thu, 1 Dec 2016, Matt Price wrote:


I have just done something I'm very excited about.  Given a directory name
(the variable ~assignment~ in this case) and a list of student info, search
through the directory for files whose names contain the student names, and
attach those to newly created subtrees.

Before now, manually attaching those files has been a real pain, so it's
great to have this automated! However, sometimes the name I have on file
doesn't quite match the submitted name.


A Google Scholar search on 'personal name matching' will point you to the 
literature on this subject.


You might get lucky and find something in a scripting language that Babel 
supports that you can piggyback onto.


HTH,

Chuck

Re: [O] v9.0 ignores org-export-babel-evaluate

[Charles C. Berry]

On Thu, 1 Dec 2016, Alexander Vorobiev wrote:


I noticed this happening with R source code blocks after the upgrade.


This should be fixed in master.

But use `org-export-use-babel' instead as `org-export-babel-evaluate' is 
obsolete.


Chuck

Re: [O] List restarts numbering at 1 after table

[Charles C. Berry]

On Fri, 25 Nov 2016, Roger Mason wrote:


Hello,

I have a table in a list, like this:

2. Write stuff in the empty table:
# See http://orgmode.org/manual/LaTeX-specific-attributes.html to get
# predetermined width on export.
#+ATTR_LATEX: :align |p{2cm}|p{2cm}|
|--+|
| This | That   |
|--+|
|  ||
|--+|
|  ||
|--+|
|  ||
|--+|
|  ||
|--+|
|  ||
|--+|
3. Write the answer to another question here


On export, the list numbering after the table reverts to 1.  Is there a
way to avoid this?


Indentation matters. I put 4 spaces before every line under `2.'

2. Write stuff in the empty table:
   # See http://orgmode.org/manual/LaTeX-specific-attributes.html to get
   # predetermined width on export.
   #+ATTR_LATEX: :align |p{2cm}|p{2cm}|
   |--+--|
   | This | That |
   |--+--|
   |  |  |
   |--+--|
   |  |  |
   |--+--|
   |  |  |
   |--+--|
   |  |  |
   |--+--|
   |  |  |
   |--+--|
3. Write the answer to another question here


And exporting to ascii the numbering starts at 1. and continues at 2. 
after the table.


Exporting in latex, both items and the table are all enclosed in one 
enumerate environment.


HTH,

Chuck

Re: [O] Tangling include files

[Charles C. Berry]

On Thu, 24 Nov 2016, Robert Klein wrote:


On Wed, 23 Nov 2016 21:22:08 -0800
"Charles C. Berry" <ccbe...@ucsd.edu> wrote:


On Thu, 24 Nov 2016, Harry Butterworth wrote:


I tried org-org-export-to-org which puts everything into a single
document but it strips the :tangle parameters out so a subsequent
tangle doesn't generate any source code.



You might try this. Put this at the *top* of your file:

--8<---cut here---start->8---

#+PROPERTY: header-args :eval never-export



[deleted]



A line

#+Property: tangle yes


That idiom is *obsolete* and *deprecated* for a long time and 
*incompatible* as of org 9.0.




in your org document is sufficient to get it tangled (in org 8.3.6).



The point of that line was to prevent unwanted evaluation. Presumably, OP 
had :tangle headers in the desired locations in the original org file.


Chuck

Re: [O] Tangling include files

[Charles C. Berry]

On Thu, 24 Nov 2016, Harry Butterworth wrote:


I tried org-org-export-to-org which puts everything into a single document
but it strips the :tangle parameters out so a subsequent tangle doesn't
generate any source code.



You might try this. Put this at the *top* of your file:

--8<---cut here---start->8---

#+PROPERTY: header-args :eval never-export

#+NAME: tangle file
#+BEGIN_SRC emacs-lisp :eval yes :exports results
(org-babel-tangle)
#+END_SRC

--8<---cut here---start->8---

Type C-c C-c on the property line to refresh it.

Now export. Type 'y' in reply to the query to eval the `tangle file' src 
block and again to the `discard edits' query.


Even exporting to a buffer should be fine. You do not really want the 
exported document, you just want to force the inclusions to take place and 
then run that src block.


This should work, because `org-export-as' will expand all the include's 
before running babel. If the above block runs before any others, then the 
:tangle headers will still be in place.


In fact you could create a separate file, place all the above in it and 
add one line at the bottom to include the top level org file you want to 
tangle from. Then export that.


HTH,

Chuck

Re: [O] Release 9.0 test failed: test-ob/indented-cached-org-bracket-link

[Charles C. Berry]

On Sat, 19 Nov 2016, John Kitchin wrote:


I have also seen this error on my mac. I guess it is from the trailing
slash as you suggest:


echo $TMPDIR

/var/folders/5q/lllv2yf95hg_n6h6kjttbmdwgn/T/




So,

: testdir=${TMPDIR%/}/tmp-orgtest

in mk/default.mk would handle this on my mac, but I do not know if 
this is fully portable.


OTOH, (expand-file-name "test.txt") resolves double-slashes and seems like 
the right idiom in any case.


Chuck

Re: [O] Release 9.0 test failed: test-ob/indented-cached-org-bracket-link

[Charles C. Berry]

On Fri, 18 Nov 2016, Nicolas Goaziou wrote:


Hello,

"Charles C. Berry" <ccbe...@ucsd.edu> writes:


On Fri, 18 Nov 2016, Nicolas Goaziou wrote:


Hello,

David Talmage <david.talm...@shoutpoint.com> writes:


I built org 9.0 on my Mac today.  'make test' reported one failed test.  I
don't know if it is important or not.  Please advise me.

'make test' said:

1 unexpected results:
   FAILED  test-ob/indented-cached-org-bracket-link




[snip]




Another option is to modify the test so it prints some useful debugging
information before failing (e.g., contents of default-directory and
return value of (org-babel-execute-src-block)).



Doing this with `make test', I see that default-directory is let bound to

"/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T//tmp-orgtest/"

and (concat default-directory "test.txt") will retain the double slash.

The return value from the second (org-babel-execute-src-block) has only a 
single slash between 'T' and 'tmp'. Hence the failure.


When run interactively, there is no double slash and the test succeeds.

Using

: (expand-file-name "test.txt")

in place of

: (concat default-directory "test.txt)

cleans out the double slash and succeeds either with `make test' or 
interactively.


So, maybe make that change?

Chuck

Re: [O] Inheritance of tangle file for org babel blocks is broken in org 9

[Charles C. Berry]

On Fri, 18 Nov 2016, William Henney wrote:


Hi,

Since upgrading to version 9.0, tangling of babel source blocks no longer
works properly for me.


It works for me with Org mode version 9.0.1 (release_9.0.1-31-g0a24f5).

Running your ECM, the `tail' of C-c C-v C-i:

:tangle test-B.el

Maybe try restarting emacs to be sure 9.0.1 loads cleanly?

HTH,

Chuck

Re: [O] Release 9.0 test failed: test-ob/indented-cached-org-bracket-link

[Charles C. Berry]

On Fri, 18 Nov 2016, Nicolas Goaziou wrote:


Hello,

David Talmage  writes:


I built org 9.0 on my Mac today.  'make test' reported one failed test.  I
don't know if it is important or not.  Please advise me.

'make test' said:

1 unexpected results:
   FAILED  test-ob/indented-cached-org-bracket-link


Our build bot doesn't report this error and I cannot reproduce it
either. None of us is using a Mac, though.



I have a Mac and I *can* reproduce this running `make test'. But following 
the README for interactive testing, the test succeeds:


Selector: test-ob/indented-cached-org-bracket-link
Passed:  1
Failed:  0
Skipped: 0
Total:   1/1

I do not know what further steps to take to debug this.

??

Chuck

Re: [O] [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0

[Charles C. Berry]

On Sun, 13 Nov 2016, Nicolas Goaziou wrote:


Hello,

"Charles C. Berry" <ccbe...@ucsd.edu> writes:


[snip]


Thinking about it, wouldn't `org-export-use-babel' or even
`org-export-with-babel' (as `org-export-with-author'...) be simpler and
yet, as clear?



You are right. `org-export-use-babel' it is.

Thanks for the suggestions. I pushed them to master just now.


Chuck

[O] [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0

[Charles C. Berry]

On Sat, 12 Nov 2016, Nicolas Goaziou wrote:

[discussion of problems interpreting the variable 
`org-export-babel-evaluate' deleted]




It is tempting to `make-obsolete-variable' this variable and change
its name to something that more completely describes what does not
happen when set to nil.


It can be done for Org 9.1.



OK. I changed the name to `org-export-process-with-babel', which I hope 
suggests more profound actions than `org-export-babel-evaluate'.


I think the attached patch does this properly, but this is my first use of 
`define-obsolete-function-alias', so it might be best to check what I have 
done.


ChuckFrom 3885129980a02eb0d4694e9e15888dea6ee95c60 Mon Sep 17 00:00:00 2001
From: Charles Berry 
Date: Sat, 12 Nov 2016 18:54:20 -0800
Subject: [PATCH] make-obsolete-variable `org-export-babel-evaluate'

* doc/org.texi: Better explain what the variable
  `org-export-process-with-babel' does.

* lisp/ob-exp.el: Small docstring change.

* lisp/org-compat.el: Define `org-export-babel-evaluate' as the
  obsolete alias for `org-export-process-with-babel'.

* lisp/ox-icalendar.el, lisp/ox.el, testing/lisp/test-ob-exp.el,
  testing/lisp/test-ob-lob.el, testing/lisp/test-ox.el: Change the
  obsolete variable name in many places.

Users were often confused that setting this variable to nil will cause
header arguments to be ignored in addition to preventing code from
being evaluated.  It is hoped that the documentation changes and the
name `org-export-process-with-babel' will better convey that everything
babel does can be switched off with this variable.
---
 doc/org.texi| 24 +---
 lisp/ob-exp.el  | 12 ++--
 lisp/org-compat.el  |  2 ++
 lisp/ox-icalendar.el|  2 +-
 lisp/ox.el  |  2 +-
 testing/lisp/test-ob-exp.el | 36 ++--
 testing/lisp/test-ob-lob.el |  2 +-
 testing/lisp/test-ox.el |  2 +-
 8 files changed, 43 insertions(+), 39 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index ede2352..81364d2 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14938,17 +14938,19 @@ Both the code block and its results will be exported.
 Neither the code block nor its results will be exported.
 @end table
 
-It is possible to inhibit the evaluation of code blocks during export.
-Setting the @code{org-export-babel-evaluate} variable to @code{nil} will
-ensure that no code blocks are evaluated as part of the export process.  This
-can be useful in situations where potentially untrusted Org mode files are
-exported in an automated fashion, for example when Org mode is used as the
-markup language for a wiki.  It is also possible to set this variable to
-@code{inline-only}.  In that case, only inline code blocks will be
-evaluated, in order to insert their results.  Non-inline code blocks are
-assumed to have their results already inserted in the buffer by manual
-evaluation.  This setting is useful to avoid expensive recalculations during
-export, not to provide security.
+It is possible to inhibit the evaluation of code blocks and ignore header
+arguments during export.  Setting the @code{org-export-process-with-babel}
+variable to @code{nil} will ensure that no code blocks are evaluated as part
+of the export process.  This can be useful in situations where potentially
+untrusted Org mode files are exported in an automated fashion, for example
+when Org mode is used as the markup language for a wiki.  No header arguments
+will be processed.  For this reason it is often better to set `:eval
+never-export' to prevent code evaluation but still allow headers to be
+honored.  It is also possible to set this variable to @code{inline-only}.  In
+that case, only inline code blocks will be evaluated, in order to insert
+their results.  Non-inline code blocks are assumed to have their results
+already inserted in the buffer by manual evaluation.  This setting is useful
+to avoid expensive recalculations during export, not to provide security.
 
 Code blocks in commented subtrees (@pxref{Comment lines}) are never evaluated
 on export.  However, code blocks in subtrees excluded from export
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 6aebcd5..1d77e6a 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -38,10 +38,10 @@
 
 (defvar org-src-preserve-indentation)
 
-(defcustom org-export-babel-evaluate t
-  "Switch controlling code evaluation during export.
+(defcustom org-export-process-with-babel t
+  "Switch controlling code evaluation and header processing during export.
 When set to nil no code will be evaluated as part of the export
-process and no header argumentss will be obeyed.  When set to
+process and no header arguments will be obeyed.  When set to
 `inline-only', only inline code blocks will be executed.  Users
 who wish to avoid evaluating code on export should use the header
 argument `:eval never-export'."
@@ -50,7 +50,7 @@ argument `:eval never-export'."
   

Re: [O] HTML export with ":export" parameter with Orgmode 9.0

[Charles C. Berry]

On Fri, 11 Nov 2016, Frederick Giasson wrote:


Hi Chuck,


even with a minimal init file.

If you ever set the value of `org-export-babel-evaluate' to nil this might 
produce the behavior you describe. 


Maybe, but as stated in the manual: "Setting the org-export-babel-evaluate 
variable to nil will ensure that no code blocks are evaluated as part of the 
export process."


Argh! That paragraph needs to be revised.



From here: http://orgmode.org/manual/Exporting-code-blocks.html

The thing is that I indeed want to make sure that the code blocks are 
evaluated, but to me evaluation of code block is different than what to 
export from the Org file. It is often the case that I don't want export to 
evaluate anything, but just to export what is in the Org file's markup (while 
following what the header parameters say).




Setting `org-export-babel-evaluate' to nil will ensure that NONE of your 
header arguments are followed.


Like the docstring says

 "Users who wish to avoid evaluating code on export should use the header 
argument ‘:eval never-export’."


It is tempting to `make-obsolete-variable' this variable and change its 
name to something that more completely describes what does not happen when 
set to nil.


Chuck

Re: [O] HTML export with ":export" parameter with Orgmode 9.0

[Charles C. Berry]

On Fri, 11 Nov 2016, Frederick Giasson wrote:


Hi Nicolas,


It seems other users experienced it, yet it is unexpected and I cannot
reproduce it even with a minimal init file.


If you ever set the value of `org-export-babel-evaluate' to nil this might 
produce the behavior you describe.


In that case, see the docstring for advice.

HTH,

Chuck

Re: [O] Tangling flow control

[Charles C. Berry]

On Wed, 9 Nov 2016, Philip Hudson wrote:


On 9 November 2016 at 21:41, Charles C. Berry <ccbe...@ucsd.edu> wrote:

The org src block is just a container. Its body is a src block template that
gets copied into the variable `tmpl', which if filled and placed in file can
be tangled.


That makes sense, but it seems to conflict with what you illustrate:

#+RESULTS:
#+BEGIN_src org
,#+BEGIN_SRC shell :tangle abc.sh
ls -lt my-dir
,#+END_SRC
#+END_src

I'd expect/want:

#+RESULTS:
#+BEGIN_SRC shell :tangle abc.sh
ls -lt my-dir
#+END_SRC

Wouldn't I?



For sure. But when developing stuff like this `:wrap src org' will capture 
it and protect against messing up the rest of your *.org file.


Once you get it filling the template as you want it, remove the :wrap 
header and add a `:file script.org' header


But it is indeed optional.

Chuck

Re: [O] Tangling flow control

[Charles C. Berry]

On Wed, 9 Nov 2016, Philip Hudson wrote:


On 9 November 2016 at 17:54, Charles C. Berry <ccbe...@ucsd.edu> wrote:

On Tue, 8 Nov 2016, Philip Hudson wrote:

[snip]


How do you do "looping" flow control?

For context, what I'm trying to write is a single Org file from which
I can tangle out a number of =~/.ssh/config= files, one for each of
several hosts on a LAN. Within this file I need to repeatedly place a
template =BEGIN_SRC ssh-config= block, each time with a few words and
numbers changed. Do you do this anywhere? If so, how have you
implemented it?


It sounds like what you want is a template for the src block and another src
block that does substitutions in that template using a table of values
inside a loop.

Just to get you started, with this template:

#+NAME: template
#+BEGIN_SRC org
  ,#+BEGIN_SRC shell :tangle %to-file
  ls -lt %filename
  ,#+END_SRC
#+END_SRC

and this helper src-block

#+NAME: get-body
#+BEGIN_SRC emacs-lisp :var src-block-name="c-code"
  (save-excursion
(org-babel-goto-named-src-block
 src-block-name)
(cadr (org-babel-get-src-block-info)))

#+END_SRC


running

#+header: :wrap src org :var tmpl=get-body("template")
#+BEGIN_SRC emacs-lisp
  (org-fill-template tmpl
'(("to-file" . "abc.sh")("filename" . "my-dir")))
#+END_SRC

yields

#+RESULTS:
#+BEGIN_src org
,#+BEGIN_SRC shell :tangle abc.sh
ls -lt my-dir
,#+END_SRC
#+END_src


To revise this for your application, you need to provide a table of the
associated values for the "to-file" and "filename" keys in the alist, read
that table using a :var header, loop thru the table reconstructing the alist
each time creating src blocks, and send the output to an org tempfile.  Then
you tangle the tempfile.

Alternatively, you simply write the script files directly without bothering
to write to an org tempfile.


Thanks Chuck. I think I've got that straight. I hadn't come across
`org-fill-template' before. I think I know how to loop thru a table,
though I haven't done it myself before; I've seen how to "get" a table
as a list.

What I'm not clear about is why the template nests a shell-script
block inside an Org block. Should the outer Org block not have a
%-escaped placeholder for a :tangle target, an intermediate Org file?


No.

The org src block is just a container. Its body is a src block template 
that gets copied into the variable `tmpl', which if filled and placed in 
file can be tangled.


Alternatively, you can eval (setq tmpl "") somewhere 
(maybe in a local variables block), where the  part is 
the template.


But it seems easier to edit the template as an org src block - C-c ' puts 
your template in an OrgSrc buffer, then moving point to a src block and 
typing M-x org-edit-src-code puts its body in another OrgSrc buffer where 
you can edit it in the shell-mode or whatever mode.


Also, I suppose that template should have been an ssh-config src block to 
conform with your earlier posting. But I think you get the idea.


Chuck

Re: [O] Tangling flow control

[Charles C. Berry]

On Tue, 8 Nov 2016, Philip Hudson wrote:

[snip]


How do you do "looping" flow control?

For context, what I'm trying to write is a single Org file from which
I can tangle out a number of =~/.ssh/config= files, one for each of
several hosts on a LAN. Within this file I need to repeatedly place a
template =BEGIN_SRC ssh-config= block, each time with a few words and
numbers changed. Do you do this anywhere? If so, how have you
implemented it?




It sounds like what you want is a template for the src block and another 
src block that does substitutions in that template using a table of 
values inside a loop.


Just to get you started, with this template:

#+NAME: template
#+BEGIN_SRC org
  ,#+BEGIN_SRC shell :tangle %to-file
  ls -lt %filename
  ,#+END_SRC
#+END_SRC

and this helper src-block

#+NAME: get-body
#+BEGIN_SRC emacs-lisp :var src-block-name="c-code"
  (save-excursion
(org-babel-goto-named-src-block
 src-block-name)
(cadr (org-babel-get-src-block-info)))

#+END_SRC


running

#+header: :wrap src org :var tmpl=get-body("template")
#+BEGIN_SRC emacs-lisp
  (org-fill-template tmpl
'(("to-file" . "abc.sh")("filename" . "my-dir")))
#+END_SRC

yields

#+RESULTS:
#+BEGIN_src org
,#+BEGIN_SRC shell :tangle abc.sh
ls -lt my-dir
,#+END_SRC
#+END_src


To revise this for your application, you need to provide a table of the 
associated values for the "to-file" and "filename" keys in the alist, read 
that table using a :var header, loop thru the table reconstructing the 
alist each time creating src blocks, and send the output to an org 
tempfile.  Then you tangle the tempfile.


Alternatively, you simply write the script files directly without 
bothering to write to an org tempfile.


HTH,

Chuck

Re: [O] Bug: Unable to nest headings within export blocks [9.0 (9.0-elpa @ c:/Data/Documents/emacs.d/elpa/org-20161102/)]

[Charles C. Berry]

On Mon, 7 Nov 2016, Lixin Chin wrote:


Hi,

Thanks, yes that almost works. Unfortunately the heading line is just
reproduced verbatim in the output, whereas ideally it should be parsed
as a normal heading.

I.e., currently:

#+BEGIN_EXPORT html
,* HTML only heading
Text which should appear in HTML exports, but not \LaTeX{}.
#+END_EXPORT

Exports as:


* HTML only heading
Text which should appear in HTML exports, but not \LaTeX{}.


Whereas ideally I'd like to be able to input:

#+BEGIN_EXPORT html
* HTML only heading
Text which should appear in HTML exports, but not \LaTeX{}.
#+END_EXPORT

that would export as:


 2 HTML only 
heading

 
 
   Text which should appear in HTML exports, but not \LaTeX{}.
 
 




Run this:

#+BEGIN_SRC emacs-lisp :eval never-export :exports none
  (require 'ob-org)
  (defun eval-if-html ()
(if (not (eq org-export-current-backend 'html)) "never"))
#+END_SRC


Then export this with the html backend:

#+OPTIONS: toc:nil

#+BEGIN_SRC org :eval (eval-if-html) :exports results :results replace
  ,* HTML only heading
  Text which should appear in HTML exports, but not \LaTeX{}.
#+END_SRC

and you will get this:


1 HTML only 
heading



Text which should appear in HTML exports, but not \LaTeX{}.




With other backends you get nothing.

HTH,

Chuck

Re: [O] code blocks: update cache hash on export

[Charles C. Berry]

On Tue, 18 Oct 2016, Ulrich J. Herter wrote:


Hi everybody!

Two questions I'd like to ask the Org-community:

??

First:
When I export my document, the source blocks with outdated cache hashes
run, but no new hashes are put in the document.


Right. The exporter runs in a buffer copy, so the original is not modified.



I would like to have the hashes updated when the run on export, so next
time I export the don't need to be evaluated. This would save a lot
quite some time!

Is there a switch I missed, or any way to get this behaviour?


Run org-babel-execute-buffer (or org-babel-execute-subtree) before you 
export.





Second:
Is there a function to get the hash of a #+CALL:-block? C-c C-v a ()
doesn't work there.



`org-babel-current-result-hash' does this. It is not interactive, so if 
you want to query the value interactively, you need


 M-: (org-babel-current-result-hash)

with point in the CALL line. Or roll it into an interactive function of 
your own.


`org-ctrl-c-ctrl-c' will get the value if point is just before the hash.

HTH,

Chuck

Re: [O] gmane link broken

[Charles C. Berry]

On Sat, 1 Oct 2016, ilya shlyakhter wrote:


The link "Browse org-mode mailing list through Gmane" at
http://orgmode.org/community.html
seems broken.



There have been some recent changes to gmane.org. See

https://en.wikipedia.org/wiki/Gmane

AFAICS, the search has not (yet?) been restored.

Unless/until it is, there are other sites you can search.

You can try the search box on:

https://www.mail-archive.com/emacs-orgmode@gnu.org/

Chuck

Re: [O] export of src block ignores :results

[Charles C. Berry]

On Fri, 30 Sep 2016, Thomas Alexander Gerds wrote:



right, this is what changed and setting :eval never-export on a each
block solves the problem. however, the new way breaks all my existing
org-code.


I don't follow this. What exactly is broken?

You know all the options for setting header args, right? System-wide, 
buffer-wide, etc. For buffer-wide setting, one line is all it takes:


: #+PROPERTY: header-args :eval never-export

(and remember to C-c C-c on that line whenever you insert/edit it)



is there a reason why the header args have to be ignored when
org-export-babel-evaluate is nil? or asking more directly: would it be
possible to have another option, e.g.,

(setq org-export-babel-evaluate 'never-eval-obey-header-args)



But that is what :eval never-export does.


such that the export process does never evaluate src code but header
arguments are always obeyed?



Possible, yes. But since it adds no new capability and makes the babel 
code more involved, there isn't the motivtion to do it.


Chuck

Re: [O] export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:




[deleted]



anyway, the original problem is not solved yet.
org-babel-current-result-hash is related to the execution of the src
block which is independent of the export process since I have

(setq org-export-babel-evaluate nil).

and the problem that the results are exported in case of ":results code"
persists when I set (setq org-babel-hash-show-time nil)



Follow the advice in the docstring for `org-export-babel-evaluate'. Use 
`:eval never-export'. Set org-export-babel-evaluate to t.




so, unfortunately my question remains. which function in the export
process interprets the "results code" option?



With org-export-babel-evaluate set to nil, none of the babel functions 
are run. And none of the export transcoders take account of the header 
args, AFAICS. So the answer is `none of them'.


Chuck

Re: [O] export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Charles C. Berry wrote:


On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:


Hi Chuck

thanks for checking. my org-version is the same
release_8.3.6-1178-g2b22d5

to get the date and time of the in the results:

(setq org-babel-hash-show-time t)

but even without this option the results of the block are exported no
matter what. could someone point to the place in the export process
where the :results option is interpreted?


You probably want `org-babel-current-result-hash', which AFAICS does not 
recognize the `show-time' variant.


I think you'll need some regexp magic to make it work.


You might try this:


#+BEGIN_SRC emacs-lisp
  (setq org-babel-result-regexp
(concat
 "^[   ]*#\\+RESULTS\\[\\(?:<[0-9]"
 "\\{4\\}-[0-9]\\{2\\}-[0-9]\\{2\\} ?"
 "[0-2][0-9]:[0-6][0-9]:[0-6][0-9]> ?"
 "[^
\n[:alnum:]]*\\)?\\([[:alnum:]]+\\)"
 "\\]?:[   ]*"))
#+END_SRC


The line wrap after "[^ is due to C-M (you type C-q C-M to insert it if 
your email client messes with it and you need to redo it)


This seems like an innocuous change, but I haven't yet run this thru `make 
test' so beware.



Chuck

Re: [O] export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:


Hi Chuck

thanks for checking. my org-version is the same
release_8.3.6-1178-g2b22d5

to get the date and time of the in the results:

(setq org-babel-hash-show-time t)

but even without this option the results of the block are exported no
matter what. could someone point to the place in the export process
where the :results option is interpreted?


You probably want `org-babel-current-result-hash', which AFAICS does not 
recognize the `show-time' variant.


I think you'll need some regexp magic to make it work.

Chuck

Re: [O] Bug? org-export-babel-evaluate setting breaks :exports results

[Charles C. Berry]

On Thu, 29 Sep 2016, William Denton wrote:

I'm working on a big Org file on a slow machine, so I set 
org-export-babel-evaluate to nil so exporting to PDF just generates the file 
from what's in the buffer, without doing any calculating.




Actually it does a lot LESS than that.

The docstring notes that:

"When set to nil no code will be evaluated as part of the export
process and no header argumentss will be obeyed."

and advises:

"Users who wish to avoid evaluating code on export should use the header
argument ‘:eval never-export’."

which sounds like what you wanted.

Chuck

Re: [O] export of src block ignores :results

[Charles C. Berry]

On Thu, 29 Sep 2016, Thomas Alexander Gerds wrote:


Hi

org's development version (I am using the one updated yesterday: 2b22d50
Nicolas Go 2016-09-28) seems to ignore the :results setting of a src
block. more specifically, the export of this

#+BEGIN_SRC R  :results output :exports code  :session *R* :cache yes
2+2
#+END_SRC

#+RESULTS[<2016-09-29 08:32:48> e8e7ff579309fc6cacb1e75a0c1c671366c2eaf8]:
: [1] 4

should *not* include the results, but it does.


Using latest (release_8.3.6-1178-g2b22d5), I cannot reproduce.

Does `org-babel-sha1-hash' (C-c C-v a with point in the src block)
really yield "<2016-09-29 08:32:48> e8e7ff..." ??

I get "e8e7ff..." which causes no problems.

HTH,

Chuck

Re: [O] Dynamic tangle target?

[Charles C. Berry]

On Wed, 21 Sep 2016, Philip Hudson wrote:


AFAICT :tangle takes only "yes", "no", or a literal pathname.


Stuff like

   :tangle (my-lisp-function arg1 arg2)

will work.


How
might I dynamically generate a pathname for :tangle? I suppose what I
want is some kind of escape syntax for eval'ing a Lisp form, like
maybe:

   :tangle %(my-dynamic-filename-generator)


Try this:

#+BEGIN_SRC R :tangle (concat "my-" "file" ".R")
abs <- def
#+END_SRC

just as an example.

BTW, org-babel-view-src-block-info (C-c C-v C-i) will show you what header 
args evaluate as without the need to eval or tangle them.


HTH,

Chuck

Re: [O] Something to watch out for when including files

[Charles C. Berry]

On Tue, 20 Sep 2016, Eric S Fraga wrote:


Hello all,

just wanted to help others avoid spending a long time trying to figure
out some strange (well, unexpected) behaviour in org...

I have a document for which the LaTeX export was ignoring a
#+begin_abstract ... #+end_abstract construct near the start of the
document.  The text was simply not appearing in the LaTeX file.

Long story short: I had a #+include: directive as the first line of the
file which included an org file called preamble.org.  In that preamble
file, the last headline had the tag :noexport:.  It would seem that this
tag is not processed until after the include file has been included.  I
hope that makes sense.  In any case, this means that my abstract was
considered to be part of the noexport headline and was therefore not
exported.

Took me a very long time to figure out...  the simple solution was to
remove that noexport section entirely from the preamble file.



I find myself in the habit of using inlinetasks tagged noexport for 
various things and that might serve you in this case. That is, convert the 
headline section to an inlinetask.


Another possibility is to use something like:

#+header: :exports results :results raw replace
#+NAME: import-include-dot-org
#+BEGIN_SRC emacs-lisp
  (require 'ox-org)
  (org-export-string-as "#+INCLUDE: include.org" 'org t)
#+END_SRC

which will strip out headlines tagged with noexport during the babel phase 
of export (i.e. before parsing).



I do wonder whether the org export approach (i.e. how it "includes"
files) is correct but I can understand why the implementation is the way
it is.


I agree about the implementation. Trying to make it smarter is asking for 
trouble.


Chuck

Re: [O] Embedded LaTeX fontification

[Charles C. Berry]

On Fri, 9 Sep 2016, Kai von Fintel wrote:

When I embed LaTeX code in a `#+BEGIN_SRC latex` block and 
`org-src-fontify-natively` is set to `t`, the code is fontified as LaTeX 
code. But when the code is embedded in a `#+BEGIN_LaTeX` block, there's no 
fontification. Is that as intended? Am I missing some setting?


See ORG-NEWS

* Version 9.0
** Incompatible changes
*** New syntax for export blocks
[...]

and use the function provided there to update your *.org files.


Or could that functionality be added?


It is already there in the new export blocks.

HTH,

Chuck

Re: [O] :exports not being respected

[Charles C. Berry]

On Wed, 10 Aug 2016, Vikas Rawal wrote:

I have a with just the following header, and it is not respecting 
:exports in my R source blocks. The pdf file created has source code as 
well as the results.


What is wrong?


No ECM with src blocks, but see below.


Has the syntax changed again? I have not done anything with 
org-export-babel-evaluate.

#+TITLE: Title of this document
#+TODO: NOTES EXERCISE | DONE
#+OPTIONS: toc:nil
#+LATEX_CLASS: article
#+PROPERTY: header-args :eval never-export
#+PROPERTY: header-args :session ec404


Missing *plus* sign! (Don't forget `C-c C-c' !)

#+PROPERTY: header-args+ :session ec404




I am on Org-mode version 8.3.5 (release_8.3.5-1026-g096f42)


Works as expected for :exports both/results/code/none on:

Org-mode version 8.3.5 (release_8.3.5-1061-g48a87)
Org-mode version 8.3.5 (release_8.3.5-1025-g67c29a)


Chuck

p.s. It often helps to be sure header-args are what you thought they 
should be, i.e. move to a src block and run C-c C-v C-i. Doing that I 
could see that your second header-args property line overruled the first 
one.

Re: [O] seeking good practices for writing about org using org

[Charles C. Berry]

On Thu, 4 Aug 2016, Cook, Malcolm wrote:


Hi Charles,

On Wed, 3 Aug 2016, Cook, Malcolm wrote:


> > Thanks.  Much closer.  Still some issues.  Mind taking another

gander  (hoping the attached jpeg of the webpage rendered comes
through as an attachment)
If my emacs buffer holds...
--
#+BEGIN_SRC org :exports both :results value ascii





> ...^>>
> what is the `ascii' doing?



> Can you provide a link to documentation in the manual or a

docstring describing its function?


I cannot!  I learned this from reading the code.  In ob-org.el we
find provision for this as well as `html' and `latex'


(defun org-babel-execute:org (body params)
 "Execute a block of Org code with.
This function is called by `org-babel-execute-src-block'."
 (let ((result-params (split-string (or (cdr (assoc :results params)) "")))
   (body (org-babel-expand-body:org
  (replace-regexp-in-string "^," "" body) params)))
   (cond
((member "latex" result-params)
 (org-export-string-as (concat "#+Title: \n" body) 'latex t))
((member "html" result-params) (org-export-string-as  body 'html t))
((member "ascii" result-params) (org-export-string-as body 'ascii t))
(t body)
)))


This is all undocumented.  I think it is a 'nod in the direction' of
what I am trying to accomplish, allowing to see as "results" the org
markup transcoded into the markup of a backend.  See below for my
hack extension on this idea.


Argh! Not even a mention in the docstring!

I think there was a plea a while back for updates for the
missing entries in

./worg/org-contrib/babel/languages.org

but I see `org' has nothing. Sigh!






> Why don't you have 'replace' in the :results args?

Oops.  Of course.  While trying to understand all this, I had done this to 
similar effect instead:

(setq  org-babel-default-header-args:org nil) ; fix bug? NOT silent


If this is set as a default, it is deliberate. But you can just set
it as a property in the buffer.

[stuff deleted]


I played with extending org-babel-execute:org to allow including
 MULTIPLE transcoded markdown results using screwy variant syntax of
 `:results +ascii +html +latex` with some success.


[Malcolm's extension of `org-babel-execute:org' deleted]

Writing a custom org-babel-execute:org is one way to go.

Or slurp the code into another babel block, format it there, and wrap
the results accordingly. This might be best for your purposes. You can
write a block to format the original code, one to format it as latex,
one as html, one as markdown, etc. Put them in your personal
library-of-babel and ingest them. Then #+CALL lines will create the
markup you need for any src block (which you will mark `:exports none'
so all formatting is done by #+CALL's).

HTH,

Chuck