Inconsistent use of \ref and \eqref in ox-latex and ox-html

[Brian Powell]

This topic was discussed in 2015:



However, it seems that it we are still stuck with inconsistent exports between 
latex and HTML.

The issue is that when exporting equation numbers with ox-html, it uses 
MathJax's \eqref that wraps the equation in parentheses, for example:

"Refer to (3) for more."

However, when exporting the same document with ox-latex, it uses Latex's \ref 
that does not wrap the equation in parentheses. Would it be possible to add an 
option or variable to ox-html for the user to select whether to use \ref or 
\eqref on export? 

For those of us that publish to HTML and PDF, it is very difficult because you 
end up with either double or no parentheses.

My proposed fix would be a change to ox-html from:

   (format "\\eqref{%s}"
   (org-export-get-reference destination info))

to

   (format (if org-html-export-mathjax-ref "\\ref{%s}" 
"\\eqref{%s}")
   (org-export-get-reference destination info))

The variable org-html-export-mathjax-ref is non-nil to use \ref vs. nil to be 
the default \eqref.

Cheers, 
Brian   

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

denis.maier.li...@mailbox.org writes:

> Bruce has already sent a link to Pandoc's org-mode Reader where you
> can find the citation modes. The standard (markdown) implementation
> can be found here:
> https://github.com/jgm/pandoc/blob/f2b337768e95c8903f65e597f7d8cd81938dacc3/src/Text/Pandoc/Readers/Markdown.hs
>

Thank you.

> Anyway, currently there are basically three modes:
> - NormalCitation
> - SuppressAuthor
> - AuthorInText

[...]

> So:
> [@doe] => NormalCitation
> [-@doe] => SuppressAuthor
> @doe argues ... => AuthorInText
> -@doe [23] => SuppressAuthor

Let's assume Org implements SuppressAuthor as "-@doe", so far it has:

| Syntax| Mode| Sample output |
|---+-+---|
| @doe or [cite:@doe]   | AuthorInText| Doe (2020)|
| -@doe or [cite:-@doe] | AuthorInText + SuppressAuthor   | (2020)|
| [@doe] or [(cite):@doe]   | NormalCitation  | (Doe, 2020)   |
| [-@doe] or [(cite):-@doe] | NormalCitation + SuppressAuthor | (2020)|

So, we could mix suppress author with some other style, although this
seems useless for the time being.

Current syntax is not great because it is ad-hoc, and not very
future-proof, if new modes appear. Also, the "(cite)" key is a bit
mouthful, "citep" might have been prettier. Anyway, is it complete
enough?

Also, there is some ambiguity between modes applying reference-wise,
i.e., "suppress author", and modes applying to the whole reference,
i.e., NormalCitation and AuthorInText.

Therefore, I'm wondering: has the following any meaning?

  [cite: -@doe; @foo]
  [(cite): -@doe; @foo]

> Depending on CSL's future development there might well be other
> citations modes. I personally think there's much to learn from
> biblatex, but that's a different debate...

As a related node, from Biblatex, we may also need, e.g., [(Cite):...],
but this was rejected for some reason a long time ago.

Regards,

-- 
Nicolas Goaziou

Re: org-clock misleading description for a prompt option

[Kyle Meyer]

Dmitrii Korobeinikov  writes:

>> That seems confusing to me as well (at least being the not-advanced
>> clocker that I am).  I suspect the confusion comes from the different
>> perspective from which it's written.  You're talking about restarting
>> Emacs and clocking in again; the description is, I think, written
>> assuming the context of the prompt being triggered due to idle time.  In
>> that scenario, hitting i/q or 'k => all' have the same effect; a new
>> entry is not created.
>
> I am not sure I follow. Is idle time some sort of concept used by
> org-clock for something more than the interface explanations?

Yes, see

(info "(org)Resolving idle time")

