Re: citation biblatex fullcite

[Andreas Leha]

Dear Bruce,

"Bruce D'Arcus"  writes:

> On Wed, May 11, 2022 at 6:43 AM Andreas Leha
>  wrote:
>>
>> "Bruce D'Arcus"  writes:
>>
>> > On Tue, May 10, 2022, 11:20 PM Andreas Leha
>> >  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> how can I use the (rather) new citation engine with the biblatex backend
>> >> to export to \fullcite ?
>> >
>> > We should add a style for this that maps to biblatex fullcite and
>> > natbib bibentry, and which ultimately would work as well in oc-csl.
>> >
>> > But in the meantime, you can create a custom one.
>> >
>> > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
>> >
>>
>> Dear Bruce and Dominik,
>>
>> Thanks for the swift reply!  I seem to be missing something:
>>
>> Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles)
>>
>> What am I missing?
>
> That variable was added more recently, after org-cite was merged.
>
> Perhaps you have an older version?
>

Thanks.  Well, time to update I guess.  But that'll have to wait until
my current lecture is over.  Never change a running system

Best,
Andreas

Re: source block evaluation in #+DATE line

[Andreas Leha]

Dear Eric,

Eric S Fraga  writes:

> On Wednesday, 11 May 2022 at 17:50, Eric S Fraga wrote:
>> ⚠️ Caution: External sender
>>
>>
>> On Wednesday, 11 May 2022 at 05:15, Andreas Leha wrote:
>>> Thanks for the comments.  And sorry for the misleading example.  I do not
>>> want to use source blocks to insert a date.  In fact I want to include
>>> the current git commit hash on the title slide.
>>
>> I do this by:
>
> [...] which I now realise uses a src block so probably not what you
> want/need.


On the contrary.  This is brilliant!  I had not thought getting the full
#+DATE line to be generated via a code block.  I've adopted your idea to
my needs and it works perfectly now.

Thanks a lot.

Best,
Andreas

Re: citation biblatex fullcite

[Andreas Leha]

"Bruce D'Arcus"  writes:

> On Tue, May 10, 2022, 11:20 PM Andreas Leha
>  wrote:
>>
>> Hi all,
>>
>> how can I use the (rather) new citation engine with the biblatex backend
>> to export to \fullcite ?
>
> We should add a style for this that maps to biblatex fullcite and
> natbib bibentry, and which ultimately would work as well in oc-csl.
>
> But in the meantime, you can create a custom one.
>
> (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
>

Dear Bruce and Dominik,

Thanks for the swift reply!  I seem to be missing something:

Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles)

What am I missing?

Best,
Andreas



> Bruce
>
>> The use-case:
>> When creating (beamer) presentations I prefer to have the full citation
>> on the slide rather than an abbreviation.
>>
>> Thanks in advance!
>>
>> Best,
>> Andreas
>>
>>

citation biblatex fullcite

[Andreas Leha]

Hi all,

how can I use the (rather) new citation engine with the biblatex backend
to export to \fullcite ?

The use-case:
When creating (beamer) presentations I prefer to have the full citation
on the slide rather than an abbreviation.

Thanks in advance!

Best,
Andreas

Re: source block evaluation in #+DATE line

[Andreas Leha]

Hi Kaushal and Jeremie,

Thanks for the comments.  And sorry for the misleading example.  I do not
want to use source blocks to insert a date.  In fact I want to include
the current git commit hash on the title slide.

So, something like this:

src_sh[:exports results :results output wrap replace]{git describe --always 
--dirty}


But that is not evaluated...

Any hint?

Thanks,
Andreas




Kaushal Modi  writes:

> Also check out the {{{time}}} macro if you want complete control on
> the formatting of the date string.
>
> Example Org snippet:
>
> =
>
> #+date: {{{time(%Y-%m-%d)}}}
> #+options: toc:nil author:nil
>
>
> See the ~{{{time}}}~ macro in [[info:org#Macro Replacement][org#Macro
> Replacement]].
>
> The format passed to the ~time~ macro is same as that understood by
> [[help:format-time-string]].
>
> - Note :: Remember to escape the commas. \\
>   Example: ~#+date: {{{time(%b %e %Y\, %a)}}}~.
>
> #+begin_src emacs-lisp
> (org-export-as 'ascii)
> #+end_src
>
> =

source block evaluation in #+DATE line

[Andreas Leha]

Hi all,

how can I have a source block result in a #+Date line?

I am creating a beamer presentation.  While the code works and the
results get exported nicely at any other position, in the #+Date line
only the code is exported.

Here is the MWE:

-
#+TITLE: MWE
#+AUTHOR:Me
#+EMAIL: me@all
#+DATE:  Only Code Exported: src_sh[:exports results :results output wrap 
replace]{date}
#+LaTeX_CLASS: beamer
#+OPTIONS: H:2

* Demonstration
** Inline Code Blocks Are Not Executed Everywhere

- Here, the results are correctly exported: src_sh[:exports results :results 
output wrap replace]{date}
- But in the =#+DATE:= line only the code is exported
-

Thanks in advance!

Best,
Andreas

- GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
  cairo version 1.16.0) of 2022-03-08
- Org mode version 9.5.3

Re: Why is there no inline-src syntax highlighting?

[Andreas Leha]

Timothy  writes:

