I’m currently in the process of removing (or at least making substantial progress towards removing) the dependency on bibtex-completion in bibtex-actions, and am wondering what the best way is to create a new bib note for org-roam v2?
Basically, I have a bibtex-actions-open-notes command, which now opens a note if it exists. But I want it (at least optionally) to create a new note if it doesn’t exist.
Any tips?
I guess I’d use org-capture?
Doesn’t orb-edit-note do the job? At least you can look at its code to see how it implements the desired behaviour. It checks whether the note exists and prepares and calls org-roam-capture- otherwise.
I hadn’t checked, but ideally I could indeed just do something like this:
(setq bibtex-actions-file-edit-note-function 'orb-edit-note)
EDIT: yes, that’s exactly what I need!
Any chance you’ll be removing the org-ref dependency soon?
Good!
Not until org-cite citations scraping is implemented in Org-roam.
OK, I’'ll set it up so folks can do that, and note the option in the docstring.
Thanks!
A related followup:
What’s your current thinking on how to best identify a bib note?
I have examples like this in updated v2 notes files:
:ROAM_REFS: cite:wallace-wells2019
So if I understand right, ROAM_REFS replaces ROAM_KEY, and there can be multiple.
What about the value of that for bib notes in v2, and with org-cite?
The above is I guess org-ref syntax. It turns out org-cite won’t (currently at least) allow a citation to be inserted there. Should it?
What is the ideal way to do this going forward?
What’s your current thinking on how to best identify a bib note?
Through an external API. Either Org-ref or Org-cite or some other way. One should be able to take the string after fetching it from ROAM_REFS and prove it with the functions provided by the backend that it is indeed what Org-roam calls a ref. If it’s a ref, it should be cached in the sqlite database in the respective column. What is an Org-roam ref should be decided by Org-roam.
It’s then up to ORB to insert a valid string into ROAM_REFS—when the note is created through ORB—so that it can then be recognized as a ref by Org-roam and cached into the database. Currently, it inserts an cite:citekey link. It is trivial to make it insert a [cite:@citekey]. It is also up to ORB to be able to recognize a valid “bib note” in a ROAM_REFS string given to it, for orb-note-actions for example. Currently, ORB checks whether the string matches against org-ref-cite-re and recognizes it’s a bib note if if does match.
Org-roam actually doesn’t care much about Org-ref. What it calls a ref is just a valid link element. So any link in ROAM_REFS is recognized as a valid ref. Org-roam uses org-element to determine what’s in ROAM_REFS. If it is a link, it additionally checks it with org-ref-cite-types. If it is a member of that list, it does some processing to possibly split the cite keys and that’s it, nothing special about Org-ref. It does basically the same for other link types, so Org-roam recognizes a link as a valid ref as long as org-element (external API) is able to parse the string as an Org link.
To support org-cite, however, Org-roam should be able to recognize the Org element citation as a valid ref — to decide whether this should be cached into the database. It should be fairly easy to do though.
So if I understand right,
ROAM_REFSreplacesROAM_KEY, and there can be multiple.
Right. Also, by an unspoken convention ORB assumes that there is only one cite:link there. It doesn’t cover multiple.
What about the value of that for bib notes in v2, and with org-cite?
A valid citation element that can be parsed by org-element.
It turns out org-cite won’t (currently at least) allow a citation to be inserted there. Should it?
It cannot be inserted there by the interactive command org-cite-insert. Nothing prevents it to be inserted there programmatically by other means, nor for the string be read from there. There is one consequence, however. Currently, if one calls org-open-at-point while on a cite:link within ROAM_REFS, one gets the Org-ref hydra with familiar options to open PDF, go to the BibTeX entry, etc. Many users find this useful. With the current implementation of Org-cite in Org-mode, it seems that not only one cannot “officially” insert org-cite elements into property drawers, but they are also not recognized as such by org-element. This means that org-cite-activate or org-cite-follow processors don’t work there.
There’s another problem ATM, which there are other org-cite functions around export functionality based on these citations.
We wouldn’t want org-cite-list-citations, for example, to return these citations, as it could potentially screw up formatting. Basically, they should be ignored.
So if the constraints were loosened on this to allow them in property drawers, then other code would have to be adapted to ignore them.
Right?
If I understand all this correctly, I might ask on the org-mode list about this though.
EDIT: I just posted the question on the org list.
It depends on how exactly citations are collected for export. It’s possible to export without drawers, moreover people typically do not export drawers I guess. It’s actually easy to check.
But as I said, nothing prevents Org-roam from implementing support for org-cite citations. It will be fully working in terms of note indexing, backlinks and so on.
It depends on how exactly citations are collected for export.
A function that iterates though the citation elements, and returns the unique ones. It doesn’t have to consider property drawers ATM because they’re not allowed there; hence no associated functionality. That’s all I’m saying.
But as I said, nothing prevents Org-roam from implementing support for
org-citecitations. It will be fully working in terms of note indexing, backlinks and so on.
Yes, I understand, but I’m asking a broader question here; about interop and such. I just wanted to confirm we wanted cites allowed in the property drawers before asking for it.
https://lists.gnu.org/archive/html/emacs-orgmode/2021-08/msg00317.html
I didn’t say that. There may be a good reason why citations are not allowed in property drawers, and the export difficulties as you said may be one such reason. What I wanted to say is that neither Org-roam nor ORB need this as a technical requirement. The only reason this may be desirable is that some users, not sure how many, may find it useful to be able to activate a citation in the property drawer. I personally don’t need that, because I use the orb-note-actions interface, which in a broader sense acts as an “activate” processor for the citation key associated with the note.
Yes, I understand. But the latter point seems reason enough to ask the question, particularly given that links are allowed there. There have been a few other instances where the constraints have been loosened as a consequence.