Even if you don't customize org-clock-idle-time, the option mentioned in
the second paragraph of that page, you can trigger that prompt manually
to account for being idle by calling org-resolve-clocks (bound to 'C-c
C-x C-z' by default).

> Whether I restart emacs or purposefully insert (while no clocks are
> running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do
> org-clock-in, the behaviour is the same.

Right.  I'd say that falls into the same category as the restart.  The
key, as you mention, it that there is no clock running (versus a clock
running with idle time to account for).

> Also, 'k => all' is not an
> option for me, it just asks for a number, defaulting to the elapsed
> time. Perhaps it's because I am running an older version of org-mode
> (9.3.6.)

Sorry for the unclear shorthand.  I just meant "hit k, select the
default value to keep all idle time".

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

[Salomon Turgman]

Thank you very much. I will explore what you suggest. I'm glad I emailed,
seems like I was going down the wrong path.

Salomon

On Fri, Apr 10, 2020, 1:10 PM Berry, Charles 
wrote:

> Salomon, see inline comments below.
>
> HTH,
>
> Chuck
>
> > On Apr 10, 2020, at 7:56 AM, Salomon Turgman  wrote:
> >
> > Hello all,
> >
> > Thanks in advance for any hints you can provide for this. I am trying to
> create a derived back-end that handles a new type of block in org-mode. I
> am trying to derive using the html export backend as a parent.
> >
> > Currently I am solving my problem like this:
> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
> level.
> > #+BEGIN_EXPORT html
> > Simulation 1: Manual control of the tank
> level.
> > 
> > 
> > 
> > Some other cool stuff here.
> > 
> > 
> > 
> > var app = Main1.init({node:
> document.getElementById("main1")});
> > #+END_EXPORT
> >
> > This has a few downsides:
> > 1. I have to specify the caption twice since export translator does not
> handle captions.
> > 2. I have to include substantial amounts of html.
> > 3. I have keep track of references to simulations manually (simulation
> 1, simulation 2, etc)
> > 4. I have to include the identifier `main1` or `Main1` in several
> locations in the snippet.
> >
> > I could solve some of this with an automated snippet insertion tool but
> I thought that maybe I can get the export back-end to do most of the work
> for me.
> >
> > So I am trying to derive as follows (in pseudo-elisp-code):
> > (require 'ox)
> > (require 'ox-html)
> >
> > (org-export-define-derived-backend 'textbook 'html
> >   :menu-entry
> >   '(?I "Export textbook section"
> >((?b "To buffer" org-html-export-as-html)
> >   (?I "To file" org-html-export-to-html)
> >   (?o "As HTML file and open"
> > (lambda (a s v b)
> >   (if a (org-html-export-to-html t s v b)
> >   (org-open-file (org-html-export-to-html nil s v
> b)))
> >   :translate-alist '((simulation . org-textbook-simulation)))
>
> From the `org-export-define-backend' docstring:
>
> "TRANSCODERS is an alist between object or element types and
> functions handling them."
>
> But `simulation' is not such a type. So, this will not work.
>
> >
> > (defun org-textbook-simulation (element contents info)
> >   (let* ((simnum (extract simnum value))
> >   (caption (org-export-get-caption element))
> >  (divid (extrac divid value))
> >   (modid (convert divid into modid))
> >  )
> > (format "Simulation %simnum%: %Caption%.
> >   
> > 
> > 
> >   
> > var app = %modid%.init({node:
> document.getElementById(\"%divid%\")});"
> >simnum caption divid modid divid)))
> >
> > With the hope that I can do something like this in my .org file:
> >
> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
> level.
> > #+BEGIN_SIMULATION main1
> > Some other cool stuff here
> > #+END_SIMULATION
>
>
> I think an easier approach is to write a babel src-block that formats the
> inputs you need and creates a value that is your desired output.
>
> Use `:var' header arguments to define the inputs.
>
> Use `:wrap html' to prevent the exporter from changing the output.
>
> Subsequent calls can use the `#+CALL' idiom.
>
> You can use any scripting language that suits you - elisp, python, shell,
> R, ... --- for this purpose.
>
> If you are skilled in emacs-lisp you might write an `eval' macro instead
> of a src block.
>
> >
> > Am I on the right track here? Can someone point me to an example on how
> to:
> > 1. Keep track of the number of simulations for referencing?
>
> Using the babel approach, you would need a `:session' with a persistent
> variable that would hold the count. You would need to initialize it in your
> document so that subsequent exports will start counting at zero.
>
> > 2. Extract the caption properly? The above is just my guess.
>
>
> IIRC, the info channel is not populated when babel runs, so you will need
> to parse the src-block and extract the `:caption' element. I think you can
> use a `:var cap=(find-caption)' idiom, where `find-caption' is a function
> you write using `org-element-context' as a starting point.
>
> Or if the only need you have for the caption is within that src block just
> use `:var cap="".
>
> > 3. Extract the divid value (main1)
>
> :var divid="main1"
>
>
> > 4. And finally, how to get org to recognize the new SIMULATION block so
> that it can apply `org-textbook-simulation`? Do I need to register this
> type of block somewhere? Or is the name of the first member of the
> :translate-alist translation pair have some special meaning?
>
> Don't go in that direction. Use babel or write an eval macro.
>
> [snip]
>

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

[Berry, Charles]

Salomon, see inline comments below. 

HTH, 

Chuck

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

> 3. Extract the divid value (main1)

:var divid="main1"


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

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

[snip]

Re: org-clock misleading description for a prompt option

[Dmitrii Korobeinikov]

> That seems confusing to me as well (at least being the not-advanced
> clocker that I am).  I suspect the confusion comes from the different
> perspective from which it's written.  You're talking about restarting
> Emacs and clocking in again; the description is, I think, written
> assuming the context of the prompt being triggered due to idle time.  In
> that scenario, hitting i/q or 'k => all' have the same effect; a new
> entry is not created.

I am not sure I follow. Is idle time some sort of concept used by
org-clock for something more than the interface explanations?

Whether I restart emacs or purposefully insert (while no clocks are
running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do
org-clock-in, the behaviour is the same. Also, 'k => all' is not an
option for me, it just asks for a number, defaulting to the elapsed
time. Perhaps it's because I am running an older version of org-mode
(9.3.6.)

пт, 10 апр. 2020 г. в 10:47, Kyle Meyer :
>
> Dmitrii Korobeinikov  writes:
>
> > When you run org-clock-in and then restart emacs, clocking in again
> > will show a prompt asking what to do w/ the unfinished entry. "i"
> > means "ignore this question; the same as keeping all the idle time".
> > However, a new entry is created if this is chosen without doing
> > anything about unfinished one. Keeping all the idle time w/ "k"
> > updates the unfinished entry before starting a new one. "i" doesn't do
> > that, so the description seems a bit misleading.
>
> That seems confusing to me as well (at least being the not-advanced
> clocker that I am).  I suspect the confusion comes from the different
> perspective from which it's written.  You're talking about restarting
> Emacs and clocking in again; the description is, I think, written
> assuming the context of the prompt being triggered due to idle time.  In
> that scenario, hitting i/q or 'k => all' have the same effect; a new
> entry is not created.
>
> This resolving on clock-in vs resolving when idle discrepancy shows in
> at least one other part of the description: the final sentence says that
> the uppercase variants leads to a clocked out state, but that's not true
> when org-clock-resolve is triggered from an org-clock-in call.
>
> So, while I think things could be improved here (contributions welcome),
> those changes should keep both contexts in mind.

Re: Bug: org-insert-item behaves weirdly and then fails

[Jarmo Hurri]

Nicolas Goaziou  writes:

> Indeed. This should now be fixed.

Was that quick or what!? Kudos.

Jarmo

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

[Salomon Turgman]

Hello all,

Thanks in advance for any hints you can provide for this. I am trying to
create a derived back-end that handles a new type of block in org-mode. I
am trying to derive using the html export backend as a parent.

Currently I am solving my problem like this:
#+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
#+BEGIN_EXPORT html
Simulation 1: Manual control of the tank level.



Some other cool stuff here.



var app = Main1.init({node:
document.getElementById("main1")});
#+END_EXPORT

This has a few downsides:
1. I have to specify the caption twice since export translator does not
handle captions.
2. I have to include substantial amounts of html.
3. I have keep track of references to simulations manually (simulation 1,
simulation 2, etc)
4. I have to include the identifier `main1` or `Main1` in several locations
in the snippet.

I could solve some of this with an automated snippet insertion tool but I
thought that maybe I can get the export back-end to do most of the work for
me.

So I am trying to derive as follows (in pseudo-elisp-code):
(require 'ox)
(require 'ox-html)

(org-export-define-derived-backend 'textbook 'html
  :menu-entry
  '(?I "Export textbook section"
   ((?b "To buffer" org-html-export-as-html)
(?I "To file" org-html-export-to-html)
(?o "As HTML file and open"
(lambda (a s v b)
  (if a (org-html-export-to-html t s v b)
(org-open-file (org-html-export-to-html nil s v b)))
  :translate-alist '((simulation . org-textbook-simulation)))

(defun org-textbook-simulation (element contents info)
  (let* ((simnum (extract simnum value))
 (caption (org-export-get-caption element))
 (divid (extrac divid value))
 (modid (convert divid into modid))
 )
(format "Simulation %simnum%: %Caption%.
  


  
var app = %modid%.init({node:
document.getElementById(\"%divid%\")});"
   simnum caption divid modid divid)))

With the hope that I can do something like this in my .org file:

#+CAPTION[Manual control]: Simulation 1: Manual control of the tank level.
#+BEGIN_SIMULATION main1
Some other cool stuff here
#+END_SIMULATION

Am I on the right track here? Can someone point me to an example on how to:
1. Keep track of the number of simulations for referencing?
2. Extract the caption properly? The above is just my guess.
3. Extract the divid value (main1)
4. And finally, how to get org to recognize the new SIMULATION block so
that it can apply `org-textbook-simulation`? Do I need to register this
type of block somewhere? Or is the name of the first member of the
:translate-alist translation pair have some special meaning?

Thank you very much for any assistance and thank you for org-mode!

-s-

Re: Bug: org-insert-item behaves weirdly and then fails

[Nicolas Goaziou]

Hello,

Jarmo Hurri  writes:

> Consider the following org file:
>
> # ---
> 1. Some text [fn:: foo]
>
> 2. 
>
> 3. with items
> # ---
>
> The bug can be reproduced with the following:
> 1. go to the end of first line
> 2. press M-return , that is (org-meta-return)
> 3. return to step 1
>
> You will notice that item numbers will first start to behave weirdly,
> then eventually an error will be thrown.

Indeed. This should now be fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

bug org-open-at-point zotero link

[Charles Millar]

Hi,

Current versions

Org mode version 9.3.6 (release_9.3.6-472-g8e3b73 @ 
/usr/local/share/org-mode/lisp/)
GNU Emacs 28.0.50 (build 91, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, 
cairo version 1.16.0) of 2020-04-10


From reading the documentation zotero is a valid link type and I would 
expect that org-open-at-point, C-c C-o, would open the following link


[[zotero://select/items/1_XPZL74VM][Behr, Michael. “A Research Workflow 
with Zotero and Org Mode.” mkbehr.com, September 19, 2015. 
http://www.mkbehr.com/posts/a-research-workflow-with-zotero-and-org-mode/.]]


Instead I receive the following error

request-default-error-callback: http://127.0.0.1:23119/zotxt/select error

I saved the link in Zotero with a snapshot.

I can open the link using org-zotxt-open-attachement.

If, however I save the link without a snapshot,

[[zotero://select/items/1_3AH6WNKZ][“A Research Workflow with Zotero and 
Org Mode | Mkbehr.Com.” Accessed April 10, 2020. 
http://www.mkbehr.com/posts/a-research-workflow-with-zotero-and-org-mode/.]]


and try org-zotxt-open-attachment I receive the following error

No attachments for item!
deferred error : (error "No attachments for item!")

If I org-open-at-point for the same link I receive

request-default-error-callback: http://127.0.0.1:23119/zotxt/select error

In the first instance is this a bug? Or is there a setting that I have 
to add to my localhost?


In the second case is this a org-zotxt or Zotero issue?

Charlie Millar

Bug: org-insert-item behaves weirdly and then fails

[Jarmo Hurri]

Greetings.

The following happens with the latest version of the stable branch and
the latest version of the master branch.

Consider the following org file:

# ---
1. Some text [fn:: foo]

2. 

3. with items
# ---

The bug can be reproduced with the following:
1. go to the end of first line
2. press M-return , that is (org-meta-return)
3. return to step 1

You will notice that item numbers will first start to behave weirdly,
then eventually an error will be thrown.

My emacs version is

GNU Emacs 26.3

Any ideas?

Jarmo

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Fri, Apr 10, 2020 at 5:30 AM  wrote:

...

> [Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
> citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 0, 
> citationHash = 0}] [Str "[@doe]"]]

I just wanted to add a quick note on this, in case anyone is wondering:

That `citationNoteNum` key there would be used internally where the
style "class" was "note-based"; as in, where the processor was
generating citations as footnotes.

In the CSL implementations I'm aware of (pandoc-citeproc with markdown
and org docs, or Zotero with LibreWrtier or MS Word), one can go
back-and-forth between "note-based" and "in-text" without modifying
the markdown source. The code is smart enough to know the different
between a citation in the text (that needs to be "footnoted"), and a
citation already in a footnote (which simply renders to be rendered,
without adding a new footnote), and how to get the correct footnote
numbering across the output document.

Bruce

Re: wip-cite status question and feedback

[denis . maier . lists]

Hi,

very good to see these things are getting discussed again. (Back then, I have 
been following the citation syntax discussion from a distance rather then 
participating actively, so that's my first post here.)

It would be great if Org had a closer integration with a Citeproc. This would 
be a huge improvement for those who use Emacs and Org for academic writing.

Anyway, concerning this:

> Speaking of which, I read about the "citation modes", which may be preferred 
> over "suppress author". What are these citation modes? How do you combine 
> them if "suppress author" is one of the "citation modes".

Bruce has already sent a link to Pandoc's org-mode Reader where you can find 
the citation modes. The standard (markdown) implementation can be found here: 
https://github.com/jgm/pandoc/blob/f2b337768e95c8903f65e597f7d8cd81938dacc3/src/Text/Pandoc/Readers/Markdown.hs

Anyway, currently there are basically three modes:
- NormalCitation
- SuppressAuthor
- AuthorInText

At the moment, there is no way to combine modes.

A simple markdown sample:

#+BEGIN_SRC
[@doe]

[-@doe]

@doe argues ...

-@doe [23]
#+END_SRC

Gives:

#+BEGIN_EXAMPLE
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix 
= [], citationMode = NormalCitation, citationNoteNum = 0, citationHash = 0}] 
[Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix 
= [], citationMode = SuppressAuthor, citationNoteNum = 0, citationHash = 0}] 
[Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix 
= [], citationMode = AuthorInText, citationNoteNum = 0, citationHash = 0}] [Str 
"@doe"],Space,Str "argues",Space,Str "\8230"]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix 
= [Str "23"], citationMode = SuppressAuthor, citationNoteNum = 0, citationHash 
= 0}] [Str "@doe",Space,Str "[23]"]]
#+END_EXAMPLE

So:
[@doe] => NormalCitation
[-@doe] => SuppressAuthor
@doe argues ... => AuthorInText
-@doe [23] => SuppressAuthor

I do admit that this last example is a bit pointless, but it shows a point. => 
SuppressAuthor takes precedence over the other modes in both cases.

Depending on CSL's future development there might well be other citations 
modes. I personally think there's much to learn from biblatex, but that's a 
different debate...

Best,
Denis

RE: [Bug] org-store-link should not insert a document level ID property

[Gustav Wikström]

Hi,

Just wanted to say that the patch is applied on master. It's solving the 
problem. Regarding user-configuration that can be added later if needed. It's 
not wrong right now per se.

Cheers!
Gustav

> -Original Message-
> From: Gustav Wikström
> Sent: den 5 april 2020 17:50
> To: Matt Lundin ; Org Mode List 
> Subject: RE: [Bug] org-store-link should not insert a document level ID
> property
> 
> Hi again,
> 
> Patch is attached. It's not applied yet as it doesn't include anything about
> user-configuration yet. @Matt Lundin, care to elaborate what you had in mind
> in terms of that?
> 
> With this patch a link before first headline is stored with the filename (no
> path) as description. Following the link does what you'd expect. Tests ran
> fine with the patch applied.
> 
> Regards
> Gustav
> 
> > Hi,
> >
> > > -Original Message-
> > > From: Matt Lundin 
> > > Sent: den 5 april 2020 00:13
> > > To: Org Mode List 
> > > Cc: Gustav Wikström 
> > > Subject: [Bug] org-store-link should not insert a document level ID
> property
> > >
> > > The introduction of document-level property drawers (commit
> > > 1bdff9f73dc1e7ff625a90e3e61350bdea99f29c from May 2019) introduced
> > > inconsistencies in the behavior of org-id and org-store-link.
> > >
> > > If org-id-link-to-org-use-id is set to t or 'create-if-interactive,
> > > calling org-store-link above the first headline in an org file will
> > > insert a PROPERTY drawer and an ID at top of the file, so that the file
> > > (call it "~/test.org") looks like this:
> > >
> > > --8<---cut here---start->8---
> > > :PROPERTIES:
> > > :ID:   1f43e860-9e7b-4c8f-82b9-6ed3352e589f
> > > :END:
> > >
> > > * First headline
> > > --8<---cut here---end--->8---
> > >
> > > However, the link that Org actually stores is "[[file:~/test.org]]", so
> > > the ID is irrelevant.
> > >
> > > In addition, a link to a document-level ID does not work. Following
> > > "[[id:1f43e860-9e7b-4c8f-82b9-6ed3352e589f]]" results in this error:
> > >
> > > user-error: Before first headline at position 14 in buffer test.org
> > >
> > > So either:
> > >
> > > 1. org-id and org-store-link/org-open-link should support document level
> > >ids in a user-configurable way, or
> > > 2. org-id-get-create should detect whether it is above the first heading
> > >and should not create an id
> > >
> > > Option #2 would obviously be the easier fix.
> > >
> > > Gustav: were IDs within the scope of your initial thinking about
> > > document level properties? Or are these largely irrelevant?
> >
> > Yes, they were in scope and ID should mean something also before first
> > headline. I'll have a look to see what can be done. Thanks for finding
> this!
> >
> > >
> > > Best,
> > > Matt

Re: org-ref: xxx-add-bibtex-entry with an org-capture like interface

[Alan Schmitt]

Hello,

On 2020-04-09 15:43, John Kitchin  writes:

> This is basically what doi-add-bibtex-entry does. There isn't one
> function that does arxiv too, but there is arxiv-add-bibtex-entry. Those
> are both commands in org-ref. These don't pop up a buffer for approval,
> that is something you would have to build yourself.
>
> There are many workflows people want, the one above works for me when I
> am writing, and just want to add entries with minimal disruption. I
> usually polish the entries later if needed. I can see a slower, approach
> like you describe too.

There is also the biblio-lookup command (from biblio.el,
https://github.com/cpitclaudel/biblio.el) that might be useful for this.

Best,

Alan

Org-babel Matlab (session) output is malformed

[Karthik Chikmagalur]

I'm trying to evaluate some Matlab code using org-babel in a session:

#+BEGIN_SRC matlab :session :results output
a = 4;
b = a + 3
c = a - 3
#+END_SRC

And following the org-babel documentation, (something like) this is the output 
I expect:

#+RESULTS:
#+begin_example
b =

 7

c =

 1
#+end_example

But this is the output I get:

#+RESULTS:
#+begin_example
a = 4;
b = a + 3

b =

 7
c = a - 3

c =

 1
'org_babel_eoe'

ans =

'org_babel_eoe'
#+end_example

(Including the =#+begin_example= etc)

After going through the source of the function =org-babel= calls, here is 
what's supposed to happen:

1. =org-babel-octave-evaluate-session= copies the code into the Matlab REPL 
(calling =matlab-shell= if necessary) and the shell runs it.
2. It then copies the result back as a string up to the end-of-evaluation 
token, and then removes the original code from the output string.

it looks like =org-babel-octave-evaluate-session= is not reading the 
end-of-evaluation token (='org_babel_eoe'=) correctly, and not removing the 
input code from the resulting string either. This looks like it should be an 
easy fix, but I couldn't figure it out.

Any ideas how to fix this?

Notes:

1. The relevant function(s) are in 
=/usr/share/emacs/27.0.90/lisp/org/ob-octave.el= or equivalent location. I am 
using Emacs 27.0.90.

2. The same org-babel module pulls double duty for Octave and Matlab with a 
flag to distinguish between uses, hence the name. When I run the same test as 
an Octave source block it runs correctly:
   
#+BEGIN_SRC octave :session :results output
a = 4;
b = a + 3
c = a - 3
#+END_SRC

#+RESULTS:
: 
: b =  7
: c =  1

3. This issue regards evaluation of source blocks with the =:results output= 
option, where org-babel includes in the results block everything that the REPL 
prints to stdout. (This is different from the default =:results value= option 
where only the return value of the block is considered as a result.)


- Karthik