Closed bdarcus closed 3 years ago
Thanks for raising this issue!
A few ideas, in rough order of importance/significance Style names, and (maybe) short aliases ... the obvious question is style/command names. I thought about maybe short aliases too, for users entering these by hand. WDYT?
Yes, a list of such cite styles/commands to support is definitely needed for the implementation, and a few days ago I received a comment notification about a useful proposal of yours complete with recommendations for short aliases but it seems that it got somehow deleted/lost in the meantime.
Would it be possible to allow for swappable backends? For example, to use the haskell or rust citeproc in place of the lisp-based processor.
I can certainly imagine separating functionality which is useful for plugging CSL citeproc libraries into Org in general from the citeproc-el specific parts; in fact this seems a very sensible approach. The details will probably become clearer when I start writing the code.
Edit: I do see you have the "backends" defcustoms, which is obviously related.
unfortunately, they are unrelated, citeproc-el has its own "backends" for producing output in different formats (currently there are backends for html, org, LaTeX and plain text), and those options specify how to map Org backends to these citeproc-el backends.
Yes, a list of such cite styles/commands to support is definitely needed for the implementation, and a few days ago I received a comment notification about a useful proposal of yours complete with recommendations for short aliases but it seems that it got somehow deleted/lost in the meantime.
That got overtaken by more recent discussions on the list, etc., particularly the messages today.
The current state of consensus is reflected on my wiki (just because I didn't know where else to put it):
At this point, the key decision point is around handling "variants"; whether to have sub-styles for this or not.
@andras-simonyi - you might be interested in these enhancements to parsebib, which includes support for csl-json:
Suggestion: just get something basic coded that will allow folks to use citeproc-org with org-cite that you can announce, and then add support for different styles and sub-styles as you have time and interest.
Suggestion: just get something basic coded that will allow folks to use citeproc-org with org-cite that you can announce, and then add support for different styles and sub-styles as you have time and interest.
Thanks, this is exactly the roadmap I have in mind, first just adapt citeproc-org to the new API and then develop citproc-el and citeproc-org further in tandem. It seems that finally I'll have some time to work on this, hopefully the first iteration can be done in the next few days, maybe some new features as well.
Great!
I just thought of something as a consequence of playing with the existing backends.
It would be nice to somehow be able to specify multiple backends and styles in the same file.
Example: a CSL style for citeproc-org, and a biblatex style for that processor.
Will you be able to remove the org-ref
requirement with this? It really bothers me how heavy that is, and that it installs things like helm by default, that I never use.
This is the mapping table I posted to the list yesterday, and which Nicolas implemented today.
Noauthor is aka "suppress author." Parentheses indicate shortcuts.
| Style | Variant | NatBib Command | BibLaTeX Command |
|---------------+----------------------+----------------+------------------|
| author (a) | caps-full (cf) | | Citeauthor |
| author (a) | full (f) | citeauthor* | citeauthor |
| author (a) | caps (c) | Citeauthor | Citeauthor* |
| author (a) | | citeauthor | citeauthor* |
|---------------+----------------------+----------------+------------------|
| noauthor (na) | bare | citeyear | |
| noauthor (na) | | citeyearpar | autocite* |
|---------------+----------------------+----------------+------------------|
| locators (l) | bare-caps (bc) | | Notecite |
| locators (l) | bare (b) | | notecite |
| locators (l) | caps (bc) | | Pnotecite |
| locators (l) | | | pnotecite |
|---------------+----------------------+----------------+------------------|
| nocite (n) | | nocite | nocite |
|---------------+----------------------+----------------+------------------|
| text (t) | bare (b) | citealp | |
| text (t) | caps (c) | Citep | Textcite |
| text (t) | full (f) | citep* | |
| text (t) | bare-caps (bc) | Citealp | |
| text (t) | bare-full (bf) | citealp* | |
| text (t) | caps-full (cf) | Citep* | |
| text (t) | bare-caps-full (bcf) | Citealp* | |
| text (t) | | | textcite |
|---------------+----------------------+----------------+------------------|
| (default) | caps (c) | Citep | Autocite |
| (default) | bare (b) | citealp | cite |
| (default) | bare-caps (bc) | Citealp | Cite |
| (default) | full (f) | citep* | |
| (default) | bare-full (bf) | citealp | |
| (default) | caps-full (cf) | Citep* | |
| (default) | bare-caps-full (bcf) | Citealp* | |
| (default) | | citep | autocite |
|---------------+----------------------+----------------+------------------|
Hmm ... guess Nicolas beat you to it ;-)
So maybe could see about adding "author" style support to citeproc.el
, which then makes it easy to support "text", since it's just "author/bare" + "noauthor" (suppress author).
Just wondering: should I still be using this repo, or is oc-csl.el
now a better option? Wnndering in particular if citeproc-org potentially interferes with the new system.
THanks!
Thanks for the comments! Based on the (astonishingly quick :-) ) development of the built in org-cite framework, I plan to remove wip-cite support from this package entirely but keep the package around for org-ref users -- as far as I can see several people rely on it, e.g., for exporting org-ref citations to Hugo using ox-hugo.
As for using the new native Org citations with CSL styles, I think the best bet will indeed be oc-csl
for a while. It's possible that in the future I'll try to put together an alternative org-cite CSL export processor with some extra capabilities (e.g., currently oc-csl
doesn't support org-bibtex bibliographies but citeproc-el
does, adding direct support for Zotero sqlite bibs is also a possibility), but for now the focus will definitely be on oc-csl
and on seeing how far it can be pushed.
@bdarcus: in the light of the comments above, should we close this issue, or rename it to something like "remove org-cite support"?
In the light of the above comments and the comments at the begiinning of the README I'm closing this.
Now that the draft code has been updated on the main org-mode repo, thought I'd put this to possibly discuss details best left off the list.
A few ideas, in rough order of importance/significance
Style names, and (maybe) short aliases
As I've been working on this: https://github.com/bdarcus/bibtex-actions/pull/113 ...
... the obvious question is style/command names.
In his latest post, Nicolas notes including these styles in the "basic" processor he coded (I'll put an asterick next to those that would be relevant to citeproc-el).
Current status of my UI is thus this, which aligns partially with
oc-basic
, with those not so relevant to CSL dropped, andlocators
added.I thought about maybe short aliases too, for users entering these by hand. WDYT?
To facilitate testing, could we have a small test file to load the proper config for use with
emacs -Q
?Here's the start of the init code; just need a citeproc processor to hook up to it.
https://gist.github.com/bdarcus/2645f99363fc47ddab2aae24c5d9e66c
Would it be possible to allow for swappable backends? For example, to use the haskell or rust citeproc in place of the lisp-based processor.
That would allow room to make citeproc-org the canonical processing interface, at least for CSL.
Edit: I do see you have the "backends" defcustoms, which is obviously related.