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:
> ```





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

2020-03-29 Thread Berry, Charles



> On Mar 29, 2020, at 1:13 PM, Joost Kremers  wrote:
> 
> 
> On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. 
> wrote:
>>> On Mar 28, 2020, at 3:00 PM, Joost Kremers  wrote:
>>> Is this expected behaviour? Am I doing something wrong?
>> 
>> IIUC what you did, then yes and yes.
>> 
>> This is the accepted idiom:
>> 
>> #+PROPERTY: header-args :tangle yes
> 


What we really need is an ECM rather than snippets of code.

This ECM works for me:

#+begin_src org

  ,* try python
  :PROPERTIES:
  :header-args:python: :tangle yes
  :END:
  ,#+begin_src python
  "a+b"
  ,#+end_src


#+end_src

producing a file of the same name with the .py extension with one line 
containing "a+b".

I am on release Org mode version 9.3.6 (release_9.3.6-442-g97f0f1 ), but this 
also work on release_9.3-34-g2eee3c

HTH,

Chuck

p.s. `M-x org-lint' may reveal some issues with your file that might not be 
obvious to the eye.

> I have tried:
> 
> #+begin_example
> #+PROPERTY: header-args:python :tangle yes :dir  /home/joost/tmp/dlpy
> #+end_example
> 
> which AFAICT is the syntax shown in the info node you mentioned. I have also 
> tried a file name instead of =yes=, both with and without quotes, but it 
> doesn't work.
> 
> What I really want is to have a property block with the =:tangle= arg under 
> each top-level header, like so:
> 
> #+begin_example
> :PROPERTIES:
> :header-args:python: :tangle out1.py
> :END:
> #+begin_example
> 
> because I want the code below each top-level header to be tangled to a 
> separate file. Again, AFAICT this is the syntax described in the info manual.
> 
> Hmm, experimenting a bit more I find that if I leave out the =python= part, 
> it works:
> 
> #+begin_example
> :PROPERTIES:
> :header-args: :tangle out1.py
> :END:
> #+begin_example
> 
> But the info manual gives this example:
> 
> #+begin_example
> :PROPERTIES:
> :header-args:clojure::session *clojure-1*
> :END:
> #+begin_example
> 
> The same is true for the #+PROPERTY block at the top of the file: leave out 
> the =python=, it works. Isn't it possible to restrict tangling to source 
> blocks of a particular language? (Or, more specifically what I want: to 
> specify different tangling targets for different language? I wanted to have 
> both python and bash code blocks under one header and have them tangled to 
> different files...)
> 
> Joost
> 
> 
> -- 
> Joost Kremers
> Life has its moments





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

2020-03-29 Thread Berry, Charles



> On Mar 28, 2020, at 3:00 PM, Joost Kremers  wrote:
> 
> Hi list,
> 
> I'm having trouble tangling an Org file. Basically, if I put a =:tangle= 
> header argument in a =#+PROPERTY= line at the top of the file or in a 
> =:PROPERTIES:= block under a header, it is not picked up and the code blocks 
> to which (I think) it should apply are not tangled. Only when I put a 
> =:tangle= argument at the top of the source block itself is the source block 
> tangled.
> 
> Is this expected behaviour? Am I doing something wrong?

IIUC what you did, then yes and yes.

This is the accepted idiom:

#+PROPERTY: header-args :tangle yes

Remember that if you add or change that line you need to update with C-c C-c or 
`org-mode-restart'.

Maybe you omitted the `header-args'. That used to be correct syntax but was 
obsoleted some time back.

See (info "(org) Using Header Arguments")

HTH,

Chuck


> 
> Emacs 26.3, Org 9.3.6.
> 
> TIA
> 
> Joost
> 
> 
> -- 
> Joost Kremers
> Life has its moments
> 
> 





Re: tangling from multiple files

2020-03-19 Thread Berry, Charles
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. 
> 
> HTH,
> 
> Chuck





Re: tangling from multiple files

2020-03-18 Thread Berry, Charles


> On Mar 18, 2020, at 6:29 PM, David Bremner  wrote:
> 
> "Berry, Charles"  writes:
> 
>>> On Mar 17, 2020, at 4:21 PM, David Bremner  wrote:
>>> 
>>> 
>>> I've seen this question around e.g. stack overflow, but none of the
>>> answers I found seems really satisfactory.
>>> 
>>> I'd like to share a set of begin_src / end_src blocks in a.org between
>>> b.org and c.org; in particular b.org and c.org contain noweb references
>>> to names defined in a.org. Is there a better way than using
>>> (org-babel-lob-ingest "a.org")? This seems a bit clunky, requiring
>>> manual action every time a.org changes.
>>> 
>> 
>> 
>> Put 
>> 
>> #+include: ./a./org
>> 
>> directives in b.org and c.org
>> 
>> You might want to put the directives inside a non-exported drawer. See 
>> `org-export-with-drawers’  docstring.
> 
> This works fine (modulo the extra /) for exporting, but doesn't seem to
> work for tangling. Does it work for tangling for you; i.e. is b.scm
> produced with the two defines in it?
> 

Right. It does not work directly for tangling. So also use 

#+export_file_name: b2.org

(say)

Then load ox-ob.el, export as C-c C-e O o (org-org-export-to-org),  visit 
b2.org and tangle from there. 

HTH,

Chuck



Re: tangling from multiple files

2020-03-18 Thread Berry, Charles


> On Mar 17, 2020, at 4:21 PM, David Bremner  wrote:
> 
> 
> I've seen this question around e.g. stack overflow, but none of the
> answers I found seems really satisfactory.
> 
> I'd like to share a set of begin_src / end_src blocks in a.org between
> b.org and c.org; in particular b.org and c.org contain noweb references
> to names defined in a.org. Is there a better way than using
> (org-babel-lob-ingest "a.org")? This seems a bit clunky, requiring
> manual action every time a.org changes.
> 


Put 

#+include: ./a./org

directives in b.org and c.org

You might want to put the directives inside a non-exported drawer. See 
`org-export-with-drawers’  docstring.

HTH,

Chuck

> For example, here is a.org
> 
> #+name: x.scm
> #+begin_src scheme
> (define x 1)
> #+end_src
> 
> #+name: y.scm
> #+begin_src scheme
> (define y 2)
> #+end_src
> 
> and here is b.org. You can imagine c is similar, but maybe swaps the
> order of x and y
> 
> #+begin_src scheme :tangle "b.scm" :noweb strip-export
> <>
> <>
> #+end_src
> 
> # Local Variables:
> # eval: (org-babel-lob-ingest "a.org")
> # End:
> 
> 



Re: Src blocks laid out side-by-side

2020-02-08 Thread Berry, Charles



> On Feb 8, 2020, at 2:13 AM, Fraga, Eric  wrote:
> 
> On Friday,  7 Feb 2020 at 17:59, Steve Downey wrote:
>> I have a need to lay out source blocks side by side, in order to present
>> before and after changes to the source. If I could embed a block in a
>> table, that would do it.
> 
> Do you need this layout in org file itself or only in an exported
> document from the org file?
> 
> For the latter, you can use inline directives to achieve this.  E.g. if
> you were exporting to PDF via LaTeX, you could start/end minipages
> around each src block.
> 


Right. And the side-by-side issue for markdown is handled with inline html like 
this:

https://stackoverflow.com/questions/43232279/how-can-one-display-tables-side-by-side-in-github-markdown

The trick is that 'md snippets fall back to html. So @@html:  @@ etc are 
needed.

HTH,

Chuck 





Re: org-babel-load-file support elisp

2020-02-04 Thread Berry, Charles