> Hi all,
>
> It's great how #+begin_src blocks support 'native' syntax highlighting,
> but inline src_lang{} blocks don't seem to be formatted/highlighted at
> all.
>
> I'm wondering why this is. Might anyone know?
>
> Also, if this is just a case of no-one bothering to provide that
> functionality would there be any interest in me submitting
> https://tecosaur.github.io/emacs-config/config.html#fontifying-inline-src
> as a patch? (see https://0x0.st/-ZRa.png for a preview, this also
> includes prettifying {{{results()}}}, which I'm quite a fan of).


It seems to work great here.

Best,
Andreas

Re: [O] [babel] return file from R

[Andreas Leha]

Hi Chuck,

"Charles C. Berry" <ccbe...@ucsd.edu> writes:
> On Tue, 19 Jan 2016, Andreas Leha wrote:
>
>> Hi Chuck,
>>
>
> [snip]
>
>> I've tested your patch and it seems to work.  But it does seem to need
>> an analogous change in org-babel-R-evaluate-session to also cure blocks
>> with ':session'.
>>
>
> Correct. I committed a patch like this and added a test
>

Thanks!

Andreas

Re: [O] [babel] return file from R

[Andreas Leha]

Hi Chuck,

Thanks for following that up.  And sorry for the long delay.


"Charles C. Berry" <ccbe...@ucsd.edu> writes:
> On Thu, 17 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I think there is a bug in the handling of results of R src blocks.  What
>> is the suggested way to make an R block return a link to a file?  The
>> obvious way appends a newline character to the file link (which is
>> broken because of that).
>>
>> Here is an example:
>> --8<---cut here---start->8---
>> #+NAME: TESTSRC
>> #+BEGIN_SRC R :results file
>>  a <- file.path("junk", "test.org")
>>  a
>> #+END_SRC
>>
>> #+RESULTS: TESTSRC
>> [[file:junk/test.org
>> ]]
>>
>> --8<---cut here---end--->8---
>
>
> That *is* the suggested way, and it will work in (say) emacs-lisp. The
> problem for `:results value' (the default) is that a newline is added
> to the result by `org-babel-R-evaluate-external-process'.
>
> This *might* be the fix, but I do not have time to check it thoroughly:
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index f72cd95..f660bbd 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -397,7 +397,7 @@ last statement in BODY, as elisp."
>   (org-babel-result-cond result-params
> (with-temp-buffer
>   (insert-file-contents tmp-file)
> - (buffer-string))
> + (org-babel-chomp (buffer-string) "\n"))
> (org-babel-import-elisp-from-file tmp-file '(16)))
>   column-names-p)))
>  (output (org-babel-eval org-babel-R-command body
>
>
> In the meanwhile, you can work around by using `:results output' and
> wrapping the result in cat().
>

Using the ':results output' work around won't work on most of my code
blocks as these are typically longer and more verbose.  So, that really
is just a work-around.

I've tested your patch and it seems to work.  But it does seem to need
an analogous change in org-babel-R-evaluate-session to also cure blocks
with ':session'.

--8<---cut here---start->8---
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index f72cd95..193548e 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -397,7 +397,7 @@ last statement in BODY, as elisp."
(org-babel-result-cond result-params
  (with-temp-buffer
(insert-file-contents tmp-file)
-   (buffer-string))
+   (org-babel-chomp (buffer-string) "\n"))
  (org-babel-import-elisp-from-file tmp-file '(16)))
column-names-p)))
 (output (org-babel-eval org-babel-R-command body
@@ -431,7 +431,7 @@ last statement in BODY, as elisp."
(org-babel-result-cond result-params
  (with-temp-buffer
(insert-file-contents tmp-file)
-   (buffer-string))
+   (org-babel-chomp (buffer-string) "\n"))
  (org-babel-import-elisp-from-file tmp-file '(16)))
column-names-p)))
 (output
--8<---cut here---end--->8---


Regards,
Andreas

Re: [O] Changing org-block background with org-src-fontify-natively

[Andreas Leha]

Hi,

John Kitchin  writes:

> It doesn't sounds like there is a way to do language specific colors.
> Karl Voit writes:

>> * Nick Dokos  wrote:

[ ... ]

>>
>> It would be fine to have both: org-src-fontify-natively *and* a
>> background colour I can set.

I'd like to 'back' this feature request.

My Org mode experience would also benefit a lot from having source block
backgrounds again and with per-language configurable background colour.

Regards,
Andreas

[O] [babel] return file from R

[Andreas Leha]

Hi all,

I think there is a bug in the handling of results of R src blocks.  What
is the suggested way to make an R block return a link to a file?  The
obvious way appends a newline character to the file link (which is
broken because of that).

Here is an example:
--8<---cut here---start->8---
#+NAME: TESTSRC
#+BEGIN_SRC R :results file
  a <- file.path("junk", "test.org")
  a
#+END_SRC

#+RESULTS: TESTSRC
[[file:junk/test.org
]]

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

Regards,
Andreas

[O] cache and lint

[Andreas Leha]

Hi all,

I just had an error (something including "search" and "wrong side" ...)
during org-lint.  As it turned out this error went away after I ran
`org-element-cache-reset'.  Hence my question: Would it make sense to
include running `org-element-cache-reset' into `org-lint'?

Best,
Andreas

[O] [lint] imagemagick

[Andreas Leha]

Hi all, 

I get a spurious linting warning
,
| high  Unknown header argument ":imagemagick"
`

While that header argument should be valid for latex blocks.

Regards,
Andreas

Re: [O] [lint] imagemagick

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> I get a spurious linting warning
>> ,
>> | high  Unknown header argument ":imagemagick"
>> `
>>
>> While that header argument should be valid for latex blocks.
>
> Assuming possible values for :imagemagick are nil and t, this is now
> fixed in master.
>

Thanks a lot!

I am not sure about the possible values, though.  babel header arguments
usually take 'yes' and 'no' as values for TRUE and FALSE.  Examples are
:tangle, :comments, etc.
So, I have been using ':imagemagick yes' until now.

But on the other hand ':imagemagick no' is not doing the expected thing.

Regards,
Andreas

Re: [O] cache and lint

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> I just had an error (something including "search" and "wrong side" ...)
>> during org-lint.  As it turned out this error went away after I ran
>> `org-element-cache-reset'.  Hence my question: Would it make sense to
>> include running `org-element-cache-reset' into `org-lint'?
>
> I don't think this should be the default, no. This will delete useful
> information.

I know next to nothing about all the internals here, so I guess you are
right.  My motivation to write here was just to minimize the chance that
org-lint reports errors that are not caused by the document itself.

>
> The cache bug leading to the error should be fixed, tho.

I am sorry, that I cannot be of more help anymore.  Luckily, the error
is gone right now...

Regards,
Andreas

Re: [O] [lint] imagemagick

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> I am not sure about the possible values, though.  babel header arguments
>> usually take 'yes' and 'no' as values for TRUE and FALSE.
>
> Which is, IMO, a mistake. Lisp has already some definition of TRUE and
> FALSE which is not language-centric.

I agree completely.

>
>> Examples are :tangle, :comments, etc. So, I have been using
>> ':imagemagick yes' until now.
>>
>> But on the other hand ':imagemagick no' is not doing the expected
>> thing.
>
> I looked at the source and every time, :imagemagick is treated as
> a boolean, so "yes" and "no" are equivalent to t.

Exactly.  I guess my implicit question was, whether we should aim to
make :imagemagick accept 'no' as nil to be consistent with the general
org babel conventions.

As I get it, you would say: no.

(The next question would be whether we live with inconsistency or
whether we should switch the other header arguments backward
incompatibly use t and nil as well...)

>
> At least, the declaration seems on par with the source.

Yes, thanks!

Andreas

Re: [O] [babel] return file from R

[Andreas Leha]

Hi Chuck,

"Charles C. Berry" <ccbe...@ucsd.edu> writes:
> On Thu, 17 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I think there is a bug in the handling of results of R src blocks.  What
>> is the suggested way to make an R block return a link to a file?  The
>> obvious way appends a newline character to the file link (which is
>> broken because of that).
>>
>> Here is an example:
>> --8<---cut here---start->8---
>> #+NAME: TESTSRC
>> #+BEGIN_SRC R :results file
>>  a <- file.path("junk", "test.org")
>>  a
>> #+END_SRC
>>
>> #+RESULTS: TESTSRC
>> [[file:junk/test.org
>> ]]
>>
>> --8<---cut here---end--->8---
>
>
> That *is* the suggested way, and it will work in (say) emacs-lisp. The
> problem for `:results value' (the default) is that a newline is added
> to the result by `org-babel-R-evaluate-external-process'.

Thanks for the confirmation.

>
> This *might* be the fix, but I do not have time to check it thoroughly:
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index f72cd95..f660bbd 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -397,7 +397,7 @@ last statement in BODY, as elisp."
>   (org-babel-result-cond result-params
> (with-temp-buffer
>   (insert-file-contents tmp-file)
> - (buffer-string))
> + (org-babel-chomp (buffer-string) "\n"))
> (org-babel-import-elisp-from-file tmp-file '(16)))
>   column-names-p)))
>  (output (org-babel-eval org-babel-R-command body
>

I'll try to test this in the next days.

>
> In the meanwhile, you can work around by using `:results output' and
> wrapping the result in cat().

Yes.  But usually my source blocks are more noisy and produce some
messages, which would break this approach.

Thanks again,
Andreas

Re: [O] Problem with org-export--delete-comments

[Andreas Leha]

Hi Nicolas and Ethan,

Nicolas Goaziou  writes:
> Hello,
>
> Ethan Ligon  writes:
>
>> I've long used the following construction for displayed equations in org
>> #
>> \[
>> u_i(c)=p_i\lambda
>> \]
>> #
>> which (i) gives nice space for reading equations in the org-source, and 
>> (ii) nicely protects the display equation from (fill-paragraph) and 
>> friends.
>>
>> However, exporting with this construction *stopped* working after commit 
>> 53a4209; what happens now is that ox.el replaces the # with a blank line, 
>> breaking my single paragraph into  three.
>
> I see only one paragraph above. Could you elaborate a bit?

I think the problem is in the exported latex file rather than in the org
document.  While the org document indeed has one paragraph the exported
latex file does not.  I can reproduce this.

With this org document:

--8<---cut here---start->8---
* Test

I've long used the following construction for displayed equations in org
#
\[
u_i(c)=p_i\lambda
\]
#
which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
--8<---cut here---end--->8---


I get this latex doc (relevant part only):

--8<---cut here---start->8---
\section{Test}
\label{sec:orgheadline1}

I've long used the following construction for displayed equations in org

\[
u_i(c)=p_i\lambda
\]

which (i) gives nice space for reading equations in the org-source, and
(ii) nicely protects the display equation from (fill-paragraph) and
friends.
--8<---cut here---end--->8---

I agree that the paragraph should not be broken in the exported
document.  There are also other use cases for comments inside
paragraphs.

[ ... ]

Regards,
Andreas

Re: [O] Problem with org-export--delete-comments

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> I agree that the paragraph should not be broken in the exported
>> document.  There are also other use cases for comments inside
>> paragraphs.
>
> Note that Org doesn't support comments within paragraphs since a comment
> ends a paragraph. In this case, the export output matches the contents
> of the document.
>
> Again, I'm not sure there is a solution satisfying all needs here. 
>

I do not really follow the footnote problem (not using footnotes much)
with this.  But if removing the line following the comment works, then
I'd suggest to simply also comment that newline.

In my opinion comments are not newlines.  Exporting comment lines as
newlines makes it impossible to comment newlines, which might be
desirable -- see this thread.

But I might be missing the point here.

> However, you can mimic inline comments with export snippets, e.g.,
> @@comment:...@@.

That is handy.  I would not have thought of that.

Regards,
Andreas

[O] [babel] noweb reference with default values

[Andreas Leha]

Hi all,

I'd like to hear your ideas on how to include noweb references to code
blocks in a way that the default values are used as parameter values.

Here is a little example:

#+PROPERTY: header-args:R :session *testR*

The background is that I like to use Org mode table to record small data.

#+name: datatable
| A |  B |
|---+|
| 1 | 10 |
| 2 | 20 |

Usually I want to pre-process and/or convert such data.

#+name: read_datatable
#+header: :var datatable=datatable
#+begin_src R :results none
  datatable$B <- 10 * datatable$B 
#+end_src

Later I would like to use that data in larger (R-) code blocks.  I'd
like such code blocks to DWIM:

#+name: some_code
#+begin_src R :noweb yes :results graphics :file testplot.png
  <>
  plot(datatable$A, datatable$B)
#+end_src

But they do not: They are not stand alone and do not execute -- unless I
executed `read_datatable' manually/by chance upfront.



My current solution is to export the table to csv and read that csv in
`read_datatable'.

If the result of `read_datatable' is a single table again (as in this
MWE) I usually return that to Org mode which works ok.  But often the
result is more complex than that.

I see two ways to go:
- I could serialize more complex objects to disk and return a file name.
  But I'd prefer to not go through disk.
- I could pass the same arguments as to `read_datatable' also to
  `some_code'.  But that is duplication and becomes quite convoluted in
  the case of several noweb references with several arguments each.

Any ideas how to do that better?

Thanks,
Andreas

Re: [O] [babel] noweb reference with default values

[Andreas Leha]

Hi Chuck,

"Charles C. Berry" <ccbe...@ucsd.edu> writes:
> On Mon, 14 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I'd like to hear your ideas on how to include noweb references to code
>> blocks in a way that the default values are used as parameter values.
>>
>> Here is a little example:
>>
>> #+PROPERTY: header-args:R :session *testR*
>>
>> The background is that I like to use Org mode table to record small data.
>>
>> #+name: datatable
>> | A |  B |
>> |---+|
>> | 1 | 10 |
>> | 2 | 20 |
>>
>> Usually I want to pre-process and/or convert such data.
>>
>> #+name: read_datatable
>> #+header: :var datatable=datatable
>> #+begin_src R :results none
>>  datatable$B <- 10 * datatable$B
>> #+end_src
>>
>> Later I would like to use that data in larger (R-) code blocks.  I'd
>> like such code blocks to DWIM:
>>
>> #+name: some_code
>> #+begin_src R :noweb yes :results graphics :file testplot.png
>>  <>
>>  plot(datatable$A, datatable$B)
>> #+end_src
>>
>> But they do not: They are not stand alone and do not execute -- unless I
>> executed `read_datatable' manually/by chance upfront.
>
> Try this:
>
> #+name: read_datatable
> #+header: :var datatable=datatable
>
> #+begin_src R :results value :colnames yes
>datatable$B <- 10 * datatable$B
>datatable
> #+end_src
>
> #+name: some_code
> #+HEADER: :var datatable=read_datatable()
>
> #+begin_src R :noweb yes :results graphics :file testplot.png
> plot(datatable$A, datatable$B)
> #+end_src
>

Thanks!  I am aware of that possibility.  Should have posted a more
involved example.  This works if I only return a table.  Or something
else, that can be passed through Org.  But it fails for instance if the
result is a function (or more functions...).

Regards,
Andreas

Re: [O] export subtree

[Andreas Leha]

Hi Skip,

Skip Collins  writes:
> The export dispatcher allows me to export only the current subtree.
> This is nice, but I would like to avoid having to put point in just
> the right place before invoking the dispatcher. I have a document with
> lots of things in it. One of the top-level headlines contains the
> content of what I want to export. Is there a way to flag this heading
> and its contents as the main export document so that wherever my
> cursor is, when I export the document it only processes the correct
> heading, treating its text as the title of the document?

Try to run `org-export-dispatch' with a prefix from the second time
onwards (so, do C-u C-c C-e).

>From its docstring:

,
| When ARG is C-u, repeat the last export action, with the same set
| of options used back then, on the current buffer.
`

This might do what you want already.

Regards,
Andreas

Re: [O] export subtree

[Andreas Leha]

Hi Skip,

Skip Collins <skip.coll...@gmail.com> writes:
> Andreas Leha <andreas.l...@med.uni-goettingen.de> wrote:
>>> The export dispatcher allows me to export only the current subtree.
>>> This is nice, but I would like to avoid having to put point in just
>>> the right place before invoking the dispatcher. I have a document with
>>> lots of things in it. One of the top-level headlines contains the
>>> content of what I want to export. Is there a way to flag this heading
>>> and its contents as the main export document so that wherever my
>>> cursor is, when I export the document it only processes the correct
>>> heading, treating its text as the title of the document?
>>
>> Try to run `org-export-dispatch' with a prefix from the second time
>> onwards (so, do C-u C-c C-e).
>
> Good try, but it does not do what I want. It selects the subtree
> currently at point, just as if I ran the dispatcher again and selected
> the same options. It might be a nice enhancement if the dispatcher
> remembered which subtree it used last time so that it really could
> repeat a subtree export with the same options and from the same
> subtree.

That is what it does for me.  As I said, you have to do the first export
the normal way.

What is your Org version (M-x org-version)?

Regards,
Andreas

Re: [O] Jumping between source blocks in a file

[Andreas Leha]

Hi Andrew,

Martin Yrjölä  writes:
> Hi Andrew!
>
> Andrew Kirkpatrick writes:
>
>> If this is deemed useful, I'm happy to make changes suitable for
>> inclusion in the project.
>
> Thanks for sharing! I would certainly want these functions included in
> org-mode by default. They streamline at least my literate programming
> workflow substantially.
>

Sorry for joining late.  I too find these useful.

(Also useful would be the possibility to jump to noweb references
directly from the src buffer...)

Regards,
Andreas

Re: [O] Jumping between source blocks in a file

[Andreas Leha]

Rainer M Krug <rai...@krugs.de> writes:
> Rainer M Krug <rai...@krugs.de> writes:
>
>> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>>
>>> Hi Andrew,
>>>
>>> Martin Yrjölä <martin.yrj...@gmail.com> writes:
>>>> Hi Andrew!
>>>>
>>>> Andrew Kirkpatrick writes:
>>>>
>>>>> If this is deemed useful, I'm happy to make changes suitable for
>>>>> inclusion in the project.
>>>>
>>>> Thanks for sharing! I would certainly want these functions included in
>>>> org-mode by default. They streamline at least my literate programming
>>>> workflow substantially.
>>>>
>>>
>>> Sorry for joining late.  I too find these useful.
>>
>> Absolutely - very useful. Please include!
>>>
>>> (Also useful would be the possibility to jump to noweb references
>>> directly from the src buffer...)
>>
>> Very nice idea indeed - or possibly even expand them when executing? But
>> I think this would be a job for the mode in the source buffer...
>
> Actually, expand them when opening the Source Buffer (C-c ') and
> possibly update them when closing?
>

This might conflict with open Source Buffers for the referenced code
block.

>>
>> At the moment, these noweb references are very nice, but not so nice when
>> debugging a source block where they are used.

Exactly.

Regards,
Andreas

Re: [O] LATEX text in figure environment

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Hi
>
> I want to add a todo note (from the todonotes package) in a figure
> environment. What I want should look as follow, so that the to note sits
> in the environment (based on [http://tex.stackexchange.com/a/256802/6941]
> ):
>
> ,
> | \begin{figure}[htb]
> | \centering
> | \includegraphics[width=.9\linewidth]{fig-strategies.pdf}
> | \caption{from \cite{Roura-Pascual2009_rmkc}}
> | \todo[inline]{This figure needs to be redone and further info added}
> | \end{figure}
> `
>
> I tried
>
> #+LATEX: \todo[inline]{This figure needs to be redone and further info added}
> #+CAPTION: from cite:Roura-Pascual2009_rmkc
> [[file:fig-strategies.pdf]]
>
>
> but this results in the todo being outside the environment:
>
> ,
> | \todo[inline]{This figure needs to be redone and further info added}
> | \begin{figure}[htb]
> | \centering
> | \includegraphics[width=.9\linewidth]{fig-strategies.pdf}
> | \caption{from \cite{Roura-Pascual2009_rmkc}}
> | \end{figure}
> `
>
> #+CAPTION: from cite:Roura-Pascual2009_rmkc
> [[file:fig-strategies.pdf]]
> #+LATEX: \todo[inline]{This figure needs to be redone and further info added}
>
>
> resulting in the todo being behind the environment and
>
> #+CAPTION: from cite:Roura-Pascual2009_rmkc
> #+LATEX: \todo[inline]{This figure needs to be redone and further info added}
> [[file:fig-strategies.pdf]]
>
>
> resulting in no environment at all (as #+CAPTION is not before the
> figure).
>
> At the moment I am using
>
> #+begin_figure
> {{{if-latex-else([[file:fig-strategies.pdf]], [[file:fig-strategies.png]])}}}
> #+LATEX: \caption{from \cite{Roura-Pascual2009_rmkc}}
> #+LATEX: \todo[inline]{This figure needs to be redone and further info added}
> #+end_figure
>
> which gives me what I want:
>
>
> ,
> | \begin{figure}
> | \includegraphics[width=.9\linewidth]{fig-strategies.pdf}
> | \caption{from \cite{Roura-Pascual2009_rmkc}}
> | \todo[inline]{This figure needs to be redone and further info added}
> | \end{figure}
> `
>
> But it is really not org-ish (caption specified as LaTeX, citation as
> latex, environment specified).
>
> Is there a way to achieve this more org like? Am I missing some #+?
>

Does this do what you want?

#+ATTR_LATEX: :caption \caption{from 
cite:Roura-Pascual2009_rmkc}\todo[inline]{This figure needs to be redone and 
further info added}
[[file:fig-strategies.pdf]]

Best,
Andreas

Re: [O] LATEX text in figure environment

[Andreas Leha]

Rainer M Krug  writes:
> Rasmus  writes:
>
>> Rainer M Krug  writes:
>>
>>> Hi
>>>
>>> I want to add a todo note (from the todonotes package) in a figure
>>> environment. What I want should look as follow, so that the to note sits
>>> in the environment (based on [http://tex.stackexchange.com/a/256802/6941]
>>> ):
>>>
>>> ,
>>> | \begin{figure}[htb]
>>> | \centering
>>> | \includegraphics[width=.9\linewidth]{fig-strategies.pdf}
>>> | \caption{from \cite{Roura-Pascual2009_rmkc}}
>>> | \todo[inline]{This figure needs to be redone and further info added}
>>> | \end{figure}
>>> `
>>
>> This works up to the order of caption and the todo macro.
>>
>> #+caption: from \cite{Roura-Pascual2009_rmkc}
>> #+begin_figure
>> [[file:fig-strategies.pdf]]
>> #+latex: \todo[inline]{This figure needs to be redone and further info added}
>> #+end_figure
>
> Thanks,
>
> Rainer

Hi Rainer,

And if you do not mind the todonote in the caption (should work, I
guess) this might work as well:

#+CAPTION: from cite:Roura-Pascual2009_rmkc @@latex:\todo[inline]{This figure 
needs to be redone and further info added}@@
[[file:fig-strategies.pdf]]

Best,
Andreas

Re: [O] @@latex:...@@ syntax - where can I find info on it?

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Hi
>
> I read at tha moment a lot of mails here regarding the @@latex:...@@ (or
> @@html:...@@) syntax. I understand d=that these fragments are only
> inserted when the corresponding backend is used - correct?
>
> Where can I find further information on this? i in the org-info file
> does not give anything (except C-@ which is something completely
> different) and googling also nothing?
>

I am not aware of a central place for this.  But it is mentioned in
the backend specific manual pages of section 12.  For instance
[[http://orgmode.org/manual/Quoting-LaTeX-code.html#Quoting-LaTeX-code][Section
12.7.4 Quoting LaTeX code]] for the latex case.

Best,
Andreas

Re: [O] Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Martin Carlé <m...@aiguphonie.com> writes:
>
>> On 2015-11-04 Wed 14:14, Andreas Leha wrote:
>>
>>> ,---
>>> | > I'd say it is a bug if the results from evaluation differ between
>>> | > manual evaluation and during export.
>>> | >
>>> | > And even if it is not explicitely contradicting the manual [1] (which
>>> | > does not say anything about finding references), I'd prefer if
>>> | > references in COMMENT'ed sections are not found -- neither during export
>>> | > nor during evaluation.  This would be more inline with my intuition of
>>> | > COMMENT is equivalent to # (which is also suggested by the fact that
>>> | > COMMENT is described in the section on #).
>>> `---
>>
>> I'd like to strongly support this view.
>
> Fixed, in master (02c78501472fba94f8cf5a3d218b5c8845b28827).
>
> Thank you.
>

Thank you.

Regards,
Andreas

Re: [O] Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi Nick,

Nick Dokos <ndo...@gmail.com> writes:
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> ...
>> So, to me it is more surprising that the manual execution works.  For
>> instance, I might have two tables with the same name.  Then, COMMENTing
>> one of them should ensure that the other one is used.
>>
>
> COMMENT works during export *only* I believe. You have to explicitly
> comment out one of the tables otherwise. If there are two tables with
> the same name, babel will use the one nearer the beginning of the file
> and ignore the second one (I determined this experimentally, *not* by
> reading and understanding the code - ymmv).

Thanks for following up on this.  I also ran some tests now and confirm
what you see.  Test code below [2].

I'd say it is a bug if the results from evaluation differ between
manual evaluation and during export.

And even if it is not explicitely contradicting the manual [1] (which
does not say anything about finding references), I'd prefer if
references in COMMENT'ed sections are not found -- neither during export
nor during evaluation.  This would be more inline with my intuition of
COMMENT is equivalent to # (which is also suggested by the fact that
COMMENT is described in the section on #).


Regards,
Andreas

[1] http://orgmode.org/manual/Comment-lines.html#Comment-lines


[2] Test code
--8<---cut here---start->8---
* Test COMMENTing babel reference

** COMMENT Table 1
#+name: testtable
| a | b |
|---+---|
| 1 | 2 |


# ** Table 2
# #+name: testtable
# | c | d |
# |---+---|
# | 3 | 4 |


# ** Table 2.5
# #+name: testtable2
# | c | d |
# |---+---|
# | 3 | 4 |



** Table 3
#+name: testtable
| e | f |
|---+---|
| 5 | 6 |


** Use (one of) the visible tables
This gives different results during export compared to manual
evaluation.
#+begin_src R :var tab=testtable :colnames yes :exports results
  tab
#+end_src

#+results:
| a | b |
|---+---|
| 1 | 2 |

** Use the #'ed table  :noexport:
This works neither during export nor during manual evaluation.
#+begin_src R :var tab=testtable2 :colnames yes :exports results
  tab
#+end_src
--8<---cut here---end--->8---

Re: [O] Org Babel resolution of `:var` value reference inconsistent

[Andreas Leha]

Hi myq,

myq  writes:
> Sometime since Org version 8.3beta and now, the way Org Babel resolves
> the value of the `:var` header argument when assigned to a reference has
> changed.
>
> Previously, the following would work when exporting:
>
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> ** COMMENT
>
> #+TBLNAME: table-data
> | number | measurement |
> |+-|
> | 1  | 10  |
>
>
> The above /still/ works when manually evaluating the block (C-c C-c whil
> in the block), but when exporting, the following error is thrown:
> `org-babel-ref-resolve: Reference `table-data' not found in this buffer`
>
> Curiously, the following tweak works for both manual evaluation and for
> exporting and produces the same results that the above file used to
> produce:
>
> #+OPTIONS: inline:nil
> * test
>
> #+BEGIN_SRC R :var dat=table-data
>   print(summary(dat));
> #+END_SRC
>
> *** test
> #+TBLNAME: table-data
> | number | measurement |
> |+-|
> | 1  | 10  |
> *** END
>
> This seems to be a bug, but perhaps there is a reason for this new
> behaviour?
>
> Thank you in advance for any insights.

There are two ways to exclude subtrees from export: the COMMENT keyword
and the :noexport: tag.  I think what you want to use here is the
:noexport: tag.

Here is the difference:

- COMMENTing a subtree is meant to be (roughly?) the same as putting '# '
  at the beginning of all the lines from that region.

- The :noexport: tag will simply skip the region from export.

So, to me it is more surprising that the manual execution works.  For
instance, I might have two tables with the same name.  Then, COMMENTing
one of them should ensure that the other one is used.

HTH,
Andreas

Re: [O] problems with export and :cache

[Andreas Leha]

Hi all,

As a follow-up.  The caching produces un-expected results for call lines
'in the other direction' as well: Changes in the arguments to the called
code block do not invalidate the cache.

--8<---cut here---start->8---
* Test Cached Export

** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src


** Cached Calls
Execute these calls one after the other.

#+name: cached_call
#+call: foo("qux") :cache yes

#+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]: cached_call
: bar="qux"


#+name: cached_call
#+call: foo("qux") :cache yes


#+name: cached_call
#+call: foo("quxxx") :cache yes


For me, the last one does not call foo, but I expect it to do so.
--8<---cut here---end--->8---

Regards,
Andreas


PS: I have not updated org yet.

Re: [O] problems with export and :cache

[Andreas Leha]

Hi Aaron,

Aaron Ecay <aarone...@gmail.com> writes:
> Hi Andreas,
>
> 2015ko urriak 28an, Andreas Leha-ek idatzi zuen:
>> 
>> Hi all,
>> 
>> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>>> Hi all,
>>> 
>>> babel's :cache seems to be ignored during export.  At least on #+call
>>> lines.
>>> 
>>> In the example below the caching works fine for interactive evaluation,
>>> i.e. C-c C-c on the #+call line returns immediately.
>>> 
>>> If I export the subtree with the #+call line, however, the code block
>>> gets executed and the export is slow.
>
> Export works by making a copy of the org buffer, modifying it in some
> ways while executing babel code, then exporting the modified buffer
> copy.  The modifications can under some circumstances change the
> relevant features for the cache, leading to spurious re-evaluation.
>
> I tried to write a patch that would do the buffer modifications in such
> a way that they would not affect the cache.  But I was never happy with
> the patch, and also could not find a nice simple test case for the
> re-evaluation bug.  So this work never went anywhere.  (It was also 2
> years ago, so things could have changed quite a bit.)  The simple patch
> attached to this message fixes a bug that my testing indicated was
> responsible for erroneous re-evaluations at least some of the time.
>

Thanks a lot.  I applied your patch but it seems that your patch does
not solve the problem in this specific situation.  Or do I miss
something?


> I personally regard the babel cache as dangerous and unpredictable in
> its present form.  You’re much better off using language-specific
> caching/memoization features and/or a disciplined regime of manual
> reevaluation.

I agree and avoid the caching mechanism generally.  But all alternative
approaches do involve more work, so I am regularly tempted to use it
again.

Generally, I think that caching is a sensitive area.  And if we think
that it is unpredictable and advise people to stay off of it, we are
better off removing it than offering it in this state.  At least until
it behaves (more) predictable.


>
>>> 
>>> I'd expect no evaluation even during export.
>>> 
>>> Is this a bug or am I missing something?
>>> 
>>> Regards,
>>> Andreas
>>> 
>>> PS: The example:
>>> 
>>> * Test Cached Export
>>> ** A long running code block.
>>> #+name: foo
>>> #+begin_src emacs-lisp :var bar="baz"
>>> (sit-for 15)
>>> (message "bar=%S" bar)
>>> #+end_src
>>> 
>>> #+RESULTS: foo
>>> : bar="baz"
>>> 
>>> ** Calling
>>> 
>>> Exporting this subtree will demonstrate my problem.  I expect the call
>>> line below to not execute anything.  This works for interactive
>>> execution (C-c C-c).  But if I export this subtree only, the code is
>>> executed.
>>> 
>>> This returns immediately thanks to the cached result.
>>> #+call: foo("qux") :cache yes
>>> 
>>> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
>>> : bar="qux"
>> 
>> 
>> I should have added that adding :eval no-export to the #+call line does
>> not help either.
>
> There are two places you could add the :eval option.  See
> (info "(org) Evaluating code blocks") .  You may have to experiment with
> putting it in one or both places in order to get the desired result.
> (If none of the possible combinations works, then it is a bug IMO.)

True.  But can you explain to me why it is not possible to disable the
evaluation of a call line?  If the evaluation of a code block is
disabled (:eval never) there is no evaluation and no results.  If I
specify ':eval never' at the end of the #+call line I do not get any
results either but the called source block is unnecessarily and
unexpectedly evaluated.

So, basically I would argue that

  #+call: foo("qux") :eval never

should do what it says an evaluate never, i.e. it should behave as

  #+call: foo[:eval never]("qux") :eval never

Regards,
Andreas




>
> From d7355798edc643bbbca7ab1ead2a2e11f37aa64c Mon Sep 17 00:00:00 2001
> From: Aaron Ecay <aarone...@gmail.com>
> Date: Thu, 29 Oct 2015 13:31:28 +
> Subject: [PATCH] babel: fix header arg duplication
>
> * lisp/ob-core.el (org-babel-process-params): Make idempotent.
> * testing/lisp/test-ob.el (ob/process-params-no-duplicates): New test.
> ---
>  lisp/ob-core.el |  8 +++-
>  testing/lisp/test-ob.el | 12 
>  2 fi

Re: [O] problems with export and :cache

[Andreas Leha]

Hi Thomas,

Thomas S. Dye <t...@tsdye.com> writes:
> Aloha all,
>
> Aaron Ecay <aarone...@gmail.com> writes:
>
>> Hi Nicolas,
>>
>> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
>>> 
>>> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>>> 
>>>> Generally, I think that caching is a sensitive area.  And if we think
>>>> that it is unpredictable and advise people to stay off of it, we are
>>>> better off removing it than offering it in this state.  At least until
>>>> it behaves (more) predictable.
>>> 
>>> Is it necessarily broken?
>>
>> If this means “can it ever work?” then I think the answer is “yes it
>> can”.  But I think the current implementation is broken and likely to
>> remain so for the foreseeable future.  The issues are:
>>
>> 1. :cache only works for code which is a pure function of its header args
>> 2. When combined with :session, the environment that the code is evaluated
>>in is not created anew each time it is run.  This makes it much easier
>>to leak references to (e.g.) variables defined in other blocks
>> 3. The proper notion of purity is not easily defined when the code does
>>things like modifying the emacs environment, touching the filesystem,
>>or accessing the language’s RNG.
>> 4. We (org devs) don’t actually understand how the semantics of cache
>>interacts with other babel features.  See:
>><http://mid.gmane.org/86fvqqc8jb@somewhere.org>.
>>
>> 1-3 are likely to be extremely confusing for users, especially less
>> technically sophisticated ones (what’s a “pure function” anyway)?  The
>> inability to give a clear introductory explanation of the feature in
>> combination with 4 indicating we don’t actually understand it ourselves
>> makes me feel like we should not be advertising, let alone recommending,
>> it.
>>
>> The only other literate programming environment that I know of that
>> implements such a feature is knitr (for R).  They address these issues
>> by providing (optional) free-variable analysis to construct a dependency
>> graph between code blocks.  There is also some handling of RNG seed
>> values.  The documentation <http://yihui.name/knitr/demo/cache/> is much
>> more comprehensive, including a prominent statement about the dangers of
>> side effect-ful code and a nuanced discussion of several issues,
>> including the RNG.
>>
>> Aaron
>>
>> PS I’ve looked through my old notes on the interaction of cache with
>> babel export.  I can’t reproduce any of my old test cases, so maybe that
>> bug has been fixed as a side effect of some other change.
>
> FWIW, I think relying on cache to speed up export is the wrong
> approach.  Having all code run during each export is, to me, a feature
> that makes a document "live."  I'm willing to be patient during export
> to get this feature.
>
> If speed is important and a live document isn't desired, then one
> solution is to rename the results and refer to this name in the
> document, rather than to the name of the code block that produced the
> results.  I do this manually, which is OK, but I've often wanted
> something like :persist-as my-result so I can be certain to have a good
> link from the results back to the code that produced them.

There we go again.  Another advice not to use the :cache.

>
> That said, points 2 and 4 seem to me serious issues that users must
> understand if they choose to use :cache.  So, at the least, the
> documentation needs revision.
>

Just to add (maybe that belongs to point 4 anyway): And the caching
should work predictably -- even during export.

Regards,
Andreas

[O] [babel] :eval and #+call lines

[Andreas Leha]

Hi all,

Since this is not related to caching, I post this as a separate question
from [1].

I want to argue that specifying ':eval never' as argument to a #+call
line should transitively apply to the called block as well.

Here is the example:

--8<---cut here---start->8---
* Test
** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src

** Calling

This should not execute anything IMO.
#+call: foo("qux") :eval never

I.e. it should behave as this:
#+call: foo[:eval never]("qux") :eval never
--8<---cut here---end--->8---

Regards,
Andreas



[1] http://permalink.gmane.org/gmane.emacs.orgmode/102349

[O] problems with export and :cache

[Andreas Leha]

Hi all,

babel's :cache seems to be ignored during export.  At least on #+call
lines.

In the example below the caching works fine for interactive evaluation,
i.e. C-c C-c on the #+call line returns immediately.

If I export the subtree with the #+call line, however, the code block
gets executed and the export is slow.

I'd expect no evaluation even during export.

Is this a bug or am I missing something?

Regards,
Andreas

PS: The example:
--8<---cut here---start->8---
* Test Cached Export
** A long running code block.
#+name: foo
#+begin_src emacs-lisp :var bar="baz"
  (sit-for 15)
  (message "bar=%S" bar)
#+end_src

#+RESULTS: foo
: bar="baz"

** Calling

Exporting this subtree will demonstrate my problem.  I expect the call
line below to not execute anything.  This works for interactive
execution (C-c C-c).  But if I export this subtree only, the code is
executed.

This returns immediately thanks to the cached result.
#+call: foo("qux") :cache yes

#+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
: bar="qux"
--8<---cut here---end--->8---

Re: [O] problems with export and :cache

[Andreas Leha]

Hi all,

Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
> Hi all,
>
> babel's :cache seems to be ignored during export.  At least on #+call
> lines.
>
> In the example below the caching works fine for interactive evaluation,
> i.e. C-c C-c on the #+call line returns immediately.
>
> If I export the subtree with the #+call line, however, the code block
> gets executed and the export is slow.
>
> I'd expect no evaluation even during export.
>
> Is this a bug or am I missing something?
>
> Regards,
> Andreas
>
> PS: The example:
>
> * Test Cached Export
> ** A long running code block.
> #+name: foo
> #+begin_src emacs-lisp :var bar="baz"
>   (sit-for 15)
>   (message "bar=%S" bar)
> #+end_src
>
> #+RESULTS: foo
> : bar="baz"
>
> ** Calling
>
> Exporting this subtree will demonstrate my problem.  I expect the call
> line below to not execute anything.  This works for interactive
> execution (C-c C-c).  But if I export this subtree only, the code is
> executed.
>
> This returns immediately thanks to the cached result.
> #+call: foo("qux") :cache yes
>
> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]:
> : bar="qux"


I should have added that adding :eval no-export to the #+call line does
not help either.

To me this seems to be a bug.

Best,
Andreas

Re: [O] org-reveal questions

[Andreas Leha]

Hi,

Fabrice Popineau  writes:
> I switched to org-reveal from beamer.
> Beamer clutters your slides with too much markup. 
> (I ended up with much more markup than text in my slides).

... which of course can be changed by customizing the theme ...

It seems that to get close to how you want your slides to look, you need
to customize the theme in either of beamer and reveal.

Depending on whether you prefer to do that in css/js or latex, you might
arrive there quicker.

Andreas


>
> Moroever, Reveal offers features that no pdf reader offers at least under 
> windows :
> - separate frame for notes, timer, next slide
> - ability to synchronize other clients on the master display 
> (your students can connect and their slides move as you move yours)
> And it is very quick to compile a deck of x100 slides, where beamer can take 
> minutes.
>
> To answer the first question :
> - load bootstrap in the  section of your slides
> - then you can add div's with class col-xs-6 for example and split your frame 
> in 2 columns.
>
> I load bootstrap, mathjax and some personal js and css. It is working pretty 
> well.
> It is not as clean as beamer out of the box, but it is more efficient. 
> With a good css, it should be as clean as beamer. 
>
> Fabrice
>
> 2015-10-23 10:39 GMT+02:00 Eric S Fraga :
>
>
>  On Friday, 23 Oct 2015 at 09:45, Xebar Saram wrote:
>  > Thx Eric
>  >
>  > ill check out beamer..i guess i need to know latex for that right?
>
>  Not necessarily. You can do a lot without any LaTeX knowledge. Most of
>  the issues you had with org-reveal are solved in ox-beamer.
>
>  Check out http://orgmode.org/worg/exporters/beamer/ox-beamer.html
>  --
>  : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-161-gd2ac25

Re: [O] Bug: LaTeX export: internal target + \autoref{} broken [8.3.2 (8.3.2-elpaplus @ /home/myq/.emacs.d/elpa/org-plus-contrib-20150929/)]

[Andreas Leha]

Hi ☕◦m̰̱̐y̿q̟̽,


☕◦m̰̱̐y̿q̟̽  writes:
>
> Given the following Org document:
>
> ,
> | #+MACRO: refp \autoref{$1}, \autopageref{$1}
> |
> |
> | * section
> |
> | Please see the results in {{{refp(sec:info)}}}.
> |
> | * info<>
> |
> | The results are here.
> `
>
> When exporting to LaTex, I expect `autoref' and `autopageref' to
> correctly refer to the target `sec:info'. However, recent versions of
> Org do not do that. I now get the following when exporting to LaTeX:
>
> ,
> | % Created 2015-10-21 Wed 03:25
> | \documentclass[11pt]{article}
> | % [...]
> | \begin{document}
> | % [...]
> | \section{section}
> | \label{sec:orgheadline1}
> |
> | Please see the results in \autoref{sec:info}, \autopageref{sec:info}.
> |
> | \section{info\label{orgtarget1}}
> | \label{sec:orgheadline2}
> |
> | The results are here.
> | \end{document}
> `
>
> When compiled, the following warning is issued:
>
> ,
> | Latex failed to resolve 2 reference(s)
> `
>
>
> This did not occur in Org Mode 8.3beta.
>

Please see `org-latex-prefer-user-labels'.

Best,
Andreas

[O] order in agenda

[Andreas Leha]

Hi all,

I am aware, that overlapping events cannot be displayed really well in
the (linear) agenda view.  But if I have two events starting at the same
(day and) time, I'd prefer the one with the later end time to appear
always below the other one.  Is that already achievable?

Here is an excerpt of my current agenda for next week showing
sub-optimal (IMO) ordering:
,
|   work: 16:00-18:00 Meeting with XXX :work::ATTACH:
|   work: 16:00-16:45 Event 2 :work::
`

Regards,
Andreas

Re: [O] order in agenda

[Andreas Leha]

Hi Nick,

Nick Dokos <ndo...@gmail.com> writes:
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> I am aware, that overlapping events cannot be displayed really well in
>> the (linear) agenda view.  But if I have two events starting at the same
>> (day and) time, I'd prefer the one with the later end time to appear
>> always below the other one.  Is that already achievable?
>>
>> Here is an excerpt of my current agenda for next week showing
>> sub-optimal (IMO) ordering:
>> ,
>> |   work: 16:00-18:00 Meeting with XXX :work::ATTACH:
>> |   work: 16:00-16:45 Event 2 :work::
>> `
>>
>
> C-h v org-agenda-sorting-strategy RET
>
> Maybe you can do something with user-defined-{up,down}?
>

Thanks for the pointer.  Indeed, user-defined-{up,down} seem to be the
way to go.  I'll look into that.

Thanks,
Andreas

Re: [O] Bug in latex export figure labels?

[Andreas Leha]

Nicolas Goaziou  writes:
> Hello,
>
> garj...@garjola.net writes:
>
>> I am having issues when exporting to LaTeX using labels in figures. The
>> following snippet
>>
>>> > >
>>> #+CAPTION: Comparison >
>>> #+NAME:  fig:irreg2   >
>>> #+attr_latex: :width 0.9\textwidth :placement [H] >
>>> [[file:irregular_red.png]]>
>>> > >
>>
>> gets exported as (see the label)
>>
>>>  >
>>> \begin{figure}[H]>
>>> \centering   >
>>> \includegraphics[width=0.9\textwidth]{irregular_red.png} >
>>> \caption{\label{fig:orgparagraph1}   >
>>> Comparison}  >
>>> \end{figure} >
>>>  >
>>
>> instead of 
>>
>>>  >
>>> \begin{figure}[H]>
>>> \centering   >
>>> \includegraphics[width=0.9\textwidth]{irregular_red.png} >
>>> \caption{\label{fig:irreg2}Comparison}   >
>>> \end{figure} >
>>>  >
>>
>> I noticed this when updating the melpa package to the latest one. Using
>> the git repository I have tried several versions of org-mode and the
>> "bug" was introduced between release 8.2.9 and release 8.3. 
>>
>> Since I am a little bit surprised that this has not been noticed, I am
>> reluctant to say that this is a bug, but the same file gets exported
>> differently with these 2 releases.
>>
>> I have also tried to change +NAME to +LABEL and the result is the same.
>>
>> Am I doing something wrong?
>
> This is a feature. See `org-latex-prefer-user-labels'.
>

Maybe `org-latex-prefer-user-labels' deserves its own FAQ entry.

Or a changed default value.


Regards,
Andreas

Re: [O] SOLVED: LaTeX equation align in orgmode?

[Andreas Leha]

Rainer M Krug  writes:
> Eric S Fraga  writes:
>
>> On Monday, 28 Sep 2015 at 21:10, Rainer M Krug wrote:
>>> Hi
>>>
>>> I would need in a document several equations which are aligned as in 
>>> http://tex.stackexchange.com/a/167908/6941
>>
>> I use align all the time.
>>
>>> How can I use the following latex formula in orgmode?
>>>
>>> \begin{proof} The proof is a follows: 
>>> \begin{align}
>>> (x+y)^3&=(x+y)(x+y)^2\\
>>>&=(x+y)(x^2+2xy+y^2)\\
>>>&=x^3+3x^2y+3xy^3+x^3.\qedhere
>>> \end{align}
>>> \end{proof}
>>
>> Where is proof defined? You may need to add specific packages to
>> org-latex-packages-alist.
>
> The proof and the ".\qedhere"
>
> Stupid typos.
>
>>
>> In any case, I find that it is safer generally to enclose all LaTeX
>> fragments in a LaTeX block: #+begin_latex ... #+end_latex.
>
> Good idea - but then the preview does not work anymore?
>

see http://orgmode.org/worg/org-hacks.html#orgheadline91

Best,
Andreas

Re: [O] LaTeX equation align in orgmode?

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Hi
>
> I would need in a document several equations which are aligned as in 
> http://tex.stackexchange.com/a/167908/6941
>
> How can I use the following latex formula in orgmode?
>
> \begin{proof} The proof is a follows: 
> \begin{align}
> (x+y)^3&=(x+y)(x+y)^2\\
>&=(x+y)(x^2+2xy+y^2)\\
>&=x^3+3x^2y+3xy^3+x^3.\qedhere
> \end{align}
> \end{proof}
>
>
> I have effectrively
>
> #+LATEX_HEADER: \usepackage{amsmath}
>
> * The equations
>
> \begin{equation}
> \begin{align}
> (x+y)^3&=(x+y)(x+y)^2\\
>&=(x+y)(x^2+2xy+y^2)\\
>&=x^3+3x^2y+3xy^3+x^3.\qedhere
> \end{align}
> \end{equation}
>
>
> but with latex fragment preview (C-c C-x C-l) I only get an empty frame.
>
> How can use this align environment in org?

This seems to a problem with your setup of preview latex.  It
should work just fine.

For me the following org file works as expected -- also with
previewing the equation.

--8<---cut here---start->8---
#+LaTeX_header: \usepackage{amsmath} %% needed explicitely for org-preview-latex


* Test align

\begin{align}
(x+y)^3&=(x+y)(x+y)^2\\
   &=(x+y)(x^2+2xy+y^2)\\
   &=x^3+3x^2y+3xy^3+x^3.\qedhere
\end{align}
--8<---cut here---end--->8---

I do not seem to have any special setup for previewing latex,
though...

Sorry to be of no further help.

Regards,
Andreas

Re: [O] Beamer :BEAMER_envargs: [allowframebreaks] not working

[Andreas Leha]

Hi Jeremie,

Jeremie Juste  writes:
> Hello,
>
> It's my first post here finally. Most of my questions were answered
> before by you.:). I have the lastest version of org mode and search
> with the best of my abilities if any had the same issue but couldn't
> find anything.
>
> I have some difficulty with the org-mode variable :BEAMER_envargs.
>
> It does not allow frame break. There was a post on SO about the issue
>
> http://stackoverflow.com/questions/29384107/org-mode-framebreak-does-not-work-with-label-option-in-exported-beamer
>
> As a fix they recommend the following fix
> (setq org-beamer-frame-default-options "allowframebreaks,label=")
>
> This doesn't do the job and on the tex file it produces something like
> \begin{frame}[allowframebreaks,label=,label={sec:orgheadline1}]{part 1}
>
> I tried with
> (setq org-beamer-frame-default-options "allowframebreaks")
> but the results were not better,
>
>
> Finally removing label={sec:orgheadline1} did the job.
> \begin{frame}[allowframebreaks]{part 1}
>
> So I suspect there is a problem with label={sec:orgheadline1}.
>
>
> Can someone help please?
>

