Continuing the discussion from Org-roam-bibtex for Org-Roam v2:
You should put the function in parentheses: M-x eval-expression (org-element-context)
I think this variable contains a list of Org elements, more specifically, only the elements called object containers. I checked it and in my case citation
is on the list. But somehow Org fails to parse it as such.
Good news: it parses as you expect on my end:
(citation
(:style "text"
:begin 39
:post-blank 0
:end 68
:contents-begin 50
:contents-end 67 ...))
… and when on an individual reference/key:
(citation-reference
(:key "aclu2011"
:begin 50
:end 67
:post-blank 0
:prefix (#("see " 0 4 ...))
:suffix (#(" p23" 0 4 ...)) ...))
Bad news: I guess there’s something wrong on your end.
BTW, I have had problems with running the bibtex-actions option last few days. If you were trying that, you might try with just the cite-init.el loaded.
I’ve figured out what’s wrong. The package has been loaded and working correctly. The problem is in the restrictions imposed on the citation keys. It appears that a citation key may only start with “_” or an alphabetical symbol:
(defconst org-element-citation-key-re
(rx "@"
(group
(any "_" alpha) ;; <- only "_" or alphabetical symbol
(opt (zero-or-more (any "#$%&+./:<>?_~-" alnum)) (any "_" alnum))))
"Regexp matching a citation key.
Key is located in match group 1.")
Since >95% of my citation keys start with a digit, e.g. 2020-JACS-8946
, and the one I was testing I randomly picked from the database, the citation I picked up was not recognized as such. Citation keys starting with a letter work fine.
I wonder whether this is a conscious decision or just an unintended bug.
It was an oversight. It should be fixed soon.
I was looking through the oc.el code, and wondering:
There’s a org-cite-list-keys
function, with the following docstring: “List citation keys in the exported document.”
But, per the docstring, it’s currently only available for export.
Would that be useful to have more widely available for OR/ORB?
I was thinking about @jethro’s note that:
Org-roam just needs to register the new citation links during db build and updates.
Would the above function work for that @jethro?
I’m asking because if the answer is yes I will ask if he can make the change.
Latest updates today should now have fixed this.
Bruce, thank you for coaxing org-cite out of the cold case and back into action. You appear, to me at least, to have provided the impetus to get this long-awaited and long-sorely-needed feature over the finish line.
My citation keys start with numbers too, so I’m relieved to see that this constraint was relaxed before the feature shipped.
Is there a document somewhere describing what the new org-cite
feature is?
I’m hoping for something with features found in the basic emacs bibtex links, mixed with features in org-ref.
First, that the links are to a bibtex or biblatex file of references.
Second, that links inside of an org file are rendered something like current emacs bibtex links. In other words, a link typed in like this:
… blah [[file:energy.bib::Wang13extrmQRpowTranf][Wang & Li 2013: Estimation Extreme Conditional]] blah blah…
is displayed in an emacs org buffer something like this:
… blah Wang & Li 2013: Estimation Extreme Conditional blah blah ,
Finally, it would also be great if, when you put your cursor over a link like the above, that emacs displayed the paper details in the minibuffer, as is done now by org-ref
.
Native Org citations are more like footnotes, which have been around for a while, but more powerful. They are not links, they are separate syntax elements. Org-cite provides a convenient programmer’s interface to implement what you have listed above. There is a basic support for “following” a citation, which allows to jump to the corresponding BibTeX entry.
Yeah, what @mshevchuk said. All of those features were discussed in development, so the design of org-cite
will make it all possible, if not necessarily implement it itself.
Practically speaking, I’d expect to see little packages pop up that implement different pieces of functionality on top of this. An org-ref
version targeted at this, would be a no-brainer, for example, and likely much simpler than the current code, though I do wonder if much smaller and more modular packages would make more sense doing forward.
Has the maintainer of org-ref
expressed interest in doing such a port?
Yes, with caveats.
What he says in this post seems to be his position; basically that it would provide an opportunity to simplify his code a lot and for that reason he’s interested, but that’s he’s busy with other things, so it would take time.
Thanks for the pointer @bruce, I’ll read that thread to gain a deeper understanding of this new feature and what’s likely next.
Do note more recent traffic this month and last reflects some evolution, in part based on these earlier discussions.
I do wonder if developers working in this space might benefit from a conversation, to avoid duplication and such. I still cannot really explain the landscape of these packages clearly; when one should use which, for example.
I’m not so familiar with navigating in the mail-list. Although I’ve read all conversation that I found, it’s not so clear to me how much they have progressed with this feature. Can anybody tell me if this feature branch is close to merging? What are the difference with wip-cite
and wip-cite-new
? Is one obsoleted and the other one active, or are they incompatible right now?
It is close to merging.
Edit: the former is obsoleted.
IIRC, the former had a shorthand and the “suppress-author” option that allowed you do this, as with pandoc citations:
[-@doe]
Both are now gone.
The latter adds “sub-styles”, so you can do [cite/text/full:@doe]
or shortcut [cite/t/f:@doe]
, and therefore use the same styles and sub-styles to target different output formats.
Not sure if I’ve mentioned this here yet, but org-cite recently got a new oc-csl
processor, which uses citeproc.el
to provide robust formatting across output formats.
So you will, for example, be able to set that as default, and it will work across HTML, LaTeX, plain text.
But you can also configure it, say, to output to biblatex for latex output.
Aside: I’ve also encouraged Nicolas to add citation previews derived from citeproc.el to that processor.
And the style+sub-style approach means citations are largely portable across the processor backends, basic, natbib, biblatex, csl.
Full disclosure: I’m the creator of CSL