> On Feb 3, 2020, at 10:03 PM, Jack Kamm  wrote:
> 
> Tim Cross  writes:
> 
>> All other language specifiers comply to the pattern of source block
>> languages being the language major mode name without the '-mode', but
>> there is no elisp-mode.
> 
> Sorry to be pedantic, but I think shell source blocks are another
> exception here. 

[snip]

FWIW, so are R and julia (ess-r-mode, ess-julia-mode) and c++ (cc-mode).

I suspect more examples are "out there".

Chuck




Re: C-c C-c to close the buffer in *Org Src ...* buffers

2020-01-31 Thread Berry, Charles



> On Jan 31, 2020, at 3:03 AM, Bastien  wrote:
> 
> Hi all,
> 
> I'd like to make  an equivalent to  in Org Src buffers
> so that hitting  will close the buffer, which seems natural.
> 
> WDYT?

Many modes used in org src buffers have C-c C-c in their maps. python, latex, 
c++, shell, R, ...

I often use C-c C-c in R src edit buffers to eval functions and code blocks, so 
this will be an inconvenience for me (and I suspect for others).

HTH,

Chuck





Re: breakage: Using self-defined Macro in macro definition

2020-01-20 Thread Berry, Charles


> On Jan 20, 2020, at 2:27 AM, Robert Klein  wrote:
> 
> 
> Hi,
> 
> when I use a self-defined macro in a macro definition, subsequent
> macros in the same macro definition don't get expanded (tested with
> org version 9.2.1 and tip of maint):


The expansions in your example follow the rules. 

The problem as explained below is that you have created a macro whose expansion 
cannot be further expanded.

> 
> --- snip example ---
> #+Macro: newline (eval "\n")

That will add a newline character.

> #+Macro: new $1 {{{newline}}}#+Index: $1 {{{newline}}}

This is a bit tricky. It adds a newline character before the hash `#'.

Then you have this line in the current buffer (see the 
`org-export-with-buffer-copy' docstring):

#+Index: $1 {{{newline}}} 

and org needs to do something with it, but as the manual says

Org recognizes macro references in following Org markup areas:
paragraphs, headlines, verse blocks, tables cells and lists.  Org also
recognizes macro references in keywords, such as ‘CAPTION’, ‘TITLE’,
‘AUTHOR’, ‘DATE’, and for some back-end specific export options.

and INDEX was not one of the keywords, so the reference is not recognized. 

So it is not expanded. This has nought to do with it being `self-defined'.

Of course, you see it on export if the exporter deals with INDEX (it looks like 
you are using 'latex).

> 
> Use the {{{new(format)}}}
> command to format a string according to the
> /format-string/ argument.
> --- snip example ---
> 
> 
> the output of which is:
> 
> --- snip resulting output ---
> Use the format a 
> \index{format {{{newline
> command to format a string according to the
> \emph{format-string} argument.
> --- snip resulting output ---
> 
> 

As expected.

> The expected output would be:
> 
> --- snip expected output ---
> Use the format a 
> \index{format} 
> command to format a string according to the
> \emph{format-string} argument.
> --- snip expected output ---
> 
> 
> PS: leaving the second {{{newline}}} out is not a solution, as
> paragraph reformatting will put the macro in the middle of the line.
> 
> 
> 
> The issue doesn't crop up, when using a predefined macro, e.g. ` date'
> or `author'.
> 
> 
> It also doesn't show up, when the first macro in the macro is e.g. the
> predefined macro `date'.  That is the following example 2 works ok:
> 
> --- snip example 2 ---
> #+Date: <2020-01-20 Mon>
> #+Macro: old $1 {{{date}}} {{{newline}}} alpha {{{newline}}} beta
> 
> {{{old}}}
> --- snip example 2 ---
> 
> 
> Thanks for any hints/help.
> 

None of those examples involve a macro that creates output in which further 
macros cannot be recognized.

Build an `eval' macro that does all the expansions within its own code without 
referring to other macros. The property API may help with this.

Or maybe try an idiom that does not use a macro, such as a custom link.

HTH,

Chuck

Re: Wholesale changes to LaTeX headers

2019-12-31 Thread Berry, Charles



> On Dec 31, 2019, at 7:42 AM, Norman Walsh  wrote:
> 
> Hi,
> 
> I want to make wholesale changes to the LaTeX preamble exported from
> Org mode. I want to put \RequirePackage and \PassOptionsToPackage
> calls before the \documentclass, I want to write a specific set of
> macros after the \documentclass, I want to craft a couple of
> \renewcommands, etc.
> 
> Where should I begin?


Execute this src block:

#+begin_src emacs-lisp :results none
(info "(org) LaTeX header and sectioning")
(describe-variable 'org-latex-classes)
#+end_src

Browse the *info* buffer and study the *Help* buffer.

Then type

`M-x customize-variable RET org-latex-classes RET`

and add your custom class or modify an existing class to your liking.

HTH,

Chuck





Re: Turn function into interactive

2019-12-30 Thread Berry, Charles


> On Dec 29, 2019, at 9:26 PM, Lawrence Bottorff  wrote:
> 
> I've discovered org-outline-level which when in a code block under a given 
> header delivers as expected:
> 
> * This old level
> #+BEGIN_SRC emacs-lisp
> (org-current-level)
> #+END_SRC
> 
> #+RESULTS:
> : 1
> 
> Now, how could I turn this into an interactive callable with M-x? My stab in 
> the dark
> 
> (defun my-insert-level ()
>   (interactive)
>   (insert (org-outline-level)))

> doesn't seem to be working. 

It works, but just isn't what you wanted. ;-)

Note:

,[ C-h f insert RET ]
| insert is a built-in function in ‘C source code’.
| 
| (insert  ARGS)
| 
| Insert the arguments, either strings or characters, at point.
| Point and after-insertion markers move forward to end up
|  after the inserted text.
| [...]
`-


So try something like

