Re: Search and replace excluding code blocks?

2024-01-30 Thread Berry, Charles


> On Jan 29, 2024, at 3:47 PM, Vikas Rawal  wrote:
> 
> Hi all,
> 
> Is it possible to search and replace a regex/string in an org file excluding 
> the code blocks from its scope?
> 
> Say, I want to replace all opening quotes (") by backticks(``) in the text 
> but not in the code blocks. Is there a way one could achieve that?
> 

Sure, the recommended way to search and replace programmatically is given in 

(info "(elisp) Search and Replace")

Hacking that slightly to test if point is in a src block and using the double 
quote preceded by white space as the search string and replacing by that white 
space and double backticks gives:



#+begin_src elisp
  (goto-char 0)
  (while (re-search-forward "\\([[:space:]]\\)\"" nil t)
(unless (eq (org-element-type (org-element-at-point)) `src-block)
  (replace-match "\\1``")))
#+end_src

You can roll this into a function and add arguments as desired to allow 
different search/replacement strings. 

Best,

Chuck



Re: Feature request: Allow export to convert broken links to plain text

2023-09-11 Thread Berry, Charles
Ryan,

> On Sep 9, 2023, at 9:13 PM, Ryan C. Thompson  wrote:
> 
> So, this isn't an ideal solution, since it requires me to prefix any 
> potential offending links with "maybe:". But it's good enough for me.
> 

It is good that you have a solution, albeit with the caveat you mention above.

A couple of thoughts:

There is a hook that operates on the copy buffer before parsing viz. 
"org-export-before-parsing-functions is a variable defined in ‘ox.el’." (In 
older versions, it was org-export-before-parsing-hook.) Maybe you can add a 
hook that will add that prefix to all links, so you do not need to put it in 
your working files.

Or you could write an elisp macro that takes two arguments (link, desc) and 
uses them to either construct a link or your preferred substitute if it fails 
validation. 

HTH,

Chuck



Re: [Pre-PATCH v2] Add the capability to specify lexical scope in tangled files (was: Add new :lexical header argument)

2023-07-15 Thread Berry, Charles



> On Jul 15, 2023, at 9:11 AM, Thomas S. Dye  wrote:
> 
> 
> Ihor Radchenko  writes:
> 
>> "Thomas S. Dye"  writes:
>> 
 Am I correct that language-specific header arguments are not yet covered
 in the manual?  I can't find any reference of "lexical" there.
>>> 
>>> Yes, I believe so.  Language-specific header arguments for many languages 
>>> are documented at 
>>> https://orgmode.org/worg/org-contrib/babel/languages/index.html. Several 
>>> languages are not documented there; in these cases the documentation is 
>>> typically in the source code.
>> 
>> It is actually slightly awkward that built-in babel backends are not
>> documented in the manual, while, for example, export backends are.
>> 
> Agreed, but the two differ.  With export, the goal is to produce code 
> recognized as correct by the target software.  With babel, the general goal 
> is to provide language agnostic literate programming, which often produces 
> something that meets standards of correctness not implemented in software.  
> The idea of built-in babel backends, as distinct from contributed backends, 
> or backends distributed by package archive is a function of maintenance 
> burden and distribution channel, rather than something intrinsic to the 
> backend itself and how it contributes to literate programming.  
>> However, unless my memory deceives me, Bastien or Nicolas previously
>> voiced against adding babel documentation. Though I cannot find the
>> relevant discussion now and cannot recall the arguments (if there was
>> such discussion at all).
> 
> IIRC, there wasn't much discussion.   The current situation doesn't seem ripe 
> for documentation in the manual.
> 


Agreed. Maybe it would suffice to use enhanced docstrings for the 
org-babel-execute: functions and point to them in the manual.


The params argument could list the language specific keys and the language 
specific handling of key common to all languages (e.g. `:results graphics' in R 
jumps through a number of hoops that might deserve mention)

Chuck 


> Here are some potential hurdles:
> - there are likely too many built-in backends;
> - the built-in backends are a mixed bag--ob-lua seems half-finished to me, 
> though I don't program in lua and struggled to set up the language to write 
> the documentation stub on Worg;
> - nearly a dozen of the built-in babel backends lack documentation outside 
> the source code (see 
> https://orgmode.org/worg/org-contrib/babel/languages/index.html#orgbc466c5); 
> and
> - language support is inconsistent (see 
> https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html), which 
> introduces complications for language agnostic literate programming.
> 
> One way forward might distinguish between babel backends for GNU software and 
> babel backends for non-GNU software, with the former built in, guaranteed to 
> be consistent to some standard (which needs to be formulated), and documented 
> in the manual and the latter moved to contrib or a package archive, with 
> documentation (if any) on Worg.
> 
> Others might have better ideas.
> 
> All the best,
> Tom
> -- 
> Thomas S. Dye
> https://tsdye.online/tsdye
> 
> 





Re: Preserving leading zeros

2023-05-28 Thread Berry, Charles
William,

Have you considered http://gewhere.github.io/org-bibtex ??

Or using the approach therein, viz. use properties to store bib data in org?

HTH,
Chuck

> On May 28, 2023, at 7:46 AM, William Denton  wrote:
> 
> I'm thinking about moving a personal library catalogue system into Org.  This 
> would involve ISBNs, and when ISBNs had 10 digits some would have leading 
> zeros. It turns out leading zeros are removed when something looks like a 
> number.
> 

[snip]





Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-29 Thread Berry, Charles
Bastien et al,

> On Dec 29, 2022, at 8:00 AM, Bastien Guerry  wrote:
> 
> I think it would make sense to convert Elisp lists into R lists
> directly.  Jeremie, would you be okay with this?
> 


Perhaps there are some hiccups. 

The R `data.frame' type is a list with some added attributes. In that list each 
top level element is a *column* in the data.frame.

In the elisp list produced by rendering a table as in `:var mydf=atab', each 
top level element is a sequence containing one *row* of the table `atab'.

So if elisp lists are to be converted to R lists, ob-R will need to know 
whether the list came from a table to decide whether to render top level 
elements as list elements or as data.frame rows.

---

There might be some useful applications for converting org lists to R lists and 
vice versa. But it looks like a significant amount of effort to get it right.

Best,

Chuck
 





Re: [BUG] Header-args :results output of code block don't take precedence above headline header-args [9.6 (release_9.6-32-gc59d6d @ /tmp/org/org-mode/lisp/)]

2022-12-09 Thread Berry, Charles
Rens,

This is not a bug. Seee below.

> On Dec 7, 2022, at 9:47 AM, Rens Oliemans  wrote:
> 
> Hi all,
> 
> A code block with ":results output" as header argument still has its
> output silenced if it's inside a headline with ":results none". MWE:
> 
> 1. Create an .org file with the following content:
> 
> * Sub-tree with =:results none=
> :PROPERTIES:
> :header-args: :results none
> :END:
> 
> #+BEGIN_SRC bash :results output
>  echo "is silent"
> #+END_SRC


This is the correct handling.

See (info "(org) Results of Evaluation").

`output' is a `Collection' option. `none' is a `Handling' option. 

If you want to override a `Handling' option you need another `Handling' option. 
e.g.

#+BEGIN_SRC bash :results output replace
  echo "is silent"
#+END_SRC

HTH,

Chuck








Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Berry, Charles
Hi Greg,


> On Dec 5, 2022, at 4:41 PM, Greg Minshall  wrote:
> 
> hi, Charles,
> 
>> This makes a list like '("a" "b" "c") into a data.frame with one column.
> 
> 1. which version of Org are you running?
> : Org mode version 9.6 (9.6-g60de19 @ 
> /home/minshall/.emacs.d/straight/build/org/):
> 

Org mode version 9.6 (release_9.6-14-g53814a (dated 2022-12-02)

> 2. is my below example yours?


Not with the change I indicated (which includes your changes of sequencep to 
listp)

I have


#+begin_src R :var list='("a" "b" "c")
 list
#+end_src

#+RESULTS:
| a |
| b |
| c |



> 
> i think i used to see the behavior you describe in 9.5.
> 

So, isn't that what is wanted?


HTH,

Chuck


> cheers, Greg
> 
> 
> 
> #+begin_src R :var list='("a" "b" "c")
>  list
> #+end_src
> 
> #+RESULTS:
> | a | b | c |





Re: [BUG] ob-R.el: extra empty data.frame columns generated from plain lists after recent change [9.6 (release_9.6-3-ga4d38e @ /usr/share/emacs/30.0.50/lisp/org/)]

2022-12-05 Thread Berry, Charles



> On Dec 4, 2022, at 6:43 PM, Greg Minshall  wrote:
> 
> i see this same behavior.  to me, (org-babel-R-assign-elisp) seems to be
> the problem, but it hasn't changed any time recently.  (nor, if my =git
> blame= is done correctly, has anything else in ob-R.el.)
> 
> i don't understand how (org-babel-R-assign-elisp) thinks.  it seems to
> assign =max= and =min= assuming that =value= is a list of (at least one)
> list(s).
> 
> this *might* be a fix.  but, i don't have a lot of confidence it will
> not have bad side effects for other cases.  (though i tested it with a
> simple list, and a simple table with more than one row, and a list of
> two lists, the first of length 3, the second of length 2.):
> 
> modified   lisp/ob-R.el
> @@ -241,7 +241,7 @@ This function is called by `org-babel-execute-src-block'."
> (defun org-babel-R-assign-elisp (name value colnames-p rownames-p)
>   "Construct R code assigning the elisp VALUE to a variable named NAME."
>   (if (listp value)
> -  (let* ((lengths (mapcar 'length (cl-remove-if-not 'sequencep value)))
> +  (let* ((lengths (mapcar 'length (cl-remove-if-not 'listp value)))
>(max (if lengths (apply 'max lengths) 0))
>(min (if lengths (apply 'min lengths) 0)))
> ;; Ensure VALUE has an orgtbl structure (depth of at least 2).

- (unless (listp (car value)) (setq value (list value)))
+ (unless (listp (car value)) (setq value (mapcar 'list value)))


> 

This makes a list like '("a" "b" "c") into a data.frame with one column.

HTH,
Chuck






Re: [BUG] ob-R: session evaluation returns empty ouputs with Org 9.6 [9.6 ( @ /home/fsantos/.emacs.d/elpa/org-9.6/)]

2022-12-01 Thread Berry, Charles



> On Nov 30, 2022, at 5:48 PM, Ihor Radchenko  wrote:
> 
> William Denton  writes:
> 
>> I tried that, but it didn't fix it. :(
> 
> Ok. I was able to reproduce on my side.
> 
>> With a minimal setup, running the R block with a :session makes it ask where 
>> the 
>> working directory should be (the default in the prompt is the directory the 
>> test 
>> Org file is in).  Setting ess-startup-directory to 'default-directory 
>> doesn't 
>> change that, or the output problem.
> 
> It looks like there is something wrong with comint-prompt-regexp in R
> buffers. It somehow does not match the prompt.
> 
> I will need to look further.
> 

The older (commit bed47b437d8cde7a98bafdb07996e248b40f70e6e) version of 
org-babel-comint-with-output used comint-prompt-regexp and works fine.

I don't really follow how `org-babel-comint-prompt-separator` gets set to 
something useful in the current version. 

Reverting org-babel-comint-with-output to that older commit (and eval-ing the 
defun for org-babel-R-evaluate-session) seems to fix this case for those who 
need `:results output` in R src blocks till this gets sorted out.

HTH,

Chuck



Re: substitutions in html export?

2022-07-18 Thread Berry, Charles
Kevin,

> On Jul 17, 2022, at 1:54 PM, kevinbanjo  wrote:
> 
> When I look at the doc string for (org-macro-replace-all) it says:
> 
> Optional argument KEYWORDS, when non-nil is a list of keywords,
> as strings, where macro expansion is allowed.
> 
> I tried passing it '("export-block") but it didn't work, but it seems like 
> something like that should be close.
> 

Does this help?

Adding this to your example:

Here is an inline code src_emacs-lisp[
:results html :exports results :var num=numbers()]{
(format "the result is %d." num )} End.


Produces a paragraph:


Here is an inline code the result is 40. End.



> This whole area of org documentation seems pretty obtuse, with few examples.

Did you browse worg? Especially this:

https://orgmode.org/worg/org-contrib/babel/index.html


Agree that documentation is a WIP and export blocks are mentioned only in 
reference to specific exporters, so there is that.

HTH,
Chuck



Re: substitutions in html export?

2022-07-17 Thread Berry, Charles
Kevin,

> On Jul 17, 2022, at 10:18 AM, kevinbanjo  wrote:
> 
> 
> 
> On Sun, Jul 17, 2022 at 7:24 AM Ihor Radchenko  wrote:
> See inline calls in 
> https://orgmode.org/manual/Evaluating-Code-Blocks.html#Evaluating-Code-Blocks
> 
> I did this and it didn't work (but the one outside the export block did):
> 
> #+title:test
> 
> #+name: numbers
> #+begin_src emacs-lisp :exports none
> 40 
> #+end_src
> 
> #+begin_export html
> 
> the result is call_numbers()
> 
> #+end_export


The export block provides text that is to be used "as is" by the html backend. 
So, "call_numbers()" is treated as html.

You need to construct the export block programmatically. Maybe something like 

#+begin_src emacs-lisp :results html :exports results :var num=numbers()
   (format "the result is %d" num )
#+end_src

 
HTH,

Chuck






Re: Bug: ob-R.el breaks when :session is specified

2022-05-15 Thread Berry, Charles


Um...

> On May 15, 2022, at 2:46 AM, Christian Heinrich 
>  wrote:
> 
> I run 
> 
> emacs -q --load /tmp/init.el --file=/tmp/test.org 
> 
> with my /tmp/init.el being only
> 
>> (require 'package)
>> (package-initialize)
>> (add-to-list 'load-path "~/.emacs.d/straight/repos/org/lisp/")
>> (require 'org)
>> 
>> ;(require 'ess-site)

The line above is commented out. So how do you load ess-site?


>> (org-babel-do-load-languages
>>   'org-babel-load-languages
>>'((R . t)))
> 
> I hope this constitutes a minimal example for a config - please correct me if 
> I'm wrong.


Just spitballing here:

Have you tried instrumenting `org-babel-R-evaluate-session'? 

Maybe watching changes made to the session buffer on first evaluation and 
comparing to subsequent evals helps.

HTH,
Chuck



Re: How to export to markdown programmatically without the table of contents?

2022-05-01 Thread Berry, Charles



> On May 1, 2022, at 2:20 AM, Marcin Borkowski  wrote:
> 
> Hi fellow Orgers,
> 
> I'd like to export a Org-mode formatted string to markdown, but without
> the table of contents.
> 
> (org-export-string-as my-string 'md t '(toc nil))
> 
> didn't work (the ToC was still there).  What am I missing?


It does seem odd that BODY-ONLY as `t' gives a toc. With latex it does not 
regardless of `:with-toc'.

: (org-export-string-as my-string 'md t '(:with-toc nil))

seems to give what you want.

HTH,
Chuck






Re: handling as special special block in derived export

2022-01-19 Thread Berry, Charles
Matt,

> On Jan 19, 2022, at 5:52 AM, Matt Price  wrote:
> 
> However, I'd really like to add a less verbose syntax, like this:
> 
> #+begin_r-stack :frag (appear appear)
> [[imglink1]]
> [[imglink2]]
> #+end_r-stack
> 
> My question is: will the exporter preserve information from these header-like 
> arguments, and is 
> there a mechanism I can use in a custom ~special-block-function~ to make use 
> of htem?
> 

Not as you have it there, but

#+header: :frag (appear appear)
#+begin_r-stack
[[imglink1]]
[[imglink2]]
#+end_r-stack


parses as 

(special-block
 (:type "r-stack" :begin 727 :end 815 :contents-begin 775 :contents-end 801 
:post-blank 0 :post-affiliated 759 :header
(":frag (appear appear)")
:mode nil :granularity element :parent nil))

if that helps.

Chuck



Re: should a "wrapped" table result behave differently than one that is not?

2022-01-18 Thread Berry, Charles
Eric,

> On Jan 18, 2022, at 9:05 AM, Eric S Fraga  wrote:
> 
> been wrapped in a RESULTS special block be different than one that is
> not wrapped (beyond the wrapping, of course)?  Specifically, wrapping
> the results seems to cause org to ignore that ATTR_LATEX :center toggle
> [1].  A minimal example, both org and resulting LaTeX, attached.
> 
> I guess it makes sense in that the attr line will probably be applied to
> the results special block.  I am not sure how to get around this.
> Suggestions very welcome indeed!  I do need to wrap the results in a
> block of some type so I can control the formatting in the resulting PDF
> export but I do not want the table centred necessarily [2].
> 


This is annoying, but I think you can get the product you want by 
"pre-wrapping" the results.

Here is an example:

#+begin_src org
  Show default:

  ,#+begin_src emacs-lisp :exports both
  org-latex-tables-centered
  ,#+end_src

  ,#+name: awrappedtable
  ,#+header: :exports results
  ,#+header: :results value
  ,#+begin_src emacs-lisp
'((1 2) (3 4))
  ,#+end_src

  ,#+begin_results
  ,#+attr_latex: :center nil
  ,#+RESULTS: awrappedtable
  : initial filler
  ,#+end_results
#+end_src


On export I get

Show default:

\begin{verbatim}
org-latex-tables-centered
\end{verbatim}

\begin{verbatim}
t
\end{verbatim}


\begin{results}
\begin{tabular}{rr}
1 & 2\\
3 & 4\\
\end{tabular}
\end{results}


HTH,
Chuck






Re: Way to mark contents of an Org special block as verbatim?

2022-01-09 Thread Berry, Charles



> On Jan 9, 2022, at 8:58 AM, Kaushal Modi  wrote:
> 
> How do we disable Org from transforming this:
> 
>E = -J \sum_{i=1}^N s_i s_{i+1}
> 
> to this:
> 
> 
>E = -J i=1^N s\_i si+1

Ahh! Sorry!

So,
:   (format "{{<%s>}}\n%s{{}}\n" type contents type)

has the contents already parsed and transcoded which you do not want. So use 
something like:

#+begin_src emacs-lisp

(let ((raw-contents
  (buffer-substring-no-properties
   (org-element-property :contents-begin special-block)
   (org-element-property :contents-end special-block
 (format "{{<%s>}}\n%s{{}}\n" type raw-contents type))

#+end_src

HTH,

Chuck



Re: Way to mark contents of an Org special block as verbatim?

2022-01-08 Thread Berry, Charles



> On Jan 8, 2022, at 3:29 PM, Kaushal Modi  wrote:
> 
>> What am I missing?
>> 
>> It seems like you want your derived backend to transcode special blocks 
>> somewhat differently than the parent backend. And adding a special block 
>> export filter doesn't quite do the job.
> 
> I tried out the example Juan posted and it works perfectly well. But
> it would require to user to do something similar for each arbitrary
> new special block they need. E.g. #+being_katex, #+begin_tikz,
> #+begin_tikzjax (could be anything!) where the content needs to be
> kept unmodified.
> 

Right, so maybe use `(member type )' rather than 
'(equals type "newlatex")' in the3 example below.


>> For that purpose, you should write a special block transcoder - perhaps 
>> falling back to the parent backend for block types you do not wish to handle 
>> as described above.
> 
> Can you please point me to an example?
> 

A simple one here:

#+begin_src emacs-lisp
  ;; minimal backend with latex parent
  (org-export-define-derived-backend 'newlatex 'latex
:translate-alist
'((special-block . org-newlatex-special-block)))

  ;; special block transcoder
  (defun org-newlatex-special-block (special-block contents info)
"Newlatex special block transcoder."
(let
 ((type (org-element-property :type special-block)))
  (if (equal type "newlatex")
  (format "{{}}\n%s{{}}\n" contents)
;; not `newlatex` so default to latex transcoder
(org-export-with-backend 'latex special-block contents info
#+end_src

Eval the above, then use this as an example by copying the following
src block to an org buffer and entering

M-; (org-export-to-buffer 'newlatex "*Org NEW LATEX Export*" nil nil nil t) RET

#+begin_src org

  ,#+begin_newlatex
  This is the new content
  ,#+end_newlatex


  ,#+attr_latex: :caption \MyCaption{HeadingA}
  ,#+BEGIN_proof
 dot-dot-dot
  ,#+END_proof

#+end_src

I get an *Org NEW LATEX Export* buffer like this:

#+begin_example
{{}}
This is the new content
{{}}


\begin{proof}
dot-dot-dot
\MyCaption{HeadingA}
\end{proof}

#+end_example


>> Block specific customizations could rely on a backend specific attribute.
> 
> Yes, I am doing block-specific customization (like support
> #+attr_shortcode above special blocks here[1]). But I don't know how
> to get back the original content of the special block because the
> `contents` arg received by the exporter's org-hugo-special-block
> already has the Org entities, and sub/super replacements done.
> 
> [1]: 
> https://urldefense.com/v3/__https://github.com/kaushalmodi/ox-hugo/blob/458142675bb5a0e7ee26ecea07d75c10aa52184b/ox-hugo.el*L2872__;Iw!!LLK065n_VXAQ!xZhh--YwGpo06BbAHLF_A2MY_4mk4gBxHgFG3InZakP_7mdFDpyBNMgqvDVvBimzWQ$
>  





Re: Way to mark contents of an Org special block as verbatim?

2022-01-08 Thread Berry, Charles


> On Jan 6, 2022, at 11:46 AM, Kaushal Modi  wrote:
> 
> On Thu, Jan 6, 2022 at 2:33 PM Juan Manuel Macías
>  wrote:
>> I just realized that there is a much simpler solution for your katex
>> environment :-)
>> 
>> You can use an example block, and define your custom environment using
>> the attribute :environment
> 
> Sorry, but this exporter is derived from md, and before exporting the
> verbatim body of the special block needs to be surrounded with some
> special syntax, with some optional stuff that the user specifies. Also
> it could any special block name:
> - katex
> - tikz
> - tikzjax
> 
> In any case, if user has this in Org:
> 
> #+begin_FOO
> 
> #+end_FOO
> 
> I need to export:
> 
> {{< FOO custom stuff >}}
> 
> {{< /FOO >}}
> 
> 

What am I missing? 

It seems like you want your derived backend to transcode special blocks 
somewhat differently than the parent backend. And adding a special block export 
filter doesn't quite do the job.

For that purpose, you should write a special block transcoder - perhaps falling 
back to the parent backend for block types you do not wish to handle as 
described above.

Block specific customizations could rely on a backend specific attribute.

HTH,
Chuck



bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-31 Thread Berry, Charles
Max,

> On Dec 31, 2021, at 4:05 AM, Max Nikulin  wrote:
> 
> 
> Should some function a macro be provided to facilitate declaring languages as 
> data format (config files, JSON, YAML, etc.) rather than executable source 
> code?

I think we already have this in the form of export blocks, viz.

#+name: yaml_header_1
#+begin_export yaml
output:
  html_document:
toc: true
toc_depth: 2
#+end_export

will be ignored by babel and by exporters that do not define a transcoder for 
`yaml' blocks.

The data can be used in transcoders for derived backends or in src blocks like 
this one:

#+begin_src emacs-lisp :var yaml_dat_1=yaml_header_1
  yaml_dat_1
#+end_src

And =C-c '= will invoke an edit buffer in yaml mode (if available).

And it seems that fontifying natively works just as with src blocks.

Best,
Chuck







bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-30 Thread Berry, Charles
Rudy,

> On Dec 29, 2021, at 11:26 PM, Rudolf Adamkovič  wrote:
> 
> (Note: I do not know what ECM stands for.)


ECM stands for =Exemple Complet Minimal=, per 
https://orgmode.org/worg/org-faq.html#ecm, which says "The term refers to test 
files that can reliably reproduce a bug with the minimal amount of code."

It also references 
https://list.orgmode.org/orgmode/80oc3s13rg@somewhere.org/ for more details.

Roughly, an ECM is something a reader should be able to copy into a file and 
run "as is" on his/her setup. 

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-29 Thread Berry, Charles
Max,

> On Dec 29, 2021, at 4:53 AM, Max Nikulin  wrote:
> 
> On 25/12/2021 02:52, Berry, Charles wrote:
>> For that case, setting buffer or heading properties, such as:
>> #+begin_src org
>>   :PROPERTIES:
>>   :header-args: :eval yes :exports results
>>   :header-args:bibtex: :eval no
>>   :END:
>> #+end_src
>> resolves the issue.
> 
> Chuck, is it expected that the following form to specify properties 
> suppresses of evaluation during export but allows execution during processing 
> of `org-babel-execute-buffer'? I am puzzled that behavior for property drawer 
> is different.
> 

It isn't different when you have `:header-args:elisp: :eval no' in the drawer.

I get the message `Evaluation of this elisp code block is disabled.' either way.

Caveat: I am running release_9.5.1-233-ged5335.

But a couple of things:

1) Be sure to refresh when introducing `#+property' lines. If you paste in a 
property line and then org-babel-execute-src-block, the property will not be 
acknowledged. AFAICS, property drawers do not suffer from this. 

2) Property drawers only affect the heading under which they are placed unless 
placed at the top of the file. And either way, it is an error to insert a blank 
line above a property drawer. org-lint will complain although the message may 
be cryptic.

3) You probably know this, but exports use `org-babel-exp-process-buffer' which 
may perform differently than `org-babel-execute-buffer'. 




>  >8 
> #+property: header-args :eval yes :exports both
> #+property: header-args:elisp :eval no
> 
> #+begin_src elisp
>  (message "From elisp")
> #+end_src
>  8< 


HTH,
Chuck





bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-25 Thread Berry, Charles
Rudy,

Thanks for the comment, but ...

> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič  wrote:
> 
> I think we look at the problem from two different perspectives.  You
> look at the problem from the "how" perspective, whereas I look at it
> from the "why" perspective.  Sure, we can work around everything in Org.
> Now, does that mean that Org should try to execute BibTeX blocks when
> executing a buffer?  I do not think so.

Using standard features (properties, header-args) in a standard way does not 
strike me as a `work around'.

You have not made a clear case that src blocks are even needed to support your 
use case. It may well be that export blocks (which never execute) would work 
just as well.  But with no ECM, one can only guess.

I'm still inclined to call this a feature request, not a bug. And decisions 
about adding complexity to an already complicated code base should take that 
point of view, IMO.

Best,

Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-24 Thread Berry, Charles


> On Dec 23, 2021, at 8:09 PM, Ihor Radchenko  wrote:
> 
> Rudolf Adamkovič  writes:
> 
>>> So, Org cannot distinguish between language backends that are simply
>>> not loaded and the ones that do not define org-babel-execute:lang.
>> 
>> Oh, if we have this architectural limitation in place, then Org cannot
>> help the user, and every user will have "explain" to Org that executing
>> BibTeX makes no sense.  I guess we can then close this bug then!
> 
> Not necessarily close. As I proposed above, one way is adding a user
> customisation. And we do not have to force the users adding trivial
> things like bibtex. Bibtex may be one of the defaults.

Honestly, I think there is no problem here to solve. 

If there is a use case that you think I didn't cover below, please provide an 
ECM and directions for triggering the unwanted behavior.

Details:

---

Exports do not eval blocks for which there is no org-babel-execute:.

So, `C-c C-e l L' (and so on) will *not eval* bibtex src blocks.

The problem cited here *only* exists for execution using 
org-babel-execute-buffer or similar functions.

For that case, setting buffer or heading properties, such as:

#+begin_src org
  :PROPERTIES:
  :header-args: :eval yes :exports results
  :header-args:bibtex: :eval no
  :END:
#+end_src

resolves the issue.

So the user needs to add just one-line per language to set this up.

Following (info "(org) Property Syntax") the user can set this behavior for all 
Org files by customize-ing `org-global-properties', whose docstring gives 
plentiful details.

---



HTH,
Chuck



Re: exporter: How to get :file property on a src block in an exporter

2021-12-22 Thread Berry, Charles



> On Dec 22, 2021, at 2:16 PM, Yasushi SHOJI  wrote:
> 
> Hi,
> 
> On Thu, Dec 23, 2021 at 3:22 AM Berry, Charles  
> wrote:
>>> On Dec 22, 2021, at 8:07 AM, Yasushi SHOJI  wrote:
>>> On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  
>>> wrote:
>>>> Then, why don't I have :file in the info?
>>> 
>>> The :exports must be "file" to have the file name in the info.  I used
>>> to have "code" because
>>> I wanted to export code with the file name as an attribute.
>> 
>> I don't see that here:
>> 
>> #+begin_src emacs-lisp :exports code :file abc
>>  (assq :file (caddr (org-babel-get-src-block-info 'light)))
>> #+end_src
>> 
>> #+RESULTS:
>> : (:file . abc)
> 
> Indeed, this one works.  But I don't see :file, or the whole
> :parameters in the info arg passed to my function.

Of course. Your function is called after the buffer is parsed.

> 
>> `org-export-as' runs `org-babel-exp-process-buffer' *before*  it parses the 
>> buffer and the header args get stripped from the copy buffer at that time.
> 
> Would you mind telling me where the stripping part is in the code, and
> the reason why it strips?

'...at that time' was meant to refer to when `org-babel-exp-process-buffer' 
runs. So look there.

Why? I didn't have a hand in that decision, but my guess is that almost always 
the header args are only useful in babel per se, so there is no reason to hang 
onto them.


> 
>> So you need to find a way to get the :file header arg whilst babel runs and 
>> hang onto it for later use.
> 
> I'm still learning but :parameters, which holds :file, are already
> gone from the info arg when org-myexporter-src-block is called.
> 

That is what I tried to say.

Best,
Chuck



Re: exporter: How to get :file property on a src block in an exporter

2021-12-22 Thread Berry, Charles



> On Dec 22, 2021, at 8:07 AM, Yasushi SHOJI  wrote:
> 
> On Thu, Dec 23, 2021 at 12:52 AM Yasushi SHOJI  
> wrote:
>> Then, why don't I have :file in the info?
> 
> The :exports must be "file" to have the file name in the info.  I used
> to have "code" because
> I wanted to export code with the file name as an attribute.
> 


I don't see that here:

#+begin_src emacs-lisp :exports code :file abc
  (assq :file (caddr (org-babel-get-src-block-info 'light)))
#+end_src

#+RESULTS:
: (:file . abc)

---

Another problem for you: 

`org-export-as' runs `org-babel-exp-process-buffer' *before*  it parses the 
buffer and the header args get stripped from the copy buffer at that time. 

So you need to find a way to get the :file header arg whilst babel runs and 
hang onto it for later use.

This can be a tricky business.

HTH,

Chuck



> I think I can work on it.
> 
> Thanks Ihor for your hint!
> 
> Best regards,
> -- 
> yashi
> 
> 





bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-21 Thread Berry, Charles


> On Dec 21, 2021, at 2:53 PM, Rudolf Adamkovič  wrote:
> 
> I struggle to understand.  Why do we need a customization?  If Org knows
> that some backend exists but has no execute function, why does it even
> try to execute it?  It cannot.  Do I miss something?


Sorry if my prior posts were garbled. To clarify:

When exporting src blocks for which there is no execute function for the lang, 
the block will not be executed and the export will proceed.

When evaluating src blocks in other circumstances, e.g. M-x 
org-babel-execute-buffer, the process will terminate when 
org-babel-execute-src-block issues `(error "No org-babel-execute function for 
%s!" lang))'

The latter can be a clue that the name of a lang is misspelled or that 
org-babel-load-languages needs to be customized to provide the execute function.

IMO, nothing needs fixing. The ability to handle OP's original issue is already 
in place.

HTH,
Chuck

bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-18 Thread Berry, Charles



> On Dec 18, 2021, at 11:57 AM, Charles Berry  wrote:
> 
> There are workable approaches under the current setup. 
> 
> -


Also, when exporting it looks `org-babel-exp-results' does not attempt to run 
src blocks for which

(fboundp (intern (concat "org-babel-execute:" lang)))

is nil.

So doing an export should `just work'.

HTH,

Chuck





bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-18 Thread Berry, Charles



> On Dec 18, 2021, at 1:49 AM, Ihor Radchenko  wrote:
> 
> "Berry, Charles"  writes:
> 
>> If I have a typo in the name of a language, the error message you quote 
>> tells me what my mistake was. 
>> 
>> I'd say that is a feature, not a bug.
> 
> Agree. However, some languages simply do not define babel execute
> function. The error is same regardless whether a language backend is not
> available/not loaded or the backend is loaded, but does not provide
> babel execute function.
> 
> Maybe we can provide a custom list of languages where we do not throw
> the error? If a language is in the list and there is no babel execute
> function, we can simply ignore the source block. If a language is in the
> list, but there is babel execute function, we throw another error.
> 
> Though I am not a big fan of introducing yet another customisation.
> Maybe someone has better ideas?
> 

I believe there is a feeling that org-babel is already so complicated that 
adding features should be avoided. 

There are workable approaches under the current setup. 

---

For one, you can define lang specific header-args, so just define :eval no for 
the lang's that you want to use, but that do not have org-babel-execute: 
defined: 

#+property: header-args:nada :eval no
#+property: header-args :exports both :eval yes

The code here will be rendered, but the block will not execute:

#+begin_src nada
  "haha"
#+end_src

---

Another is to use a custom :eval arg like this:

#+property: header-args :eval (my-eval-p) :exports both

#+begin_src not_defined
  "haha"
#+end_src

Where `my-eval-p' is defined as:

#+begin_src emacs-lisp
  (defun my-eval-p ()
(let ((lang (car (org-babel-get-src-block-info 'light
  (if (fboundp (intern (concat "org-babel-execute:" lang)))
  "yes"
"no")))
#+end_src

Obviously, you can elaborate `my-eval-p' to satisfy individual needs.

Best,
Chuck







bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-17 Thread Berry, Charles


> On Dec 16, 2021, at 8:51 PM, Kyle Meyer  wrote:
> 
> Rudolf Adamkovič:
> 
>> I have a .org file with two kinds of src blocks:
>> 
>> 1. sqlite blocks
>> 2. bibtex blocks
>> 
>> I want to execute all sqlite blocks with org-babel-execute-buffer.
>> 
>> When I try to do so, org-mode complains:
>> 
>> org-babel-execute-src-block: No org-babel-execute function for bibtex!
>> 
>> I know I can work around the problem (as one does in org-mode) with:
>> 
>> #+property: header-args:bibtex+ :eval no
>> 
>> Then, why not skip the irrelevant blocks, the ones with no execute 
>> functions, by default?


If I have a typo in the name of a language, the error message you quote tells 
me what my mistake was. 

I'd say that is a feature, not a bug.

HTH,
Chuck

> 
> I don't know, but I've reassigned this bug in order to redirect this to
> the Org list, which serves as the primary place for Org development and
> discussion.
> 


Re: reference a remote named block in #+CALL: line

2021-11-02 Thread Berry, Charles
Matt,

> On Nov 2, 2021, at 3:19 AM, Matt Price  wrote:
> 
> I am getting used to calling library-of-babel functions with local data 
> structures as input variables, e.g. in this line:
> 
> #+CALL: list2table(data=common-issues-list, order="rows") :results  table  
> raw 
> 
> where `common-issues-list` is a named org-mode list in the current file, e.g. 
> 
> #+NAME: common-issues-list
> - some
> - things
> - here
> 
> In this particular case, I'd like to maintain a single data structure and use 
> it in a bunch of places (it's a document I re-use in several courses, all of 
> which are published online with different metadata stored in headings). Is 
> there a syntax for referring to #+NAME'd elements in remote files?
> 
> Sorry if I'm missing something that is explained in the docs -- I am not 
> finding this in what I think of as the obvious places.  
> 

AFAIK, there is nothing like this.

However, it looks like it would be easy to modify `org-babel-lob-ingest' by 
adding another argument giving the name (or a list of names) of src blocks that 
you want added to `org-babel-library-of-babel' by replacing the `when 
source-name' with something like `when (member source-name only-these-names)' 
so only src blocks you want to invoke are ingested.

HTH,

Chuck






Re: [PATCH] async process in R

2021-09-28 Thread Berry, Charles
Jeremie,

> On Sep 28, 2021, at 12:34 AM, Jeremie Juste  wrote:
> 
> Thanks for the feedback. With the following patch, I made sure that
> ess-inject-source is set to default before evaluating the buffer.
> 
> So even if I set
> (setq ess-inject-source 'function-and-buffer), I get the following
> output. Note that I get the same output in the IESS console buffer when
> I execute the command following command.
> 
> #+begin_src R :session *R*  :results output :async yes
>  Sys.sleep(2)
>  1:5
> 
>  10:20
>  1:2
> #+end_src


OK. The patch works when applied on top of the previous 2 (but the second one 
has the same name, so there is that to watch out for).

However, I think we are not quite home free. With `:async no', this works as 
expected:

#+begin_src R :session *R*  :results output :async no
  Sys.sleep(2)
  1:5
  10:
a
  1:2
#+end_src

#+RESULTS:
: 
: [1] 1 2 3 4 5
: 
: Error: object 'a' not found
: 
: [1] 1 2


But changing to `:async yes', the error aborts in a way that omits the output.

HTH,
Chuck



Re: [PATCH] async process in R

2021-09-27 Thread Berry, Charles
Jeremie,

> On Sep 27, 2021, at 3:56 PM, Berry, Charles  wrote:
> 
> There is something in my init that doesn't play nice with this.  



(setq ess-inject-source nil)


seems to be the culprit.


Also note, even with ess-inject-source set to t, there is an indentation issue:

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(2)
1:5

10:20
#+end_src

#+RESULTS:
: [1] 1 2 3 4 5
:  [1] 10 11 12 13 14 15 16 17 18 19 20



HTH,

Chuck



Re: [PATCH] async process in R

2021-09-27 Thread Berry, Charles
Jeremie,


There is something in my init that doesn't play nice with this.  

IOW, emacs -q and then load the minimal stuff works OK, but my usual startup 
does not.

#+begin_src R :session *R*  :results output :async yes
Sys.sleep(5)
1:5
#+end_src

#+RESULTS:
: > > 
: [1] 1 2 3 4 5
: >

It may take me a while to figure out what it is.

:-(

HTH,

Chuck


> On Sep 27, 2021, at 1:28 PM, Jeremie Juste  wrote:
> 
> Hello Chuck,
> 
> On Monday, 27 Sep 2021 at 18:28, Berry, Charles wrote:
>> 
>> It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
>> default setting.
> 
> Thanks again for your suggestion. The following patch to be applied on
> top of the previous one, solves the issue.
> 
> 
> #+begin_src R :session *R*  :results output :async yes
> Sys.sleep(5)
> 1:5
> #+end_src
> 
> #+RESULTS:
> : [1] 1 2 3 4 5
> 
> 
> The function (ess-eval-buffer), when the parameter VIS is nil,  misled me in 
> the sense that it inverses
> the value of ess-eval-visibly.
> 
> Note as well that all the tests in test-ob-R.el passed including the
> tests for async evaluation from [1] ob-session-async.
> 
> [1]: 
> https://urldefense.com/v3/__https://github.com/jackkamm/ob-session-async/__;!!LLK065n_VXAQ!wfTTIQ1fHIH2f6FmnUYZow4BoKA9_bQyOgBdm4tgLfJxbDF0vVs4sTbSQ0Zm-7YjVg$
>  .
> 
> <0001-ob-R.el-Patch-async-evaluation-when-results-output.patch>
> Thanks again to Jack for this useful feature.
> 
> Best regards,
> Jeremie





Re: [PATCH] async process in R

2021-09-27 Thread Berry, Charles
Jeremie,

> On Sep 26, 2021, at 10:13 AM, Jeremie Juste  wrote:
> 
> But for the time being result output produces the following output.
> 
> #+begin_src R :session *R*  :results output :async
> Sys.sleep(1)
> print(1:5)
> #+end_src
> 
> #+RESULTS:
> : > Sys.sleep(1)
> : > print(1:5)
> : [1] 1 2 3 4 5
> : > 'ob_comint_async_R_end_53c0a42fed17cf78f5508e5293029430'
> 
> 
> From my understanding the async command of python does not suffer from
> this issue. I'm not sure if the issue needs to be solve at the ob-R.el
> or at the ob-core.el. I welcome any comments on this patch or any idea
> to move it forward.


It looks like you have `(setq ess-eval-visibly t)' here. I think that is a 
default setting.

With (setq ess-eval-visibly nil), I get 

#+RESULTS:
: > 
: [1] 1 2 3 4 5
: > >


which is better, but the prompts still need cleaning along the lines of 
`org-babel-R-evaluate-session'.

It seems like this is an ob-R.el issue.

HTH,
Chuck





Re: Org babel source blocks ignore buffer-local variables

2021-09-06 Thread Berry, Charles



> On Sep 6, 2021, at 1:53 AM, Dominik Schrempf  
> wrote:
> 
> Thank you, this solution works. May I ask about the reasons of such a
> distinction?


[i.e. between exec-path and (getenv "PATH")]

Well, this is how `shell' and `shell-command-on-region' both do it, and they 
seem to be the underlying engines.  So you might ask elsewhere why it is so.

There are probably a lot of circumstances in which the distinction makes sense 
in babel shell blocks. 

You would not want to use exec-path if your src block was being executed 
remotely, for example.

I think different shells can sensibly use different PATH defaults, so that 
might be another circumstance in which the default to exec-path could trip you 
up.

HTH,
Chuck





Re: Org babel source blocks ignore buffer-local variables

2021-09-04 Thread Berry, Charles


> On Sep 4, 2021, at 5:30 AM, Dominik Schrempf  
> wrote:
> 
> Hello,
> 
> I use directory local environments with =envrc= [1], and run into trouble when
> using (Bash) Org Babel source code blocks. The buffer local environment seems 
> to
> be ignored (see the example at the bottom).
> 
> This seems to have been discussed in the course of a GitHub issue of
> =inheritenv= [2], which is pulled in by =envrc=. Also, on this mailing list,
> there was a short discussion [3].
> 
> Do you have any thoughts on this? Is there an easy way to make Org Babel 
> source
> blocks honor buffer local setups?
> 
> Thank you!
> Dominik
> 
> #+name: Scratch
> #+begin_src sh :exports both :results output verbatim
> function path () { echo "$PATH" | tr ':' '\n'; }
> path
> #+end_src
> 
> #+RESULTS: Scratch
> #+begin_example
> /home/dominik/Evolutionary-Biology/Scripts/nix-flakes
> /home/dominik/Evolutionary-Biology/Scripts
> /home/dominik/bin/nix-flakes
> /home/dominik/bin
> /run/wrappers/bin
> /home/dominik/.nix-profile/bin
> /etc/profiles/per-user/dominik/bin
> /nix/var/nix/profiles/default/bin
> /run/current-system/sw/bin
> /nix/store/3l9lddwxz1mayaxvw8iy50ygzzfh1s1b-emacs-27.2/libexec/emacs/27.2/x86_64-pc-linux-gnu
> #+end_example
> 
> The Emacs =exec-path= variable has the following value:
> 
> #+begin_quote
> exec-path is a variable defined in ‘C source code’.
> Its value is
> ("/nix/store/cnxncxyghj3gfpfvng6z4l8k4hfl48wq-ghc-8.10.6-with-packages/bin/" 
> "/nix/store/435paza0j48aa9vgvf6r2l12nrg4ld11-patchelf-0.12/bin/" 

[snip]

Indeed, ~exec-path~ and ~(getenv "PATH")~ can differ.

If you want to set PATH for a shell src block, you can do something like:

#+begin_src sh :results output verbatim :var PATH=(mapconcat 'identity 
exec-path ":")
  echo $PATH
#+end_src

HTH,

Chuck

  

Re: Number format for table results outut from R data.frame/tibble

2021-08-21 Thread Berry, Charles



> On Aug 21, 2021, at 9:58 AM, John Hendy  wrote:
> 
> 
> Interesting, and thanks for taking a look. I don't think I specified
> sufficiently that I'm actually aiming for latex/pdf output and
> therefore want the org table. 

John,

If you want a latex export, you should use one of the many R packages[1] that 
format R objects for latex output.

For example:

#+begin_src R :session foo :results output latex
library(tibble)
library(xtable)
tmp <- tibble(x=1:5, y=x/pi)
xtable(tmp)
#+end_src

#+RESULTS:
#+begin_export latex

% latex table generated in R 4.1.0 by xtable 1.8-4 package
% Sat Aug 21 10:23:18 2021
\begin{table}[ht]
\centering
\begin{tabular}{rrr}
  \hline
 & x & y \\ 
  \hline
1 &   1 & 0.32 \\ 
  2 &   2 & 0.64 \\ 
  3 &   3 & 0.95 \\ 
  4 &   4 & 1.27 \\ 
  5 &   5 & 1.59 \\ 
   \hline
\end{tabular}
\end{table}
#+end_export

The xtable() and its print method have loads of options for formatting, setting 
environments and labels, and adding captions.

If you insist on doing this in org without the assistance of an R package, you 
will need to use a `:post' header argument.  If you have solid elisp skills, 
this is a viable option.

HTH,
Chuck

[1] One list of such is at: 
https://stackoverflow.com/questions/5465314/tools-for-making-latex-tables-in-r



Re: Bug: :session results in unfriendly error reporting

2021-08-16 Thread Berry, Charles
James,

> On Aug 15, 2021, at 4:41 PM, James Powell  wrote:
> 
> I write a deliberate syntax error into a code block:
> 
> : #+begin_src R :session
> :   x <- 1
> :   y xx z
> : #+end_src
> 
> I put my cursor in there and C-c C-c.
> 
> What I expect: a gentle useful report about the error.

Right. But there is no error as far as babel is concerned. R has handled the 
condition. So there is nothing for babel to see/do.


> Maybe even org would move the cursor to the point of the
> error in the org buffer.  If not, at least the buffer
> "*Org-Babel Error Output*" will open and show me the error,
> something like this (see also [1]),
> 
> : Error: unexpected symbol in:
> : "x <- 1
> : y xx"
> : -UUU:@**--F2  *Org-Babel Error Output*   All L17(Compilation etu) 
> 4:13PM 0.53 Mail --$
> 

`:results output' might help you here, since it will send the terminal output 
back to babel.

If that doesn't suffice, you might use handlers provided by R to find your way 
out. But I think that will get sticky as what you create in your example is a 
parse error.  

If the source blocks are eval'ed as part of an export, you have the option of 
exporting via ox-ravel[*] and using the knitr chunk options to handle errors in 
the way you want.

> What happens instead:
> 
> - the *R* buffer is displayed.  It contains a long spammy traceback
>   that has run off of the top of the screen.  To learn more I have to
>   move the cursor into the *R* buffer and page back to the top of the
>   traceback.
> 
> On the other hand, if I set ":session none", I get much friendlier
> behavior.  The Error Output buffer opens with the simple error message
> in it as I showed above when I use this source block:
> 
> : #+begin_src R :session none
> :   x <- 1
> :   y xx z
> : #+end_src
> 

Running R in this fashion starts a fresh process which signals an error that 
babel can handle.  I see no easy way to get sessions to sends signals that 
babel can process.

> I do not want to abandon :session because my code reads in a lot of
> data to get started and I want my scripts, not my environment to be
> "real" so I am not depending on R's ability to save and reload the
> workspace at all [2] or on "Org's (clever and useful but) somewhat clunky
> and inflexible method of passing data explicitly" [3].

One of the motivating factors for creating ox-ravel[*] was to have flexible 
caching of R objects. This is provided in knitr, Sweave, and similar report 
generators. For interactive use, knit-ing a document that has caching enabled 
at the start of a session is a fast and painless way to get all the objects 
needed to modify a document.

HRH,

Chuck

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


> 
> Is there a way to get back to the "Error Output" buffer opening with a
> simple message /while/ having :session being enabled?
> 
> thank you,
>   James P.
> 
> References
> 
> [1] "Currently the only action Babel takes with STDERR is to display it in a
> pop-up buffer when code block evaluation fails" (Eric Schulte in 2012, at
> https://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg00057.html).
> 
> [2] « what will you save as your lasting record of what happened?
>   [...[ As a beginning R user, it's OK to consider your environment
>   [...]  "real."  However, in the long run, you'll be much better off
>   if you consider your R scripts as "real." » (p. 111, Wickham, H. "R
>   for data science : import, tidy, transform, visualize, and model
>   data" O'Reilly Media, 2016).  To facilitate this, I have disabled
>   'save workspace' permanently:
>   : q <- function (save = "no", status = 0, runLast = TRUE)
>   : .Internal(quit(save, status, runLast))
> 
> [3] «When I look at Org and think of "session-based" blocks, I see a
> potential big benefit in having multiple source-blocks throughout
> my document share the same session»
> (https://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00654.html,
> the only good hit for a search for "session Org-Babel Error Output" at
> https://lists.gnu.org/archive/html/emacs-orgmode/ as of
> [2021-08-15 Sun]).
> 
> 
> -- 
> James E. Powell, MS
> Pronouns: he/him/his
> Applied Physics PhD Candidate
> Department of Physics
> Portland State University
> Home page: http://web.pdx.edu/~powellj
> Office: SRTC 409B Phone: +1-503-725-8515
> 
> 
> 



Re: ob-R: Error about longer than max-lines even with :result silent

2021-08-15 Thread Berry, Charles


> On Aug 15, 2021, at 6:19 AM, Yasushi SHOJI  wrote:
> 
> Hello,
> 
> It seems like the following ECM cause an error:
> Error (org-babel): Error reading results: (user-error "Region is
> longer than ‘org-table-convert-region-max-lines’ (999) lines; not
> converting")
> 
> I assumed that with ":results silent" it shouldn't warn or error about
> the output.  Is it expected or a bug?
> 

This is expected per the `org-babel-insert-result' docstring.

However, the documentation does not mention that `:results none' is an option.  
Is that what you want?

HTH,
Chuck



Re: bug: Error handling in source blocks.

2021-08-10 Thread Berry, Charles



> On Aug 9, 2021, at 9:13 PM, James Powell  wrote:
> 
>  Error handling is important and hard to get right.  Me, I prefer to
>   treat every warning as an error (-Werror in gcc, "options(warn=2)" in
>   R, etc).  I want the system to grind to a halt at the least sign of
>   trouble.

If the effect of an error is to return no result (as in your example), you can 
use a :post header-arg to check for a nil value in `*this*' and issue a 
user-error. 

Example:

#+name: check-res
#+begin_src emacs-lisp
(or *this* (error "nil result")) 
#+end_src


#+begin_src R :exports both :post check-res()
  x <- f838293483$x8483848
#+end_src


See (info "(org) Results of Evaluation") and scroll to `post-processing' for 
details on the :post header.

The user-error halts export.

HTH,
Chuck






Re: Number format for table results outut from R data.frame/tibble

2021-08-06 Thread Berry, Charles
John,

> On Aug 6, 2021, at 8:38 AM, John Hendy  wrote:
> 
> Greetings,
> 
> I'm wondering how to align the results from the R buffer (which I
> like) vs. the results printed by Org-mode for table results. Here's a
> toy example:
> 

`tbl_df' objects come with their own print/show method. And it does things like 
add color and text formats. This is nice in a terminal, but not when you want 
to display them in org.

Turning off the color might be enough to give you a usable result:

#+begin_src R :session foo :results output drawer
library(tibble)
options( cli.num_colors=1 )
tmp <- tibble(x=1:5, y=x/pi)
tmp
#+end_src

#+RESULTS:
:results:

# A tibble: 5 x 2
  x y
   
1 1   0.3
2 2   0.6
3 3   1. 
4 4   1. 
5 5   2.
:end:


If this is not close to what you need, I suggest writing your own formatting 
function. If you have limited emacs-lisp skill, I suggest doing this in R.

HTH,

Chuck



Re: setting export options in headline properties

2021-07-21 Thread Berry, Charles
Matt,

Check (info "(org) Export Settings")

and especially, the para near bottom:

When exporting sub-trees, special node properties can override the
above keywords.  These properties have an ‘EXPORT_’ prefix.  For
example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific
sub-tree.  Except for ‘SETUPFILE’, all other keywords listed above have
an ‘EXPORT_’ equivalent.

HTH,

Chuck

> On Jul 21, 2021, at 11:52 AM, Matt Price  wrote:
> 
> Hi,
> 
> I'm not sure if I'm reading the documentation properly, but my understnading 
> is that I ought to be able to set export options as subtree properties, and 
> that if I do so, they should be picked up by export engines when exporting 
> subtrees.  However, that doesn't see to be happening for me, and from what I 
> can tell, `org-export-get-environment` is not overriding global values when 
> passed the `subtreep` parameter.
> 
> I tried the following with emacs -Q , which seems to confirm my issue. Is 
> this the expected behaviour, and if so, is there some other way for me to set 
> subtree-level export options?
> 
> --
> ** subtree
> :PROPERTIES:
> :SUBTITLE: testing
> :REVEAL_TITLE_SLIDE: nil
> :HTML_CONTAINER: section
> :END:
> 
> 
> #+begin_src emacs-lisp 
> (let ((info (org-export-get-environment 'html t)))
>   (string-join `(,(plist-get info :subtitle) ,(plist-get info 
> :html-container)) "\n")
>   )
> #+end_src
> 
> #+RESULTS:
> : 
> : div
> --
> 
> thanks as always!



Re: [PATCH] ob-R output file with graphics parameter

2021-07-10 Thread Berry, Charles
Jack,

I will be going offline for a week or so, so I will have to defer more 
discussion.

I know that `silent' silences an unwanted file link. 

And there are a few other ways to do this.  

So, if it is determined to proceed, adding an implicit `file' will not prohibit 
uses in which it was not actually wanted.

Best,
Chuck

> On Jul 10, 2021, at 2:00 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> If you modify the ECM to change `:exports results' to `:exports
>> none' and clean older fig[12].png's from the directory, the export
>> fails.
> 
> Thanks for this example. I had mistakenly thought that code blocks
> with ":exports none" would be evaluated for side effects, but you are
> right, these blocks are skipped altogether during export.
> 
> Instead, I think this use case could be handled by the ":results silent"
> header. Blocks with that header are evaluated during export, but the
> result is not inserted into the org buffer or the exported document. It
> seems like a more general way to evaluate code blocks for side effects
> only.
> 
> To test this out, you could replace the header arguments in your
> example with:
> 
> ":exports results :results graphics file silent :file fig1.png"
> 
>> So if everyone else is determined to make this change I can live
>> with it.
> 
> I do hope someone submits an RFC, so we can discuss this more
> concretely. I still think it would be nice if we could go back to just
> ":results graphics" to insert a figure. Unfortunately, I'm not currently
> able to propose the patch, as I'm still in limbo w.r.t. my employer
> agreement.





Re: A requires/provides approach to linking source code blocks

2021-07-09 Thread Berry, Charles
Tim,

> On Jul 8, 2021, at 12:32 PM, Tim Cross  wrote:
> 
> My concern here is with the additional complexity. This is already a
> somewhat complex aspect of org mode and the behaviour you describe can
> effectively be done using noweb, although as you say, not as
> declarative in style.


This (and the rest of what you said) is very well taken.

I share your concern that adding features to an already rich feature suite will 
make babel very difficult to penetrate.

Best,
Chuck

p.s. Extracting code from src blocks need not depend on `org-babel-tangle' and 
friends. Custom exporters have to potential to render code using attribute keys 
and other export features.  And such exporters have the virtue of not adding 
complexity to the org code base.



Re: [PATCH] ob-R output file with graphics parameter

2021-07-06 Thread Berry, Charles



> On Jul 6, 2021, at 12:20 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for 
>> each `y' depending on your setup)
> 
> I don't see the example on your last email, could you try re-attaching
> it?
> 
> Thanks,
> Jack

Mea culpa.

#+begin_src org

  ,* subfig ECM
  :PROPERTIES:
  :EXPORT_FILE_NAME: subfigures.tex
  :EXPORT_OPTIONS: toc:nil
  :EXPORT_LATEX_HEADER: \usepackage{subfig}
  :END:

  ,#+macro: subfig @@latex: 
\subfloat[$1]{\includegraphics[width=0.49\linewidth]{$2}}@@

  ,#+name: sub1
  ,#+begin_src R :exports results :results graphics :file fig1.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 1")
  ,#+end_src


  ,#+name: sub2
  ,#+begin_src R :exports results :results graphics  :file fig2.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 2")
  ,#+end_src


  ,#+begin_figure
  @@latex: {\centering@@
  {{{subfig(First,fig1)}}}
  {{{subfig(Second,fig2)}}}
  @@latex: }@@
  ,#+end_figure
#+end_src





Re: [PATCH] ob-R output file with graphics parameter

2021-07-06 Thread Berry, Charles



> On Jul 6, 2021, at 8:04 AM, Jack Kamm  wrote:
> 
> Hello again,
> 
>>> A user might like to construct a figure consisting of various subfigures 
>>> such as in a subfloat environment.
>>> 
>>> Will this be reasonably simple to accomplish if `:results graphics' (with 
>>> no `file' element) automatically inserts a link?
>>> 
>>> Currently, omitting the file element leaves the link out, which I believe 
>>> is the most direct way to approach subfloats.
>> 
>> Thanks for bringing up this use case, it hadn't occurred to me before.
> 
> Thinking about this more, it occurred to me that the ":exports code" or
> ":exports none" header should already handle this.
> 
> When that header is set, the graphics result won't be added to the latex
> document, and the user can construct the subfigure separately in latex.
> 
> Then we wouldn't need to support the use-case of ob-R creating a graphic
> but not producing a result from it...which still feels a little strange
> to me, to be honest.
> 
> Or am I missing something still?


Well, if the src blocks export nothing, the graphics results are not produced 
and no files are created. 

Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for each 
`y' depending on your setup)


1) Produces two graphics files:
   - fig1.png
   - fig2.png

2) Produces file `subfigures.pdf` with a page with one figure containing those
   subfigures rendered side-by-side.

If you modify the ECM to change `:exports results' to `:exports none' and clean 
older fig[12].png's from the  directory, the export fails.

Of course, there are workarounds to having Type=file implied by 
Format=graphics. So if everyone else is determined to make this change I can 
live with it.

Best,
Chuck


 



Re: using previous =#+results= when =:eval never=

2021-07-04 Thread Berry, Charles



> On Jul 3, 2021, at 10:19 PM, Greg Minshall  wrote:
> 
> Chuck,
> 
> thanks.  (i'm not surprised at an e-lisp suggestion from you! :)
> 
> i worry about accidental modification of the base case results during
> the chaos of development.  it occurs to me (reading through
> (org-babel-ref-resolve)) to keep my base case source blocks marked with
> [:results silent], which should prevent accidental modification. (*)
> 

This seems unnecessary. 

Be warned that the behavior of `org-babel-update-intermediate` is not intuitive 
- at least to me.  My reading of the doctstring is that the result of a named 
src block can be changed when it is non-nil. AFAICS, this never happens.  
Instead, the return value from `org-babel-ref-resolve` is copied from the named 
result.

For your ECM, after deleting the `:eval never`, if I append `+ 1` to the 
`mtcars[1:3,]` and execute then next src block, I get 

#+begin_src emacs-lisp
(compare-old-to-new "testcountsdecompose")
#+end_src

#+RESULTS:
: Comparison failed for block testcountsdecompose

and the original in-buffer value did not change.

I can remove the `+ 1` and rerun the above block and the result is `t`

HTH,

Chuck

> then, i would change [:results silent] to, e.g., [:results silentx], in
> the base case source blocks whenever i wanted to re-create those
> results.
> 
> for, e.g., inspecting the results when things differ, it would be nice
> to stay in the language of the rest of the code.  but i suspect i'll be
> able to do some e-lisp magic on the RHS of a :var, e.g., crudely
> 
> : #+begin_src R :var basecaseresults=(org-babel-read-named-result 
> "testcountsdecompose")

> 
> i'll play around with it.  (i suspect i'll be motivated to use an e-lisp
> macro, to eliminate the quotes, for example.)
> 
> again, thanks.
> 
> cheers, Greg
> 
> (*) this relies on current org-mode behavior, where
> (org-babel-read-result) will return results from a result block from a
> source block marked [:results silent].  i have no idea how likely this
> behavior is to change in the long run.





Re: using previous =#+results= when =:eval never=

2021-07-03 Thread Berry, Charles



> On Jul 3, 2021, at 9:35 AM, Greg Minshall  wrote:
> 
> hi.
> 
> i am trying to simplify adding regression test cases to a program.
> 
> to generate the base, "compared-to" results, i want to write some code
> in a source block, then evaluate it, producing the "true" value.
> 
> then, later during development, i want to check if the code that ran in
> that block gives the same results.  to do this, i preface the test check
> block with, e.g., =:var fu=bar=.  obviously, i do *not* want to
> re-create the base results; so, after producing the base case results, i
> tried marking the source block that produces the results =:eval never=.
> 
> but, doing that, using `:var fu=bar` on a test check source block, fu's
> value is nil. (*)
> 
> is there a way to convince org-mode to, in the face of =:eval never=, go
> ahead and pass the *previous* results?  or, some other idea of how to do
> this?  there will be a large number of these test cases.
> 
> cheers, Greg


Greg,

I think it would be easier to leave :eval alone and instead evaluate the src 
block using `org-babel-ref-resolve' and compare to the current value. Something 
like this is a start:


#+begin_src emacs-lisp
  (defun org-babel-read-named-result (blkname)
(save-excursion
  (org-babel-goto-named-result blkname)
  (org-babel-read-result)))
#+end_src


#+begin_src emacs-lisp
(defun compare-old-to-new (refname)
  (let ((new (org-babel-ref-resolve refname))
(old (org-babel-read-named-result refname)))
(or (equal old new)
(format "Comparison failed for block %s" refname
#+end_src

Then eval'ing `(compare-old-to-new "testcountsdecompose")` for the ECM you gave 
will give `t` if the result is the same and return a string saying which block 
failed the test.

I suppose you could loop thru `(org-babel-src-block-names)` if you want to 
check all the named blocks in a file.

HTH,

Chuck


> 
> (*) this is sort of confusing, so here's an example:
> 
> #+begin_src org
>  ,#+name: testcountsdecompose
>  ,#+begin_src R :eval never
>mtcars[1:3,]
>  ,#+end_src
> 
>  ,#+RESULTS: testcountsdecompose
>  |   21 | 6 | 160 | 110 |  3.9 |  2.62 | 16.46 | 0 | 1 | 4 | 4 |
>  |   21 | 6 | 160 | 110 |  3.9 | 2.875 | 17.02 | 0 | 1 | 4 | 4 |
>  | 22.8 | 4 | 108 |  93 | 3.85 |  2.32 | 18.61 | 1 | 1 | 4 | 1 |
> 
>  ,#+name: testcounts
>  ,#+header: :var testcountsdecompose=testcountsdecompose :results output
>  ,#+begin_src R
>str(testcountsdecompose)
>  ,#+end_src
> 
>  ,#+RESULTS: testcounts
>  :  chr "nil"
> #+end_src
> 
> whereas, if the =testcountsdecompose= source block does *not* have
> =:eval never=, my =testcountsdecompse= variable has all the rows and
> columns i was hoping for.
> 
> 





Re: [PATCH] ob-R output file with graphics parameter

2021-07-03 Thread Berry, Charles
Sorry if I have misunderstood the proposals here, but ...

A user might like to construct a figure consisting of various subfigures such 
as in a subfloat environment.

Will this be reasonably simple to accomplish if `:results graphics' (with no 
`file' element) automatically inserts a link?

Currently, omitting the file element leaves the link out, which I believe is 
the most direct way to approach subfloats.

If you deem it important to have the default behavior of `:results graphics` 
generate a link, maybe you can assure that there is a mechanism to avoid 
inserting the link when that is what the user wants.

Best,
Chuck
> On Jul 2, 2021, at 9:21 PM, Jack Kamm  wrote:
> 
> Hi Jeremie,
> 
>>> The requirement for a second file parameter was added in Org 9.3 to
>>> support the use case in this thread:
>>> 
>>> https://urldefense.com/v3/__https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/__;!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlolMfVxcA$
>>>  
>>> 
>>> But this syntax is annoyingly verbose for ob-R users, and also broke
>>> lots of ob-R examples prior to Org 9.3.
>>> 
>>> A simple fix might be to have the "graphics" flag implicitly add the
>>> "file" flag as well. But we would need to first check that this doesn't
>>> break other use cases.
>> 
>> I do agree with this solution. If the current specification works, we
>> could make it easy for ob-R user by implicitly adding a file flag. But
>> as far as I understand, the change will have to be made in ob-core.el.
> 
> Hmm, I think you're right -- this would have to be done in ob-core.el.
> 
> I think it would still make sense though, and would be beneficial beyond
> ob-R. According to [1], the "graphics" and "link" arguments don't do
> anything unless used with "file", so it would make sense for them to
> automatically add the "file" argument.
> 
> [1] 
> https://urldefense.com/v3/__https://orgmode.org/manual/Results-of-Evaluation.html*Results-of-Evaluation__;Iw!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlqSa5Lb1Q$
>  





Re: Passing a variable into an R source block.

2021-05-28 Thread Berry, Charles



> On May 28, 2021, at 8:52 AM, Roger Mason  wrote:
> 
> Hello,
> 
> I have an SQL source block that returns this:
> 
> #+RESULTS: query
> 
> 

[snip]

> I would like to pass this into R for further processing.  At the moment
> I have this:
> 
> #+begin_src R :session :colnames yes :var data=query
>  r <- data.frame($data)

[snip]

data.frame($data) is not valid R syntax. If you are new to R doing some 
tutorials will help.

I suggest you use C-c C-v C-v (org-babel-expand-src-block) to see what the R 
code is and debug the result given in the the *Org Babel Preview...* buffer.

HTH,
Chuck






Re: when executing a src block with latex construct, display problem because of +

2021-05-15 Thread Berry, Charles
Uwe,

You used `:exports code :eval never-export' (from an earlier posting). 

I think you want `:exports both :eval never-export' to keep babel from removing 
the results.

HTH,
Chuck

> On May 15, 2021, at 1:18 PM, Uwe Brauer  wrote:
> 
> Chuck, 
>> Uwe,
>> [snip]
> 
> 
>> [screenshot deleted]
> 
>> Oh, I misunderstood.
> 
>> The result looks like latex. So why not use `:results output latex' ?
> 
> I tried that also, then however the result is 
> #+RESULTS:
> #+begin_export latex
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.608696 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.391304 \\ 
> \end{align*}
> #+end_export
> 
> That is ok for displaying, but if I now want also to export this org
> file to latex, the align construct is not exported, sigh. 
> 
> As the great philosopher M. Jagger said:
> 
> «You Can't Always Get What You Want»



Re: when executing a src block with latex construct, display problem because of +

2021-05-15 Thread Berry, Charles
Uwe,

[snip]

> On May 15, 2021, at 11:10 AM, Uwe Brauer  wrote:
> 
> Thanks, it did not help. To make this clear the problem occurs in the
> result block, not in the source block. 
> 
> 
> 
> That is exported to 
> #+RESULTS:
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.000139982 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.99986 \\ 
> \end{align*}
> 
> 
> I attach a screenshot just in case
> 
> Uwe 

[screenshot deleted]

Oh, I misunderstood.

The result looks like latex. So why not use `:results output latex' ?

HTH,
Chuck 






Re: when executing a src block with latex construct, display problem because of +

2021-05-15 Thread Berry, Charles
Uwe,

> On May 15, 2021, at 6:31 AM, Uwe Brauer  wrote:
> 
> 
> Hi 
> 
> I have the following src block
> 
> #+begin_src matlab :results output raw :exports code  :eval never-export
> addpath /home/oub/ALLES/HGs/Matlab-init/Statistic
> sens=0.7;
> spec=0.95;
> aspec=1-spec;
> prob=0.1;
> sal=1-prob;
> [bp,bpinv,bn,bninv]=mibayes(sens,spec,prob);
> disp('\begin{align*}')
> disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
> fprintf('P(\\text{No-Covid19}) &= 1- P(\\text{Covid19}) = 1-%g=%g 
> \n',prob,sal)
> fprintf('P(\\text{+}|\\text{No-Covid19}) &= 1-
> P(\\text{-}|\\text{No-Covid19}) = 1-%g=%g  \n',spec,aspec)
> fprintf('&=\\frac{%g \\cdot %g}{%g\\cdot%g + (1-%g)\\cdot %g} 
> \n',spec,prob,spec,prob,spec,sal)
> fprintf('P(\\text{Covid19}|-)&=%g  \n', bp);
> fprintf('P(\\text{No-Covid19}|+)&=1-P(\\text{Covid19}|+)=%g  \n', bpinv);
> disp('\end{align*}')
> #+end_src
> 
> That is exported to 
> #+RESULTS:
> \begin{align*}
> P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
> P(\text{No-Covid19}) &= 1- P(\text{Covid19}) = 1-0.1=0.9\\ 
> P(\text{+}|\text{No-Covid19}) &= 1-P(\text{-}|\text{No-Covid19}) = 
> 1-0.95=0.05 \\ 
> &=\frac{0.95 \cdot 0.1}{0.95\cdot0.1 + (1-0.95)\cdot 0.9}\\ 
> P(\text{Covid19}|-)&=0.000139982 \\ 
> P(\text{No-Covid19}|+)&=1-P(\text{Covid19}|+)=0.99986 \\ 
> \end{align*}
> 
> Now in my org mode file, the lines between the +
> 
> \text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\
>  
> 
> Get a overstrike.
> 
> How can I avoid that?


Customize `org-src-lang-modes' adding ` ("matlab" . octave)'.

HTH,

Chuck





Re: displaying equations with ob-latex

2021-05-06 Thread Berry, Charles



> On May 6, 2021, at 7:39 PM, michael-franz...@gmx.com wrote:
> 
> Ok, I got some progress, I did "C-C C-x C-l" and got the equation.
> 

Great!


> The equation in extremely small though.
> 


Try customizing `org-format-latex-options'. The :scale element controls size. I 
tried 2.0 and it seems like a good value for my screen.

Best,

Chuck

>> Sent: Friday, May 07, 2021 at 1:36 PM
>> From: "Berry, Charles" 
>> To: "michael-franz...@gmx.com" 
>> Cc: "Help Emacs Orgmode" 
>> Subject: Re: displaying equations with ob-latex
>> 
>> 
>> 
>>> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
>>> 
>>> After I do "C-c C-c", I just get a message saying "Code block evaluation 
>>> complete."
>>> 
>> 
>> 
>> Are you doing this in a buffer that has ONLY the text between the `cut here' 
>> lines and exactly that?
>> 
>> If not, please try it in such a buffer.
>> 
>> It may help to copy and paste as typos in header names or values can be 
>> unnoticed and drastically alter behavior. If your mail client reformats 
>> text, maybe try copy and paste from the mail list archive.
>> 
>> Also, check with point in the src block using C-c C-v C-i that the header 
>> args got processed properly. You should see lines like these in the *Help* 
>> buffer:
>> 
>> ::exportsnone
>> 
>> ::resultsdrawer replace
>> 
>> 
>> If you did it in such a buffer and the buffer is unaltered but still 
>> displays the message, I have to admit that I cannot tell from here what the 
>> problem might be.
>> 
>> On my setup, things behave just as outlined.
>> 
>> When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste 
>> the text to *scratch* and delete the lisp comment at the top, then M-x 
>> org-mode RET, then C-c C-c with point in the src block, answer 'y e s RET' 
>> to the query, I get the equation displayed in the results drawer. And the 
>> export goes OK.
>> 
>> I am using org-version 9.4.5.
>> 
>> HTH,
>> 
>> Chuck
>> 
>> 
>> 





Re: displaying equations with ob-latex

2021-05-06 Thread Berry, Charles



> On May 6, 2021, at 4:20 PM, michael-franz...@gmx.com wrote:
> 
> After I do "C-c C-c", I just get a message saying "Code block evaluation 
> complete."
> 


Are you doing this in a buffer that has ONLY the text between the `cut here' 
lines and exactly that?

If not, please try it in such a buffer.

It may help to copy and paste as typos in header names or values can be 
unnoticed and drastically alter behavior. If your mail client reformats text, 
maybe try copy and paste from the mail list archive.

Also, check with point in the src block using C-c C-v C-i that the header args 
got processed properly. You should see lines like these in the *Help* buffer:

:   :exportsnone

:   :resultsdrawer replace


If you did it in such a buffer and the buffer is unaltered but still displays 
the message, I have to admit that I cannot tell from here what the problem 
might be.

On my setup, things behave just as outlined.

When I start emacs with -q, then M-S-; (require 'ob-latex) RET, then paste the 
text to *scratch* and delete the lisp comment at the top, then M-x org-mode 
RET, then C-c C-c with point in the src block, answer 'y e s RET' to the query, 
I get the equation displayed in the results drawer. And the export goes OK.

I am using org-version 9.4.5.

HTH,

Chuck





Re: displaying equations with ob-latex

2021-05-06 Thread Berry, Charles



> On May 6, 2021, at 3:08 PM, michael-franz...@gmx.com wrote:
> 
> Did you manage to get the equations displayed, I have tried again and could 
> not do
> it.  It might be beneficial to give more details and some more examples on 
> what to do.
> 

Yes, the one equation was displayed as a preview. 

Maybe I was not clear in my directions so try this bit:

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

1. Copy the text between the `cut here' lines to its own org buffer.
2. Place cursor in the eqn1 src block.
3. Type ~C-c C-c~ and respond to any prompt about evaluating with ~y~.
4. An eqn1 results block should appear with a :results: drawer
   containing an equation in it.
5. Type ~C-c C-x C-l~.
6. The equation should be previewed in the :results: drawer.
7. Export to LaTeX Buffer with ~C-c C-e C-b l L y~ 
8. Only an enumerate environment and the equation should appear in the
   LaTeX buffer.

#+name: eqn1
#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
#+end_src

#+call: eqn1() :results latex

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




> Can I export on a window that is to right window of the code window?

IIUC, the question is 

:  when I export (as in item 5 in the list above), will the LaTeX buffer
:  open in a window to the right of the one containing the org buffer?

This is what happens in my setup when I have the org buffer displayed in a 
frame with just one window.

But how windows are displayed depends on many factors. See (info "(emacs) 
Windows") for some of the details. So you may need to customize or resize your 
frame to get the same behavior.


>  I can one use plain
> tex commands.  Texinfo mainly supports plain tex, org mode in basically 
> latex, so the
> two programs do not currently work well together.
> 

Um, I don't see how this gets to the original question.

> Texinfo has the good feature to show equations (but only for plain tex) 
> whereas org
> is good with latex (but not very adept at displaying the output in an emacs 
> window).

There are probably a lot of opinions in the org community about how well org 
handles previewing output. For me it works well. YMMV.

HTH,

Chuck



Re: displaying equations with ob-latex

2021-05-06 Thread Berry, Charles



> On May 6, 2021, at 12:50 AM, michael-franz...@gmx.com wrote:
> 
> 
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".

Right. This is because `:results latex replace' is the default for latex src 
blocks and the leads to wrapping everything in a latex export block. 

The context inside that block is `export-block' - i.e. it is not a 
`greater-element' and cannot contain other elements.  AFAIK, there is not 
previewer for export blocks - latex or otherwise.

The context for an equation inside a greater-element is latex-fragment. And 
those can be rendered via `org-latex-preview'.

If you want to render equations for previewing, you could put them into a 
drawer that is not repeated in the export.

To make this work, you probably want something like this

#+begin_src org

  ,#+name: eqn1
  ,#+begin_src latex :exports none :results drawer 
  \(y = x\beta + \epsilon\)
  ,#+end_src

 
  Here is the equation for export:

  ,#+call: eqn1() :results latex

#+end_src

Evaluating the latex src block (C-c C-c) will create a `results' drawer line 
this:

#+RESULTS: eqn1
:results:
\(y = x\beta + \epsilon\)
:end:

but the `:exports none' will strip that out on export. The call line will 
create this on export:

#+RESULTS:
#+begin_export latex
\(y = x\beta + \epsilon\)
#+end_export


HTH,

Chuck






Re: Is it possible to #+include: src blocks and tangle them too?

2021-04-16 Thread Berry, Charles
Hi Greg,

> On Apr 16, 2021, at 8:27 AM, Greg Minshall  wrote:
> 
> Rama,
> 
> one other comment/suggestion.
> 
>> I haven’t been able to fully work with Donald Knuth’s suggestion of
>> writing a Literate Program directly in a tool like orgmode/noweb since
>> it is a nuisance to keep having to type C-c ' to go into the editing
>> mode of the language concerned.
> 
> while i have not much experience with it, you might look at the emacs
> packages polymode, poly-org, and poly-whatever-other-languages-you-use.
> it seems as if they might give you [C-c ']-like behavior when editing
> source blocks in line in an org mode buffer.
> 
> (others who use polymode: does this make sense?)


I have tried it a few times, but not had satisfactory results. 

I use mostly R src blocks, so I want to have ESS like functionality. And I 
really like to be able to execute src blocks with 
`org-babel-execute-src-block'. 

Unfortunately, it seems like polymode gets into conflicts with org mode from 
time to time. My memory is a bit dim on exactly the issues, but I think there 
were freezes. Maybe turning off all the stops and whistles in org mode (like 
fontification) would solve this, but I never gave it a go. 

Having said that, I will say it is easy enough to install and try out. And 
perhaps your mileage will vary.

Best,
Chuck



Re: [PATCH] Wrap LaTeX snippets in $$ with markdown export

2021-03-31 Thread Berry, Charles



> On Mar 31, 2021, at 9:41 AM, Timothy  wrote:
> 
> I anticipate that this change may be somewhat contentions because ox-md
> explicitly follows only the original Markdown spec from 2003, however
> I've thought this over and come to the conclusion that this change is
> still in keeping with that, and beneficial.


Will this handle LaTeX macros[1] gracefully and other things intended as raw 
LaTeX?

Best,
Chuck

[1] https://pandoc.org/MANUAL.html#latex-macros



Re: org-in-org

2021-03-08 Thread Berry, Charles
Greg,

> On Mar 7, 2021, at 11:44 PM, Greg Minshall  wrote:
> 
> i guess when i used the term "recursive execute function" (i tend to
> confuse "execute" and "export"), i was thinking of something like: when
> i export an org file, and it runs into an org-in-org block to export,
> then your code runs on that block.  the recursive part is that, when
> your code is runninng on the org-in-org block, and runs into an
> "org-in-org-in-org" block (that is also marked to export), it runs on
> *that*.  ad, but not normally infinitum.

I admit to being baffled by this.

If you have nested org src blocks and you recursively enter each org block 
using `org-edit-special' and execute the src blocks other than org lang, then 
exit with `org-edit-src-exit', when you complete this the org buffer will have 
nested src blocks and results with one or more comma escapes prepended to lines 
that start with `#+` or `*`. 

When you export this, you end up with a document that has the comma escapes 
reduced by one in those nested blocks. The appearance of these is not 
altogether pleasing to my eye.

Have you tried creating a document with nested org src blocks and stepping 
through the recursion to be sure it is something you want and really need?

If you have a particular use case, maybe it can be handled in a one-off manner.

Best,
Chuck



Re: org-in-org

2021-03-07 Thread Berry, Charles



> On Mar 7, 2021, at 8:14 AM, Greg Minshall  wrote:
> 
> Charles,
> 
> thanks.  any thing you'd like to add to the R-via-ESS/org-mode
> repository, that would be great.
> 
> in general, afaik, the contents of org-in-org buffers export okay.  at
> least plain ones.  would could like to have the embedded code blocks go
> through some pretty-printer, but currently i don't see that as an issue.
> 
> as i mentioned to Jeremie, an issue is getting the org-in-org block to
> do its export.  i don't know if creating a recursive "execute" function
> for org source blocks -- which would cause them (modulo :eval, :exports,
> etc.) to evaluate their source blocks -- might be useful.
> 

Sorry, I do not know what a  `recursive "execute" function' would be/do in this 
context.

---

You said to Jeremie:
 
"during export of the *outer* org document, it could cause
the inner org block(s) to be executed and their results revealed."

AFAICS, the document below does exactly that upon export and can be exported 
using a command line idiom with proper attention to init-file issues (and let 
binding `org-confirm-babel-evaluate' to nil if you want to run in batch mode). 

As an example, html export will create a document that displays a ` block with the R src block named `readdata-code' and 
the `#+RESULTS: readdata-code' block in it. 

--8<---cut here---start->8---
#+begin_src emacs-lisp :exports results :results none
  (org-babel-map-executables nil 
(let ((org-confirm-babel-evaluate nil))
  (org-edit-src-code)
  (org-babel-execute-buffer)
  (org-edit-src-exit)))
#+end_src


#+NAME: readdata-code
#+BEGIN_SRC org
  ,#+NAME: readdata-code
  ,#+BEGIN_SRC R :results output

  read.csv(text="a,b,c\n1,2,3\n4,5,6",header=T) -> mydata1

  summary(mydata1)
  ,#+END_SRC

#+END_SRC
--8<---cut here---end--->8---


If that isn't what is needed, maybe you can provide the desired output when 
exporting the above sans the emacs-lisp src block.


Best,
Chuck





Re: org-in-org

2021-02-23 Thread Berry, Charles
Greg, 

See inline

> On Feb 23, 2021, at 6:24 AM, Greg Minshall  wrote:
> 
> i have a question about org-in-org source blocks.  i volunteered to help
> in an effort to provide a tutorial of using the ESS (Emacs Speaks
> Statistics) package for R, in particular, from org mode.
> 
> i'd like to write my contribution as a .org file.  i'd like to include
> fragments of org code, including source blocks (in R).  and, i'd like to
> show various result types.  so, i'd like to be able to have the
> #+RESULTS show up in the org-in-org source block as exported inside the
> containing .org file.

I think I get your intention. You want the visual to look like it would if the 
src-edit buffer was opened in emacs as org.

> 
> and, i'd like to trigger all this from a makefile, using some emacs
> batch script to export the containing .org file into a .html or .pdf
> file.
> 
> (i *think*) what i would like to end up with is what it would like if i
> had manually opened the org-in-org source blocks (C-c‌'), then went to
> each (or, possibly, selected, i guess) source blocks inside *that*
> (org-in-org) source block, and executed each, producing a #+RESULTS
> block for each, then closed the org-in-org source block (C-c‌', again),
> and then exported the containing .org file.
> 
> is this possible?  any ideas?


I have two alternative approaches:

1) Add an export engine for "org" to ox-ravel[1]. This is a trivial 
customization of `org-ravel-engines' to add a '("org" . "engine='org'") 
element.  Then add a custom language engine[2] for rmarkdown or knitr.

The actions for the makefile would be a ravel export to generate *.Rmd, *.Rnw, 
or *.Rhtml files followed by rmarkdown::render or knitr::knit on the generated 
files.

2) Define this function:

#+begin_src emacs-lisp
  (defun org-exe-org ()
(let ((org-confirm-babel-evaluate nil))
  (org-edit-src-code)
  (org-babel-execute-buffer)
  (org-edit-src-exit)))
#+end_src

In an org buffer with one or more org src blocks containing R src blocks:

eval this

 (org-babel-map-executables nil (org-exe-org))

Then export the buffer to pdf or html.

I haven't tested this much, but for the snippet below evaluating that line and 
exporting to html produces two framed blocks with R src blocks and the results 
displayed in each:

--8<---cut here---start->8---
#+begin_src org
  ,#+begin_src R
print("abc")
  ,#+end_src
#+end_src


#+begin_src org
  ,#+begin_src R
print("def")
  ,#+end_src
#+end_src
--8<---cut here---end--->8---

I expect doing this in batch mode will not be a challenge.

For pdf output the result is rather plain. Maybe there is some minted idiom 
that would help?

HTH,
Chuck

p.s. I am an `ess-intro' member, in case it helps to move the conversation to 
there.


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

[2] https://bookdown.org/yihui/rmarkdown-cookbook/custom-engine.html 

Re: Org failing to format a link with verbatim text

2021-02-17 Thread Berry, Charles



> On Feb 17, 2021, at 4:25 PM, Okam  wrote:
> 
> 
> I have attached a minimum working example.  The bad formatting also
> occurs when just pasting the link.  In the example, Org mode highlights
> from beginning of the phrase "=verbatim text 1=" to the end of the
> phrase "=verbatim text 3=" in the verbatim font style. Part of the link
> is hidden as normal, but the text within the region of now verbatim text
> is not hidden, including some of the brackets.
> 
> I have reproduced this without loading a configuration, so it is present
> in version of Org included in the Gccemacs branch of Emacs.
> 
> Does that help?


Yes. Thank You.

Use

#+begin_src emacs-lisp 
(setq org-fontify-emphasized-text nil)
#+end_src

to fix this. Note that an emacs restart is needed. See (info "(org) Emphasis 
and Monospace").

You might complain about the wording that suggests that only exports are 
affected, but I am not sure that claiming the behavior per se is a bug will get 
much traction.

HTH,
Chuck



Re: Org failing to format a link with verbatim text

2021-02-16 Thread Berry, Charles


> On Feb 16, 2021, at 1:20 PM, Okam  wrote:
> 
> I am using the Emacs gccemacs branch with Org version "9.5-dev".
> I have noticed that when I try to insert the stored link
> 
> file:doc/loopy-doc.org::*Destructuring with =dash=
> 
> and use the heading as the link description, that Org cannot format this 
> link correctly in all circumstances, and tries to make the verbatim text 
> break out from the link.

The last para of (info "(org) External Links") says in part:

#+begin_quote
If spaces must be part of the link (for example in
‘bbdb:R.*Stallman’), or if you need to remove ambiguities about the
end of the link, enclose the link in square or angular brackets.
#+end_quote

To me, this sounds like advice not to drop external links amid normal text. 
i.e. put them in brackets instead.

HTH,

Chuck




Re: [question] lisp code in :results header arg.?

2021-02-16 Thread Berry, Charles


> On Feb 16, 2021, at 8:30 AM, Juan Manuel Macías  
> wrote:
> 
> Hi,
> 
> I'm exploring some ways to include a complex LaTeX preamble using source
> blocks. Consider this (code at the end of this message), that works fine.
> 
> My question is: In order to do it all in a single block, would there be
> any way to pass the output of the first block as an argument to a
> function, and put that function as a header arg (results)...?


[rest deleted]

I think you might do better to use noweb chunks, viz.

#+name: pre-amble
#+begin_src latex :exports none
  \usepackage{luacode}
  \usepackage{fontspec}
  \directlua
  {
  [...]
  }
  }
  \setmainfont{Linux Libertine O}
  [RawFeature={+ktest}]
#+end_src


#+begin_src latex :noweb yes :results drawer
,#+LaTeX_HEADER: <>
#+end_src


Evaluating the latter chunk (assuming `org-babel-load-languages' has (latex . 
t)) gives what I suspect you want.

Note that using a drawer allows replacement of the result.

HTH,
Chuck




Re: na=\"nil\" in ob-R.elo

2021-01-15 Thread Berry, Charles



> On Jan 14, 2021, at 3:42 PM, Brett Presnell  wrote:
> 
> 
> Probably a silly question, but in ob-R.el, what is the reason for
> setting na=\"nil\" when defining org-babel-R-write-object-command?  Is
> this an elisp compatibility thing?
> 

I don't get it either. The value corresponding to the NA becomes a string in 
emacs-lisp whether \"nil\" or \"\" is used.

So when passed to elisp via a :post header referencing an emacs-lisp src block, 
its treated as a string.   


> Regardless, I generally (always?) want na=\"\" for this, so I am finding
> all those "nil"s very annoying, and the only way that I see to defeat
> them is to redefine org-babel-R-write-object-command.
> 
> If there is no reason for the current behavior (doubtful I know) and if
> I am not missing an obvious work-around, then I would like to suggest
> changing this behavior.  Otherwise, would it be feasible to add an
> option for R code blocks (:nastring?) where one could specify the NA
> replacement string?
> 
> What do you think?  It's easy to suggest I know and certainly beyond my
> elisp coding skills at present, but I am supposing that someone more
> fluent in elisp could do this safely without too much trouble.
> 


You can use a :post header to customize outputs like this to make them more 
pleasing. Or just use your own `org-babel-R-write-object-command'.

Adding another header arg qualifies as feature creep and in this case would 
require non-trivial work to implement.

HTH,

Chuck



Re: did behaviour of RET change again?

2020-12-18 Thread Berry, Charles



> On Dec 18, 2020, at 5:06 AM, Eric S Fraga  wrote:
> 
> Just a quick heads-up:
> 
> I have just installed org from git (a few hours ago) and now it seems
> that RET no longer indents.  Is this intentional?
> 
> I know that there has been some discussion on the mailing list but I
> seem to have lost track of the decision, if any, taken.  


That was Subject: How to preserve empty headings

X-Universally-Unique-Identifier: 3B7C5634-13EF-4F54-B9A6-C3D8C4342A8D


AFAICS, the behavior discussed there is unchanged as of this moment (9.4.3 from 
git master), viz RET and C-j behave differently and honor electric-indent-mode 
in doing so.

Also, I don't see any git log entries that are suggestive since that time.
HTH,

Chuck


[snip]



Re: How to preserve empty headings

2020-11-30 Thread Berry, Charles



> On Nov 30, 2020, at 11:25 AM, Diego Zamboni  wrote:
> 
> What are RET and C-j bound to?
> 
> In my setup, RET is bound to =org-return=, which does not delete spaces, but 
> C-j is bound to =org-return-and-maybe-indent=, which does. So I have the 
> opposite behavior as yours.
> 


Probably you have `electric-indent-mode' set to nil.

C-j is org-return-and-maybe-indent.

RET is org-return.

If I read the docstrings correctly, org-return (thru org--newline) and 
org-return-and-indent-maybe both trefer to electric-indent-mode, but in 
opposite manner (nil vs. t).

Chuck

[rest deleted]



Re: How to preserve empty headings

2020-11-30 Thread Berry, Charles


> On Nov 30, 2020, at 9:21 AM, Titus von der Malsburg  
> wrote:
> 
> 
> When I start a new line with '* ' followed by RET, the space is automatically 
> deleted and I’m left with a line that just has the asterisk (i.e. not a 
> headline).
> 
> Unfortunately there are use cases where empty headlines make sense and they 
> occur often in my work.  One example is Beamer slides where each headline at 
> some level produces a slide.  If the user needs a slide without title 
> (common, e.g., for a large images that fill the slide), an empty headline is 
> needed.
> 
> Is there a way to teach Org to leave the empty headline intact?
> 
> I may be old-fashioned but when I type '* ', I do it for a reason and I wish 
> that my text editor respects that. :)
> 


Instead of `* SPACE RET', try `* SPACE C-j'.

This works for me and leaves a blank heading intact through export.

HTH,

Chuck

Re: Bring up a screen giving option to open a series of orgmode files

2020-11-22 Thread Berry, Charles



> On Nov 22, 2020, at 11:03 AM, Gerardo Moro  wrote:
> 
> 
> M-x find-dired RET Documents/Org/ RET -iname "*.org" RET
> 
> Once I press "RET", what does -iname mean? I am new in Emacs. You mean, this 
> is just using find-dired to browse the org files?
> 


See (info "(emacs) Dired and Find")

and find-dired's help string (i.e. C-h f find-dired RET)

the `-iname "*.org"' bit is used as ARG for which pursuing the man page for 
`find' is helpful.

HTH,

Chuck



Re: Bring up a screen giving option to open a series of orgmode files

2020-11-22 Thread Berry, Charles



> On Nov 22, 2020, at 2:09 AM, Jean Louis  wrote:
> 
> * Gerardo Moro  [2020-11-22 13:02]:
>> Basically that :)
>> I'm looking for some setup that allows me to open a menu with a list of
>> files and shortcut access keys to open them.
>> 
>> Probably somebody has done this before.
> 
> Let me invent something for you:
> 
> find Documents/Org/ -type f -iname "*.org" -exec echo " * [[file:`realpath 
> {}`][{}]]" > meta-org.org \;
> 
> Instead of "Documents/Org/" you should put there your own top
> directory where you keep Org files.
> 
> Then open meta-org.org
> 

Nice.

Or for a one-off solution:

M-x find-dired RET Documents/Org/ RET -iname "*.org" RET

And use the dired buffer to navigate.

HTH,

Chuck



Re: Using a code block as input to another code block

2020-11-22 Thread Berry, Charles
Inline.

> On Nov 21, 2020, at 2:30 PM, Magnus Therning  wrote:
> 
> I know I can use an example block (literal example) as input to a code
> block, but I haven't found a way to fontify examples. Since my input is
> code (JSON, and various programming languages) I would really like to
> have that, as well as the language's mode when editing by using
> ~org-edit-source-code~.
> 
> A code block gives me fontification, but I haven't found a way to pass a
> code block as is to another code block.
> 
> For instance, something like this:
> 
> #+name: code-input
> #+begin_src C
> #include 
> #+end_src
> 
> #+begin_src bash :var input=input :results verbatim
> cat < ${input}
> EOF
> #+end_src


Sounds like you want the :noweb header and code chunks, viz.
 
#+begin_src bash :noweb yes :results verbatim
cat <>
EOF
#+end_src

HTH,

Chuck

[deleted]




Re: How to wrap Org code generated by a source block?

2020-11-10 Thread Berry, Charles



> On Nov 10, 2020, at 10:10 AM, Diego Zamboni  wrote:
> 
> I tried also with =:wrap src org=, but then upon export it's exported 
> literally as Org src code, instead of interpreted as such. The drawer was 
> exactly what I needed, and allows reevaluation of the block, replacing all 
> the results correctly.
> 

If you have loaded `ob-org.el', this is the moral equivalent to drawer:

#+header:  :wrap "src org :exports results :results replace"

But it is so awkward, I would not use it.

HTH,

Chuck





Re: How to wrap Org code generated by a source block?

2020-11-10 Thread Berry, Charles



> On Nov 10, 2020, at 6:13 AM, Diego Zamboni  wrote:
> 
> I want to generate some parts of my document programmatically from an 
> emacs-lisp src block - i.e. the code produces Org markup which I want to then 
> export. Is there a way to wrap the #+RESULTS block in an environment that 
> still gets evaluated as Org text (e.g. when exporting)?
> 
> 


Try `:results drawer'

You can also do fancy stuff using `:wrap "src ..."' where `...' is a language 
and additional header args. One language choice is `org', but I don't think 
this approach is what you need.

HTH,
Chuck



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-29 Thread Berry, Charles
Just on a whim, I changed `org-babel-exp-results' by deleting


  (let (org-confirm-babel-evaluate-NOT)

and the matching right parenthesis.

Now I get a single prompt to confirm evaluation using Ruiyang's ECM.

HTH,

Chuck
> On Oct 28, 2020, at 8:16 PM, Kyle Meyer  wrote:
> 
> 吴锐扬 writes:
> 
>> The author explained his motivation for the commit in the mailing list 
>> before it got applied:
>> 
>>> That's because lob calls get wrapped internally in an anonymous
>>> emacs-lisp source block that then feeds through the result from the
>>> actual call as elisp.  The attached patch should suppress the
>>> confirmation for the wrapper call.  To the best of my knowledge nothing
>>> dangerous can happen with that evaluation and all confirmations for the
>>> call stack down from there have already taken place according to the
>>> users' setup.
> 
> Just for reference: it looks like that's
> 
>  
> https://urldefense.com/v3/__https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid__;!!LLK065n_VXAQ!29k-PVwb9XnRUW2w0NBea_sA5uaG3P1Ck0lJ_EyddjelOaIrJGxmvvR28RAyZpjHiQ$
>  
> 
>> If I understand correctly, executing a lob call would trigger two user
>> confirmations in the past, and this commit was meant to suppress one
>> of the two confirmations. (I may be wrong since I am a fairly new user
>> of org mode.)
> 
> Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
> (Babel: avoid superfluous confirmation for internal wrapper,
> 2013-04-10), there are two queries.  On that commit, there is one.
> 
>> Now there is no confirmation at all. IMHO, there should be exactly
>> one confirmation ideally.
> 
> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
> 
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.



Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-28 Thread Berry, Charles
FWIW, it doesn't seem like an accident. You might ping the author of this 
commit:

$ git log -S "(let (org-confirm-babel-evaluate)"
commit 56bf3d789146fcd3c9f82d875de28c394fe593a0
Author: Achim Gratz 
Date:   Wed Apr 10 20:28:31 2013 +0200

Babel: avoid superfluous confirmation for internal wrapper

* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.

* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation
  of the emacs-lisp wrapper execution around a lob call.



HTH,

Chuck

> On Oct 28, 2020, at 4:32 AM, Eric S Fraga  wrote:
> 
> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote:
>> I have org-confirm-babel-evaluate set to t by default. With this, I
>> expect to be queried with the execution of every code block or lob
>> call. However, this does not happen when exporting lob calls (to latex
>> for example). Here is an example:
> 
> Confirmed with fairly recent org from git with
> org-confirm-babel-evaluate set to t.  Does seem a little strange.  It
> doesn't bother me much as I don't export org files that I haven't
> created myself but it does appear to be a hole.
> 
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
> 
> 



Re: Bug: Math mode doesn't work if followed by a dash [9.4 (nil @ /home/gutin/.emacs.d/.local/straight/build/org-mode/)]

2020-09-29 Thread Berry, Charles
See below.

> On Sep 29, 2020, at 11:53 AM, Richard Lawrence  wrote:
> 
> "Berry, Charles"  writes:
> 
>> The case Gutin describes conforms to the documentation, viz. `$x\beta$-` 
>> should produce math mode LaTeX as I read the next paragraph. 
>> 
>> From (info "(org) LaTeX fragments"):
>> 
>>   • Text within the usual LaTeX math delimiters.  To avoid conflicts
>> with currency specifications, single ‘$’ characters are only
>> recognized as math delimiters if the enclosed text contains at most
>> two line breaks, is directly attached to the ‘$’ characters with no
>> whitespace in between, and if the closing ‘$’ is followed by
>> whitespace, punctuation or a dash.
> 
> Hmm, good point.
> 
> It looks to me like the relevant function is
> org-element-latex-fragment-parser, and the code for that hasn't changed
> much in several years (last change was 2017). (Also, I was wrong,
> parsing latex fragments is not done with just a regexp.) I can confirm
> that this function parses "$foo" in "$foo$ bar" as a latex fragment, but
> not in "$foo$-bar"
> 
> Not sure if the problem here is the code or the documentation. Perhaps
> the documentation should be updated to reflect the current behavior?
> 

Using 

"\\(-\\|\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|$\\)"

as the regexp for the `looking-at-p` seems to resolve this. To save you some 
eyestrain, there is "-\\|" added near the beginning right after "\\(" to match 
the trailing dash.

Per (info (elisp) "Syntax Class Table"), neither \\s. nor \\s- include the 
dash. \\s_ includes dash, but also $, so that seems like trouble. 

Caveat: I've not run `make test`, so am unsure if there is a subtle gotcha 
hidden here.

HTH,

Chuck

Re: Bug: Math mode doesn't work if followed by a dash [9.4 (nil @ /home/gutin/.emacs.d/.local/straight/build/org-mode/)]

2020-09-29 Thread Berry, Charles
See below.

> On Sep 28, 2020, at 11:42 AM, Richard Lawrence  wrote:
> 
> Hi Gutin,
> 
> gutin  writes:
> 
>> What I meant is that if you type
>> 
>>  $*$-algebra
>> 
>> and hit C-c C-x C-l, then the "$*$" doesn't get replaced with a
>> mathematical image. A similar problem happens when you export to Latex:
>> The dollar signs get escaped.
> 
> I believe this is intentional. There are too many other uses of dollar
> signs that people might want to use in Org documents that might be
> broken if Org treated them as math mode delimiters; so the regexp that
> matches math mode delimiters is deliberately limited in scope.

[rest deleted]

The case Gutin describes conforms to the documentation, viz. `$x\beta$-` should 
produce math mode LaTeX as I read the next paragraph. 

From (info "(org) LaTeX fragments"):

   • Text within the usual LaTeX math delimiters.  To avoid conflicts
 with currency specifications, single ‘$’ characters are only
 recognized as math delimiters if the enclosed text contains at most
 two line breaks, is directly attached to the ‘$’ characters with no
 whitespace in between, and if the closing ‘$’ is followed by
 whitespace, punctuation or a dash.

But the $...$ and $$...$$ seem fragile. I recall advice to avoid them in favor 
of \(...\) and \[...\].

FWIW, my sanity has been aided by using yf/org-electric-dollar[1], which 
inserts `\(\)` when I type `$` and leaves point where you need it to enter math 
mode LaTex. A dash after the closing parenthesis is no problem.

HTH,

Chuck


[1] https://orgmode.org/list/87vc913oh5@yahoo.fr/
;; from Nicolas Richard 
;; Date: Fri, 8 Mar 2013 16:23:02 +0100
;; Message-ID: <87vc913oh5@yahoo.fr>







Re: Help debugging R source code block output problem with :session

2020-09-08 Thread Berry, Charles
Jack,

Maybe I am confused here:

> On Sep 8, 2020, at 7:51 AM, Jack Kamm  wrote:
> 
> Yes, if we did that then tmp-file would have a prefix like
> "/scp:user@hostname:", and elisp would then know to read the result file
> from the remote host.
> 
> Before pasting tmp-file into R code, we should also call
> 
> (org-babel-process-file-name tmp-file 'noquote)
> 
> to remove the tramp prefix when referring to the file from R.

this is already present in `org-babel-R-evaluate-session' in the call to 
`org-babel-comint-eval-invisibly-and-wait-for-file'' just a couple of lines 
further down in the `(cl-case result-type (value ...))' branch.

The other use of `tmp-file' in that block is the one that requires the prefix, 
right?

So nothing more to fix.

??

Chuck



Re: Help debugging R source code block output problem with :session

2020-09-07 Thread Berry, Charles
Jack,

> On Sep 7, 2020, at 6:06 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> I can confirm that this works on my setup in each of the scenarios in which 
>> `default-directory' got set correctly in the session buffer.
>> 
>> At some point, my default-directory got reset to drop the tramp prefix 
>> "/scp:/user@host:" in one session after faithfully running the src block 
>> several times. I am unable to sort out why or even reproduce this.
> 
> Thanks for taking the time to test again. If you have any further
> feedback at any point, please don't hesitate.
> 


Thanks. This seems like it will help me.  

Also, I wonder if the `:results value' case can be handled in a similar manner, 
viz. 

-  (let ((tmp-file (org-babel-temp-file "R-")))
+  (let ((tmp-file (with-current-buffer session (org-babel-temp-file "R-"
   
Best,
Chuck



Re: Help debugging R source code block output problem with :session

2020-09-07 Thread Berry, Charles
Jack,

I can confirm that this works on my setup in each of the scenarios in which 
`default-directory' got set correctly in the session buffer.

At some point, my default-directory got reset to drop the tramp prefix 
"/scp:/user@host:" in one session after faithfully running the src block 
several times. I am unable to sort out why or even reproduce this.

Chuck

> On Sep 7, 2020, at 1:07 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> This does not work for my remote session.
> 
> Thanks for testing this.
> 
> The remote tests I originally tried did not cover this case -- I only
> tested the case where both org-file and session were remote, but didn't
> test the case where org-file was local and session was remote.
> 
> I've now tested this case as well, and added some fixes for it. I'm
> reattaching the patch in full.
> 
> However, this implementation does require the R session to have the
> correct default-directory -- see details below.





Re: Help debugging R source code block output problem with :session

2020-09-07 Thread Berry, Charles
Jack,

This does not work for my remote session.

I run from macOS locally and on a Linux host remotely.  I use 

M-x shell RET
R RET
M-x ess-remote RET R RET

to start the R session.

The problem is that tempfiles on the remote host are like 
"/tmp/RtmpeFHudh/file23a66d2fc1f9", but emacs tries to use 
'/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T/babel-OSXKNd/R-oNOVVB'

`org-babel-temp-file' doesn't honor remote connections AFAICS.

Maybe there is some comint or tramp idiom that would solve this, but I do not 
know what it is.

Chuck

> On Sep 7, 2020, at 1:45 AM, Jack Kamm  wrote:
> 
> I just realized my patch had an issue where it freezes if there is an
> error in the source block.
> 
> I'm attaching a second patch, to be applied on top of the first one, that 
> fixes the issue.
> 
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index b37e3965a..5ddf0ebd1 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -441,7 +441,7 @@ (defun org-babel-R-evaluate-session
> (output
>  (let* ((tmp-file (org-babel-temp-file "R-")))
>(with-temp-file tmp-file
> -  (insert (concat body "\n" org-babel-R-eoe-indicator)))
> +  (insert body))
>(with-current-buffer session
>(let* ((process (get-buffer-process (current-buffer)))
>   (string-buffer "")
> @@ -450,8 +450,9 @@ (defun org-babel-R-evaluate-session
>   (concat string-buffer text)))
>  comint-output-filter-functions)))
>  (ess-send-string
> - process (format "source('%s', print.eval=TRUE)"
> - (org-babel-process-file-name tmp-file 'noquote)))
> + process (format "tryCatch(source('%s', print.eval=TRUE), 
> finally=print(%s))"
> + (org-babel-process-file-name tmp-file 'noquote)
> + org-babel-R-eoe-indicator))
>  (while (not (string-match (regexp-quote org-babel-R-eoe-output)
>string-buffer))
>(accept-process-output process))





Re: Bug: Babel+R handles spaces wrongly in tables [9.3.6 (release_9.3.6 @ /home/cassou/.emacs.d/lib/org/lisp/)]

2020-09-06 Thread Berry, Charles



> On Sep 6, 2020, at 4:32 AM, Damien Cassou  wrote:
> 
> 
> Hi,
> 
> it seems that, if a cell within a table contains a space, the
> corresponding value passed as parameter to a R script will be
> wrong.


Not exactly. Your ECM has one column, and using both columns removes the issue.

Here is another ECM that illustrates the bug:

#+begin_src R :results output :var accounts=(identity '("A B" "C")) 
print(accounts)
#+end_src


The bug is in `org-babel-R-assign-elisp' which attempts to get the number of 
elements in each line of a table, but when the table has just one row or column 
it gets this wrong.


> Please find a very simple org file attached to this email. I
> expect the length of the variable to be 2 (which is the length of '("A
> B" "C") and not 3. Apparently, R receives this array instead: '("A B"
> "C" nil).
> 

Actually the length should be 1, i.e. a data.frame with a single column of two 
elements.

BTW, C-c C-v C-v with point in the src block will show you what R `receives'.

Unfortunately, there are other cases where the variable assignment does not 
work seamlessly for R src blocks.  There are workarounds, but they are ungainly 
- like using a src block for another language to render the table and then 
using a noweb reference to it to import the data. 

HTH,
Chuck



Re: Bug: Source blocks before first ":tangle yes" are not tangled to file [9.4 (nil @ /Users/ezchi/.emacs.d/.local/straight/build/org-mode/)]

2020-09-03 Thread Berry, Charles
I get one file, "foo.el", with both src blocks.

Chuck

> On Sep 3, 2020, at 1:31 PM, Enze Chi  wrote:
> 
> Hi Charles:
> 
> Thanks for the clear explanation. Add default ":tangle yes" does what I 
> expected. 
> 
> But when I try to tangle it to a file like this (with default ":tangle no"):
> (org-babel-tangle nil "foo.el")
> 
> I end up get 2 files:
> foo.el:
> (setq foo "hello")
> 
> test_tangle.el:
> (setq bar "world")
> 
> Should I expect only:
> foo.el:
> (setq bar "world")
> 
> 
> 
> On Fri, Sep 4, 2020 at 3:10 AM Berry, Charles  wrote:
> Not a bug. See inline.
> 
> > On Sep 3, 2020, at 12:37 AM, Enze Chi  wrote:
> > 
> > 
> > Remember to cover the basics, that is, what you expected to happen and
> > what in fact did happen.  You don't know how to make a good report?  See
> > 
> >  https://orgmode.org/manual/Feedback.html#Feedback
> > 
> > Your bug report will be posted to the Org mailing list.
> > 
> > 
> > I have a org file like this (test_tangle.org):
> > 
> > #+begin_src emacs-lisp
> >   (setq foo "hello") ;
> > #+end_src
> > 
> 
> There was no :tangle header arg specified for this block. Hence it is never 
> tangled.  I believe this is well documented in the manual.
> 
> Running `org-babel-view-src-block-info' (C-c C-v C-i) with point in the src 
> block will confirm this this by listing the header args including `:tangle no'
> 
> If you want all src blocks to be tangled, you should study
> 
> (info "(org) Using Header Arguments")
> 
> to set a system-wide or buffer wide default.
> 
> HTH,
> 
> Chuck
> 
> 
> > #+begin_src emacs-lisp :tangle yes
> >   (setq bar "world") 
> > #+end_src
> > 
> > 
> > After I run "(org-babel-tangle nil nil)"
> > 
> > I expect both of them are tangled to "test_tangle.el":
> > 
> > (setq foo "hello")
> > (setq bar "world")
> > 
> > 
> > But I only got:
> > 
> > (setq bar "world")
> > 
> > 
> > 
> > Emacs  : GNU Emacs 27.1.50 (build 1, x86_64-apple-darwin19.6.0, NS 
> > appkit-1894.60 Version 10.15.6 (Build 19G73))
> >  of 2020-08-14
> > Package: Org mode version 9.4 (nil @ 
> > /Users/ezchi/.emacs.d/.local/straight/build/org-mode/)
> > 
> > current state:
> > ==
> > (setq
> >  org-src-mode-hook '(org-src-babel-configure-edit-buffer
> > org-src-mode-configure-edit-buffer)
> >  org-link-shell-confirm-function 'yes-or-no-p
> >  org-metadown-hook '(org-babel-pop-to-session-maybe)
> >  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
> >  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
> >   [add-hook change-major-mode-hook org-show-all append local]
> >   5]
> > #[0 "\300\301\302\303\304$\207"
> >   [add-hook change-major-mode-hook org-babel-show-result-all
> >append local]
> >   5]
> > org-babel-result-hide-spec org-babel-hide-all-hashes)
> >  org-archive-hook '(org-attach-archive-delete-maybe)
> >  org-confirm-elisp-link-function 'yes-or-no-p
> >  org-agenda-before-write-hook '(org-agenda-add-entry-text)
> >  org-metaup-hook '(org-babel-load-in-session-maybe)
> >  org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
> > "\n\n(fn ENTRY)"]
> >  org-babel-pre-tangle-hook '(save-buffer)
> >  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
> >  org-babel-header-arg-expand)
> >  org-agenda-loop-over-headlines-in-active-region nil
> >  org-occur-hook '(org-first-headline-recenter)
> >  org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
> >  org-cycle-show-empty-lines
> >  org-optimize-window-after-visibility-change)
> >  org-speed-command-hook '(org-speed-command-activate
> >  org-babel-speed-command-activate)
> >  org-export-before-parsing-hook '(org-attach-expand-links)
> >  org-confirm-shell-link-function 'yes-or-no-p
> >  org-link-parameters '(("attachment" :follow org-attach-follow :complete
> > org-attach-complete-link)
> >   ("id" :follow org-id-open)
> >   ("eww" :follow org-eww-open :store org-eww-store-link)
> >   ("rmail" :follow org-rmail-open :store
> > org-rmail-store-link)
> >   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
>

Re: Bug: Source blocks before first ":tangle yes" are not tangled to file [9.4 (nil @ /Users/ezchi/.emacs.d/.local/straight/build/org-mode/)]

2020-09-03 Thread Berry, Charles
Not a bug. See inline.

> On Sep 3, 2020, at 12:37 AM, Enze Chi  wrote:
> 
> 
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
> 
>  https://orgmode.org/manual/Feedback.html#Feedback
> 
> Your bug report will be posted to the Org mailing list.
> 
> 
> I have a org file like this (test_tangle.org):
> 
> #+begin_src emacs-lisp
>   (setq foo "hello") ;
> #+end_src
> 

There was no :tangle header arg specified for this block. Hence it is never 
tangled.  I believe this is well documented in the manual.

Running `org-babel-view-src-block-info' (C-c C-v C-i) with point in the src 
block will confirm this this by listing the header args including `:tangle no'

If you want all src blocks to be tangled, you should study

(info "(org) Using Header Arguments")

to set a system-wide or buffer wide default.

HTH,

Chuck


> #+begin_src emacs-lisp :tangle yes
>   (setq bar "world") 
> #+end_src
> 
> 
> After I run "(org-babel-tangle nil nil)"
> 
> I expect both of them are tangled to "test_tangle.el":
> 
> (setq foo "hello")
> (setq bar "world")
> 
> 
> But I only got:
> 
> (setq bar "world")
> 
> 
> 
> Emacs  : GNU Emacs 27.1.50 (build 1, x86_64-apple-darwin19.6.0, NS 
> appkit-1894.60 Version 10.15.6 (Build 19G73))
>  of 2020-08-14
> Package: Org mode version 9.4 (nil @ 
> /Users/ezchi/.emacs.d/.local/straight/build/org-mode/)
> 
> current state:
> ==
> (setq
>  org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
>  org-link-shell-confirm-function 'yes-or-no-p
>  org-metadown-hook '(org-babel-pop-to-session-maybe)
>  org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>  org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>   [add-hook change-major-mode-hook org-show-all append local]
>   5]
> #[0 "\300\301\302\303\304$\207"
>   [add-hook change-major-mode-hook org-babel-show-result-all
>append local]
>   5]
> org-babel-result-hide-spec org-babel-hide-all-hashes)
>  org-archive-hook '(org-attach-archive-delete-maybe)
>  org-confirm-elisp-link-function 'yes-or-no-p
>  org-agenda-before-write-hook '(org-agenda-add-entry-text)
>  org-metaup-hook '(org-babel-load-in-session-maybe)
>  org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
> "\n\n(fn ENTRY)"]
>  org-babel-pre-tangle-hook '(save-buffer)
>  org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>  org-babel-header-arg-expand)
>  org-agenda-loop-over-headlines-in-active-region nil
>  org-occur-hook '(org-first-headline-recenter)
>  org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
>  org-cycle-show-empty-lines
>  org-optimize-window-after-visibility-change)
>  org-speed-command-hook '(org-speed-command-activate
>  org-babel-speed-command-activate)
>  org-export-before-parsing-hook '(org-attach-expand-links)
>  org-confirm-shell-link-function 'yes-or-no-p
>  org-link-parameters '(("attachment" :follow org-attach-follow :complete
> org-attach-complete-link)
>   ("id" :follow org-id-open)
>   ("eww" :follow org-eww-open :store org-eww-store-link)
>   ("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
>   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
>   ("irc" :follow org-irc-visit :store org-irc-store-link
> :export org-irc-export)
>   ("info" :follow org-info-open :export org-info-export
> :store org-info-store-link)
>   ("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
>   ("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
>   ("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
>   ("bbdb" :follow org-bbdb-open :export org-bbdb-export
> :complete org-bbdb-complete-link :store
> org-bbdb-store-link)
>   ("w3m" :store org-w3m-store-link) ("file+sys")
>   ("file+emacs") ("shell" :follow org-link--open-shell)
>   ("news" :follow
> #[514 "\301\300\302Q\"\207"
>  ["news" browse-url ":"] 6 "\n\n(fn URL ARG)"]
> )
>   ("mailto" :follow
> #[514 "\301\300\302Q\"\207"
>  ["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"]
> )
>   ("https" :follow
> #[514 "\301\300\302Q\"\207"
>  ["https" browse-url ":"] 6 "\n\n(fn URL ARG)"]
> )
>   ("http" :follow
> #[514 "\301\300\302Q\"\207"
>  ["http" browse-url ":"] 6 "\n\n(fn URL ARG)"]
> )
>   ("ftp" :follow
> #[514 "\301\300\302Q\"\207" ["ftp" browse-url ":"]
>  6 "\n\n(fn URL ARG)"]
> )
>   ("help" :follow org-link--open-help)
>   ("file" :complete org-link-complete-file)
>   ("elisp" :follow org-link--open-elisp)
>   ("doi" :follow org-link--open-doi))
>  org-link-elisp-confirm-function 'yes-or-no-p
>  )
> 





Re: Help debugging R source code block output problem with :session

2020-08-29 Thread Berry, Charles
This problem has been bugging people for years and previous attempts to solve 
it have always run up against creating more problems in the process of solving 
this one.

This workaround gives the same results with or without `:session "NEW"' and 
same as OPs first src block:

#+header: :prologue "capture.output({" :epilogue "})"
#+begin_src R :results value verbatim :session "NEW" 
print("  ")
print("one  three")
print("end")
#+end_src

If you do decide to dig into solving this, please be sure that remote sessions 
and graphical outputs are not broken.  test-ob-R.el does not cover those cases. 
 In fact, it is pretty short, so there are probably other things that could 
break without `make test' complaining.

HTH,

Chuck


> On Aug 29, 2020, at 12:24 AM, Jack Kamm  wrote:
> 
> Hi Dylan,
> 
>> The patch does fix that issue -- but it introduces a different bug 
>> for code blocks with ~:session~: the R block now only produces 
>> output from the last statement evaluated.
> 
> Of course, you're right. Good catch.
> 
> Here's another attempt. It fixes the issue by modifying the R comint
> regular expression, requiring it to match at the beginning of the line.





Re: [PATCH] Add org-md-src-block for src-block formater

2020-08-27 Thread Berry, Charles
You might want to browse the ox-ravel repository[1].

It provides a collection of exporters that support reformatting src blocks and 
inline src blocks for a variety of output formats (including markdown).

Basically, it will produce a derived backend that adds source block 
reformatting to whatever the parent backend provides.

It is aimed at R flavored exports (knitr, Rmarkdown, Sweave), but customizable. 
One can, for example, allow emacs-lisp and shell src blocks to execute during 
export, but format python, C++ and R blocks for markdown and subsequent 
processing. It is easy to apply to any markdown exporter

See ox-ravel.org for details on customization.

It has plenty of stops and whistles even without customization. Check out the 
examples, such as demos.org and markdown.org.


HTH,

Chuck  

[1] 
https://github.com/chasberry/orgmode-accessories/blob/org-9-plus/markdown.org

> On Aug 26, 2020, at 10:26 PM, Naoya Yamashita  wrote:
> 
> Hi,
> I found `ox-md` exporter drop src-block language information.
> My patch fixes the behavior; to embed src-block language information
> using markdown src block grammar.
> 
> 1. Open some buffer
> 2. Tnsert below code
> 3. Turn on `org-mode`
> 4. `C-c C-e m M` (export as markdown in temp buffer)
> 
> ## org source
> ```org
> #+begin_src python
> print(1 + 2)
> #+end_src
> 
> #+begin_src emacs-lisp
> (print "hello")
> #+end_src
> 
> #+begin_src
> something source code
> #+end_src
> ```
> 
> ## before
> ```markdown
> 
> # Table of Contents
> 
> 
> 
> print(1 + 2)
> 
> (print "hello")
> 
> something source code
> 
> ```
> 
> ## after
> ```markdown
> 
> # Table of Contents
> 
> 
> 
> ```python
> print(1 + 2)
> ```
> 
> ```emacs-lisp
> (print "hello")
> ```
> 
> ```
> something source code
> ```
> 
> ```
> <0001-Add-org-md-src-block-for-src-block-formater.patch>





Re: Can you automatically noweb include?

2020-08-07 Thread Berry, Charles
Good catch. Also it works if you put the property block at the very beginning 
of the file.

This sometimes helps:

M-x org-lint RET

which in this case reports "Incorrect contents for PROPERTIES drawer"

which is a bit cryptic IMO, but does point to any issue with the property.

HTH,

Chuck

> On Aug 7, 2020, at 2:18 PM, Thomas S. Dye  wrote:
> 
> It works here if you remove the blank line between the headline and the 
> PROPERTIES block.
> 
> William McCoy writes:
> 
>> Chuck,
>> 
>> Thanks very much for your response.  I didn't know about those options.  
>> When I
>> use C-c C-v C-i, I get the following:
>> 
>> Lang: python
>> Properties:
>>:header-argsnil
>>:header-args:python nil
>> Header Arguments:
>>:cache  no
>>:exportscode
>>:hlines no
>>:noweb  no
>>:resultsoutput replace
>>:sessionnone
>>:tangle no
>> 
>> And C-c C-v C-v, shows that the import statements in the header do not get
>> expanded into the code block.
>> 
>> So I am obviously doing something wrong.  There appear to be no typos or
>> misspellings and the org file containing the coded is exactly this:
>> 
>> * Test of prologue header
>> 
>> :PROPERTIES:
>> :header-args:python+: :prologue "import numpy as np; import os"
>> :END:
>> 
>> #+BEGIN_SRC python :results output
>> print(np.__version__)
>> #+END_SRC
>> 
>> #+RESULTS:
>> 
>> 
>> My init file has no org babel header arguments defined.
>> 
>> I am using C-c C-v C-b or C-c C-v C-s to evaluate and I get
>> 
>> "Code block produced no output." in the mini-buffer.
>> 
>> 
>> If I use C-c C-c directly on the code block itself I get:
>> 
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> NameError: name 'np' is not defined
>> 
>> Is there something else I need to do to get babel to recognize the 
>> header-args?
>> 
>> Thanks
>> 
>> 
>> On 8/7/20 12:51 PM, Berry, Charles wrote:
>>> 
>>>> On Aug 7, 2020, at 8:39 AM, William McCoy  wrote:
>>>> 
>>>> This use of :prologue appeared to me to be very useful.  But for some 
>>>> reason when I try it out it does not work for me.  I just get a message 
>>>> that the code block produced no output and that 'np' is not defined.  Just 
>>>> to check, when I put the import statements directly within my code block 
>>>> it works fine.
>>>> 
>>>> I am running:  Org mode version 9.3.7 (9.3.7-16-g521d7f-elpa
>>>> 
>>>> Any idea what I'm doing wrong?
>>>> 
>>>> 
>>> It is sometimes useful to use C-c C-v C-i to see what header args org has 
>>> detected for a source block. Misspelled words sometimes wreak havoc and 
>>> invisible characters can cause real pain.
>>> 
>>> 
>>> Also, it helps to use C-c C-v C-v to to see the expanded code block. When I 
>>> do this with Kens' ECM, I get
>>> 
>>> import numpy as np; import os
>>> print(np.__version__)
>>> 
>>> in the preview buffer.
>>> 
>>> HTH,
>>> 
>>> Chuck
>>> 
>>> 
>>>> On 8/6/20 2:12 PM, Ken Mankoff wrote:
>>>>> Actual example:
>>>>> 
>>>>> 
>>>>> * Prologue test
>>>>> :PROPERTIES:
>>>>> :header-args:python+: :prologue "import numpy as np; import os"
>>>>> :END:
>>>>> 
>>>>> #+BEGIN_SRC python :results output
>>>>> print(np.__version__)
>>>>> #+END_SRC
>>>>> 
>>>>> #+RESULTS:
>>>>> : 1.18.4
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Aug 5, 2020 at 3:03 PM Ken Mankoff  wrote:
>>>>> What about using :pre or :prologue and setting it at the header or 
>>>>> document level?
>>>>> 
>>>>> Please excuse brevity. Sent from tiny pocket computer with 
>>>>> non-haptic-feedback keyboard.
>>>>> 
>>>>> On Wed, Aug 5, 2020, 14:22 George Mauer  wrote:
>>>>> Use case:
>>>>> 
>>>>> I'm using ob-racket but this would apply just as well to a few other 
>>>>> workflows I have with python or js.
>>>>> 
>>>>> I would like to write a helper function in a src block and then 
>>>>> automatically have access to it in other src blocks further down the 
>>>>> document. I don't really want a stateful session (nor does ob-racket 
>>>>> support sessions) so I essentially want the equivalent of automatically 
>>>>> including it everywhere so I don't have to type it out all the time (and 
>>>>> have it screw up syntax coloring/indentation).
>>>>> 
>>>>> Is this currently possible? Does anyone have any ideas for how to extend 
>>>>> things so it is?
>>> 
> 
> 
> --
> Thomas S. Dye
> https://tsdye.online/tsdye





Re: Can you automatically noweb include?

2020-08-07 Thread Berry, Charles



> On Aug 7, 2020, at 8:39 AM, William McCoy  wrote:
> 
> This use of :prologue appeared to me to be very useful.  But for some reason 
> when I try it out it does not work for me.  I just get a message that the 
> code block produced no output and that 'np' is not defined.  Just to check, 
> when I put the import statements directly within my code block it works fine.
> 
> I am running:  Org mode version 9.3.7 (9.3.7-16-g521d7f-elpa
> 
> Any idea what I'm doing wrong?
> 
> 

It is sometimes useful to use C-c C-v C-i to see what header args org has 
detected for a source block. Misspelled words sometimes wreak havoc and 
invisible characters can cause real pain.


Also, it helps to use C-c C-v C-v to to see the expanded code block. When I do 
this with Kens' ECM, I get

import numpy as np; import os
print(np.__version__)

in the preview buffer.

HTH,

Chuck


> On 8/6/20 2:12 PM, Ken Mankoff wrote:
>> Actual example:
>> 
>> 
>> * Prologue test
>> :PROPERTIES:
>> :header-args:python+: :prologue "import numpy as np; import os"
>> :END:
>> 
>> #+BEGIN_SRC python :results output
>> print(np.__version__)
>> #+END_SRC
>> 
>> #+RESULTS:
>> : 1.18.4
>> 
>> 
>> 
>> 
>> On Wed, Aug 5, 2020 at 3:03 PM Ken Mankoff  wrote:
>> What about using :pre or :prologue and setting it at the header or document 
>> level?
>> 
>> Please excuse brevity. Sent from tiny pocket computer with 
>> non-haptic-feedback keyboard.
>> 
>> On Wed, Aug 5, 2020, 14:22 George Mauer  wrote:
>> Use case:
>> 
>> I'm using ob-racket but this would apply just as well to a few other 
>> workflows I have with python or js.
>> 
>> I would like to write a helper function in a src block and then 
>> automatically have access to it in other src blocks further down the 
>> document. I don't really want a stateful session (nor does ob-racket support 
>> sessions) so I essentially want the equivalent of automatically including it 
>> everywhere so I don't have to type it out all the time (and have it screw up 
>> syntax coloring/indentation).
>> 
>> Is this currently possible? Does anyone have any ideas for how to extend 
>> things so it is?
> 





Re: Macro replacement inside +attr_latex line

2020-08-06 Thread Berry, Charles



> On Aug 4, 2020, at 6:17 AM, Vikas Rawal  wrote:
> 
> Found the answer in the mailing list archives
> (https://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00234.html).
> Not allowed.
> 


But, ...

#+macro: attr_latex #+attr_latex: $1


* abc

{{{attr_latex(:width 10)}}}
[[file:abc.png]]

should get you started.

HTH,
CCB




> Vikas
> 
> On Tue, 4 Aug 2020 at 18:33, Vikas Rawal  wrote:
>> 
>> Does orgmode macro replacement not work in an +attr_latex line? I was
>> thinking of using shortcuts for some complex latex syntax.
>> 
>> Vikas
> 
> 





Re: org-sbe and code blocks in a different files

2020-07-09 Thread Berry, Charles



> On Jul 9, 2020, at 12:09 AM, Michael Welle  wrote:
> 
> Hi Douglas,
> 
> Douglas Perrin  writes:
> 
>> Hi Michael,
>> Maybe I am not understanding what you want to do but I use
>> org-babel-lob-ingest/org-sbe to execute blocks from other files on
>> start-up like this:
>> # Local Variables:
>> # eval: (org-babel-lob-ingest "Template-Loader.org")
>> # eval: (org-sbe "Init-Template") ;; the name of a block
>> in Template-Loader.org file
>> # End:
>> 
>> I assume this means that org-sbe can see the block names from the other
>> file. But I haven't tested the behavior with #call just executing elisp.
>> Doug
> thanks for bringing that up again. Your example works, of course. After
> further inspection I think that variables kill my example:
> 
> This code block comes from a file I processed with org-babel-lob-ingest.
> o-b-l-i returns the correct number of code blocks in that file and org-bab
> 
> #+name: boing
> #+begin_src elisp :var range=42
> (message "Hello, crude world: %s" range)
> #+end_src
> 
> This comes from the file where I want to use the code block:
> 
> |+|
> | <2020-02-19 Wed>--<2020-02-21 Fri> | #ERROR |
> #+TBLFM: $2='(org-sbe "boing" (range 23))
> 
> That fails. After removing the variable from the code block and from
> org-sbe it works as expected. It works as well if I copy the code block
> including the variable into the file with the table. Might be a bug or
> my own stupidity?
> 


Not stupidity. AFAICS there is no call in org-sbe to org-babel-lob-get-info, so 
the params are not updated.  I supposed this counts as a bug.

As a workaround

#+TBLFM: $2='(org-babel-ref-resolve "boing(range=23)")

should do.

HTH,

Chuck





Re: [BUG] recently commits on master branch breaks command 'org-babel-demarcate-block'

2020-05-30 Thread Berry, Charles



> On May 29, 2020, at 7:03 PM, stardiviner  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> When I have a source block (The "|" represents the point):
> 
> #+begin_src sh :eval no
> chrome --remote-debugging-port
> |
> 
> #+end_src
> 
> Then press =[C-c C-v d]=, it becomes like this:
> 
> #+begin_src sh :eval no
> chrome --remote-debugging-port
> #+end_src
> 
> #+begin_src
> sh :eval no
> 
> #+end_src
> 
> - --

Exactly. Commit 5f0a9cca3 adds a `\n' in line 1911 that should have been a 
space. 

Chuck

[snip]



Re: Tricking org-mode into using markdown conventions

2020-05-05 Thread Berry, Charles


> On May 5, 2020, at 1:46 AM, Ihor Radchenko  wrote:
> 
>> I am assuming though, from the lack of answers back, that there appears to
>> be no way to have org-mode grok markdown code blocks (triple backticks)
>> when it parses as a substitute for `#+BEGIN_SRC` ?
> 
> #+BEGIN_SRC is a part of org syntax, "```" is not.
> You will need to modify the org-mode internals to do change it.
> Depending on implementation details of org-mode, changing
> org-block-regexp and all the occurrences of "BEGIN_SRC" and "END_SRC" in
> org mode sources might achieve what you want, but there is no guarantee
> that it will not be broken in future versions of org.
> 

True. 

However, if your interest is only in exporting a document with such markup, 
there is `org-export-before-processing-hook'.

I haven't tried this but if you want to execute such src blocks, maybe polymode 
would work.

HTH,

Chuck


> Best,
> Ihor
> 
> 
> Daryl Manning  writes:
> 
>> This looks great (your elisp-fu is impressive) and definitely fulfills
>> making it look markdown-ish. Thanks! Will plug it in tonight and take it
>> for a pain.
>> 
>> I am assuming though, from the lack of answers back, that there appears to
>> be no way to have org-mode grok markdown code blocks (triple backticks)
>> when it parses as a substitute for `#+BEGIN_SRC` ?
>> 
>> Daryl.
>> 
>> 
>> On Mon, May 4, 2020 at 3:37 PM Diego Zamboni  wrote:
>> 
>>> Ihor,
>>> 
>>> Awesome, thanks for the tip. Using your code, the following config (inside
>>> the code from https://pank.eu/blog/pretty-babel-src-blocks.html) produces
>>> a display with the backticks instead of begin/end_src:
>>> 
>>>  (defun yant/str-to-glyph (str)
>>>"Transform string into glyph, displayed correctly."
>>>(let ((composition nil))
>>>  (dolist (char (string-to-list str)
>>>(nreverse (cdr composition)))
>>>(push char composition)
>>>(push '(Br . Bl) composition
>>> 
>>>  (defun rasmus/org-prettify-symbols ()
>>>(mapc (apply-partially 'add-to-list 'prettify-symbols-alist)
>>>  (cl-reduce 'append
>>> (mapcar (lambda (x) (list x (cons (upcase (car
>>> x)) (cdr x
>>> `(("#+begin_src" . ,(yant/str-to-glyph
>>> "```")) ;; ⎡ ➤  ➟ ➤ ✎
>>>   ("#+end_src"   . ,(yant/str-to-glyph
>>> "```")) ;; ⎣ ✐
>>>   ("#+header:" . ,rasmus/ob-header-symbol)
>>>   ("#+begin_quote" . ?«)
>>>   ("#+end_quote" . ?»)
>>>(turn-on-prettify-symbols-mode)
>>>(add-hook 'post-command-hook 'rasmus/org-prettify-src t t))
>>> 
>>> It looks like this in my config (the bars hide the header arguments):
>>> 
>>> [image: image.png]
>>> 
>>> --Diego
>>> 
>>> 
>>> On Mon, May 4, 2020 at 6:19 AM Ihor Radchenko  wrote:
>>> 
> I did a quick test, and it seems
> that =prettify-symbols-alist= (which is what this code uses) can only
> replace for a single character, so I was not able to make it display
> the three backticks, but there might be other techniques that can be
> used.
 
 Yes, there is another technique.
 See part of my config below:
 
 
  (defun yant/str-to-glyph (str)
"Transform string into glyph, displayed correctly."
(let ((composition nil))
  (dolist (char (string-to-list str)
(nreverse (cdr composition)))
(push char composition)
(push '(Br . Bl) composition
 
  (append pretty-symbol-patterns
`(((yant/str-to-glyph " ") org-specific ,(format
 "^\\(\\*\\{%d,%d\\}\\)\\*[^*]" (1- org-inlinetask-min-level) (1-
 org-inlinetask-max-level)) (org-mode) 1)
  ((yant/str-to-glyph "⇒⇒⇒") org-specific ,(format
 "^\\(\\*\\{%d,%d\\}\\)\\(\\*\\)[^*]" (1- org-inlinetask-min-level) (1-
 org-inlinetask-max-level)) (org-mode) 2)
  (?╭ org-specific "^[ ]*#[+]NAME" (org-mode))
  (?╭ org-specific "^[ ]*#[+]name" (org-mode))
  (?├ org-specific "[ ]*#[+]begin_src" (org-mode))
  (?├ org-specific "[ ]*#[+]BEGIN_SRC" (org-mode))
  (?╰ org-specific "[ ]*#[+]end_src" (org-mode))
  (?╰ org-specific "[ ]*#[+]END_SRC" (org-mode))
  ((yant/str-to-glyph "") org-specific ":\\(ATTACH\\):"
 (org-mode) 1)
  ((yant/str-to-glyph "☠D") org-specific "\\>>> (org-mode))
  ((yant/str-to-glyph "◴S") org-specific "\\>>> (org-mode
 
 Diego Zamboni  writes:
 
> Hi Daryl,
> 
> If it's for display purposes only, you might be able to simply use
> display substitutions for things to appear the way you want. For
> example, I use the technique described here:
> https://pank.eu/blog/pretty-babel-src-blocks.html to replace the
> begin/end_src strings with symbols. I did a 

Re: Self-sufficient Org file with customised export? :eval-when?

2020-05-01 Thread Berry, Charles



> On Apr 30, 2020, at 11:55 AM, akater  wrote:
> 

[deleted - discussion of html export]

> -
> 
> 
> If I may prematurely offer my vision: Common Lisp has special operator
> eval-when which specifies when the enclosed code is to be evaluated (or
> compiled).  Example:
> 
> (eval-when (:compile-toplevel) (defun f () ..))
> 
> specifies that function f should be defined during compilation only.
> 
> I believe it would be neat if Org-mode widely supported :eval-when
> header argument inspired by Common Lisp's eval-when.  Usage examples
> would be:
> 
> #+begin_src emacs-lisp :eval-when compile load
> ..
> #+end_src
> 

You can effectively do this by using an elisp expression for the value of an 
:eval arg like this:


#+begin_src emacs-lisp :eval (or (bound-and-true-p my-eval-flag) "no")
"done"
#+end_src

which honors the value of `my-eval-flag' if there is one.

You can also use a call to a src block. e.g. `:eval my-src-block(a=1,b=2)'

HTH,

Chuck



Re: How to add new type of block to a derived back-end?

2020-04-10 Thread Berry, Charles
Salomon, see inline comments below. 

HTH, 

Chuck

> On Apr 10, 2020, at 7:56 AM, Salomon Turgman  wrote:
> 
> Hello all,
> 
> Thanks in advance for any hints you can provide for this. I am trying to 
> create a derived back-end that handles a new type of block in org-mode. I am 
> trying to derive using the html export backend as a parent.
> 
> Currently I am solving my problem like this:
> #+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
> #+BEGIN_EXPORT html
> Simulation 1: Manual control of the tank level.
> 
> 
> 
> Some other cool stuff here.
> 
> 
> 
> var app = Main1.init({node: 
> document.getElementById("main1")});
> #+END_EXPORT
> 
> This has a few downsides:
> 1. I have to specify the caption twice since export translator does not 
> handle captions.
> 2. I have to include substantial amounts of html.
> 3. I have keep track of references to simulations manually (simulation 1, 
> simulation 2, etc)
> 4. I have to include the identifier `main1` or `Main1` in several locations 
> in the snippet.
> 
> I could solve some of this with an automated snippet insertion tool but I 
> thought that maybe I can get the export back-end to do most of the work for 
> me.
> 
> So I am trying to derive as follows (in pseudo-elisp-code):
> (require 'ox)
> (require 'ox-html)
> 
> (org-export-define-derived-backend 'textbook 'html
>   :menu-entry
>   '(?I "Export textbook section"
>((?b "To buffer" org-html-export-as-html)
>   (?I "To file" org-html-export-to-html)
>   (?o "As HTML file and open"
> (lambda (a s v b)
>   (if a (org-html-export-to-html t s v b)
>   (org-open-file (org-html-export-to-html nil s v b)))
>   :translate-alist '((simulation . org-textbook-simulation)))

>From the `org-export-define-backend' docstring:

"TRANSCODERS is an alist between object or element types and
functions handling them."

But `simulation' is not such a type. So, this will not work.

> 
> (defun org-textbook-simulation (element contents info)
>   (let* ((simnum (extract simnum value))
>   (caption (org-export-get-caption element))
>  (divid (extrac divid value))
>   (modid (convert divid into modid))
>  )
> (format "Simulation %simnum%: %Caption%.
>   
> 
> 
>   
> var app = %modid%.init({node: 
> document.getElementById(\"%divid%\")});"
>simnum caption divid modid divid)))
> 
> With the hope that I can do something like this in my .org file:
> 
> #+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
> #+BEGIN_SIMULATION main1
> Some other cool stuff here
> #+END_SIMULATION


I think an easier approach is to write a babel src-block that formats the 
inputs you need and creates a value that is your desired output. 

Use `:var' header arguments to define the inputs.
 
Use `:wrap html' to prevent the exporter from changing the output.

Subsequent calls can use the `#+CALL' idiom.

You can use any scripting language that suits you - elisp, python, shell, R, 
... --- for this purpose. 

If you are skilled in emacs-lisp you might write an `eval' macro instead of a 
src block.

> 
> Am I on the right track here? Can someone point me to an example on how to:
> 1. Keep track of the number of simulations for referencing?

Using the babel approach, you would need a `:session' with a persistent 
variable that would hold the count. You would need to initialize it in your 
document so that subsequent exports will start counting at zero.

> 2. Extract the caption properly? The above is just my guess.


IIRC, the info channel is not populated when babel runs, so you will need to 
parse the src-block and extract the `:caption' element. I think you can use a 
`:var cap=(find-caption)' idiom, where `find-caption' is a function you write 
using `org-element-context' as a starting point.

Or if the only need you have for the caption is within that src block just use 
`:var cap="".

> 3. Extract the divid value (main1)

:var divid="main1"


> 4. And finally, how to get org to recognize the new SIMULATION block so that 
> it can apply `org-textbook-simulation`? Do I need to register this type of 
> block somewhere? Or is the name of the first member of the :translate-alist 
> translation pair have some special meaning?

Don't go in that direction. Use babel or write an eval macro.

[snip]



Re: R session and plotting in x11 window

2020-04-07 Thread Berry, Charles
Matt,

I am glad you got past your roadblock.

I am puzzled by your use of `dev.set'. I have never explicitly invoked that 
function. 

FWIW, I have used R for more than 20 years and routinely write packages or 
reports that create graphics.

And I use ESS (and used its predecessor S-mode) as my principal IDE for that 
work. (Org relies on ESS for modes relating to R.) I routinely use Mac OS, but 
occasionally work with Linux and Windows.

Invoking R from the terminal window (or equivalent on Windows) and typing 
interactive commands, I get:

> dev.cur()
null device 
  1 
> plot(1:5)
> dev.cur()
quartz 
 2 
> 

Note there is no call to dev.set(). 

The quartz device (the interactive default on Mac OS) is invoked implicitly by 
plot as described by the `Details' in the help page displayed by typing 
`?device' as the R prompt"

"If no device is open, calling any high-level graphics function will cause a 
device to be opened."

If I start emacs and open an org buffer with just this src block in it:

#+begin_src R
  dev.cur()
  plot(1:5)
  dev.cur()
#+end_src

then place point in the src block and type the line in this example block

#+begin_example
C-c ' C-n RET C-n C-n
#+end_example

I end up with the same output as above in my *R* session buffer. A new graphics 
device is opened and the plot appears in it.


Best,

Chuck

> On Apr 6, 2020, at 6:26 PM, Matt Price  wrote:
> 
> 
> 
> On Sun, Apr 5, 2020 at 1:19 PM Berry, Charles  wrote:
> 
> 
> > On Apr 4, 2020, at 4:27 PM, Matt Price  wrote:
> > 
> > Does anyone know much about the difference between an R session opened by 
> > typing M-x R, and the R session opened by org-babel?
> 
> 
> Short answer: almost none.
> 
> Long answer: what `org-babel-R-initite-session' and friends do.
> :-) thanks, I should have been looking for that 
> 
> > 
> > I'm just learning R and my usual method for learning a language is to keep 
> > a kind of notebook in org with code snippets they I can execute and iterate 
> > on rapidly as I learn. This works great in R when I'm just doing math.  
> > When I am working on plots, it would be nice to have them open up quickly 
> > either in emacs or in the standard x11 window that R session opened switch 
> > M-x R opens up.  
> > 
> > I know I can set the src block headers to produ e a file, but when I'm just 
> > iterating rapidly I often switch back and forth between a data output and a 
> > graphical output, and typing/erasing those headers is clunky and slow. It 
> > would be easier to just paste the plot command into the console and have it 
> > pop open the window... But that doesn't seem to work. Anyone know if I can 
> > tweak something to make that possible?
> > 
> 
> 
> I sam really puzzled by this. Do you have an ECM that illustrates this?
> 
> Working interactively on my Mac (Quartz - X11 is the device), I routinely do 
> what you describe - usually working from the src edit buffer - and the plots 
> are displayed (and older plots are available via clover-left or some such).
> 
> If I had to guess, I'd say that you are opening an R session, but not using 
> it. If you execute a src block, but it does not have a `:session' header, a 
> new instance of R will create a plot file and then exit. If you look in the 
> default directory, you would see `Rplots.pdf' or some such.
> 
> The only other thing that comes to mind is that you opened a device that is 
> holding on to all your plots. Try `dev.cur()' in R immediately before and 
> after you create a plot and see what the result is.
> 
> This was the problem. I don't see that I'm calling dev.set() anywhere but 
> when the session initiates dev.cur() returns
> 
> null
>  1
> 
> calling dev.set(1) or dev.set(2) launches an R_x11 window and future plots 
> are displayed there.  As I say, I'm just learning R, and I don't really 
> understand how the device is set up. I also don't understand why it would be 
> set to X11 in a plain-old R session, but not in an org-babel R session. Most 
> references to "device" in ~ob-R.el~ seem to be managing file outputs, and 
> "X11". For now I don't think I'll explore  a proper solution as I'm already 
> pretty far down a rabit hole just learning R at all!  But thanks very much 
> for this workaround. 
> 
> Matt
> HTH,
> 
> Chuck





Re: tangling from multiple files

2020-04-05 Thread Berry, Charles



> On Apr 4, 2020, at 11:08 AM, David Bremner  wrote:
> 
> "Berry, Charles"  writes:
> 
>> Oops. Correction below.
>> 
>>> On Mar 18, 2020, at 7:38 PM, Berry, Charles  wrote:
>>> 
>>> 
>>> Right. It does not work directly for tangling. So also use 
>>> 
>>> #+export_file_name: b2.org
>>> 
>>> (say)
>>> 
>>> Then load ox-ob.el,
>> 
>> load ox-org.el, rather.
>> 
>>> export as C-c C-e O o (org-org-export-to-org),  visit b2.org and tangle 
>>> from there. 
> 
> I finally got around to trying this. In a broad sense it works, but
> (at least with default settings) it loses the keywords on individual
> source blocks.


I see.

It looks like you are back to `org-babel-lob-ingest'.

Maybe the issue you raised at the start of having to re-ingest after changes 
could be addressed by a function in `org-babel-pre-tangle-hook'.

HTH,

Chuck








Re: R session and plotting in x11 window

2020-04-05 Thread Berry, Charles



> On Apr 4, 2020, at 4:27 PM, Matt Price  wrote:
> 
> Does anyone know much about the difference between an R session opened by 
> typing M-x R, and the R session opened by org-babel?


Short answer: almost none.

Long answer: what `org-babel-R-initite-session' and friends do.

> 
> I'm just learning R and my usual method for learning a language is to keep a 
> kind of notebook in org with code snippets they I can execute and iterate on 
> rapidly as I learn. This works great in R when I'm just doing math.  When I 
> am working on plots, it would be nice to have them open up quickly either in 
> emacs or in the standard x11 window that R session opened switch M-x R opens 
> up.  
> 
> I know I can set the src block headers to produ e a file, but when I'm just 
> iterating rapidly I often switch back and forth between a data output and a 
> graphical output, and typing/erasing those headers is clunky and slow. It 
> would be easier to just paste the plot command into the console and have it 
> pop open the window... But that doesn't seem to work. Anyone know if I can 
> tweak something to make that possible?
> 


I sam really puzzled by this. Do you have an ECM that illustrates this?

Working interactively on my Mac (Quartz - X11 is the device), I routinely do 
what you describe - usually working from the src edit buffer - and the plots 
are displayed (and older plots are available via clover-left or some such).

If I had to guess, I'd say that you are opening an R session, but not using it. 
If you execute a src block, but it does not have a `:session' header, a new 
instance of R will create a plot file and then exit. If you look in the default 
directory, you would see `Rplots.pdf' or some such.

The only other thing that comes to mind is that you opened a device that is 
holding on to all your plots. Try `dev.cur()' in R immediately before and after 
you create a plot and see what the result is.

HTH,

Chuck





Re: rmarkdown-like production of multiple plots in org

2020-04-02 Thread Berry, Charles



> On Mar 31, 2020, at 12:23 PM, Matt Price  wrote:
> 
> I'm completely new to R.
> 
> I've started working with a project that creates plots using the ggplot 
> package -- so by default it creates grid objects, rather than writing to 
> files.  
> 
> In rmarkdown/rstudio, I can write something like this in a SOMEFILE.Rmd : 
> 
> ```
> install_github('eeholmes/CoV19')
> library(CoV19)
> getdata();
> plot4(world, 'Ontario Canada') 
> plot2(world, 'Italy') 
> plot4(states, "WA")
> ```
> 
> I sort of love how the rmarkdown package will just create all 3 of those 
> plots, save them to auto-named files, and render to HTML.

Actually, this is knitr (which rmarkdown Imports) at work.  There are options 
as to how knitr will handle multiple plots in a chunk as described in

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

(which include `fig.show="animate"' to create an animation based on multiple 
plots!)

So this applies to various filetypes in addition to *.Rmd (*.Rnw, for one). 


>  In RStudio, running just that block will also create all three blocks and 
> display them in the editor.  
> 
> By contrast, creating a series of many plots in org is fairly tedious.  I 
> have to name the plot individually & put each function call in its own src 
> block. Is there any way to mimic the behaviour of rmarkdown instead? I odn't 
> understand babel or R enough to really even see how something like that could 
> be implemented, but I'd appreciate some pointers.  Thank you!

Getting babel to handle this seamlessly would be a significant effort.

You can use ox-ravel (https://github.com/chasberry/orgmode-accessories.git) to 
export to *.Rmd and then render the result.  However, that does not have the 
interactivity of `org-babel-execute-src-block' and does not insert the graphics 
into the *.org file. 

I suppose that a function could be created to narrow to the src block, export 
it as *.Rmd to a buffer, run that buffer as the `text' arg of knitr::knit, then 
add links for the png's back to the *.org file. I haven't thought much about 
this - getting this to work in a simple case would not be too hard, but there 
may be a can of worms that this approach opens.

HTH,

Chuck





Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block

2020-03-30 Thread Berry, Charles



> On Mar 30, 2020, at 3:23 PM, Joost Kremers  wrote:
> 

[stuff deleted]

> 
> If I reverse the order and add a `+` sign, like so:
> 
> ```
> :PROPERTIES:
> :header-args:python+: :session py1 :results function
> :header-args:python+: :tangle out1.py
> :END:
> ```
> 
> the code does indeed get tangled, but the `:results` header arg isn't picked 
> up, because the code block doesn't produce any output.


Not so.

`org-babel-view-src-block-info' (C-c C-v C-i with point in the src block below) 
reports

,
| Lang: python
| Properties:
|   :header-argsnil
|   :header-args:python :session py1 :results function :tangle out1.py
| Header Arguments:
|   :cache  no
|   :exportscode
|   :hlines no
|   :noweb  no
|   :resultsfunction replace
|   :sessionpy1
|   :tangle out1.py
`

> 
> For reference, this is my test file:
> 
> ```
> * Header 1
> :PROPERTIES:
> :header-args:python+: :session py1 :results function
> :header-args:python+: :tangle out1.py
> :END:
> 
> #+begin_src python
> a=1
> b=2
> c=a+b
> return c
> #+end_src
> 
> #+RESULTS:
> ```





  1   2   3   >