(Untested!)

I suspect that this is due to org-latex-prefer-user-labels being
nil.  This will make Org mode inserting auto-generated labels.
Setting this to sth non-nil might work here.

HTH,
Andreas

Re: [O] export: noweb blocks substituted versus verbatim ?

[Andreas Leha]

Hi Brian,

Brian Beckman  writes:
> Hello -- I have a situation where some code blocks with noweb references in
> them <> are substituted inline when I export the document, and
> other code blocks with noweb references, are copied verbatim into the
> exported PDF. I do not know what causes this difference in behavior and I
> don't know how to control it, but I'd like to control it. I'd like to be
> able to specify that some blocks have behavior 1 (references substituted
> inline) and other blocks have behavior 2 (references verbatim).
>
> I'm sure this is pilot error, but I'm stumped and would be grateful for 
> advice. 

[[ omitted: the MVE ]]

As far as I can see, the difference is that some of the code blocks have
the header argument `:noweb yes', while others do not.

I do not know how to achieve working noweb extension during evaluation
but omitting noweb extension during export, though.

HTH,
Andreas

Re: [O] Tangle including code generating graphics for :results graphics

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Hi
>
> Is it possible to tangle an R code block including the code which is
> generating the graphs when using =:results graphics= ?
>
> I would like to tangle these code blocks generating the graphs as I
> would like to have a script which I can use to easily update all graphs
> when the simulated input data is updated. I have this for the actual
> analysis which works perfectly, but would like to have the same for the
> graphs. At the same time, I like the clarity of specifying :width and
> :height and other parameter for the plotting as header arguments.
>
> I have
>
> ,
> | :PROPERTIES:
> | :header-args+: :prologue "env <- fitBFGS; attach(env)"
> | :header-args+: :epilogue "detach(env); rm(env)"
> | :END:
> `
>
> and this is tangled perfectly - but obviously not the code for
> plotting. Is there an argument / setting to enable this?
>
> Thanks,
>
> Rainer