(defun my-insert-level ()
  (interactive)
  (insert (format "%d" (org-outline-level

To insert a string.

HTH,

Chuck

Re: Bug: org-tempo expansion comments out the following src block when org-src-tabs-natively is 't [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]

2019-12-18 Thread Berry, Charles



> On Dec 18, 2019, at 5:07 AM, Ihor Radchenko  wrote:
> 
> Recipe:
> 
> 1. emacs -Q
> 2. Execute the following lisp code:
> 
> (setq org-src-tab-acts-natively t)
> (require 'org-tempo)

I did not need to add this line to confirm the behavior:

> (push (cons "el" "src emacs-lisp") org-structure-template-alist)
> 
> 3. Create the following org file:
> 
> 
> 
> #+begin_src emacs-lisp
> #+end_src
> 
> 4. Put the point before the code block
> 
> 5.1. Type  
> Observed behaviour:
> 
> #+begin_src 
> 
> 
> #+begin_src emacs-lisp
> #+end_src
> 


Right. The issue seems to be that `org-tempo-add-block' puts  `>' elements in 
its recipe for converting  `org-structure-template-alist' to 
`tempo-org-template-*' values.

Those are innocuous when `org-src-tab-acts-natively' is nil.

But when `org-src-tab-acts-natively' is `t', an attempt is made to indent 
within the src block, which I guess is where the trouble lies as an error 
occurs which prevents the remainder of the template from being inserted.

If you really need `

Re: Calling/using named babel code blocks

2019-12-18 Thread Berry, Charles



> On Dec 18, 2019, at 9:10 AM, Lawrence Bottorff  wrote:
> 
> I thought I understood "metaprogramming," i.e., creating generic code blocks 
> that can be called by any other code block regardless of programming language 
> -- but apparently I don't. I have this
> 
>  #+name: my-random-gen
> #+header: :var n=0 :var lim=0
> #+BEGIN_SRC emacs-lisp
> (loop repeat n collect (random* lim))
> #+END_SRC
> 
> and I have the variables initialized to zero. But now I don't know how to 
> call it with another code block. I've tried various versions of this
> 
> #+BEGIN_SRC emacs-lisp
> my-random-gen(5 1.0)
> #+END_SRC
> 
> and this various versions of this
> 
> #+BEGIN_SRC emacs-lisp :var results=my-random-gen() :var n=5 :var lim=1.0
> results
> #+END_SRC
> 
> to no avail. What am I missing? How can I actually use, call my-random-gen in 
> other code blocks?
> 

Do these help?

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


#+BEGIN_SRC emacs-lisp :var mrg=my-random-gen(5, 1.0)
mrg
#+END_SRC

Chuck





Re: Babel: Store script in external file

2019-12-17 Thread Berry, Charles



> On Dec 16, 2019, at 1:53 PM, Michael Gauland  wrote:
> 
> I've just started playing with #+INCLUDE, so I may not be using it correctly, 
> but this works for me.

Indeed, if what the OP wants is to wrap just that code as a src block and 
export it and any results it produces during export then that is the way to go. 

However, `org-babel-execute-buffer' , `org-babel-tangle' and so on will not 
honor the #+INCLUDE directive unless an export is in progress.

HTH,

Chuck

> 
> I have a file 'sh_test', which looks like:
> for i in $(seq 10); do
> echo $i
> done
> 
> My org file:
> #+HEADER: :exports both
> #+INCLUDE: "sh_test" src sh
> 
> And the results:
> 
> ,
> | for i in $(seq 10); do
> | echo $i
> | done
> `
> 
>   1
>   2
>   3
>   4
>   5
>   6
>   7
>   8
>   9
>  10
> 
> Hope that helps.
> 
> Kind regards,
> Mike
> 
> 
> On Mon, Dec 16, 2019 at 2:22 PM Nathan Neff  wrote:
> Hello all,
> 
> I think I'm missing something basic:  I'd like to have something like this:
> 
> #+begin_src python
> #+filename: foo.py
> 
> Instead of storing my Python code in the current org file, I would like
> Babel to read foo.py and execute it, as if it was inside the .org file.
> 
> The foo.py mentioned above is fairly large, and I would like the code
> to be stored in a different file than my .org file, for brevity.
> 
> Any ideas?  I feel like I'm missing something obvious.
> 
> Thanks,
> --Nate





Re: Babel: Store script in external file

2019-12-16 Thread Berry, Charles



> On Dec 15, 2019, at 5:21 PM, Nathan Neff  wrote:
> 
> Hello all,
> 
> I think I'm missing something basic:  I'd like to have something like this:
> 
> #+begin_src python
> #+filename: foo.py
> 
> Instead of storing my Python code in the current org file, I would like
> Babel to read foo.py and execute it, as if it was inside the .org file.
> 
> The foo.py mentioned above is fairly large, and I would like the code
> to be stored in a different file than my .org file, for brevity.
> 
> Any ideas?  I feel like I'm missing something obvious.

Two things:

1. Library-of-Babel :: lets you store src blocks of code in an external file

2. noweb chunks :: let you insert code into src blocks

See https://orgmode.org/worg/library-of-babel.html and (info "(org) Noweb 
Reference Syntax")

For your example, a file `my-lob.org' with a src-block named foo-py that 
contains what foo.py contains will do it.

Then you eval `(org-babel-lob-ingest "my-lob.org")' any time before executing 
the file that contains this:

#+begin_src python :noweb yes
<>
...

HTH,

Chuck





Re: Babel: Set org-babel-min-lines-for-block-output for single code block?

2019-12-16 Thread Berry, Charles



> On Dec 15, 2019, at 1:55 PM, Nathan Neff  wrote:
> 
> Hello all,
> 
> I just found the org-babel-min-lines-for-block-output variable.
> 
> I have a table like this:
> 
> #+RESULTS: people-table
> | User  | ID | Homepage |
> |---++--|
> | Bob   |  1 | http://example.com/bob   |
> | Steve |  2 | http://example.com/steve |
> 
> And a code block like this:
> 
> #+begin_src python :var people=people-table :results output 
> for i, person in enumerate(people):
> print('- ' + person[0])
> print("  " + person[2])
> #+end_src
> 
> I would like to set org-babel-min-lines-for-block-output variable for 
> only the above code block.  Is this possible using #+property or something 
> like that?
> Or do I need to have a "wrapper" elisp block around my python code?


Use the `:wrap example' header.

HTH,

CCB





Re: Best way to template a big table

2019-12-12 Thread Berry, Charles



> On Dec 12, 2019, at 8:03 AM, Lawrence Bottorff  wrote:
> 
> I just figured out that this 
> 
> #+BEGIN_SRC emacs-lisp :results table
> '((H1 H2 H3) (text11 text12 text13) (text21 text22 text23) (... ... ...) 
> (textN1 textN2 textN3))
> #+END_SRC
> 
> #+RESULTS:
> | H1 | H2 | H3 |
> | text11 | text12 | text13 |
> | text21 | text22 | text23 |
> | ...| ...| ...|
> | textN1 | textN2 | textN3 |
> 
> is probably a better way all around, i.e., "best practice." If any one knows 
> how to get the horizontal lines added in. . . .


Add an `hline' in the right place. Like this:

#+BEGIN_SRC emacs-lisp :results table
'((H1 H2 H3) hline (text11 text12 text13) (text21 text22 text23) (... ... ...) 
(textN1 textN2 textN3))
#+END_SRC

HTH,

Chuck



Re: File tags prevent autocomplete of global tags

2019-12-11 Thread Berry, Charles


> On Dec 10, 2019, at 4:54 PM, E R  wrote:
> 
> Hello,
> 
> following the post below, by the same title, I was advised to notify the 
> org-mode mailing list.
> 
> https://emacs.stackexchange.com/questions/54277/file-tags-prevent-autocomplete-of-global-tags
> 
> To summarize, tags defined inside a file interfere with auto-complete of tags 
> defined globally, that is, in ~/.emacs

For completeness: you described there what is documented in

(info "(org) Setting Tags")

as the expected behavior.

You want to customize ‘org-tag-persistent-alist’ instead of `org-tag-alist'.

HTH,

Chuck

Re: Have :var reference a value

2019-12-08 Thread Berry, Charles



> On Dec 8, 2019, at 8:52 AM, George Mauer  wrote:
> 
> I'm playing around with learning racket in an org buffer and I have a bunch 
> of blocks that look like this
> 
>#+begin_src racket :var value="abbracadaabra"
>...do stuff with value...
>#+end_src
> 
> 
>#+begin_src racket :var value="abbracadaabra"
>...do other stuff with value...
>#+end_src
> 
> Is there a way to move the "abbracadaabra" string into a single location so 
> that I can just pull the var from that? I know I can put it in a table or a 
> list, but how about into a single value?

Make it a property:

#+PROPERTY: magic abbracadabra

#+begin_src emacs-lisp :var value=(org-entry-get (point) "magic" t)
value
#+end_src

#+RESULTS:
: abbracadabra


When you add/change a  property like this be sure to update (C-c C-c on the 
PROPERTY line or save, close, open the file).

For a long string, you might put it in a src block and then use :var 
value=block-name() to get it.

HTH,

Chuck



Re: “Literate” python?

2019-11-30 Thread Berry, Charles


> On Nov 29, 2019, at 9:54 AM, Norman Walsh  wrote:
> 
> Hi,
> 
> I’ve seen a couple of pointers recently to using Org mode and tangle
> to write more literate Emacs configurations. I use Org+babel all the
> time to write “interactive” documents, so I thought I’d try out tangle
> from Org.
> 
> I didn’t want to start with something as comlicated as my Emacs
> config :-) so I figured I’d kick the tires with a small python
> program. That did not end well.
> 
> Consider:
> 
> #+TITLE: Python literate programming
> #+OPTIONS: html-postamble:nil
> 
> It starts off as a completely standard Python3 program.
> 
> ---%<--
> #+BEGIN_SRC python :tangle yes :weave no
> #!/usr/bin/env python3
> 
> #+END_SRC
> 
> It defines ~a~.
> 
> #+BEGIN_SRC python :tangle yes
> def a():
>print("a")
> 
> 
> #+END_SRC
> 
> And ~b~.
> 
> #+BEGIN_SRC python :tangle yes
> def b():
>print("b")
> 
> 
> #+END_SRC
> 
> Now ~c~ is a little more complicated:
> 
> #+BEGIN_SRC python :tangle yes
> def c():
>   print("c")
> #+END_SRC
> 
> Not only does ~c~ print “c”, it calls ~a()~ and ~b()~.
> 
> #+BEGIN_SRC python :tangle yes
>   b()
>   a()
> #+END_SRC
> 
> Finally, make it importable. Not that you’d want to.
> 
> #+BEGIN_SRC python :tangle yes
> if __name__ == "__main__":
>main()
> #+END_SRC
> --->%--
> 
> That’s the script. It weaves into HTML more-or-less ok (there’s a
> weird black box at the front of indented lines, but I can come back to
> that later).
> 
> It’s a complete mess when tangled.
> 
> The extra blank lines between functions (to make pylint happy with
> some PEP guideline) have disappeared. I guess I could live with that,
> but the complete failure to preserve indention in the penultimate code
> block is a show stopper:

[results of tangling deleted]

A couple of things might help.

First, use the :noweb-ref argument to mark each of the code blocks you wish to 
tangle.  

Say `:noweb-ref tangleyes'. Or some more evocative name.

Remove the `:tangle yes' from each of those. Then, add a code block that has 
only `<>' in it and tangle it.

#+begin_src python :noweb yes :tangle yes
<>
#+end_src

The remaining problem (as you will see) is the indentation. Fix this by adding 
the `-i' flag to the penultimate code block, viz.

#+BEGIN_SRC python -i :noweb-ref tangleyes
   b()
   a()
#+END_SRC

See 12.6 Literal Examples and 15.10 Noweb Reference Syntax in the manual.

HTH,

Chuck




Re: where to place caption so babel results include caption?

2019-11-06 Thread Berry, Charles



> On Nov 6, 2019, at 1:55 AM, Ken Mankoff  wrote:
> 
> Hello,
> 
> If I have a babel block that generates a table and I'd like latex attributes 
> associated with that table, it seems to work well if I do this:
> 
> #+NAME: foo
> #+BEGIN_SRC bash :results table
> echo "${RANDOM}|${RANDOM}|"
> echo "${RANDOM}|${RANDOM}|"
> #+END_SRC
> 
> #+caption: foo
> #+latex_attr: :placement [!h]
> #+RESULTS: foo
> | 17326 | 29919 |
> | 30565 |  9548 |
> 
> 
> And I can re-run the babel block and CAPTION and ATTR_LATEX remain.
> 
> But if I want to clean with =[C-u] C-c C-v k= or 
> (org-babel-remove-result-one-or-many) and regenerate =C-c C-v C-b= or 
> (org-babel-execute-buffer), then this happens:
> 
> 
> #+RESULTS: foo
> | 17225 | 29253 |
> | 18433 | 27388 |
> 
> #+caption: foo
> #+latex_attr: :placement [!h]
> 
> If I place CAPTION and LATEX_ATTR above the babel block it isn't exported 
> correctly. Is there some way to have this work?
> 


Maybe use something like

M-: (org-babel-map-src-blocks nil (org-babel-insert-result "" '("replace"))) RET

to scrub the existing result values without removing the '#+RESULTS' line.

??

HTH,

Chuck



Re: Question mark not supported in structured templates?

2019-10-29 Thread Berry, Charles
`org-tempo' is the replacement. It is mentioned in the docstring for 
`org-structure-template-alist'. 

Here is what I have in my `emacs-init.org' file:

(The letter `p' denotes where point should land. `n' is a newline. See the 
docstring for `tempo-define-template' for more details.)


#+begin_src emacs-lisp 

  (require 'org-tempo)


  (tempo-define-template "org-src_R"
 '("#+begin_src R" p  n
   n "#+end_src" )
 " n p
  n "\\end{eqnarray}" >)
 " n p
  n "\\end{equation}" >)
 " On Oct 29, 2019, at 1:59 AM, Vladimir Nikishkin  wrote:
> 
> In the version 8 of org-mode you could indicate where to put the point
> after the template is expanded. In the template
> (list "p" "#begin_src plantuml :file ? :export both \n#end_src"),
> after the template is expanded, the point would be located after
> :file, whereas in the template (list "SO" "#begin_src scheme :export
> both \n?\n#end_src") the point would be located on the frist line
> after the header.
> 
> At the moment, `org-insert-structure-template' just inserts the
> question mark verbatim. I would consider this a regression, but maybe
> there is some replacement mechanism?





Re: Refresher on including R/ggplot2 output via latex/pdf?

2019-10-28 Thread Berry, Charles



> On Oct 28, 2019, at 12:43 AM, John Hendy  wrote:
> 
> On Mon, Oct 28, 2019 at 1:14 AM Jack Kamm  wrote:
>> 
>>> This is with emacs -Q and loading the minimal config from the initial
>>> email. Any ideas on where I might look next?
>> 
>> Sorry, I don't have many ideas here. Have you checked that ggplot works fine 
>> in a regular R session?
> 
> Indeed, it does. And as mentioned, if I used :results file graphics,
> everything works. It's able to plot and write to file... the magic
> just isn't happening with :results output graphics for some reason.
> 
> 


To wit:

commit 5c55d3a53c982563c0409e342b8940009e1409f2
Author: Nicolas Goaziou 
Date:   Sat Aug 24 00:04:06 2019 +0200

manual: Remove erroneous footnote about :file header argument

* doc/org-manual.org (Type): :file header argument no longer
implies :results file.

commit 26ed66b23335eb389f1f2859e409f46f66279e15
Author: Nicolas Goaziou 
Date:   Sat Oct 6 08:56:05 2018 +0200

ob: :file and :file-ext no longer imply :results file

* lisp/ob-core.el (org-babel-execute-src-block): ":results file" must
  be specified in order to return a file.
(org-babel-merge-params): :file and :file-ext no longer imply :results
file.
* testing/lisp/test-ob.el (test-ob/indented-cached-org-bracket-link):
(test-ob/result-file-link-type-header-argument):
(test-ob/result-graphics-link-type-header-argument): Update tests.

Deducing the results from some other arguments is not obvious.
Moreover, it prevents users from setting, e.g., :file-ext, in a node
property, as every block would then create a file.

Reported-by: Alex Fenton 


HTH,

Chuck






Re: [O] Exporting noweb-ref's without disabling org-babel processing

2019-10-23 Thread Berry, Charles
Diego,

I am not sure I understand. Here is my interpretation:

You wish to have `:exports both' behavior in your org export.

You want noweb references in the exported code to render as angle-bracketed 
chunk names, such as <> rather than being expanded in place.

If that is what you want, you can use the feature of CALL keywords that resets 
the header arguments for the src block it calls to obtain different behavior 
with the same code. For example:

#+begin_src org
  ,#+name: template-chunk
  ,#+begin_src emacs-lisp :noweb no
  (concat c b a
  <>
  )
  ,#+end_src

  ,#+CALL: template-chunk() :noweb yes :var a="A" b="B" c="C"

  ,#+begin_src emacs_lisp :noweb-ref super-duper-code
  (concat a b c)
  ,#+end_src
#+end_src

exports as 

--8<---cut here---start->8---
,
| (concat c b a
| <>
| )
`

,
| CBAABC
`


,
| (concat a b c)
`
--8<---cut here---end--->8---

HTH,

Chuck

> On Oct 22, 2019, at 1:29 PM, Diego Zamboni  wrote:
> 
> Hi,
> 
> I'm working on a Leanpub Markua exporter (not quite complete yet but already 
> usable, if you are interested: 
> https://github.com/zzamboni/ox-leanpub/tree/book-and-markua)
> 
> I would like to include the value of :noweb-ref for code blocks in exported 
> output, like noweb originally did, e.g. something like this:
> 
> #begin_src emacs_lisp :noweb-ref super-duper-code
> ...
> #end_src
> 
> to produce something like this in the export:
> 
> <>=
>  ...
> 
> After much poking around, I figured that the :noweb and :noweb-ref header 
> args are removed by org-babel *before* the src block makes it to the 
> exporter. I also discovered that by setting org-export-use-babel to nil I 
> could disable this behavior, which means that my exporter can access the 
> :noweb-ref argument by parsing the :parameters property (see 
> https://github.com/zzamboni/ox-leanpub/blob/book-and-markua/ox-leanpub-markua.el#L388).
> 
> This was good for my original purpose, but I just realized that this also 
> disables other useful org-babel features on export, such as the processing of 
> the :exports header argument, which means that both code and results are 
> always included in the export regardless of what :exports says :)
> 
> I have tried using org-babel-exp-code-template, but unfortunately if I try to 
> use "%noweb-ref" as a key in its value, it gets replaced by the value of 
> :noweb followed by "-ref" in every case.
> 
> Is there some other way of accessing org-babel header arguments like 
> :noweb-ref from the exporter, but without having to disable org-babel 
> processing completely? Any other ideas for achieving what I want?
> 
> Thanks for any ideas,
> --Diego
> 





Re: [O] Babel eval w/ C-c C-c but not (org-babel-execute-buffer)

2019-10-10 Thread Berry, Charles



> On Oct 10, 2019, at 10:21 AM, Charles Berry  wrote:
> 
>> 
>> This could work in theory, but doesn't for bash on my system. And (I think) 
>> with this method tables of output are not then injected back into the Org 
>> buffer that can be exported as part of the document.
> 

Of course!

> 
> I think in R such tables are injected with :exports results/both.
> 


 Please chalk this one up to a brain f*rt.

Chuck



Re: [O] Babel eval w/ C-c C-c but not (org-babel-execute-buffer)

2019-10-10 Thread Berry, Charles



> On Oct 10, 2019, at 9:43 AM, Ken Mankoff  wrote:
> 
> Hi Charles,
> 
> On 2019-10-10 at 18:22 +02, Berry, Charles  wrote...
>> If the language mode you use supports of evaluation of the src edit
>> buffer (e.g. ESS[R], Python), you can issue
>> 
>> C-c C-v v C-c C-b
>> 
>> for ESS[R] or
>> 
>> C-c C-v v C-c C-c
>> 
>> for Python (I think)
>> 
>> The commands will expand :var args and noweb declarations, then
>> execute the corresponding 'send-buffer' command regardless of :eval.
> 
> This could work in theory, but doesn't for bash on my system. And (I think) 
> with this method tables of output are not then injected back into the Org 
> buffer that can be exported as part of the document.


I think in R such tables are injected with :exports results/both.

But if you need bash, I guess not.

> 
>> Why not use something like this
>> 
>> :eval (ok2run)
>> 
>> where `ok2run' consults a property to decide whether to eval the block?
> 
> I need to think about this some more... Can you describe more how you picture 
> this working?

Try this:

#+begin_src org
  ,#+begin_src emacs-lisp 
(defun ok2run ( eval-arg)
  "Use EVAL-ARG as the argument for `:eval'.
If none is supplied consult
 a variable `buffer-eval-arg' if such exists
 a property called `eval-arg'
 or default to `yes'."
  (let ((eval-arg (or eval-arg
  (bound-and-true-p buffer-eval-arg)
  (org-entry-get (point) "eval-arg" t)
  "yes")))
eval-arg))
  ,#+end_src
#+end_src


#+begin_src org
  ,#+PROPERTY: header-args :eval (ok2run) :exports results

  ,* use default

  ,#+name: use-default
  ,#+begin_src emacs-lisp
  "unboundp"
  ,#+end_src

  ,* explicit no

  ,#+name: explicit-no
  ,#+begin_src emacs-lisp :eval (ok2run "no") 
  "explicit-no"
  ,#+end_src

  ,* never export in this subtree
:PROPERTIES:
:eval-arg: never-export
:END:

  ,#+name: never-export
  ,#+begin_src emacs-lisp 
  "never-export"
  ,#+end_src
#+end_src


This will give fairly fine grained control over what and when to eval. 



> Off the top of my head, I am picturing a top-level property setting :eval 
> (ok2run) and then blocks I want to always run have :eval yes and blocks I 
> want to run interactively only have a new property, ":eval-on-c-c" set to 
> "t". The, (ok2run) checks for eval-on-c-c as a header arg and returns 't' if 
> it exists and 'nil' if it does not?
> 
> 
> While your suggestions do work for some cases, they feel like work-arounds 
> for a missing feature.


Perhaps, `org-confirm-babel-evaluate' is that feature. I think with a bit of 
effort it could do what I proposed above for `ok2run'.

> Isn't the feature I'm proposing a logical enhancement? Why would someone C-c 
> C-c (or C-u C-u C-c C-c) on a code block if they didn't want it to run? 
> Shouldn't an explicit request override a local header or top-level-document 
> flag that says "don't eval"?

Maybe it is logical. 

But I am a terrible typist and sometimes end up typing things or in places I 
did not intend. 

I have disabled a number of commands to prevent me from accidentally wrecking 
my work.  

So if I mark a block with `:eval no', I want to be sure errant keystrokes do 
not override that setting.

Chuck



Re: [O] Babel eval w/ C-c C-c but not (org-babel-execute-buffer)

2019-10-10 Thread Berry, Charles



> On Oct 9, 2019, at 11:04 PM, Ken Mankoff  wrote:
> 
> Hello,
> 
> I think that even when ":eval no" is set, eval should happen if the user 
> explicitly requests it.


If the language mode you use supports  of evaluation of the src edit buffer 
(e.g. ESS[R], Python), you can issue

C-c C-v v C-c C-b

for ESS[R] or

C-c C-v v C-c C-c

for Python (I think)

The commands will expand :var args and noweb declarations, then execute the 
corresponding 'send-buffer' command regardless of :eval. 

> 
> The use case is that I have code that takes an unreasonable amount of compute 
> time to run it in Emacs (e.g. a full day of compute time). I think even with 
> :async this type of code should be run outside of emacs, so I tangle it and 
> run the python or bash scripts in a terminal.
> 
> Elsewhere in the project (Org file) I have babel blocks that I want to update 
> throughout the file. I do this by cleaning all result blocks with =C-u C-c 
> C-v k= or (org-babel-remove-result-one-or-many), then executing all blocks 
> (without =:eval no=) using =C-c C-v C-b= or (org-babel-execute-buffer).
> 
> In order to not spend days of compute time when I eval 
> (org-babel-execute-buffer), I set :eval no to the computationally heavy babel 
> blocks. But during development it would be nice to run these... hence the 
> conflict with the current Org behavior and my desire for a new feature.
> 


Why not use something like this

:eval (ok2run)

where `ok2run' consults a property to decide whether to eval the block? 



> The two-line change at the bottom implements the following behavior:
> 
> When the prefix arg is passed to org-babel-execute-src-block, the block is 
> evaluated regardless of the :eval flag.
> 
> Note that this doubles up on the prefix arg behavior, which is already set 
> according to the documentation:
> 
>> With prefix argument ARG, force re-execution even if an existing
>> result cached in the buffer would otherwise have been returned.
> 
> Questions for the list:
> 
> Is this feature something that makes sense?
> 
> If yes, then do you also think that tangling should occur when explicitly 
> requested (i.e. C-u C-c C-v C-t), even if :tangle no is set?
> 
> Suggestions for a better implementation?
> 
> Thanks,
> 
>  -k.
> 
> 
> diff --git a/lisp/ob-core.el b/lisp/ob-core.el
> index 572f97919..9f9add334 100644
> --- a/lisp/ob-core.el
> +++ b/lisp/ob-core.el
> @@ -646,7 +646,7 @@ block."
> ;; Merge PARAMS with INFO before considering source block
> ;; evaluation since both could disagree.
> (cl-callf org-babel-merge-params (nth 2 info) params)
> -(when (org-babel-check-evaluate info)
> +(when (or arg (org-babel-check-evaluate info))
>   (cl-callf org-babel-process-params (nth 2 info))
>   (let* ((params (nth 2 info))
>(cache (let ((c (cdr (assq :cache params
> @@ -663,7 +663,7 @@ block."
>   (let ((result (org-babel-read-result)))
> (message (replace-regexp-in-string "%" "%%" (format "%S" result)))
> result)))
> -  ((org-babel-confirm-evaluate info)
> +   ((or arg (org-babel-confirm-evaluate info))
> (let* ((lang (nth 0 info))
>(result-params (cdr (assq :result-params params)))
>;; Expand noweb references in BODY and remove any
> 
> 
> 





[O] org-download-screenshot on MacOS Catalina

2019-10-09 Thread Berry, Charles
I just upgraded to MacOS 10.15 and am experiencing some pain.

The faithful org-download-screenshot from 
https://github.com/abo-abo/org-download stopped working.

Instead of capturing a window or selection, it just copied the background.

This - forbidding screen capture - is considered a security feature.


After some trial-and-error I managed to get org-download-screenshot working 
again by editing System Preferences:

- Allowing Ruby access to Screen Record
- Allowing Emacs to run software locally that does not meet the system's 
security policy (this is under Developer Tools).

FWIW, I set  `org-download-screenshot-method' to "/usr/sbin/screencapture -s %s"

If someone can advise me on a better way to enable org-download-screenshot on 
Catalina, I would appreciate your advice.

Best,

Chuck



Re: [O] superfluous tags in html src block output

2019-09-14 Thread Berry, Charles
This is newer:

===
commit ded3d27b1468b878197e5fe55a70c5e13350ea27
Author: Nik Clayton 
Date:   Tue Jun 4 11:57:40 2019 +0200

ox-html: Wrap each line of a source block in a code element

* lisp/ox-html.el (org-html-do-format-code): Wrap each line of a source 
block
in a code element.

This makes it straightforward to add custom decorations to each line
using CSS :before and :after properties.

===



HTH,

Chuck


> On Sep 14, 2019, at 8:52 AM, Matt Price  wrote:
> 
> I'm seeing something I hadn't noticed before in src block html exports. 
> Instead of producing structures like:
> 
> 
> 
> ...
> ...
> ...
> 
> 
> 
> each individual like is wrapped in its own  tag.  In regular HTML 
> exports this doesn't really affect display, but in exports to reveal using 
> the highlight.js plugin, code display gets messed up. 
> 
> From what I can tell these code tags are generated in 
> org-html-do-format-code, in this section which starts on line 22459 of my 
> pretty recent org:
> 
> (org-export-format-code
>  code
>  (lambda (loc line-num ref)
>(setq loc
> (concat
>  ;; Add line number, if needed.
>  (when num-start
> (format "%s"
> (format num-fmt line-num)))
>  ;; Transcoded src line.
>  (format "%s"
>   (if num-start
>   (format " data-ox-html-linenr=\"%s\"" line-num)
> "")
>   loc)
>  ;; Add label, if needed.
>  (when (and ref retain-labels) (format " (%s)" ref
>;; Mark transcoded line as an anchor, if needed.
>(if (not ref) loc
> (format "%s"
> ref loc)))
>  num-start refs)
> 
> This code seems to have been around for a while so I don't know whether this 
> is new behaviour, but I don't think I've seen line-level  tags before.  
> Can anyone confirm?
> 
> See also a MWE in this bug report, which is probably erroneously filed in the 
> org-re-reveal repo:
> 
> https://gitlab.com/oer/org-re-reveal/issues/27 
> 
> I'd love to know whether this is expected behaviour, or if I've gone wrong 
> somewhere!
> THanks,
> Matt
> 





Re: [O] Nested calls in babel

2019-09-12 Thread Berry, Charles
Your example works for me. viz, the call to bar returns "foo" (not nil).

MacOS 10.14.6, Emacs 26.1, org release_9.2.6-534-g6f32e7

HTH,

Chuck

> On Sep 10, 2019, at 12:57 AM, Carlos Sánchez de La Lama 
>  wrote:
> 
> Hi all,
> 
> I am being unable to make nested calls work. Here is a minimal snippet:
> 
> --8<---cut here---start->8---
> #+NAME: foo
> #+BEGIN_SRC emacs-lisp
> "foo"
> #+END_SRC
> 
> #+NAME: bar
> #+CALL: foo()
> 
> #+RESULTS: bar
> : foo
> 
> #+CALL: bar()
> 
> #+RESULTS:
> : nil
> --8<---cut here---end--->8---
> 
> Why does the last call (to bar) return nil instead of the result of bar
> (which is "foo")? Actually, if I remove foo altogether, executing "bar"
> block gives an error, but executing the last call to "bar" still works
> (and still returns nil).
> 
> Are nested calls supported at all?
> 
> Thanks,
> 
> Carlos
> 
> -- 
> Carlos
> 
> 



Re: [O] Cannot display local images with orgmode under macOS

2019-09-12 Thread Berry, Charles


> On Sep 12, 2019, at 5:48 AM, Marco Wahl  wrote:
> 
> Hi,
> 
>> * The problem
>> 
>>Orgmode under macOS cannot display local images correctly, but it can 
>> display internet images
>> without problem.
>> 
>>I tried both emacs-mac and emacs-plus, they both have this image problem. 
>> But emacs under
>> ArchLinux don’t have this problem.
>> 
>>[[file:xxx.png]]  cannot be displayed even 
>> the file exists.
>>[[./xxx.png]]  cannot be displayed even 
>> the file exists.
>>[[http://example.org/xxx.png]]  can be displayed if the link exists.
>> 
>>Emacs can display any images with C-x C-f xxx.png. The problem happens 
>> only with orgmode.
>> 
>> * The reason
>> 
>>After bisecting org-mode source code I found out that this commit causes 
>> the problem:
>> 
>>
>> https://code.orgmode.org/bzg/org-mode/commit/48da60f47a77f4b99b4160fa620f258896ff4da3
>> 
>>Reverting to previous commit fixes the problem.
> 
> Gaa!  Looks like I did this.  With the commit one should be able to see
> inline images also in the case when Emacs has been build without
> imagemagick support, at least for newer Emacsens in the 27 line.
> 
> Unfortunately I don't have a Mac and cannot examine the behavior you
> describe AFAICS.
> 
> Hopefully a Org community member with access to a Mac can have a look.
> 
> 


I just updated org, I can see the offending commit.

After refreshing, I have no problems toggling display of inline images.

I have imagemagick and dvipng installed.

MacOS 10.14.6, Emacs 26.1, org release_9.2.6-534-g6f32e7

Is there anything else I can tell you?

HTH,

Chuck




Re: [O] Some whitespace stripped from emacs-lisp value in src blocks making it unreadable in certain cases

2019-09-10 Thread Berry, Charles
> On Sep 9, 2019, at 5:55 PM, akater  wrote:
> 
> Consider a lisp form that, when evaluated, produces another form. I'm
> used to org printing the resulting form nicely, in lisp blocks. However,
> this is not the case for emacs-lisp src blocks. An example:
> 
> 1. The way it should be (and is now the case) with lisp, namely sbcl:
> 
> #+begin_src lisp :results value verbatim :wrap example lisp
> (macroexpand '(defun test (a b  c) "doc" nil))
> #+end_src
> 
> #+RESULTS:
> #+begin_example lisp
> (PROGN
> (EVAL-WHEN (:COMPILE-TOPLEVEL) (SB-C:%COMPILER-DEFUN 'TEST T NIL NIL))
> (SB-IMPL::%DEFUN 'TEST
>  (SB-INT:NAMED-LAMBDA TEST
>  (A B  C)
>"doc"
>(BLOCK TEST NIL
> T
> #+end_example
> 
> 2. The way it is now with emacs-lisp and a src block header that is
> otherwise identical:
> 
> #+begin_src emacs-lisp :results value verbatim :wrap example emacs-lisp
> (macroexpand
>  '(use-package outline
>:ensure nil
>:bind
>(:map outline-mode-map
> ("" . (lambda nil (interactive) (outline-up-heading 1))
> #+end_src
> 


Using emacs 26.1 and org 9.2.5, I get 

#+RESULTS:
#+begin_example emacs-lisp
(use-package outline :ensure nil :bind (:map outline-mode-map ("" 
lambda nil (interactive) (outline-up-heading 1
#+end_example

I am unclear what the effect of `:wrap example emacs-lisp' is here.  AFAICS, 
the `emacs-lisp' has no effect.  Can you point to a place in the code where 
this has effect?

Using `:results value code :wrap src emacs-lisp' as the header args, I get this:

#+RESULTS:
#+begin_src emacs-lisp
(use-package outline :ensure nil :bind
 (:map outline-mode-map
   ("" lambda nil
(interactive)
(outline-up-heading 1
#+end_src

HTH,

Chuck





Re: [O] HTML export with LaTeX babel blocks

2019-08-29 Thread Berry, Charles


> On Aug 28, 2019, at 5:59 PM, Michaël Cadilhac  wrote:
> 
> My goal is to export SVG files of TikZ drawings in HTML.  Now, what follows 
> is a bit of a rant on `org-babel-execute:latex`; let's go through the options:
> 
> -
[snip]

Well you can try to continue on your path, but it can get `interesting'.

An alternative is to do something like this:

Define an export backend that derives from 'html. 

Flesh out the function `org-tikz-html-export-block' to process the content of 
`tikz' export blocks to render the derived SVG. Use existing functions in 
`ox-latex.el' as helpers if that works.

#+begin_src emacs-lisp
  (org-export-define-derived-backend 'tikz-html 'html
:translate-alist '((export-block . org-tikz-html-export-block)))

  (defun org-tikz-html-export-block (export-block contents info)
"Transcoder to TikZ in html exports."
(when (string= (org-element-property :type export-block) "TIKZ")
  (let ((tikz-code 
 (org-remove-indentation
  (org-element-property :value export-block
;; process TikZ code to SVG
;; produce a suitable link to include the SVG as the result
)))
#+end_src


Then blocks like

#+begin_export tikz
% tikz code goes here
#+end_export

should render when you run

#+begin_src emacs-lisp
  (org-export-to-file 'tikz-html "file-name.html") 
#+end_src 

You might adapt `org-html-export-to-html' if the features it offers are needed 
and add a :menu-entry to enable running from the export dispatcher under the 
html choices.

HTH,

Chuck


 




[O] org-babel-insert-result doesn't comma escape properly

2019-08-21 Thread Berry, Charles
Here is an ECM:

#+begin_src emacs-lisp :wrap example
"line 1
,* headline 2
,* headline 3
,* headline 4
,* headline 5
"
#+end_src


With today's master, the last `headline' is not escaped in the example block 
this produces when executed.

It seems to me that dropping the let binding for `before-finish' and placing

(unless no-escape
  (org-escape-code-in-region
   beg end))

before the insertions of 'start' and 'finish' should handle this properly. And 
trying that on the above ECM gives the right result.

That let binding was introduced in 

commit 24a76fbe572923c55774bc9f8ecc8e6d1c7ff16d
Author: Nicolas Goaziou 
Date:   Sun Aug 13 16:20:20 2017 +0200

I do not see why it was needed.

Best,

Chuck



Re: [O] getting access to a self-invented option?

2019-08-07 Thread Berry, Charles
Correction below.

[snip]

> 
>> 
>> I guess another option is to just set a buffer-local variable in the file, 
>> or use #+FILETAGS: and hack htings that way. I'm not sure what the most 
>> sustainable & org-like method relaly is... 
>> 
> 


> The obvious choice for a local file setting is an OPTION. Since your 'huveal 
> backend already has an :options-alist, you can just add another option for 
> `:mwp-export-type' there. If you want access to the value before 
> `org-export-as' runs, try something like 
> 
>   (plist-get (org-export-get-environment) :mwp-export-type) 


Rather

(plist-get (org-export-get-environment 'huveal) :mwp-export-type)

is needed to access your custom options before export is underway. 

Chuck



Re: [O] getting access to a self-invented option?

2019-08-07 Thread Berry, Charles
Matt,

See inline.

> On Aug 7, 2019, at 8:36 AM, Matt Price  wrote
> 
> 
> On Sat, Aug 3, 2019 at 1:42 PM Berry, Charles  wrote:
> Matt,
> 
> This seems like a good use case for a `derived-backend'.
> 
> You can use  `org-export-define-derived-backend' with 'hugo as the parent, 
> define a :menu-entry to add an export action for your custom export to the 
> hugo menu using '?m' (say) as the key.
> 
> Then 
> 
> C-c C-e H m
> 
> will export using your custom variant of hugo.
> 
> :-) I'm trying to use the variable to determine whether I export with hugo or 
> with my hugo-reveal franken-backend: 
> https://github.com/titaniumbones/ox-huveal . So my preference is to evaluate 
> the variable BEFORE export begins. 

But `org-export-as' doesn't execute until the dispatcher has run and the choice 
of hugo or hugo-reveal has been made. 

However, if this determination is permanently set for a particular file (you 
only export in one manner according to the variable and never alter the 
variable), then see below.


> 
> I guess another option is to just set a buffer-local variable in the file, or 
> use #+FILETAGS: and hack htings that way. I'm not sure what the most 
> sustainable & org-like method relaly is... 
> 

The obvious choice for a local file setting is an OPTION. Since your 'huveal 
backend already has an :options-alist, you can just add another option for 
`:mwp-export-type' there. If you want access to the value before 
`org-export-as' runs, try something like 

(plist-get (org-export-get-environment) :mwp-export-type) 


HTH,

Chuck



Re: [O] getting access to a self-invented option?

2019-08-03 Thread Berry, Charles
Matt,

This seems like a good use case for a `derived-backend'.

You can use  `org-export-define-derived-backend' with 'hugo as the parent, 
define a :menu-entry to add an export action for your custom export to the hugo 
menu using '?m' (say) as the key.

Then 

C-c C-e H m

will export using your custom variant of hugo.


HTH,

Chuck


> On Aug 2, 2019, at 9:10 AM, Matt Price  wrote:
> 
> I'm trying to streamline some veyr ad-hoc workflows I have. One thing I do a 
> lot during the school year is make some changes to an org source file, and 
> then export to hugo markdown with ox-hugo, and finally commit to git (after 
> that I have a git hook that generates the website & uploads the changed pages 
> to the appropriate location, usually a github-pages branch or separate repo). 
> 
> So I have this code:
> 
> (defun mwp-hugo-export-and-release ()
>   "Make it faster and easier to put my lectures up on the website."
>   (interactive)
>   
>   (let* ((modfile (org-hugo-export-wim-to-md))
>  (basedir (plist-get  (org-export-get-environment 'hugo) 
> ':hugo-base-dir ))
>  (default-directory (expand-file-name basedir)))
> (magit-stage-file modfile)
> ;; (magit-status)
> (magit-commit-create)
> )  )
> 
> It works great, I'm very happy. HOWEVER: in my websites I have two kinds of 
> outputs: 
> 
> - regular pages -- these get exported to .md files and turned into html by 
> hugo
> - lecture notes -- these get exported to reveal.js HTML pages by 
> org-re-reveal and my hugo theme treats them differently .
> 
> I would really like to set a switch somewhere in the file, something like:
> 
> #+MWP_EXPORT_TYPE: slides
> 
> And then something like 
> 
> let* ((modfile (if (eq :mwp-export-type "slides") 
> (mwp-hugo-reveal-custom-export-function)
>(org-hugo-export-wim-to-md)))
>  etc)
> do stuff)
> 
> 
> But I'm not sure how to get access to a totally non-standard option like the 
> kind I just invented in that last bit of pseudo-code. Anyone have a good 
> suggestion?
> 
> Thank you as always!
> 
> Matt





Re: [O] Contribution of a :confirm-evaluate flag to src blocks

2019-07-18 Thread Berry, Charles
Gentlemen,

I think you have stepped onto a slippery slope.

Adding an :eval option that turns off confirmation queries without user 
intervention defeats the security purpose stated for 
`org-confirm-babel-evaluate'.

Likewise, adding a new header argument that turns off such checks may have 
pernicious effects.

A better option IMO is to use existing features of babel to accomplish the end 
you desire. 

A simple option is to have a src block that let binds 
org-confirm-babel-evaluate to nil, then navigates to and executes another src 
block that contains noweb statements that execute other blocks. The user is 
prompted just once and the global behavior of `org-confirm-babel-evaluate' is 
unaltered.

There are many ways to achieve this kind of behavior and/or fine tune the 
prompting behavior with existing babel capabilities.

HTH,

Chuck

p.s. I do not get what is `too crude' about using `org-confirm-babel-evaluate'. 
Maybe an ECM would help others understand what motivates this judgment.

> On Jul 18, 2019, at 12:21 PM, Kyle Meyer  wrote:
> 
> Mackenzie Bligh  writes:
> 
>> Do you have any suggestions for the name of such a value?
> 
> I tried to avoid being responsible for a poorly chosen name :]
> 
> "'yes' or 'always'" pairs well with the existing "'no' or 'never'", but
> I suppose that risks users not realizing that it implies not querying.
> Perhaps 'eval-no-query', 'eval-without-query', or just 'without-query'?
> 
> 





Re: [O] change tables to matrix when importing, including expressions.

2019-06-13 Thread Berry, Charles
[snip]

> On Jun 13, 2019, at 6:26 AM, Uwe Brauer  wrote:
> 
> 
> However I would like 
> #+begin_src 
> #+attr_latex: :mode math :environment matrix
> D=
> | 0 | -5 |
> | 5 |  0 |
> #+end_src
> 
> To be exported as 
> 
> #+begin_src 
> \[
> D=
> \begin{matrix}
> 0 & -5 \\
> 5 & 0 \\
> \end{matrix}
> \]
> #+end_src
> 
> How can I do that? 


This is morally equivalent:


#+attr_latex: :mode math :math-prefix D= :environment matrix
| 0 | -5 |
| 5 |  0 |


There will be no newline between the '=' and the '\begin'. If that is something 
you truly need you will have to add a filter. See (info "(org) Advanced Export 
Configuration").

HTH,

Chuck



Re: [O] suppress leading ":" in org-babel outputariBLE

2019-05-31 Thread Berry, Charles
AFAICS, the latest update (99aa984) did NOT fix the issue.

There are complications in this story that I explain here.

If I start a fresh *R* session by eval'ing the src block, I get

#+RESULTS:
: 
: 12.23

and the *R* buffer ends with

--8<---cut here---start->8---
> x <- 6L
a <-sprintf("%.2f",12.234324)
cat(a,sep="\n")
'org_babel_R_eoe'
> > 
12.23
> 
[1] "org_babel_R_eoe"
> 
--8<---cut here---end--->8---


If I then open a buffer in ESS[R] mode and run ess-eval-line-visibly-and-step 
(e.g. by typing C-c C-n)

and then eval the src block again, I get 

#+RESULTS:
: 12.23

and the *R* buffer ends with

--8<---cut here---start->8---
> x <- 6L
a <-sprintf("%.2f",12.234324)
cat(a,sep="\n")
'org_babel_R_eoe'
> > 12.23
> [1] "org_babel_R_eoe"
> 
--8<---cut here---end--->8---


Presumably, a comint or ess variable has changed to effect these differences.

I am unable to discern what variable that is. 

I suspect that the changed behavior Jeremie sees now was do to something 
similar and that a fresh start will result in the extraneous line in the 
results.

:-(

Chuck


> On May 31, 2019, at 12:05 AM, Jeremie Juste  wrote:
> 
> Hello,
> 
> Many thanks updating org-mode resolved the issue
> 
> Best regards,
> Jeremie
>> FWIW, I just get the last line:
>> 
>> #+NAME:mean_purchase_per_shopping_trip
>> 
>> #+BEGIN_SRC R :var x=6 :results output :session *R*
>> a <-sprintf("%.2f",12.234324)
>> cat(a,sep="\n")
>> #+END_SRC
>> 
>> #+RESULTS:
>> : 12.23
>> 
>> This is with 
>> 
>>   GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 
>> 2019-05-01
>>   Org mode version 9.2.3 (release_9.2.3-367-gd79e80 @ 
>> /home/nick/elisp/org-mode/lisp/)
>>   R version 3.5.3 (2019-03-11) -- "Great Truth"
>> 
>> on Fedora 29.
> 
> 





[O] Outdated manual web pages left in place WAS: Re: Problems with inline source blocks

2019-05-28 Thread Berry, Charles
The OP cited this web page:

https://orgmode.org/manual/Exporting-code-blocks.html

but the link from https://orgmode.org/#docs

to the manual eventually leads this web page:

https://orgmode.org/manual/Exporting-Code-Blocks.html

which is different (note capitalization of "Code" and "Blocks").

I guess that capitalizing the words in the web page URL leaves the outdated 
page in place.

HTH,

Chuck



  1   2   3   >