That is a very relevant question and I'd be interested in the answer as
well.  But I am not aware of any support by Org mode for this.

I guess calling `org-babel-expand-src-block' prior to tangling would
answer your needs?

This would be desirable not only for plotting code blocks, also data
passed to code block is 'lost' during tangling.

I think it would be good to have a source block header argument, say
`:tangleexpanded', controlling such functionality.

WDYT?

Regards,
Andreas

Re: [O] tangle on export

[Andreas Leha]

Hi Alan,

Alan Schmitt <alan.schm...@polytechnique.org> writes:
> Hi Andreas,
>
> On 2015-09-24 14:14, Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> if all of this is for a single block, you can get away quite cheaply
>> with sth along (untested)
>>
>> #+begin_src emacs-lisp :results silent
>>   (save-excursion
>> ;; tangle
>> (org-babel-goto-named-src-block "hello")
>> (org-babel-tangle '(4)))
>> #+end_src
>>
>> and make sure this gets executed during export.
>
> I’ve tried this and somehow it replaces the whole org file with
> a version with comments and src block headers removed, and macros
> expanded. I have no idea why it does this …
>

That's what I feared.  So, you better go for the other suggestions in
this thread, the hook or calling the export from that same source block
-- now making sure not to evaluate the block again.

Best,
Andreas

Re: [O] tangle on export

[Andreas Leha]

Hi Alan,

Rainer M Krug  writes:
> Alan Schmitt  writes:
>
>> Hello,
>>
>> I have a question I feel is very basic but I did not find the answer in
>> the manual. How can I trigger the tangling of a block upon export.
>
> Tangling and exporting are two different paths (well - one could see
> tangling as a special case of exporting).
>
> You have to use an export hook (see
> http://orgmode.org/tmp/worg/org-configs/org-hooks.html for a list of
> hooks in org).
>
> I have done something similar to run a post-tangle hook:
>
> #+begin_src emacs-lisp
> (defvar org-babel-tangle-run-postTangleScript nil
>   "If non-nil, postTangleScript.sh will be executed")
> (put 'org-babel-tangle-run-postTangleScript 'safe-local-variable 'booleanp)
>
> (defun org-babel-run-post-tangle-script ()
>   (when org-babel-tangle-run-postTangleScript
> (message "running the postTangleScript.sh bash shell script")
> (shell-command "bash ./postTangleScript.sh")))
>
> (add-hook 'org-babel-post-tangle-hook 'org-babel-run-post-tangle-script)
> #+end_src
>
> Cheers,
>
> Rainer
>
>>
>> More precisely, I want to give the following example in a lecture:
>>
>> #+name:hello
>> #+begin_src ocaml :tangle myprog.ml
>> Printf.printf "Bonjour le monde !\n"
>> #+end_src
>> #+BEGIN_SRC sh :exports both :results verbatim
>> ocamlc -o myprog myprog.ml
>> ./myprog
>> #+END_SRC
>>
>> where I show a program to be compiled and actually compile it. Is there
>> a header I should put on the "hello" block to tangle it when I export
>> it?
>>
>> Thanks,
>>
>> Alan

if all of this is for a single block, you can get away quite cheaply
with sth along (untested)

#+begin_src emacs-lisp :results silent
  (save-excursion
;; tangle
(org-babel-goto-named-src-block "hello")
(org-babel-tangle '(4)))
#+end_src

and make sure this gets executed during export.

Regards,
Andreas

Re: [O] [BUG] outshine and emacs 25.0.5.1 - Was: [error] orgmode git on emacs 25 - HEAD - org-global-cycle

[Andreas Leha]

Hi Rainer,

Rainer M Krug  writes:
> Kyle Meyer  writes:
>
>> Hi,
>>
>> Rainer M Krug  writes:
>>
>>> Hi
>>>
>>> when doing global cycling using org in emacs 25.0.50.1, I get an "Before
>>> first heading" error (see backtrace below).
>>>
>>> It doesn't matter if the cursor is before or after the first header in
>>> the document.
>>>
>>> Is this something in my settings or the combination emacs 25 HEAD and
>>> org-mode git?
>>
>> I'm not able to reproduce this using emacs -Q with a recent version of
>> Org (release_8.3.1-218-g70f590) and Emacs
>> (emacs-24.5-rc3-fixed-5796-g8a6260e).  C-u org-cycle goes through all
>> the views fine.
>
> OK - it seems to be outshine:
>
> When evaluating the following:
>
> #+begin_src emacs-lisp
>  ;; must be set before outline is loaded
> (defvar outline-minor-mode-prefix "\M-#")
>
> (require 'outshine)
> (add-hook 'outline-minor-mode-hook 'outshine-hook-function)
> (setq outshine-use-speed-commands t)
>
> (eval-after-load 'outline
>   '(progn
> (require 'outline-magic)
> (define-key outline-minor-mode-map (kbd "") 'outline-cycle)))
>
> #+end_src
>
> I get the error when opening an org file.
>
> ,
> | GNU Emacs 25.0.50.1 (x86_64-apple-darwin14.5.0, NS appkit-1348.17 Version 
> 10.10.5 (Build 14F27)) of 2015-09-10
> | Org-mode version 8.3.1 (release_8.3.1-225-g66a211 @ 
> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
> `
>
>

This might be the issue discussed earlier [1].  If so, it is solved (see the 
linked thread).

Regards,
Andreas

[1] http://article.gmane.org/gmane.emacs.orgmode/100215/match=outshine

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello,
>
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> This macro is from Eric Schulte initially.  And I guess I would be out
>> of luck adapting it to new Org mode versions as well.
>
> What about
>
>   (defmacro by-backend ( body)
> `(case org-export-current-backend ,@body))
> ?
>
> Regards,

Thanks for this!  One reason less not to upgrade Org mode.

Seems to work fine!

Just note, that it works for me only after exporting
 (when tested under emacs -Q).

What about including that into org?

Regards,
Andreas

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> Seems to work fine!
>>
>> Just note, that it works for me only after exporting
>>  (when tested under emacs -Q).
>
> `org-export-current-backend' is set when exporting a document, much like
> `backend'.
>

The same protection as in the previous version seems to take effect
here:

  (defmacro by-backend ( body)
`(case (if (boundp 'org-export-current-backend) org-export-current-backend 
nil) ,@body))

Are there any issues with this?

>> What about including that into org?
>
> Wrong namespace. It should be prefixed with "org". 
>

Easy to fix.

> Also, it might be better to include it directly in :file directive
> handling if that is its sole purpose.

Could you elaborate why that might be better?  Including it as a macro
like this has the up-side to be more general.n

I think that also other header arguments would benefit from such a
(org-)by-backend switch.

In former versions (pre-dating the handling of *.tikz 'images' by
ox-latex) of the tikz code in this thread, for example, the :results
argument needed to be set according to the backend as well


Regards,
Andreas

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Haochen,

Thanks for following that up!

Haochen Xie <haoch...@acm.org> writes:
> ​Hello
> Alan,
>
> I'm not 100% sure, but I think the distorted PNG file is generated by dvipng. 
> It seems that dvipng cannot handle tikz blocks very well, and one must use 
> imagemagick for those blocks. I
> think this line:
>
> #+header: :imagemagick :iminoptions -density 600 :imoutoptions -geometry 800
>
> should be
>
> #+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 
> 800
>
> so that imagemagick would be used instead of dvipng, which is the global 
> default.

Thanks for that!  I'll keep that in mind.

Regards,
Andreas




>
> As said by Andreas, 
> ​it's probably that ​
> your
> ​​ by
> ​​-backend
> ​​ macro
> ​​ 
> ​is not working​
> properly, or, maybe you are not using a recent enough version of org-mod
> ​​e
> ​​. This
> ​​ 
> ​​magic
> ​, if I remember correctly,​
> ​​ 
> ​​is
>  
> ​​act
> uall
> ​y​
> ​​ done
> ​​ by
> ​​ a
> ​​ special
> ​​ case
> ​​ added
> ​​ to
> ​​ some
> ​​ latex
> ​​ babel
> ​​ export
> ​​ function
> ​​, wh
> ​​ich is contributed by Andreas somehow recently. You may want to try upgrade 
> your org-mode and try again.
>
> Also please follow this link [1] to fix a 
> ​bug
> in htlatex as mentioned in Andreas's mail, or your html export will fail 
> silently (showing success on emacs, but no images generated).
>
> [1] http://tex.stackexchange.com/a/232739
>
> --
>
> Mail from Haochen Xie
>
> On Thu, Sep 3, 2015 at 9:30 PM, Andreas Leha 
> <andreas.l...@med.uni-goettingen.de> wrote:
>
>
>  Hi Alan,
>
>  Glad you like the example.
>
>  Three things:
>  1. It still works for me ;-)
>  2. The distorted png might come from the bug in htlatex I mentioned in
>  this thread [1].
>  3. It seems that the by-backend does not work properly for you. I am
>  not sure about the reason for that. What org-mode version do you run?
>
>  HTH,
>  Andreas
>
>  [1] http://tex.stackexchange.com/a/232739
>
>  Alan Schmitt <alan.schm...@polytechnique.org> writes:
>  > Hello Andreas,
>  >
>  > I’m slowly catching up on the org mailing list, and I found your example
>  > very interesting. I tried to run it and it does not seem to work here.
>  > Here is what I did:
>  > - I copied the code below to a file
>  > - I evaluated the last block
>  > - I made sure that latex was one of the org-babel-load-languages
>  > language
>  > - I tried executing the first block, which generated this strange png
>  >
>  >
>  >
>  > - I exported both to html and pdf, and in both cases I would have
>  > a reference to the png instead of the svg/tikz code.
>  >
>  > I’m afraid I’m missing a step. Do you see what I’m doing wrong?
>  >
>  > Thanks,
>  >
>  > Alan
>  >
>  > On 2015-08-12 10:50, Andreas Leha <andreas.l...@med.uni-goettingen.de> 
> writes:
>  >
>  >> #+LATEX_HEADER: \usepackage{tikz}
>  >>
>  >> First execute the second code block, to define the convenience macro
>  >> and to set the required new variables in ob-latex.el. Then export to
>  >> HTML and to pdf to see the tree exported as an SVG image and as
>  >> embedded tikz respectively.
>  >>
>  >> * Tikz test
>  >> Here's a tree, exported to both html and pdf.
>  >>
>  >> #+header: :file (by-backend (html "tree.svg") (latex "tree.tikz") (t 
> "tree.png"))
>  >> #+header: :imagemagick :iminoptions -density 600 :imoutoptions -geometry 
> 800
>  >> #+header: :results file raw
>  >> #+header: :fit yes
>  >> #+begin_src latex
>  >> \usetikzlibrary{trees}
>  >> \begin{tikzpicture}
>  >> \node [circle, draw, fill=red!20] at (0,0) {1}
>  >> child { node [circle, draw, fill=blue!30] {2}
>  >> child { node [circle, draw, fill=green!30] {3} }
>  >> child { node [circle, draw, fill=yellow!30] {4} }};
>  >> \end{tikzpicture}
>  >> #+end_src
>  >>
>  >> #+results:
>  >> [[file:tree.png]]
>  >>
>  >> * COMMENT setup
>  >> #+begin_src emacs-lisp :results silent
>  >> (setq org-babel-latex-htlatex "htlatex")
>  >> (defmacro by-backend ( body)
>  >> `(case (if (boundp 'backend) (org-export-backend-name backend) nil) 
> ,@body))
>  >> #+end_src

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Eric,

Thanks for following that up!

Eric S Fraga <e.fr...@ucl.ac.uk> writes:
> On Thursday,  3 Sep 2015 at 13:30, Andreas Leha wrote:
>> Hi Alan,
>>
>> Glad you like the example.
>>
>> Three things:
>> 1. It still works for me ;-)
>
> Andreas,
>
> the example doesn't work for me with a quite recent org (updated within
> the past week) and with -Q.

I see.  Another reason for me not to upgrade?   My org is quite old.
(8.3beta (release_8.3beta-1264-g365c19))

>
> By the way, with emacs -Q, I need to "(required 'cl)" for the by-backend
> macro although this is probably done by one of the export files?
>
>> 2. The distorted png might come from the bug in htlatex I mentioned in
>> this thread [1].
>
> The solution has been pointed out by Haochen Xie in this thread
> (":imagemagick yes").  I needed this fix as well to get the png creation
> to work.
>

Good to know!  Thanks for the confirmation.  I missed that.

Note also that it might be necessary to include

 #+header: :headers '("\\usepackage{tikz}")

to the latex block.  This I only need when testing with emacs -Q.  Not
sure why, though.  I was under the impression that global
#+latex_headers should apply in latex source blocks as well?



>> 3. It seems that the by-backend does not work properly for you.  I am
>> not sure about the reason for that.  What org-mode version do you run?
>
> And it doesn't work for me either.  I recently ran into this problem
> myself with a document (long book chapter with many tikz figures) that I
> wrote about 4 months ago.  I had a deadline so couldn't track down what
> was wrong but it is all about the by-backend macro.  No matter what the
> target for export is, the by-backend macro doesn't work.  I tried to fix
> it but no luck, mostly due to my lack of emacs lisp funess...

This macro is from Eric Schulte initially.  And I guess I would be out
of luck adapting it to new Org mode versions as well.

I'd vote for a macro like this to be included in Org mode.  I think it
is quite useful to have and somehow extends the @@latex: ...@ constructs
to babel.  That way updates to org breaking this would be less probable.

Unfortunately, I don't have the time right now to even upgrade Org mode.
So, I cannot offer any testing/bisecting, I am afraid.

Best,
Andreas

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Alan,

Glad you like the example.

Three things:
1. It still works for me ;-)
2. The distorted png might come from the bug in htlatex I mentioned in
this thread [1].
3. It seems that the by-backend does not work properly for you.  I am
not sure about the reason for that.  What org-mode version do you run?

HTH,
Andreas


[1] http://tex.stackexchange.com/a/232739



Alan Schmitt <alan.schm...@polytechnique.org> writes:
> Hello Andreas,
>
> I’m slowly catching up on the org mailing list, and I found your example
> very interesting. I tried to run it and it does not seem to work here.
> Here is what I did:
> - I copied the code below to a file
> - I evaluated the last block
> - I made sure that latex was one of the org-babel-load-languages
>   language
> - I tried executing the first block, which generated this strange png
>   
>
>
> - I exported both to html and pdf, and in both cases I would have
>   a reference to the png instead of the svg/tikz code.
>
> I’m afraid I’m missing a step. Do you see what I’m doing wrong?
>
> Thanks,
>
> Alan
>
> On 2015-08-12 10:50, Andreas Leha <andreas.l...@med.uni-goettingen.de> writes:
>
>> #+LATEX_HEADER: \usepackage{tikz}
>>
>> First execute the second code block, to define the convenience macro
>> and to set the required new variables in ob-latex.el.  Then export to
>> HTML and to pdf to see the tree exported as an SVG image and as
>> embedded tikz respectively.
>>
>> * Tikz test
>> Here's a tree, exported to both html and pdf.
>>
>> #+header: :file (by-backend (html "tree.svg") (latex "tree.tikz") (t 
>> "tree.png"))
>> #+header: :imagemagick :iminoptions -density 600 :imoutoptions -geometry 800
>> #+header: :results file raw
>> #+header: :fit yes
>> #+begin_src latex
>>   \usetikzlibrary{trees}
>>   \begin{tikzpicture}
>> \node [circle, draw, fill=red!20] at (0,0) {1}
>> child { node [circle, draw, fill=blue!30] {2}
>>   child { node [circle, draw, fill=green!30] {3} }
>>   child { node [circle, draw, fill=yellow!30] {4} }};
>>   \end{tikzpicture}
>> #+end_src
>>
>> #+results:
>> [[file:tree.png]]
>>
>> * COMMENT setup
>> #+begin_src emacs-lisp :results silent
>>   (setq org-babel-latex-htlatex "htlatex")
>>   (defmacro by-backend ( body)
>> `(case (if (boundp 'backend) (org-export-backend-name backend) nil) 
>> ,@body))
>> #+end_src

[O] export (to gfm) with file local variables

[Andreas Leha]

Hi all,

How can I make my toy sample file below export properly to github
flavoured markdown (using ox-gfm)?

(Of course including the file local variables in exported *.md file...)

If I try I get
,
| hack-local-variables: Malformed local variable line: 
`

Thanks,
Andreas


PS: the sample file
--8---cut here---start-8---
#+md: !-- Some Comment --

* Test File

With text.


#+md: !--
#+md: Local Variables:
#+md:  mode: gfm
#+md:  markdown-command: marked
#+md: End:
#+md: --
--8---cut here---end---8---

Re: [O] export (to gfm) with file local variables

[Andreas Leha]

I forgot...

Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 How can I make my toy sample file below export properly to github
 flavoured markdown (using ox-gfm)?

 (Of course including the file local variables in exported *.md file...)

... and without having them apply to the current *.org file.


 If I try I get
 ,
 | hack-local-variables: Malformed local variable line: 
 `

 Thanks,
 Andreas


 PS: the sample file

 #+md: !-- Some Comment --

 * Test File

 With text.


 #+md: !--
 #+md: Local Variables:
 #+md:  mode: gfm
 #+md:  markdown-command: marked
 #+md: End:
 #+md: --


Thanks,
Andreas

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Andreas Leha]

Hi, 

Ista Zahn istaz...@gmail.com writes:
 On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou
 m...@nicolasgoaziou.fr wrote:
 Ista Zahn istaz...@gmail.com writes:

 Unless you've restored sanity by setting org-export-babel-evaluate to
 nil. Personally I think this is not a good default. Source block
 evaluation and export are distinct actions, and I don't see why they
 should be linked by default.

 Wild guess:

 Principle of least surprise: setting it to nil means results from Babel
 code are not refreshed before export, without user realizing about it.
 I think most users would like them to be up-to-date before export. It
 seems sane to me.

 The problem is that if the code blocks are non-trivial it slows down
 the export. Changing one line of documentation and exporting
 re-evaluates all the code blocks, which for me often takes several
 minutes. The defaults work for trivial examples, but not my real-world
 use. Since it's easy to make it work how I want it to via
 org-export-babel-evaluate I don't mean to complain too much. I posted
 mostly to make sure the OP knows about org-export-babel-evaluate, in
 case disabling code block evaluation on export makes sense for them.


I know that problem...

Decoupling code block evaluation and export has the problem of
decoupling code block evaluation and export ;-), though.  If you export
your document without evaluating first, how can you be sure that the
resulting document is based on the latest version of the code contained
in the code blocks?  So, from my point of view the default is the safe
option and, thus, fine.


Regards,
Andreas

Re: [O] export (to gfm) with file local variables

[Andreas Leha]

Hi Nick,

Nick Dokos ndo...@gmail.com writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 I forgot...

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 How can I make my toy sample file below export properly to github
 flavoured markdown (using ox-gfm)?

 (Of course including the file local variables in exported *.md file...)

 ... and without having them apply to the current *.org file.


 If I try I get
 ,
 | hack-local-variables: Malformed local variable line: 
 `

 Thanks,
 Andreas


 PS: the sample file

 #+md: !-- Some Comment --

 * Test File

 With text.


 #+md: !--
 #+md: Local Variables:
 #+md:  mode: gfm
 #+md:  markdown-command: marked
 #+md: End:
 #+md: --



 Add a noexport section with a control-L as contents at the end.
 Emacs only looks at the last page of the file for local variables
 so the control-L will stop it.


Thanks!  That is amazing!  That solves my second problem.  So, the
original *.org file is indeed opened in Org mode.  Nice.


Now I still need to know how to export to github flavoured markdown
(gfm) with the file local variables set.  This still fails with
,
| hack-local-variables: Malformed local variable line: 
`

Any help with that?

For reference, here is my test org file again:
--8---cut here---start-8---
#+md: !-- Some Comment --

* Test File

With text.


#+md: !--
#+md: Local Variables:
#+md:  mode: gfm
#+md:  markdown-command: marked
#+md: End:
#+md: --
--8---cut here---end---8---


Thanks,
Andreas

Re: [O] export (to gfm) with file local variables

[Andreas Leha]

Hi Nick,

Nick Dokos ndo...@gmail.com writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Nick,

 Nick Dokos ndo...@gmail.com writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 I forgot...

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 How can I make my toy sample file below export properly to github
 flavoured markdown (using ox-gfm)?

 (Of course including the file local variables in exported *.md file...)

 ... and without having them apply to the current *.org file.


 If I try I get
 ,
 | hack-local-variables: Malformed local variable line: 
 `

 Thanks,
 Andreas


 PS: the sample file

 #+md: !-- Some Comment --

 * Test File

 With text.


 #+md: !--
 #+md: Local Variables:
 #+md:  mode: gfm
 #+md:  markdown-command: marked
 #+md: End:
 #+md: --



 Add a noexport section with a control-L as contents at the end.
 Emacs only looks at the last page of the file for local variables
 so the control-L will stop it.


 Thanks!  That is amazing!  That solves my second problem.  So, the
 original *.org file is indeed opened in Org mode.  Nice.


 Now I still need to know how to export to github flavoured markdown
 (gfm) with the file local variables set.  This still fails with
 ,
 | hack-local-variables: Malformed local variable line: 
 `

 Any help with that?


 That seems to be caused by the empty lines in the Local Variables:
 section of the md file:

 div id=table-of-contents
 h2Table of Contents/h2
 div id=text-table-of-contents
 ul
 lia href=#orgheadline11. Test File/a/li
 /ul
 /div
 /div

 !-- Some Comment --

 # Test Filea id=orgheadline1/a

 With text.

 !--

 Local Variables:

 mode: gfm

 markdown-command: marked

 End:

 --

 If I get rid of them manually, I think it goes away (although I don't
 have gfm installed, so it complains about gfm-mode).

 That seems to be an ox-md (or perhaps ox-html) issue however and I'm not
 equipped to wade into those waters. Assuming this is correct, maybe you
 can add a filter to get rid of the empty lines?


Thanks for following that up!  That is interesting.  How did you see
that file with the empty lines?  I do not get anything exported --
neither md nor gfm.

- Andreas

Re: [O] user-error: No language for src block: (unnamed) when running `org-icalendar-combine-agenda-files`

[Andreas Leha]

Hi,

Just a small comment.

[ ... discussion of :caching of evaluation results ... ]

 For purely R-based work, Charles Berry’s ox-ravel package
 https://github.com/chasberry/orgmode-accessories/blob/master/ox-ravel.org
 is a very interesting approach, since it relies on the cache feature of
 knitr, which is capable of automatically detecting cross-block
 dependencies like the example above under some circumstances
 http://yihui.name/knitr/demo/cache/.  It would be interesting to see
 if that approach could be used to override :cache handling for ob-R,
 while falling back on org-babel’s less intelligent features for other
 languages (or in R environments that don’t have knitr available). 

That would be just awesome!

Regards,
Andreas

Re: [O] export (to gfm) with file local variables

[Andreas Leha]

Nick Dokos ndo...@gmail.com writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:


 Thanks for following that up!  That is interesting.  How did you see
 that file with the empty lines?  I do not get anything exported --
 neither md nor gfm.


 I looked in the  *temp* buffer (which is normally hidden - note the
 initial space), saved it as foo.md and tried to open it: I got the local
 variables error.


Thanks a lot.  Something new to learn every day!  That is really useful
to know.

Regards,
Andreas

Re: [O] export (to gfm) with file local variables

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Hello,

 Nick Dokos ndo...@gmail.com writes:

 That seems to be caused by the empty lines in the Local Variables:
 section of the md file:

 div id=table-of-contents
 h2Table of Contents/h2
 div id=text-table-of-contents
 ul
 lia href=#orgheadline11. Test File/a/li
 /ul
 /div
 /div

 !-- Some Comment --

 # Test Filea id=orgheadline1/a

 With text.

 !--

 Local Variables:

 mode: gfm

 markdown-command: marked

 End:

 --

 If I get rid of them manually, I think it goes away (although I don't
 have gfm installed, so it complains about gfm-mode).

 That seems to be an ox-md (or perhaps ox-html) issue however and I'm not
 equipped to wade into those waters. Assuming this is correct, maybe you
 can add a filter to get rid of the empty lines?

 AFAIR, Markdown requires a blank line between elements (e.g.,
 paragraphs). I haven't followed the thread, but can't you use

   #+begin_markdown
   ...
   #+end_markdown

 instead?


I can.  Thanks a lot.  That works as expected.

Regards,
Andreas

[O] ox-gfm and toc

[Andreas Leha]

Hi all,

I am confused about how tables of content are handled in ox-gfm.


If I let org-mode do the default toc (#+OPTIONS: toc:t) then the TOC
seems to work -- even without using the generated anchors for the
headlines.

Test file:

--8---cut here---start-8---
* Test File

With text.
--8---cut here---end---8---

exports to

--8---cut here---start-8---


- [Test File](#test-file)

# Test Filea id=orgheadline1/a

With text.
--8---cut here---end---8---

This does not even use orgheadline1.




If I disable the default TOC and include a TOC later via `#+TOC:
headlines 2` this toc is constructed in html and uses links to anchors.
But these anchors are not present in the md file anymore, so the TOC is
broken.

Test file:

--8---cut here---start-8---
#+OPTIONS: toc:nil

#+TOC: headlines 2

* Test File

With text.
--8---cut here---end---8---

exports to

--8---cut here---start-8---
div id=table-of-contents
h2Table of Contents/h2
div id=text-table-of-contents
ul
lia href=#orgheadline11. Test File/a/li
/ul
/div
/div

# Test File

With text.
--8---cut here---end---8---

which refers to non-existent orgheadline1.


Is this a bug in ox-gfm?

Best,
Andreas

Re: [O] outorg issue

[Andreas Leha]

Hi Kaushal,

Kaushal kaushal.m...@gmail.com writes:
 I had submitted a pull request to solve this issue on that author's outshine 
 package page a couple of months back but as Andreas noted, the author hasn't 
 been able to maintain this stuff
 due to personal reasons.

 You can fix this issue by manually making changes in your copy of outshine as 
 per this PR: https://github.com/tj64/outshine/pull/46/files

 I use outshine daily and I needed to fix only outshine.el. Probably outorg.el 
 needs a similar fix?


Thanks for your patch!  In my first quick tests, this seems to work
nicely!  Nothing seems to be needed for outorg.

Regards,
Andreas

Re: [O] outorg issue

[Andreas Leha]

Hi Pip,

Pip Cet pip...@gmail.com writes:
 Hi,
 can you confirm the issue only appears when the first line of the
 buffer isn't an outline heading? I think it's easy enough to fix then,
 and if you like you might want to try the patch I've attached.

 It's bugged me for a while that `org-back-to-heading' et al throw
 errors when they're used before the first heading, but I haven't
 really come up with a better solution.

Thank you for your patch!  It seems as it breaks global visibility
cycling, though.

Regards,
Andreas

Re: [O] outorg issue

[Andreas Leha]

Hi Bastien,

Bastien b...@gnu.org writes:
 Hi Andreas,

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 For quite some time now, I have to disable outshine/outorg [1] as it
 does give me Before first heading (complete backtrace [2]) whenever I
 open an org file followed by more issues actually using org mode.

 Copying Thorsten as the author of outshine.el, hopefully he's be able
 to dig deeper.

Thanks, but my hopes are low.  Quoting from the top of outshine's github
readme [1]:

,
| events in my life forced me away from Emacs and [...] I won't have the
| time to fix issues or code new features (though I will apply patches)
`

Regards,
Andreas

[1] https://github.com/tj64/outshine

Re: [O] 8.3 hangs

[Andreas Leha]

Hi all,

Eric Abrahamsen e...@ericabrahamsen.net writes:
 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Samuel Wales samolog...@gmail.com writes:

 i am still getting a lot of hangs in 8.3.  most often, it is when i do
 a subtree sort.

 i keep trying element debug mode, but it has magical bug preventing 
 abilities.

 org-show-entry is another place where the bug occurs.  it is part of
 recreating a more folded state after undoing a sort.

 once it was like

 Debugger entered--Lisp error: (quit)
   org-element--cache-compare
   avl-tree--do-delete
   avl-tree--do-delete
   avl-tree--do-delete
   avl-tree--do-delete
   avl-tree--do-delete
   avl-tree-delete
   org-element--cache-process-request
   org-element--cache-sync(#buffer executive.org 31756)
   org-element-at-point()
   org-cycle-hide-drawers(children)
   org-show-entry()

 anybody else getting these hangs?

 I don't. However, as explained already, what triggers the hang is
 unimportant. Once cache is corrupted, many actions can trigger a freeze.
 What matters is the root of the corruption.

 I still get hangs from time to time, and `kill -12 $(pidof emacs)'
 always shows flyspell-mode in the mix. I never get hangs without
 flyspell-mode. I think this has been mentioned before, but I don't know
 if anyone went any farther with it. I still get hangs!

Same here.

Regards,
Andreas

Re: [O] named python session

[Andreas Leha]

Hi Ken,

Ken Mankoff mank...@gmail.com writes:
 Hi Andreas,

 On 2015-08-12 at 08:06, Andreas Leha andreas.l...@med.uni-goettingen.de 
 wrote:
 How do I associate that with the python process in *mypy*?
 I am asked to start python when I run python-shell-send-region.


 I have set up my system so that Org asks for a buffer name every time 
 =org-edit-special= is called. This may be helpful to you.

   -k.
  

 *** Custom Python Session Names

 https://github.com/jorgenschaefer/elpy/issues/383

 I want each python session to optionally have a unique name, so that I
 can run multiple sessions in multiple windows/buffers/directories and
 not have them interact/interfere.

 Here I've copied =elpy-shell-get-or-create-process= from =elpy.el= and
 modified it. I also have to modify =python-shell-get-process-name=.
 This all is fairly easy, except when executing from Org it gets more
 complicated, hence the special case if a function called from
 =org-ctrl-c-ctrl-c=. 

 #+BEGIN_SRC emacs-lisp :results none
   (defun elpy-shell-get-or-create-process ()
 Get or create an inferior Python process for current buffer and return 
 it.
 Customized by KDM to make dedicated sessions
 (let* ((bufname (format *%s* (python-shell-get-process-name t)))
(proc (get-buffer-process bufname)))
   (if proc
   proc
 (run-python (python-shell-parse-command) t nil) ;; DEDICATED!
 (get-buffer-process bufname

   (defun python-shell-get-process-name (dedicated)
 (if (equal this-command 'org-ctrl-c-ctrl-c)
 (kdm/orig-py-sh-get-proc-name dedicated)
   (kdm/my-py-sh-get-proc-name dedicated)))

   (defun kdm/orig-py-sh-get-proc-name (dedicated)
 Calculate the appropriate process name for inferior Python process.
If DEDICATED is t returns a string with the form
`python-shell-buffer-name'[variable `buffer-name'].
 (let ((process-name
(if (and dedicated
 (buffer-name))
(format %s[%s] python-shell-buffer-name (buffer-name))
  (format %s python-shell-buffer-name
   process-name))

   (defun kdm/my-py-sh-get-proc-name (dedicated)
 (if (boundp 'py-buf-proc-name)
 (format %s py-buf-proc-name)
   (setq-local py-buf-proc-name
   (format %s
   (completing-read Python session name: 
nil nil nil (buffer-name) nil 
 (buffer-name)))
   )))

 #+END_SRC

Thanks a lot for setting me on the right track!  I am quite surprised
(coming from ess as my interface to R) that multiple named sessions
aren't supported out of the box for python.

I use your code now, which in my use-case works great.  Only slight
variation: I set the default python process-name to the session name
using these two functions:

#+BEGIN_SRC emacs-lisp :results none
(defun al-org-babel-get-session (optional arg info)
  Return the :session of the current source-code block.
Will return
- nil if :session is given but not named
- \none\ if no :session argument is specified
- the session name otherwise
  (interactive)
  (if (org-src-edit-buffer-p)
  (let ((beg org-src--beg-marker))
(with-current-buffer (org-src--source-buffer)
  (goto-char beg)
  (al-org-babel-get-session)))
(let* ((info (or info (org-babel-get-src-block-info)))
   (params (nth 2 info))
   (session (cdr (assoc :session params
  session)))

(defun kdm/my-py-sh-get-proc-name (dedicated)
  (let* ((sessionname (al-org-babel-get-session))
 (defaultname (or sessionname (if (equalp sessionname none)
  (buffer-name)
sessionname
(if (boundp 'py-buf-proc-name)
(format %s py-buf-proc-name)
  (setq-local py-buf-proc-name
  (format %s
  (completing-read Python session name: 
   nil nil nil defaultname nil 
defaultname))
#+END_SRC

Thanks again,
Andreas

Re: [O] outorg issue

[Andreas Leha]

Hi John,

Thanks for the confirmation!

Andreas


John Kitchin jkitc...@andrew.cmu.edu writes:
 I can only confirm I have had the same issue for a while. For me it is
 mostly when I press shift-tab. regular tab works fine for cycling.

 The problem seems to arise from the point moving to the beginning of the
 buffer when outline-back-to-heading is called, which raises that
 error. I don't have time today to dig much further. I hope that helps
 get a solution though! I miss outshine!


 Andreas Leha writes:

 Hi all,

 For quite some time now, I have to disable outshine/outorg [1] as it
 does give me Before first heading (complete backtrace [2]) whenever I
 open an org file followed by more issues actually using org mode.

 I can even reproduce this with emacs -Q and a minimal configuration [3].

 My system is:
 : GNU Emacs 25.0.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 
 10.9.5 (Build 13F1077))
 :  of 2015-06-17
 : Org-mode version 8.3beta (release_8.3beta-1264-g365c19)


 Can anyone reproduce this and/or has a fix?  Or am I missing anything
 obvious?

 Thanks in advance!


 Regards,
 Andreas




 [1] https://github.com/tj64/outshine
 https://github.com/tj64/outorg


 [2] complete backtrace when opening a random org file

 --8---cut here---start-8---
 Debugger entered--Lisp error: (error Before first heading)
   signal(error (Before first heading))
   error(Before first heading)
   outline-back-to-heading()
   outline-flag-subtree(t)
   hide-subtree()
   (save-excursion (goto-char (point-min)) (hide-subtree) (show-children 
 keep-levels) (condition-case err (while (outline-get-next-sibling) 
 (hide-subtree) (show-children keep-levels)) (error nil)))
   hide-sublevels(1)
   org-overview()
   org-set-startup-visibility()
   org-mode()
   set-auto-mode-0(org-mode nil)
   set-auto-mode()
   normal-mode(t)
   after-find-file(nil t)
   find-file-noselect-1(#buffer cellomics.org 
 ~/hipsci/cellomics/cellomics.org nil nil 
 ~/hipsci/cellomics/cellomics.org (25636441 16777218))
   find-file-noselect(~/hipsci/cellomics/cellomics.org nil nil t)
   find-file(~/hipsci/cellomics/cellomics.org t)
   funcall-interactively(find-file ~/hipsci/cellomics/cellomics.org t)
   call-interactively(find-file nil nil)
   command-execute(find-file)
 --8---cut here---end---8---



 [3] minimal startup file

 --8---cut here---start-8---
 ;; outorg/outshine pre-requisite
 (defvar outline-minor-mode-prefix \M-#)

 (add-to-list 'load-path (expand-file-name 
 ~/local/emacs/org-mode-install/lisp))
 (add-to-list 'auto-mode-alist '(\\.\\(org\\  |org_archive\\|txt\\)$ . 
 org-mode))

 ;; outorg/outshine
 (add-to-list 'load-path ~/local/emacs/org-mode-in-comments/outorg/)
 (add-to-list 'load-path ~/local/emacs/org-mode-in-comments/outshine)
 (require 'outshine)
 (add-hook 'outline-minor-mode-hook 'outshine-hook-function)
 (setq outshine-use-speed-commands t)
 --8---cut here---end---8---

 --
 Professor John Kitchin
 Doherty Hall A207F
 Department of Chemical Engineering
 Carnegie Mellon University
 Pittsburgh, PA 15213
 412-268-7803
 @johnkitchin
 http://kitchingroup.cheme.cmu.edu

[O] named python session

[Andreas Leha]

Hi python users,

I have a simple question to all python users.  I have a source block
with a named python session, e.g. 
 #+begin_src python :results output :session mypy
   x = 1
   print x
 #+end_src

Now I
- execute that source block and then I
- edit that block in its own buffer via C-c '.

My question:
How do I associate that with the python process in *mypy*?

I am asked to start python when I run python-shell-send-region.

Thanks,
Andreas

[O] outorg issue

[Andreas Leha]

Hi all,

For quite some time now, I have to disable outshine/outorg [1] as it
does give me Before first heading (complete backtrace [2]) whenever I
open an org file followed by more issues actually using org mode.

I can even reproduce this with emacs -Q and a minimal configuration [3].

My system is:
: GNU Emacs 25.0.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 
10.9.5 (Build 13F1077))
:  of 2015-06-17
: Org-mode version 8.3beta (release_8.3beta-1264-g365c19)


Can anyone reproduce this and/or has a fix?  Or am I missing anything
obvious?

Thanks in advance!


Regards,
Andreas




[1] https://github.com/tj64/outshine
https://github.com/tj64/outorg


[2] complete backtrace when opening a random org file

--8---cut here---start-8---
Debugger entered--Lisp error: (error Before first heading)
  signal(error (Before first heading))
  error(Before first heading)
  outline-back-to-heading()
  outline-flag-subtree(t)
  hide-subtree()
  (save-excursion (goto-char (point-min)) (hide-subtree) (show-children 
keep-levels) (condition-case err (while (outline-get-next-sibling) 
(hide-subtree) (show-children keep-levels)) (error nil)))
  hide-sublevels(1)
  org-overview()
  org-set-startup-visibility()
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#buffer cellomics.org 
~/hipsci/cellomics/cellomics.org nil nil ~/hipsci/cellomics/cellomics.org 
(25636441 16777218))
  find-file-noselect(~/hipsci/cellomics/cellomics.org nil nil t)
  find-file(~/hipsci/cellomics/cellomics.org t)
  funcall-interactively(find-file ~/hipsci/cellomics/cellomics.org t)
  call-interactively(find-file nil nil)
  command-execute(find-file)
--8---cut here---end---8---



[3] minimal startup file

--8---cut here---start-8---
;; outorg/outshine pre-requisite
(defvar outline-minor-mode-prefix \M-#)

(add-to-list 'load-path (expand-file-name 
~/local/emacs/org-mode-install/lisp))
(add-to-list 'auto-mode-alist '(\\.\\(org\\  |org_archive\\|txt\\)$ . 
org-mode))

;; outorg/outshine
(add-to-list 'load-path ~/local/emacs/org-mode-in-comments/outorg/)
(add-to-list 'load-path ~/local/emacs/org-mode-in-comments/outshine)
(require 'outshine)
(add-hook 'outline-minor-mode-hook 'outshine-hook-function)
(setq outshine-use-speed-commands t)
--8---cut here---end---8---

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Haochen,

You can render svg from latex through org directly.  Here is a complete
example including a tikz diagram that that works on my system (once I
tackle a bug in PGF [1]).
It renders
- png by default (and for inlining the image into the org document)
- nothing for latex (directly include the tikz code into the tex document)
- svg for html


--8---cut here---start-8---
#+LATEX_HEADER: \usepackage{tikz}

First execute the second code block, to define the convenience macro
and to set the required new variables in ob-latex.el.  Then export to
HTML and to pdf to see the tree exported as an SVG image and as
embedded tikz respectively.

* Tikz test
Here's a tree, exported to both html and pdf.

#+header: :file (by-backend (html tree.svg) (latex tree.tikz) (t 
tree.png))
#+header: :imagemagick :iminoptions -density 600 :imoutoptions -geometry 800
#+header: :results file raw
#+header: :fit yes
#+begin_src latex
  \usetikzlibrary{trees}
  \begin{tikzpicture}
\node [circle, draw, fill=red!20] at (0,0) {1}
child { node [circle, draw, fill=blue!30] {2}
  child { node [circle, draw, fill=green!30] {3} }
  child { node [circle, draw, fill=yellow!30] {4} }};
  \end{tikzpicture}
#+end_src

#+results:
[[file:tree.png]]

* COMMENT setup
#+begin_src emacs-lisp :results silent
  (setq org-babel-latex-htlatex htlatex)
  (defmacro by-backend (rest body)
`(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body))
#+end_src
--8---cut here---end---8---


Regards,
Andreas

[1] http://tex.stackexchange.com/a/232739


Haochen Xie haoch...@acm.org writes:
 Hi Fabrice,

 Thank you for mentioning dvisvgm. I did some researches on it, and it seems 
 that as for now, the only way to invoke dvisvgm is to first export the latex 
 part to dvi, and call dvisvgm
 manually to convert it to svg, then include it in the org file, which, is too 
 troublesome for me. Is there any plan to add dvisvgm as an alternative to 
 dvipng and imagemagick? IMO svg
 images will look much better than png (well, in browsers supporting it), so 
 that's a nice option to have.

 Regards,

 Haochen

 --

 Mail from Haochen Xie

 On Tue, Aug 11, 2015 at 5:53 PM, Fabrice Popineau 
 fabrice.popin...@supelec.fr wrote:


  2015-08-11 10:47 GMT+02:00 Haochen Xie haoch...@acm.org:


  Hi Andreas,

  Thank you for your reply. I've read the whole thread, and found your
  example (the second link) very useful. Although for some reason, SVG
  image is not working well on my machine (not being displayed in
  chrome, nor on IE. I don't have firefox installed), but since the SVG
  image generated by imagemagick is indeed a raster image, I don't see
  any benefit using SVG over PNG, and exporting to PNG works perfectly.

  Use dvisvgm instead of imagemagick to generate the svg file.

  Fabrice

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Haochen,

Sorry for not being clearer.  There is no imagemagick involved in the
svg generation if everything is setup correctly.  Instead the command
defined in org-babel-latex-htlatex is used.  My test file sets this to
to htlatex from tex4th [1].

At the time of the thread I linked to there was a bug in ob-latex,
though.  So, make sure to be on a recent version of org (containing at
least the commit 510e7037988d44151dea5b98631839fc8003dd57 from
2015-03-21)

Just for reference, here are the first lines of the svg that is produced
for me which look fine to me:
--8---cut here---start-8---
?xml version=1.0 encoding=iso-8859-1 standalone=no? 
?xml-stylesheet href=latex-28543ACk.css type=text/css? 
svg xmlns=http://www.w3.org/2000/svg; 
xmlns:xlink=http://www.w3.org/1999/xlink; width=60.55959pt 
height=103.23871pt viewBox=-30.27975 -94.29848 60.55959 103.23871  
--8---cut here---end---8---


Regards,
Andreas


[1] https://www.tug.org/applications/tex4ht/mn-commands.html




Haochen Xie haoch...@acm.org writes:
 Hi Andreas,

 Thank you for your code example. I've tried almost the same code which
 I saw from the thread you referred (with the htlatex initialization,
 which I'm doing in my .emacs), and indeed got a svg file as
 expected. But the problem is that when I try to browse the HTML page
 in chrome, the image is shown as broken. I check the HTML source code,
 the image is presented in an img tag, pointing to the svg file. My
 first though was that the svg file isn't recognized because it's not
 served by a HTTP server instead of being a filesystem link. I then
 tried to use python SimpleHTTPServer, then python3 -m http.server (the
 python2 SimpleHTTPServer was serving svg with a wrong Content-Type)
 but without luck.

 Today, I tried svg again, and finally figured out the problem: the svg
 file generated doesn't contain a proper xmlns in the svg tag, so both
 chrome and internet explorer is interpreting it as a plain xml file
 instead of rendering it.

 I guess this is a bug with imagemagick, but when I tried to do some
 research on this problem I found nothing. Maybe I could find something
 with more researches, but I don't have time now, and PNG is fine for
 me.

 Still, Andreas, thank you very much for helping.

 Regards,

 Haochen

 --

 Mail from Haochen Xie

 On Wed, Aug 12, 2015 at 5:50 PM, Andreas Leha 
 andreas.l...@med.uni-goettingen.de wrote:


  Hi Haochen,

  You can render svg from latex through org directly. Here is a complete
  example including a tikz diagram that that works on my system (once I
  tackle a bug in PGF [1]).
  It renders
  - png by default (and for inlining the image into the org document)
  - nothing for latex (directly include the tikz code into the tex document)
  - svg for html

  --8---cut here---start-8---
  #+LATEX_HEADER: \usepackage{tikz}

  First execute the second code block, to define the convenience macro
  and to set the required new variables in ob-latex.el. Then export to
  HTML and to pdf to see the tree exported as an SVG image and as
  embedded tikz respectively.

  * Tikz test
  Here's a tree, exported to both html and pdf.

  #+header: :file (by-backend (html tree.svg) (latex tree.tikz) (t 
 tree.png))
  #+header: :imagemagick :iminoptions -density 600 :imoutoptions -geometry 800
  #+header: :results file raw
  #+header: :fit yes
  #+begin_src latex
  \usetikzlibrary{trees}
  \begin{tikzpicture}
  \node [circle, draw, fill=red!20] at (0,0) {1}
  child { node [circle, draw, fill=blue!30] {2}
  child { node [circle, draw, fill=green!30] {3} }
  child { node [circle, draw, fill=yellow!30] {4} }};
  \end{tikzpicture}
  #+end_src

  #+results:
  [[file:tree.png]]

  * COMMENT setup
  #+begin_src emacs-lisp :results silent
  (setq org-babel-latex-htlatex htlatex)
  (defmacro by-backend (rest body)
  `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body))
  #+end_src
  --8---cut here---end---8---

  Regards,
  Andreas

  [1] http://tex.stackexchange.com/a/232739

  Haochen Xie haoch...@acm.org writes:
   Hi Fabrice,
  
   Thank you for mentioning dvisvgm. I did some researches on it, and it 
 seems that as for now, the only way to invoke dvisvgm is to first export the 
 latex part to dvi, and call dvisvgm
   manually to convert it to svg, then include it in the org file, which, is 
 too troublesome for me. Is there any plan to add dvisvgm as an alternative to 
 dvipng and imagemagick? IMO svg
   images will look much better than png (well, in browsers supporting it), 
 so that's a nice option to have.
  
   Regards,
  
   Haochen
  
   --
  
   Mail from Haochen Xie
  
   On Tue, Aug 11, 2015 at 5:53 PM, Fabrice Popineau 
 fabrice.popin...@supelec.fr wrote:
  
  
   2015-08-11 10:47 GMT+02:00 Haochen Xie haoch...@acm.org:
  
  
   Hi Andreas,
  
   Thank you for your reply. I've read the whole

Re: [O] Block level specification for tex code html export method

[Andreas Leha]

Hi Haochen,


Haochen Xie haoc...@xie.name writes:
 Hi,

 I'm trying to include a diagram drawn with tikz in a document, but
 couldn't find an elegant way to conditionally export it as png when
 generating HTML output and raw TeX code when generating PDF. It is
 possible to use

 #+OPTIONS: tex:imagemagick

 to have tex blocks in the document exported as PNG in HTML, but since
 I have other formulas which will render much better with MathJAX other
 than embedded PNGs, i really don't want to do it. What I'm currently
 doing is to use something like

 #+BEGIN_SRC latex :file diagram.png :results value raw
 \begin{tikzpicture}
 \draw (0,0) grid (7,5);
 \draw (0,0) node[below left] {$A$};
 \draw (7,5) node[above right] {$B$};
 \fill (0,0) circle (2pt);
 \fill (7,5) circle (2pt);
 \end{tikzpicture}
 #+END_SRC

 #+RESULTS[da59bc402ce2d1055b5ff471ea7e398c4e0488f5]:
 [[file:diagram.png]]

 so that the diagram will be include in the HTML file as a png image,
 and the pdf file will also include it as a raster image.

 But this method is rather a workaround. I'd like to see a vector
 diagram in the pdf file, which could be achieved if there is a way to
 specify how a block of TeX source code should be handled when exported
 to HTML regardless to the global settings. So I propose an extension
 to #+BEGIN_LaTeX block so that a new header :html will control how the
 specific block will be handled when exporting to HTML. The possible
 values might be none, t, dvipng, or imagemagick. none will ignore
 the whole block when exporting to HTML, just like the current
 behavior; t will try to call MathJAX to interpret this block of TeX
 code; and dvipng and imagemagick will call dvipng or
 imagemagick to render a png file to be embedded in the HTML page.

 If that extension is supported, we could then left the global option
 tex:t while inline a tex powered figure with great convenience. For
 example, in my use case, I could then just used the following code to
 achieve what I want:

 #+BEGIN_LaTeX :html imagemagick
 \begin{tikzpicture}
 \draw (0,0) grid (7,5);
 \draw (0,0) node[below left] {$A$};
 \draw (7,5) node[above right] {$B$};
 \fill (0,0) circle (2pt);
 \fill (7,5) circle (2pt);
 \end{tikzpicture}
 #+END_LaTeX

 As I'm new to org-mode, I may missed something that I could use
 instead (although I searched the internet very hard). Please feel free
 to disagree on me and point alternative ways to achieve my goal.

 Thanks in advance.

 Best regards,

 Haochen


There has been a thread on this list recently on this topic [1].
See [2] for an example and [3] for some further explanations.

Regards,
Andreas

[1] http://comments.gmane.org/gmane.emacs.orgmode/95174

[2] http://permalink.gmane.org/gmane.emacs.orgmode/95197

[3] http://permalink.gmane.org/gmane.emacs.orgmode/95297

Re: [O] org-html-use-unicode-chars breaks source code blocks

[Andreas Leha]

Hi,

[ deleted: discussion on beatification ]


 My initial reaction was to kill it as well.  But I might feel like this a
 bit to often (I feel the same way about headline keywords like COMMENT).

There has been repeated 'bashing' of the COMMENT keyword lately on this
list.  Let me just raise a voice in defence.  I do not mind the syntax
too much, but the functionality of commenting a whole subtree without
loosing the outline functionality is really handy.  Especially also in
distinction to the equally handy :noexport: tag.

So, even if there is probably not a high risk for the COMMENT keyword to
be dropped I just wanted to express my support for it.

Regards,
Andreas

Re: [O] Babel and R: Call code block and output plot

[Andreas Leha]

Hi Stefan,

Stefan Nobis stefan...@snobis.de writes:
 Hi.

 I'm playing a little bit with R code blocks in babel and calling them
 in different parts of my document (e.g. showing output in the main
 part and the code in the appendix).

 With most code blocks (e.g. setting some variables or outputting a
 LaTeX table with xtable) this works as expected (thanks to all working
 on this; its really great).

 Now I wanted to show a plot, but the associated code should also be
 shown in the appendix. In this case CALL seems not to work (not plot
 file is created or its empty).

 Here is a small example of what I'm trying to achieve:

 #+TITLE: Plotting Test
 #+OPTIONS: author:nil date:nil email:nil toc:nil
 #+CREATOR: Emacs 24.5.1 (Org mode 8.2.10)
 #+STARTUP: showall
 #+PROPERTY: session *R*
 #+PROPERTY: exports results

 * Main Part

 Here I want to show some plot:

 #+CALL: myplot[:exports results]()

 * Appendix

 Here the code of the plot should be shown:

 #+NAME: myplot
 #+BEGIN_SRC R :results output graphics :exports code :file my-plot.pdf
 hist(rnorm(50))
 #+END_SRC

 Any ideas what I'm doing wrong or how to better achieve my goal?


You still have to specify the format of the results of the #+CALL line, as in
#+CALL: myplot[:exports results]() :results file

BTW, I also think the 'output' in :results is spurious.

This work for me:


--8---cut here---start-8---
#+TITLE: Plotting Test
#+OPTIONS: author:nil date:nil email:nil toc:nil
#+CREATOR: Emacs 24.5.1 (Org mode 8.2.10)
#+STARTUP: showall
#+PROPERTY: session *R*
#+PROPERTY: exports results

* Main Part

Here I want to show some plot:

#+CALL: myplot[:exports results]() :results file

#+results:
[[file:my-plot.pdf]]

* Appendix

Here the code of the plot should be shown:

#+NAME: myplot
#+BEGIN_SRC R :results graphics :exports code :file my-plot.pdf
hist(rnorm(50))
#+END_SRC
--8---cut here---end---8---

Best,
Andreas

Re: [O] bug: orgtbl-to-tsv: premature end of table

[Andreas Leha]

Hi all,

Charles C. Berry ccbe...@ucsd.edu writes:
 On Wed, 22 Jul 2015, Nicolas Goaziou wrote:

 Hello,

 Charles C. Berry ccbe...@ucsd.edu writes:

 Not a bug IMO.

 Notwithstanding the R issue, I think trimming the output of a radio
 table is a bit aggressive. We cannot know if trailing (and leading)
 spaces are significant in the output format the user defined.

 I removed the trimming part in commit
 bf37cd09b128b4431e1dd1a538fbcc4be3615042.

 Let me know if you disagree with that change.

 I don't think the change broke anything that wasn't already broken.

 And my diagnosis was wrong - I was confused by a problem that remains:

 `org-babel-R-assign-elisp' is broken. Ragged rows in a table are filled 
 with  in each missing field; `org-table-to-lisp' returns a list of lists 
 of common length.

 `org-babel-R-assign-elisp' inspects that list to see if any element vary 
 in length. But they do not, and therefore `max' and `min' in the let* 
 varlist are equal and later on `ob-R-transfer-variable-table-with-header' 
 is always used.

 I think lom pik's example would not have failed had max and min differed 
 as `ob-R-transfer-variable-table-without-header' would have been used 
 instead.

 R src blocks ought to render missing elements due to ragged rows in a 
 table as NA, but this isnt the current behavior for this table:

 #+NAME: tbl-ragged
 | 1 | 2 | a |

 | 8 | 9 |   |

 It seems like the fix for this would be to prune any  at the ends of 
 lists in the value arg when beginning  `org-babel-R-assign-elisp'.

 But I am tired, so I'll defer trying this till another time.

 Best,

 Chuck

Thank you all for looking into this.  I have seen this as well and the
manual work-around (to put sth into the last cell) was getting really
annoying -- especially if the table was auto-generated by sth else.

While looking at handling tables, could I suggest to switch to csv
instead of tsv for the table passing?  I still see issues with tables
not separated.  (This happens only in preview (C-c C-v v) and not when
executing the block.)  I never had time to track this down, but I get
caught now and then.  Using csv should be more robust in this regard.

Thanks,
Andreas

Re: [O] Emacs/ESS/org freezes/hangs on big data/ RAM(~256GB) processes when run in org/babel

[Andreas Leha]

Rainer M Krug rai...@krugs.de writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Rainer,

 Hi Andreas,


 Rainer M Krug rai...@krugs.de writes:
 Charles C. Berry ccbe...@ucsd.edu writes:

 On Wed, 17 Jun 2015, William Denton wrote:

 On 17 June 2015, Xebar Saram wrote:

 I do alot of modeling work that involves using huge datasets and run
 process intensive R processes (such as complex mixed models, Gamms etc). 
 in
 R studio all works well yet when i use the orgmode eval on R code blocks 
 it
 works well for small simple process but 90% of the time when dealing with
 complex models and bug data (up to 256GB) it will just freeze emacs/ess.
 sometimes i can C-c or C-g it and other times i need to physically kill
 emacs.

 I've been having the same problem for a while, but wasn't able to
 isolate it any more than large data sets, lack of memory, and heavy
 CPU usage. Sometimes everything hangs and I need to power cycle the
 computer. :(


 And you (both) have `ess-eval-visibly' set to nil, right?

 I do statistical genomics, which can be compute intensive. Sometimes
 processes need to run for a while, and I get impatient having to wait.

 I wrote (and use) ox-ravel[1] to speed up my write-run-revise cycle in
 org-mode.

 Basically, ravel will export Org mode to a format that knitr (and the
 like) can run - turning src blocks into `code chunks'. That allows me
 to set the cache=TRUE chunk option, etc. I run knitr on the exported
 document to initialize objects for long running computations or to
 produce a finished report.

 When I start a session, I run knitr in the R session, then all the
 cached objects are loaded in and ready to use.

 If I write a src block I know will take a long time to export, I
 export from org mode to update the knitr document and re-knit it to
 refresh the cache.

 I have a similar workflow, only that I use a package like
 approach, i.e. I tangle function definitions in a folder ./R, data into
 ./data (which makes it possible to share org defined variables with R
 running outside org) and scripts, i.e. the things which do a analysis,
 import data, ... i.e. which might take long, into a folder ./scripts/. I
 then add the usual R package infrastructure files (DESCRIPTION,
 NAMESPACE, ...).
 Then I have one file tangled into ./scripts/init.R:

 #+begin_src R :tangle ./scripts/init.R  
 library(devtools)
 load_all()
 #+end_src


 and one for the analysis:

 #+begin_src R :tangle ./scripts/myAnalysis.R  
 ## Do some really time intensive and horribly complicated and important
 ## stuff here
 save(
 fileNames,
 bw,
 cols,
 labels,
 fit,
 dens,
 gof,
 gofPerProf,
 file = ./cache/results.myAnalysis.rds
 )
 #+end_src


 Now after tangling, I have my code easily available in a new R session:

 1) start R in the directory in which the DESCRIPTION file is, 
 2) run source(./scripts/init.R)

 and I have all my functions and data available.

 To run a analysis, I do

 3) source(./scripts/myAnalysis.R)

 and the results are saved in a file fn

 To analyse the data further, I can then simply use

 #+begin_src R :tangle ./scripts/myAnalysis.R
 fitSing - attach(./cache/results.myAnalysis.rds)
 #+end_src


 so they won't interfere with my environment in R.

 I can finally remove the attached environment by doing

 #+begin_src R :tangle ./scripts/myAnalysis.R  
 detach(
 name = attr(fitSing, name),
 character.only = TRUE
 )
 #+end_src

 Through these caching and compartmentalizing, I can easily do some
 things outside org and some inside, and easily combine all the data.

 Further advantage: I can actually create the package and send it to
 somebody for testing and review and it should run out of the box, as in
 the DESCRIPTION file all dependencies are defined.

 I am using this approach at the moment for a paper and which will also
 result in a paper. By executing all the scripts, one will be able to do
 import the raw data, do the analysis and create all graphs used in the
 paper.

 Hope this gives you another idea how one can handle long running
 analysis in R in org,

 Cheers,

 Rainer


 That is a cool workflow.  I especially like the fact that you end up
 with an R package.

 Thanks. Yes - the idea of having a package at the end was one main
 reason why I am using this approach.



 So, I'll try my again.   Is there there any chance to see working
 example of this?  I'd love to see that.

 Let's say I am working on it. I am working on a project which is using
 this workflow and when it is finished, the package will be available as
 an electronic appendix to the paper.

 But I will see if I can condense an example and blog it - I'll let you
 kow when it is done.


Thanks!  Either way, I am really looking forward to this.

Regards,
Andreas

Re: [O] Emacs/ESS/org freezes/hangs on big data/ RAM(~256GB) processes when run in org/babel

[Andreas Leha]

Charles C. Berry ccbe...@ucsd.edu writes:
 On Thu, 18 Jun 2015, Andreas Leha wrote:

 Hi Chuck,

 [snip: all context about workflows for R projects]

 For example, the bioConductor package geneRxCluster [1] comes from an
 Org mode document that contains the C and R code as src blocks and a
 subtree with the vignette (Using geneRxCluster) that analyzes data,
 produces graphics, etc. tangle-ing the src blocks and exporting the
 vignette creates the package.


 I'd love to see that org document, but I do not seem to be able to find
 it.  Is it available anywhere?

 Andreas,

 It is now, or at least the relevant subset of it is at:

 https://github.com/chasberry/geneRx/blob/master/Rpackage.org

 It is best viewed in Org mode as there are internal links that github
 does not honor (so you get `404 This is not...' messages if you click
 on them).

 And it is best to use those internal links as the file was not
 designed to be read from top to bottom - it has lots of snippets I
 used to develop and check code along the way that are not in the
 actual package and I have left them in place.


That is awesome!  Really appreciated!  I will take a good look.

Thanks,
Andreas

Re: [O] Emacs/ESS/org freezes/hangs on big data/ RAM(~256GB) processes when run in org/babel

[Andreas Leha]

Hi Rainer,

Rainer M Krug rai...@krugs.de writes:
 Charles C. Berry ccbe...@ucsd.edu writes:

 On Wed, 17 Jun 2015, William Denton wrote:

 On 17 June 2015, Xebar Saram wrote:

 I do alot of modeling work that involves using huge datasets and run
 process intensive R processes (such as complex mixed models, Gamms etc). in
 R studio all works well yet when i use the orgmode eval on R code blocks it
 works well for small simple process but 90% of the time when dealing with
 complex models and bug data (up to 256GB) it will just freeze emacs/ess.
 sometimes i can C-c or C-g it and other times i need to physically kill
 emacs.

 I've been having the same problem for a while, but wasn't able to
 isolate it any more than large data sets, lack of memory, and heavy
 CPU usage. Sometimes everything hangs and I need to power cycle the
 computer. :(


 And you (both) have `ess-eval-visibly' set to nil, right?

 I do statistical genomics, which can be compute intensive. Sometimes
 processes need to run for a while, and I get impatient having to wait.

 I wrote (and use) ox-ravel[1] to speed up my write-run-revise cycle in
 org-mode.

 Basically, ravel will export Org mode to a format that knitr (and the
 like) can run - turning src blocks into `code chunks'. That allows me
 to set the cache=TRUE chunk option, etc. I run knitr on the exported
 document to initialize objects for long running computations or to
 produce a finished report.

 When I start a session, I run knitr in the R session, then all the
 cached objects are loaded in and ready to use.

 If I write a src block I know will take a long time to export, I
 export from org mode to update the knitr document and re-knit it to
 refresh the cache.

 I have a similar workflow, only that I use a package like
 approach, i.e. I tangle function definitions in a folder ./R, data into
 ./data (which makes it possible to share org defined variables with R
 running outside org) and scripts, i.e. the things which do a analysis,
 import data, ... i.e. which might take long, into a folder ./scripts/. I
 then add the usual R package infrastructure files (DESCRIPTION,
 NAMESPACE, ...).
 Then I have one file tangled into ./scripts/init.R:

 #+begin_src R :tangle ./scripts/init.R  
 library(devtools)
 load_all()
 #+end_src


 and one for the analysis:

 #+begin_src R :tangle ./scripts/myAnalysis.R  
 ## Do some really time intensive and horribly complicated and important
 ## stuff here
 save(
 fileNames,
 bw,
 cols,
 labels,
 fit,
 dens,
 gof,
 gofPerProf,
 file = ./cache/results.myAnalysis.rds
 )
 #+end_src


 Now after tangling, I have my code easily available in a new R session:

 1) start R in the directory in which the DESCRIPTION file is, 
 2) run source(./scripts/init.R)

 and I have all my functions and data available.

 To run a analysis, I do

 3) source(./scripts/myAnalysis.R)

 and the results are saved in a file fn

 To analyse the data further, I can then simply use

 #+begin_src R :tangle ./scripts/myAnalysis.R
 fitSing - attach(./cache/results.myAnalysis.rds)
 #+end_src


 so they won't interfere with my environment in R.

 I can finally remove the attached environment by doing

 #+begin_src R :tangle ./scripts/myAnalysis.R  
 detach(
 name = attr(fitSing, name),
 character.only = TRUE
 )
 #+end_src

 Through these caching and compartmentalizing, I can easily do some
 things outside org and some inside, and easily combine all the data.

 Further advantage: I can actually create the package and send it to
 somebody for testing and review and it should run out of the box, as in
 the DESCRIPTION file all dependencies are defined.

 I am using this approach at the moment for a paper and which will also
 result in a paper. By executing all the scripts, one will be able to do
 import the raw data, do the analysis and create all graphs used in the
 paper.

 Hope this gives you another idea how one can handle long running
 analysis in R in org,

 Cheers,

 Rainer


That is a cool workflow.  I especially like the fact that you end up
with an R package.

So, I'll try my again.   Is there there any chance to see working
example of this?  I'd love to see that.

Thanks,
Andreas

Re: [O] Emacs/ESS/org freezes/hangs on big data/ RAM(~256GB) processes when run in org/babel

[Andreas Leha]

Hi Chuck,

[snip: all context about workflows for R projects]

 For example, the bioConductor package geneRxCluster [1] comes from an
 Org mode document that contains the C and R code as src blocks and a
 subtree with the vignette (Using geneRxCluster) that analyzes data,
 produces graphics, etc. tangle-ing the src blocks and exporting the
 vignette creates the package.


I'd love to see that org document, but I do not seem to be able to find
it.  Is it available anywhere?

Thanks,
Andreas

Re: [O] org-babel-lob-ingest and debug-init

[Andreas Leha]

Hi,

Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Hello,

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 I have two lines like this in my .emacs:

 (org-babel-lob-ingest ~/path/to/library-of-babel.org)
 (org-babel-lob-ingest ~/path/to/custom-library-of-babel.org)


 All works fine usually.  But when I start emacs using the --debug-init
 option, these lines result in

 ,
 | Debugger entered--Lisp error: (error Before first heading)
 `

 Not sure whether this is relevant, but these are basically my first lines 
 in .emacs:

 (add-to-list 'load-path ~/path/to/org-mode-from-git/)
 (require 'org-loaddefs)

 Why do I get this error?

 Many thanks in advance,
 Andreas

 Sorry, this was the wrong diagnosis.  I get 'Before first heading' now
 quite often with Org mode files (visiting the file, global visibility
 cycling, etc.)

 I got myself into this by upgrading emacs [1].  I also upgraded Org
 mode [2] to no avail.

 What am I missing?

 Dunno. A backtrace with an uncompiled Org would help.


Sorry, I did not even test with emacs -q before reporting here.

I 'found' the problem.  The problem is outshine/outorg.  Disabling those
does solve the problem.

So, it is not really Org mode related.

Regards,
Andreas

[O] org-babel-lob-ingest and debug-init

[Andreas Leha]

Hi all,

I have two lines like this in my .emacs:

--8---cut here---start-8---
(org-babel-lob-ingest ~/path/to/library-of-babel.org)
(org-babel-lob-ingest ~/path/to/custom-library-of-babel.org)
--8---cut here---end---8---

All works fine usually.  But when I start emacs using the --debug-init
option, these lines result in

,
| Debugger entered--Lisp error: (error Before first heading)
`

Not sure whether this is relevant, but these are basically my first lines in 
.emacs:

--8---cut here---start-8---
(add-to-list 'load-path ~/path/to/org-mode-from-git/)
(require 'org-loaddefs)
--8---cut here---end---8---

Why do I get this error?

Many thanks in advance,
Andreas

Re: [O] org-babel-lob-ingest and debug-init

[Andreas Leha]

Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 I have two lines like this in my .emacs:

 (org-babel-lob-ingest ~/path/to/library-of-babel.org)
 (org-babel-lob-ingest ~/path/to/custom-library-of-babel.org)


 All works fine usually.  But when I start emacs using the --debug-init
 option, these lines result in

 ,
 | Debugger entered--Lisp error: (error Before first heading)
 `

 Not sure whether this is relevant, but these are basically my first lines in 
 .emacs:

 (add-to-list 'load-path ~/path/to/org-mode-from-git/)
 (require 'org-loaddefs)

 Why do I get this error?

 Many thanks in advance,
 Andreas

Sorry, this was the wrong diagnosis.  I get 'Before first heading' now
quite often with Org mode files (visiting the file, global visibility
cycling, etc.)

I got myself into this by upgrading emacs [1].  I also upgraded Org
mode [2] to no avail.

What am I missing?

Thanks,
Andreas



[1] GNU Emacs 25.0.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 
10.9.5 (Build 13F1077))

[2] Org-mode version 8.3beta (release_8.3beta-1264-g365c19)

Re: [O] Why navigating in Org mode is so slow in overview mode?

[Andreas Leha]

Hi Gregor,

Gregor Zattler telegr...@gmx.net writes:
 Hi Nicolas,
 * Nicolas Goaziou m...@nicolasgoaziou.fr [17. Jun. 2015]:
 Hello,
 
 Q godbles...@gmail.com writes:
 
 I am view this file
 http://doc.norang.ca/org-mode.org

 It's a prettey long document, when it all folded up, navigating to previous
 line and next line takes about 2 seconds. When the sub heading is shown,
 it's more responsive. Is this a bug?
 
 I don't know. What Org version are you using? Could you use a profiler
 and report results?

 I thought this is a known problem which gets worse with the
 amount of hidden text.  The workaround is to use a
 „#+STARTUP: showeverything“ directive.  I use this in order to
 make a longish org file with many clocking lines in drawers
 usable.

 It would be great if this could be fixed.

 I would like to help but need help myself on how to produce
 profiler reports.  My org mode version is

 8.3beta (release_8.3beta-1228-gd1f9aa @ /home/grfz/src/org-mode/lisp/)

 but I have this problem since months or years.


Shot in the dark: Do have linum-mode enabled?  That is always my first
candidate when I experience slowdowns.

Best,
Andreas

Re: [O] How to end a :session?

[Andreas Leha]

Hi Rainer,

Rainer M Krug rai...@krugs.de writes:
 Christopher Witte ch...@witte.net.au writes:

 perhaps what you want is a named session, see
 http://orgmode.org/manual/session.html

 Sure - that's what I have.

 But how can I close the named session when I don't need it anymore, or
 want to start, the next time I use the named session, with a new
 session?



 On 28 May 2015 at 10:44, Rainer M Krug rai...@krugs.de wrote:

 Hi

 I can start a session as follow:

 --8---cut here---start-8---
 #+begin_src R :session Test
 cat(Session Test\n)
 #+end_src
 --8---cut here---end---8---

 Now I hava an R session named *Test*. But how can I closes this session?
 I thought about just quitting R

 --8---cut here---start-8---
 #+begin_src R :session Test
 q(save = no)
 #+end_src
 --8---cut here---end---8---

 but this does not return as ESS is waiting for the prompt ().

 Is there a way of closing the session *Test* and close the buffer?

 My reasoning is that I want to do different longer analysis in one org
 file and start each in its own session, i.e. clean R. But as they
 involve several steps, I don't want to put them into one code block.

 So I have several code blocks which I want to execute in a throw away
 session which I would like to discard afterwards.

 So I am looking for something like

 #+CLOSE_SESSION Test

 which would then close the session *Test*

 Is something like this possible at the moment?


How about

--8---cut here---start-8---
#+name: killRsession
#+begin_src emacs-lisp :var rsession=*myR* :results none
(progn
  (switch-to-buffer rsession)
  (ess-quit)
  (sleep-for 1)
  (kill-buffer))
#+end_src


#+call: killRsession(*myR*) :results none
--8---cut here---end---8---

Andreas

Re: [O] How to end a :session?

[Andreas Leha]

Hi Rainer,

Rainer M Krug rai...@krugs.de writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Rainer,

 Hi Andreas,


 Rainer M Krug rai...@krugs.de writes:
 Christopher Witte ch...@witte.net.au writes:

 perhaps what you want is a named session, see
 http://orgmode.org/manual/session.html

 Sure - that's what I have.

 But how can I close the named session when I don't need it anymore, or
 want to start, the next time I use the named session, with a new
 session?



 On 28 May 2015 at 10:44, Rainer M Krug rai...@krugs.de wrote:

 Hi

 I can start a session as follow:

 --8---cut here---start-8---
 #+begin_src R :session Test
 cat(Session Test\n)
 #+end_src
 --8---cut here---end---8---

 Now I hava an R session named *Test*. But how can I closes this session?
 I thought about just quitting R

 --8---cut here---start-8---
 #+begin_src R :session Test
 q(save = no)
 #+end_src
 --8---cut here---end---8---

 but this does not return as ESS is waiting for the prompt ().

 Is there a way of closing the session *Test* and close the buffer?

 My reasoning is that I want to do different longer analysis in one org
 file and start each in its own session, i.e. clean R. But as they
 involve several steps, I don't want to put them into one code block.

 So I have several code blocks which I want to execute in a throw away
 session which I would like to discard afterwards.

 So I am looking for something like

 #+CLOSE_SESSION Test

 which would then close the session *Test*

 Is something like this possible at the moment?


 How about

 #+name: killRsession
 #+begin_src emacs-lisp :var rsession=*myR* :results none
 (progn
   (switch-to-buffer rsession)
   (ess-quit)
   (sleep-for 1)
   (kill-buffer))
 #+end_src


 #+call: killRsession(*myR*) :results none

 Thanks - this works. But I get an error which says:

 ,
 | save-excursion: Wrong type argument: integer-or-marker-p, nil
 `

 Any suggestion on how to avoid this?


I do not see that error, so hard to say.  Do you have a backtrace?  Wild
guess: Maybe the ess-quit changed?  What version of ess are you using?

Note, that this could be improved by replacing the (sleep-for 1) with
something that actually waits until R has quit...

- Andreas

Re: [O] How to end a :session?

[Andreas Leha]

Rainer M Krug rai...@krugs.de writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Rainer,

 Rainer M Krug rai...@krugs.de writes:
 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Rainer,

 Hi Andreas,


 Rainer M Krug rai...@krugs.de writes:
 Christopher Witte ch...@witte.net.au writes:

 perhaps what you want is a named session, see
 http://orgmode.org/manual/session.html

 Sure - that's what I have.

 But how can I close the named session when I don't need it anymore, or
 want to start, the next time I use the named session, with a new
 session?



 On 28 May 2015 at 10:44, Rainer M Krug rai...@krugs.de wrote:

 Hi

 I can start a session as follow:

 --8---cut here---start-8---
 #+begin_src R :session Test
 cat(Session Test\n)
 #+end_src
 --8---cut here---end---8---

 Now I hava an R session named *Test*. But how can I closes this session?
 I thought about just quitting R

 --8---cut here---start-8---
 #+begin_src R :session Test
 q(save = no)
 #+end_src
 --8---cut here---end---8---

 but this does not return as ESS is waiting for the prompt ().

 Is there a way of closing the session *Test* and close the buffer?

 My reasoning is that I want to do different longer analysis in one org
 file and start each in its own session, i.e. clean R. But as they
 involve several steps, I don't want to put them into one code block.

 So I have several code blocks which I want to execute in a throw away
 session which I would like to discard afterwards.

 So I am looking for something like

 #+CLOSE_SESSION Test

 which would then close the session *Test*

 Is something like this possible at the moment?


 How about

 #+name: killRsession
 #+begin_src emacs-lisp :var rsession=*myR* :results none
 (progn
   (switch-to-buffer rsession)
   (ess-quit)
   (sleep-for 1)
   (kill-buffer))
 #+end_src


 #+call: killRsession(*myR*) :results none

 Thanks - this works. But I get an error which says:

 ,
 | save-excursion: Wrong type argument: integer-or-marker-p, nil
 `

 Any suggestion on how to avoid this?


 I do not see that error, so hard to say.  Do you have a backtrace?  Wild
 guess: Maybe the ess-quit changed?  What version of ess are you using?

 ess-15.03


I am on ess-15.09-devel.


 Note, that this could be improved by replacing the (sleep-for 1) with
 something that actually waits until R has quit...

 I can live with the error for now, but I might look into it some time
 later.


Fine.

Andreas

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Nicolas,

some more spurious warnings I get:


1. Captions with short version:

,
| 1105 low   Possible missing colon in keyword #+caption[Data
`

2. header arguments from ob-latex:

,
|451 high  Unknown header argument packages
|451 high  Unknown header argument imoutoptions
|451 high  Unknown header argument iminoptions
|451 high  Unknown header argument imagemagick
|451 high  Unknown header argument fit
`


Best,
Andreas

Re: [O] ox-latex: includegraphics should quote filenames

[Andreas Leha]

Hi Vaidheeswaran,

Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:
 In:
 [[./emacs-24.5.1-startup-screen-annotated.png]]

 Buggy Out:

 \includegraphics[width=.9\linewidth]{./emacs-24.5.1-startup-screen-annotated.png}

 Desired: Out:

 \includegraphics[width=.9\linewidth]{{./emacs-24.5.1-startup-screen-annotated}.png}

 Source:

 http://tex.stackexchange.com/questions/10574/includegraphics-dots-in-filename

I agree.  Although I do not actually experience this, as my custom LaTeX
classes all \use[ the ]package{grffile} (also in your Reference) by now.

I have not experienced any problem with that package and it appears to
handle more cases (especially spaces) than 'quoting'.  So, it might be
an alternative to use grffile by default?  Even with the downside of
more dependencies.  But maybe more experienced LaTeX users might have a
different opinion.

Regards,
Andreas

Re: [O] [BUG] org-edit-src-auto-save-idle-delay no effect

[Andreas Leha]

Hi all,


Andreas Leha andreas.l...@med.uni-goettingen.de writes:
 Hi all,

 Today I found out the hard way, that org-edit-src-auto-save-idle-delay
 does not have any effect for me any more.  I'd say this is a serious
 regression.

 I have tested with emacs -Q.


Turned out I have not tested properly.  Things work with emacs -Q.  So
it is my configuration.  I'll investigate.  And sorry for the noise!

Regards,
Andreas

[O] [BUG] org-edit-src-auto-save-idle-delay no effect

[Andreas Leha]

Hi all,

Today I found out the hard way, that org-edit-src-auto-save-idle-delay
does not have any effect for me any more.  I'd say this is a serious
regression.

I have tested with emacs -Q.

My system:
- GNU Emacs 24.4.50.1 (x86_64-apple-darwin13.3.0, NS appkit-1265.21 Version 
10.9.4 (Build 13E28)) of 2014-09-02
- Org-mode version 8.3beta (release_8.3beta-1174-g9651ee)

Regards,
Andreas

Re: [O] [BUG] org-edit-src-auto-save-idle-delay no effect

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Hello,

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 All my tests now show that (at least) in a fresh emacs session the
 auto-saving still works -- also repeatedly.

 But in longer running emacs sessions things stop working: I edit the
 source buffer and wait but now auto-save will happen.  This is bad as
 with a longer running emacs the risk of crashing increases together with
 the risk of now auto-saves.

 I have no clue what triggers this.  How can I debug this?  I guess the
 timer is not working any more.

 Fixed in 59da320b307f5a6e74ad6ddc6554c09448caf431. Thank you.

 Regards,

How awesome is this?!?  I was asking for help on how to write a better
bug report and I get a 'fixed in ...' as an answer.  Amazing.

Thank you very much.  I'll carefully watch my src-edit buffers...

Regards,
Andreas

Re: [O] [BUG] org-edit-src-auto-save-idle-delay no effect

[Andreas Leha]

Hi all,

Here is now a more accurate but still vague bug description.

All my tests now show that (at least) in a fresh emacs session the
auto-saving still works -- also repeatedly.

But in longer running emacs sessions things stop working: I edit the
source buffer and wait but now auto-save will happen.  This is bad as
with a longer running emacs the risk of crashing increases together with
the risk of now auto-saves.

I have no clue what triggers this.  How can I debug this?  I guess the
timer is not working any more.

Thanks,
Andreas

Re: [O] position figures side by side in PDF output

[Andreas Leha]

Hi Zhihao,

Rasmus ras...@gmx.us writes:
 Hi Zhihao,

 Zhihao Ding zhihao.d...@imm.ox.ac.uk writes:

 Could anyone give me some advice on how to position figures side by side in 
 PDF output?
 I am trying to write a report, while my figures were all originally produced 
 individually.  I’d like 
 to put them, mostly two, sometimes three, side by side sharing a same 
 caption and label. 
 Below is the syntax I am using now, which can only do one figure. 

 Does this thread answer your question?  It would give you individual
 subcaptions, but you need not use them.

  https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00548.html

 Otherwise you could use e.g. imagemagick to stick together figures.


As an alternative you could use a table.
+ easy
+ orgmode only (should work across backends)
- no scaling of images
- it is a table for latex (i.e. will appear in list of tables, etc.)

Here is a short example for the table approach and an imagemagick-based
solution as proposed by Rasmus.


--8---cut here---start-8---
* generate images  :noexport:
#+name: image1
#+begin_src R :results graphics :file img1.pdf
  plot(1:10)
#+end_src

#+results: image1
[[file:img1.pdf]]

#+name: image2
#+begin_src R :results graphics :file img2.pdf
  plot(1:5)
#+end_src

#+results: image2
[[file:img2.pdf]]

* export side-by-side

** table
#+caption: stitching side-by-side using tables
| [[file:img1.pdf]] | [[file:img2.pdf]] |

** using imagemagick

*** function   :noexport:
#+name: sidebyside
#+begin_src sh :session none :results file replace :var im1=im1.png :var 
im2=im2.png :var outname=out.png
  convert $im1 $im2 +append $outname
  echo $outname
#+end_src

*** test
#+name: combinedfig
#+call: sidebyside(im1=img1.pdf, im2=img2.pdf) :results file

#+caption: stitching side-by-side using imagemagick
#+results: combinedfig
[[file:out.png]]
--8---cut here---end---8---

Regards,
Andreas

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Rainer,

Rainer M Krug rai...@krugs.de writes:
 Rainer M Krug rai...@krugs.de writes:

 Rainer M Krug rai...@krugs.de writes:

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Rainer,

 Rainer M Krug rai...@krugs.de writes:
 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 The following library implements linting for Org syntax. The sole public
 function is `org-lint', which see.

 Internally, the library defines a new structure: `org-lint-checker',
 with the following slots:

   - NAME: Unique check identifier, as a symbol. The check is done
 calling the function `org-lint-NAME' with one mandatory argument,
 the parse tree describing the current Org buffer. Such function
 calls are wrapped within a `save-excursion' and point is always at
 `point-min'. Its return value has to be an alist (POSITION MESSAGE)
 when POSITION refer to the buffer position of the error, as an
 integer, and MESSAGE is a strings describing the error.

   - DESCRIPTION: Summary about the check, as a string.

   - CATEGORIES: Categories relative to the check, as a list of symbol.
 They are used for filtering when calling `org-lint'. Checkers not
 explicitly associated to a category are collected in the `default'
 one.

   - TRUST: The trust level one can have in the check. It is either `low'
 or `high', depending on the heuristics implemented and the nature of
 the check. This has an indicative value only and is displayed along
 reports.

 All checks have to be listed in `org-lint--checkers'.

 Results are displayed in a special *Org Lint* buffer with a dedicated
 major mode, derived from `tabulated-list-mode'. In addition to the usual
 key-bindings inherited from it, C-j displays problematic line reported
 under point and RET jumps to it.

 Checks currently implemented are:

   - duplicates CUSTOM_ID properties
   - duplicate NAME values
   - duplicate targets
   - duplicate footnote definitions
   - orphaned affiliated keywords
   - obsolete affiliated keywords
   - missing language in src blocks
   - NAME values with a colon
   - wrong header arguments in src blocks
   - misuse of CATEGORY keyword
   - coderef links with unknown destination
   - custom-id links with unknown destination
   - fuzzy links with unknown destination
   - id links with unknown destination
   - links to non-existent local files
   - special properties in properties drawer
   - obsolete syntax for PROPERTIES drawers
   - missing definition for footnote references
   - missing reference for footnote definitions
   - non-footnote definitions in footnote section
   - probable invalid keywords
   - invalid blocks
   - probable incomplete drawers
   - obsolete QUOTE section

 Since it relies on lexical binding, `pcase' and `string-prefix-p', it
 cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
 useful enough.


 This sounds very interesting and I would like to try it out. I
 understand that it can't be put into master, but could it be put into a
 branch?

 This would make testing a bit easier.


 It is.  The branch is called `wip-lint'.

 Thanks (also to Nicolas) - I found it. Just expected the branch to be
 tracked automatically.

 This is really brilliant!

 But I now get a message in one .org file:

 ,
 | Org linting process starting...
 | Search failed: ^[]*#\\+NAME: +tab:sensVar
 `

 and no results.

 Works in other .org files.

 This one is rather long (11570 lines) and many code blocks.

 Just let me know how I can trace down where this is coming from and what
 the message tells me.

 It seems that the error comes from the fact that ~#+LABEL: sensVar~ was
 defined twice.

 Renaming these results in working linting.

 OK - please ignore this last comment.

 There is an example where I get the error:

 * Fitting the kernel to the data
 The parameter which will be fitted can be found in Table [[tab:fitInitial]]

 #+CAPTION: Variables used for the initial fit of the wind profile using the 
 function and the initial values.
 #+LABEL: tab:fitInitial
 | variable   | initial value | remark 
   |
 |+---+--|

 The cause is the link [[tab:initial]] If I remove everything below and
 including the line #+CAPTION the linting works.

 ,
 |  2 high  Unknown fuzzy location tab:fitInitial
 `


Untested - but should that not be
#+NAME: tab:fitInitial
rather than #+LABEL?

Cheers,
Andreas

Re: [O] [RFC] Org linting library

[Andreas Leha]

Nicolas Goaziou m...@nicolasgoaziou.fr writes:
 Hello,

 The following library implements linting for Org syntax. The sole public
 function is `org-lint', which see.

 Internally, the library defines a new structure: `org-lint-checker',
 with the following slots:

   - NAME: Unique check identifier, as a symbol. The check is done
 calling the function `org-lint-NAME' with one mandatory argument,
 the parse tree describing the current Org buffer. Such function
 calls are wrapped within a `save-excursion' and point is always at
 `point-min'. Its return value has to be an alist (POSITION MESSAGE)
 when POSITION refer to the buffer position of the error, as an
 integer, and MESSAGE is a strings describing the error.

   - DESCRIPTION: Summary about the check, as a string.

   - CATEGORIES: Categories relative to the check, as a list of symbol.
 They are used for filtering when calling `org-lint'. Checkers not
 explicitly associated to a category are collected in the `default'
 one.

   - TRUST: The trust level one can have in the check. It is either `low'
 or `high', depending on the heuristics implemented and the nature of
 the check. This has an indicative value only and is displayed along
 reports.

 All checks have to be listed in `org-lint--checkers'.

 Results are displayed in a special *Org Lint* buffer with a dedicated
 major mode, derived from `tabulated-list-mode'. In addition to the usual
 key-bindings inherited from it, C-j displays problematic line reported
 under point and RET jumps to it.

 Checks currently implemented are:

   - duplicates CUSTOM_ID properties
   - duplicate NAME values
   - duplicate targets
   - duplicate footnote definitions
   - orphaned affiliated keywords
   - obsolete affiliated keywords
   - missing language in src blocks
   - NAME values with a colon
   - wrong header arguments in src blocks
   - misuse of CATEGORY keyword
   - coderef links with unknown destination
   - custom-id links with unknown destination
   - fuzzy links with unknown destination
   - id links with unknown destination
   - links to non-existent local files
   - special properties in properties drawer
   - obsolete syntax for PROPERTIES drawers
   - missing definition for footnote references
   - missing reference for footnote definitions
   - non-footnote definitions in footnote section
   - probable invalid keywords
   - invalid blocks
   - probable incomplete drawers
   - obsolete QUOTE section

 Since it relies on lexical binding, `pcase' and `string-prefix-p', it
 cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
 useful enough.

 Feedback welcome.


 Regards,

Hi Nicolas,

I have finally made some time to test this.  I get some
unexpected warnings:

   79 low   Unknown value myfile.R for header :tangle
  192 low   Unknown value none for header :results
22985 low   Unknown value never-export for header :eval

Thanks for this very useful tool!

Thanks,
Andreas

[O] attachments in parent

[Andreas Leha]

Hi all,

As it seems, attachments are not found when they are attached to
a parental header.  Is that on purpose?

IMO, it would be nice if attachments would be searched for up the
hierarchy as well.  The attachment directory is not inherited, as
it seems.

Here is an example illustrating my question (you'll have to
attach something yourself to make it work, though):

--8---cut here---start-8---
* Example
** Test Attachments  :ATTACH:
:PROPERTIES:
:Attachments: sample_attachment.pdf
:ID:   B1024BF6-48F1-4300-9D0D-831A410BB40B
:END:

[[att:sample_attachment.pdf][This]] is found.

*** In Subsections

[[att:sample_attachment.pdf][This]] is not found.
--8---cut here---end---8---

Regards,
Andreas

PS: the relevant part of my setup:
--8---cut here---start-8---
(require 'org-attach)
(setq org-link-abbrev-alist '((att . org-attach-expand-link)))
--8---cut here---end---8---

Re: [O] [RFC] Org linting library

[Andreas Leha]

Hi Rainer,

Rainer M Krug rai...@krugs.de writes:
 Nicolas Goaziou m...@nicolasgoaziou.fr writes:

 Hello,

 The following library implements linting for Org syntax. The sole public
 function is `org-lint', which see.

 Internally, the library defines a new structure: `org-lint-checker',
 with the following slots:

   - NAME: Unique check identifier, as a symbol. The check is done
 calling the function `org-lint-NAME' with one mandatory argument,
 the parse tree describing the current Org buffer. Such function
 calls are wrapped within a `save-excursion' and point is always at
 `point-min'. Its return value has to be an alist (POSITION MESSAGE)
 when POSITION refer to the buffer position of the error, as an
 integer, and MESSAGE is a strings describing the error.

   - DESCRIPTION: Summary about the check, as a string.

   - CATEGORIES: Categories relative to the check, as a list of symbol.
 They are used for filtering when calling `org-lint'. Checkers not
 explicitly associated to a category are collected in the `default'
 one.

   - TRUST: The trust level one can have in the check. It is either `low'
 or `high', depending on the heuristics implemented and the nature of
 the check. This has an indicative value only and is displayed along
 reports.

 All checks have to be listed in `org-lint--checkers'.

 Results are displayed in a special *Org Lint* buffer with a dedicated
 major mode, derived from `tabulated-list-mode'. In addition to the usual
 key-bindings inherited from it, C-j displays problematic line reported
 under point and RET jumps to it.

 Checks currently implemented are:

   - duplicates CUSTOM_ID properties
   - duplicate NAME values
   - duplicate targets
   - duplicate footnote definitions
   - orphaned affiliated keywords
   - obsolete affiliated keywords
   - missing language in src blocks
   - NAME values with a colon
   - wrong header arguments in src blocks
   - misuse of CATEGORY keyword
   - coderef links with unknown destination
   - custom-id links with unknown destination
   - fuzzy links with unknown destination
   - id links with unknown destination
   - links to non-existent local files
   - special properties in properties drawer
   - obsolete syntax for PROPERTIES drawers
   - missing definition for footnote references
   - missing reference for footnote definitions
   - non-footnote definitions in footnote section
   - probable invalid keywords
   - invalid blocks
   - probable incomplete drawers
   - obsolete QUOTE section

 Since it relies on lexical binding, `pcase' and `string-prefix-p', it
 cannot be added to Org 8.3, but can make it into Org 8.4, if deemed
 useful enough.


 This sounds very interesting and I would like to try it out. I
 understand that it can't be put into master, but could it be put into a
 branch?

 This would make testing a bit easier.


It is.  The branch is called `wip-lint'.

Regards,
Andreas