* citations: org-cite vs org-ref 3.0
@ 2022-03-20 12:08 Vikas Rawal
2022-03-20 13:19 ` Nicolas Goaziou
` (2 more replies)
0 siblings, 3 replies; 73+ messages in thread
From: Vikas Rawal @ 2022-03-20 12:08 UTC (permalink / raw)
To: org-mode mailing list
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
I am sorry I have not followed the discussions recently. I had
happily settled on org-cite but I find that much has changed again.
In particular, John Kitchin has given up the work on org-ref-cite and
switched back to org-ref. There is a new org-ref version 3.0 which is not
compatible with org-cite.
This obviously creates many problems including that two people using
different citation systems cannot share org files.
What is the general view of the community about this? Is there a
comprehensive discussion of pros and cons of each?
What is everyone doing? I was an org-ref user for long before I switched to
org-cite. I can now shift to citar but since I am an ivy user, the switch
is not trivial. Also, I like many helper functions that John has created,
and would have to miss those if I do not use org-ref/org-ref-cite.
This seems messy.
Vikas
[-- Attachment #2: Type: text/html, Size: 1073 bytes --]
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: citations: org-cite vs org-ref 3.0 2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal @ 2022-03-20 13:19 ` Nicolas Goaziou 2022-03-20 14:08 ` Vikas Rawal ` (2 more replies) 2022-03-20 13:32 ` Bruce D'Arcus 2022-03-20 13:42 ` Ihor Radchenko 2 siblings, 3 replies; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-20 13:19 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list Hello, Vikas Rawal <vikasrawal@gmail.com> writes: > This obviously creates many problems including that two people using > different citation systems cannot share org files. Indeed. > > What is the general view of the community about this? I don't know about the general view of the community, but, as a data point, I find it very sad. That's not helpful, tho. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 13:19 ` Nicolas Goaziou @ 2022-03-20 14:08 ` Vikas Rawal 2022-03-20 14:38 ` Bruce D'Arcus 2022-03-21 0:31 ` John Kitchin 2022-03-21 14:40 ` Max Nikulin 2 siblings, 1 reply; 73+ messages in thread From: Vikas Rawal @ 2022-03-20 14:08 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: org-mode mailing list [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] > > > What is the general view of the community about this? > > I don't know about the general view of the community, but, as a data > point, I find it very sad. > Exactly how I feel. Particularly so because org-cite was indeed inspired from org-ref and all the great work John has done on this over the years. I do not see any substantive discussion of the limitations that John has pointed out with org-cite in the archives of the mailing list. We should have a conversation about those. If I understand correctly, the main limitation according to him is that org-cite does not handle cross-references. Is that the only problem? What do others think about it? Do we want the citation system to be able to handle cross-references? If not, do we need a separate system that handles cross-references beyond what is available in org-mode already? Can that system not be created in a manner that would not break the org-cite syntax? I think we should have a conversation and collectively think of what is the best way forward. Vikas [-- Attachment #2: Type: text/html, Size: 1332 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 14:08 ` Vikas Rawal @ 2022-03-20 14:38 ` Bruce D'Arcus 0 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-20 14:38 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list, Nicolas Goaziou On Sun, Mar 20, 2022 at 10:08 AM Vikas Rawal <vikasrawal@gmail.com> wrote: >> >> > What is the general view of the community about this? >> >> I don't know about the general view of the community, but, as a data >> point, I find it very sad. > > > Exactly how I feel. Particularly so because org-cite was indeed inspired from org-ref and all the great work John has done on this over the years. I do not see any substantive discussion of the limitations that John has pointed out with org-cite in the archives of the mailing list. We should have a conversation about those. > > If I understand correctly, the main limitation according to him is that org-cite does not handle cross-references. Is that the only problem? What do others think about it? Do we want the citation system to be able to handle cross-references? If not, do we need a separate system that handles cross-references beyond what is available in org-mode already? Can that system not be created in a manner that would not break the org-cite syntax? > > I think we should have a conversation and collectively think of what is the best way forward. Yes, and no. Conversation on org-cite took place on this list for years, with diverse people, with diverse expertise and POV, cycling in and out over that time. John raised the cross-reference question towards the very end, during the testing period, when it was almost merged. https://www.mail-archive.com/emacs-orgmode@gnu.org/msg138349.html I still think the path forward on that is TBD, though as I said, I don't think it should be in scope for org-cite per se, but org more generally yes. If he has some other issues (which I suspect he does; maybe related to fontification?) that might be addressed, I'm sure he'll raise them. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 13:19 ` Nicolas Goaziou 2022-03-20 14:08 ` Vikas Rawal @ 2022-03-21 0:31 ` John Kitchin 2022-03-21 1:39 ` Timothy ` (3 more replies) 2022-03-21 14:40 ` Max Nikulin 2 siblings, 4 replies; 73+ messages in thread From: John Kitchin @ 2022-03-21 0:31 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Vikas Rawal, emacs-orgmode I do not think it is productive for the community to say or consider it is a sad situation. Many good things have emerged from these discussions, even if it is not yet consensus on a solution. It is a complex problem, with many years of effort by many people on each side. That is an indication of how ambitious this project is and that there may be more than one solution that is needed. It pains me quite a bit there is a sentiment of fractionation, and that I may be contributing to it. My regular job workload the past few years has been crushing, and I have not had the time to participate in this that I wish I had. I am not sure I can add much here without sounding or feeling defensive about org-ref, and my decision to continue supporting and developing it. I have thought about this for most of the day, and in the (very long, apologies in advance) response that follows I will do my best to provide a balanced perspective (from my point of view) on the situation. Some specific context that is important to me is that I wrote org-ref long ago to solve a specific problem for me in the preparation of scientific publications that are destined for LaTeX export. I intended it to provide nearly equivalent bib(la)tex citation export, and as reasonable an export as possible for everything else. I use org-ref professionally, and it is a complete solution for me. I simply cannot compromise on the capability org-ref provides me, or wait for an alternative complete solution in org-mode. I have work I have to do now, and org-ref lets me do it. This alone is reason enough for me to continue using, developing and supporting org-ref. I understand org is not intended to be a substitute for writing LaTeX, but it is a fact of my job that I have to do that. There are more than 8 years of legacy org-ref documents. I have written 40+ scientific papers with it, and countless technical documents with more than 8000 cite links among them. org-ref has exceeded 190K downloads from MELPA, so I feel obligated to maintain org-ref for myself, and those users. org-ref may be heavyweight in bundling a lot of capability together that could be separated into individual packages, but it is also convenient for people who need it, and a GitHUB issue or pull request away from new features. I remain committed to supporting this, and I do it in a way I can manage, hence the monolithic package design. org-cite was also developed to solve some specific citation problems for others that org-ref did not address well at the time it was started. I believe those were issues like better pre/post note support, and integration with CSL. I think org-ref and org-cite have different priorities, they solve different problems with different approaches, and they have different pros and cons. I believe there are mutually incompatible compromises one must make here because the specific choices you make determine what is easy and what is possible. There is not a direct mapping of bib(la)tex and CSL as a citation processor. They are different programs and they don't share citation commands, or style information. It is inevitable that something will be lost in the translation between these from a single source like org, and whether that loss is acceptable depends on what you need. For many things, close enough is ok for me, but for manuscripts and proposals, they must be perfect, and in bib(la)tex form for the journals I publish in. It is not that one thing is possible in one and not the other; it is that you have to compromise one to do the other no matter what you choose and that typically makes one thing or the other easier to do. I am not even sure it is possible to do everything one can do in bib(la)tex with CSL, for example, I don't know the equivalent of \citenum in CSL. org-ref sides on making bib(la)tex easy, and CSL is possible. With org-cite, CSL can be readily used across export backends, more bibliography database formats are supported, and it is also possible to get LaTeX export, although there is no goal to fully support all of bib(la)tex. A pure org approach (e.g. org-files as bibliography database) can be used, there are a lot of CSL styles to work with, and you can develop or adapt your own style if needed. With reasonable defaults this should be a straightforward introduction to using citations for new users that works out of the box. I support that. With org-ref, bib(la)tex export is almost fully supported, and is easy, and other exports via CSL are possible. Of course, you must have a working LaTeX installation, only bibtex databases are supported, and working knowledge of bib(la)tex is required to leverage this. Whether you want it or not, you get a lot of extra utilities for getting bibtex entries from a DOI, and support for cross-references, indexes, glossaries and acronyms. This is a lot to ask of people who don't need it, and convenient for those who do. I support this. Which one of these approaches is right depends on what you want to be easy. Neither is right or wrong, that is determined by what you need at the time and what you prioritize in your solution. It is even possible you need both approaches at different times. The two approaches are not compatible, but it is org-mode after all, and you can certainly convert back and forth between them for the most part. Both projects have benefited from this discussion a lot. org has org-cite now, and org-ref now handles pre/post notes like org-cite does, it supports CSL much better, and is even a little more modular, lighter weight, and more easily integrated with other completion backends than ivy or helm. That should broadly be viewed as a win-win situation. Here are some factors that have prevented me from deprecating org-ref. I spent about a month and half trying to get a solution to this at https://github.com/jkitchin/org-ref-cite, and I don't make these observations lightly. That solution was complete and highly functional for org-cite, but as I describe below not a replacement for org-ref at this time. I still welcome a new maintainer for this code. Cross-references are critical for me; without them, there is no path forward for me with org-cite. I did work on a cross-reference approach that leveraged org-cite syntax (https://github.com/jkitchin/org-ref-cite/issues/16), but there was not much appetite for the approach so I abandoned that. There are cross-reference capabilities in org, that may be suitable for some applications, but they do not come close to what org-ref offers, and that the kind of technical documents I write require. For me, any cross-reference capability would also have to support what is possible in LaTeX, and preferrably look similar to the LaTeX commands. It has not been possible to write an orthogonal package that could co-exist with org-ref to address this; this would require a new syntax for cross-references in my opinion. My opinion is that practically citations and cross-references are just links to a place in your document (either a figure/table/section/etc, or an entry in a bibliography). In org-ref, both are represented by links; of course, they have different types and functions, but they both have follow like actions. My opinion seems to be in the minority on this. I do not like the abstraction away from LaTeX cite commands in org-cite. This is an example of a compromise between LaTeX and CSL. They do not share common citation commands, so you can either choose one or the other, or make a new abstraction that generalizes them. I strongly favor the LaTeX commands because I write for LaTeX export, and there is extensive documentation for how to cite in LaTeX and what to expect. Clearly org-cite favors using the standardized abstractions in org-cite, and then mapping them to the LaTeX commands I think. My perspective on this is partially one of an educator; I have taught a lot of people how to use org-mode for technical writing. This layer of abstraction adds additional complexity to documentation, and in teaching people what to do. As a LaTeX-centric user, that abstraction adds an additional cognitive load while writing I find unwelcome. I concede that it also reflects "what I do", that org is not LaTeX, and that others may have a more CSL centric perspective. org-cite is for them. I can see that the abstraction away from the LaTeX cite commands strengthens the org is not LaTeX philosophy, and will serve part of the community well. If I wasn't required to generate LaTeX documents, and teach others how to do it, I would not feel so strongly. It is my opinion that the modularity of org-cite is a challenge. I think it is too difficult to configure, and difficult to support, even more so than org-ref. I know my opinion differs from many on the list who want modularity and configurability. I have supported org-ref since around 2014, and even the modularity there (helm or ivy) has been a challenge to support. org-ref has always been configurable, but monolithic. Still, I learned a lot from Bruce (thank you!) that pushed me to redesign parts of org-ref to be more modular and more easily pluggable to other completion backends, and less specific on ivy/helm where practical. There are limitations to this I learned about, compromises one has to choose in doing it, and consequences in maintenance, support and documentation from them. We still don't fully agree on some of these points, but org-ref is closer to that ideal than it was. Maybe one day I will abandon ivy like I did helm many years ago and feel differently about this, but that day is sufficiently far away that I don't see it now. Finally, the org-cite code is magnificent, and written at a level well above my coding skills. I am grateful to those who wrote it, and especially to Nicolas, for the opportunity to learn from it. The code I wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced emacs-lisp techniques, and more complex data structures than I am accustomed to. I learned a lot studying the org-cite code, but I will be honest that I find it difficult to make contributions to. That gave me pause in continuing to develop it. It is fair to say that org-cite showed me some ways to address limitations of org-ref that I did not see before, org-ref is better for it, and the writing community that uses pre/post notes and biblatex is much better served as a result. Where does this leave me, org-ref and org-cite? I still have differences of opinion on design choices between them, and those differences are likely irreconcilable. These differences arise from my experiences in writing, teaching, using, developing and supporting org-ref. For those who need high fidelity LaTeX export like I do, I think org-ref is still a superior solution. For everyone else, and especially if you do not need sophisticated cross-references and don't want the dependencies of org-ref, org-cite is likely the better solution. I am content to agree to disagree on these points and move forward with both packages because they solve different problems, are suitable for different communities, and they continue to benefit each other. I can see not everyone sees this as a positive situation though, and that has weighed heavily upon me lately. These times are heavy enough. Anyway, this turned out much longer than I expected, so thanks everyone who has contributed to making org better, I hope I got things mostly correct, you found it a fair assessment, we might still be friends, and thanks for reading to the end. j Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Vikas Rawal <vikasrawal@gmail.com> writes: > >> This obviously creates many problems including that two people using >> different citation systems cannot share org files. > > Indeed. >> >> What is the general view of the community about this? > > I don't know about the general view of the community, but, as a data > point, I find it very sad. > > That's not helpful, tho. > > Regards, -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 0:31 ` John Kitchin @ 2022-03-21 1:39 ` Timothy 2022-03-21 8:16 ` Dominik Schrempf 2022-03-21 12:19 ` John Kitchin 2022-03-21 3:27 ` Vikas Rawal ` (2 subsequent siblings) 3 siblings, 2 replies; 73+ messages in thread From: Timothy @ 2022-03-21 1:39 UTC (permalink / raw) To: John Kitchin; +Cc: Vikas Rawal, emacs-orgmode, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 13908 bytes --] Hi John, Thanks for your considered response. When you contrast org-cite and org-ref, you say: > With org-ref, bib(la)tex export is almost fully supported, and is easy, I find this odd as org-cite supports bib(la)tex export, and rather easily. ┌──── │ #+bibliography: references.bib │ #+cite_export: biblatex authortitle/authortitle-ibid │ │ [cite:@key] etc. │ │ #+print_bibliography: └──── The limitation which I think is on your mind is that not all bib(la)tex commands are supported, and not in the “usual” form. For instance, to get `pnotecite' one would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, you can just customise `org-cite-biblatex-styles'. For instance, `parencite' is not currently available, but if I just add `("parencite" nil "parencite" nil nil)' I can then do `[cite/parencite:]' or if I replace the first `"parencite"' with `"paren"', just `[cite/paren:]'. A package could be created, say `org-cite-literal-biblatex' which is just a copy of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and `org-cite-biblatex-style-shortcuts' (or just sets those variables in `org-cite-biblatex'). As far as I can tell this would provide exactly the functionality you say org-cite can’t provide but org-ref does. You can already use `.bib' files, and so frankly I cannot myself see the point in org-ref’s existence beyond bifurcating the community on this. At this point the only remaining motivation I see is old documents and current users, and for this a migration tool seems more appropriate. I don’t mean to be overly critical, however this is my current honest assessment of the situation. – All the best, Timothy John Kitchin <jkitchin@andrew.cmu.edu> writes: > I do not think it is productive for the community to say or consider it > is a sad situation. Many good things have emerged from these > discussions, even if it is not yet consensus on a solution. It is a > complex problem, with many years of effort by many people on each side. > That is an indication of how ambitious this project is and that there > may be more than one solution that is needed. It pains me quite a bit > there is a sentiment of fractionation, and that I may be contributing to > it. > > My regular job workload the past few years has been crushing, and I have > not had the time to participate in this that I wish I had. I am not sure > I can add much here without sounding or feeling defensive about org-ref, > and my decision to continue supporting and developing it. I have thought > about this for most of the day, and in the (very long, apologies in > advance) response that follows I will do my best to provide a balanced > perspective (from my point of view) on the situation. > > Some specific context that is important to me is that I wrote org-ref > long ago to solve a specific problem for me in the preparation of > scientific publications that are destined for LaTeX export. I intended > it to provide nearly equivalent bib(la)tex citation export, and as > reasonable an export as possible for everything else. I use org-ref > professionally, and it is a complete solution for me. I simply cannot > compromise on the capability org-ref provides me, or wait for an > alternative complete solution in org-mode. I have work I have to do now, > and org-ref lets me do it. This alone is reason enough for me to > continue using, developing and supporting org-ref. I understand org is > not intended to be a substitute for writing LaTeX, but it is a fact of > my job that I have to do that. > > There are more than 8 years of legacy org-ref documents. I have written > 40+ scientific papers with it, and countless technical documents with > more than 8000 cite links among them. org-ref has exceeded 190K > downloads from MELPA, so I feel obligated to maintain org-ref for > myself, and those users. org-ref may be heavyweight in bundling a lot of > capability together that could be separated into individual packages, > but it is also convenient for people who need it, and a GitHUB issue or > pull request away from new features. I remain committed to supporting > this, and I do it in a way I can manage, hence the monolithic package > design. > > org-cite was also developed to solve some specific citation problems for > others that org-ref did not address well at the time it was started. I > believe those were issues like better pre/post note support, and > integration with CSL. > > I think org-ref and org-cite have different priorities, they solve > different problems with different approaches, and they have different > pros and cons. I believe there are mutually incompatible compromises one > must make here because the specific choices you make determine what is > easy and what is possible. There is not a direct mapping of bib(la)tex > and CSL as a citation processor. They are different programs and they > don’t share citation commands, or style information. It is inevitable > that something will be lost in the translation between these from a > single source like org, and whether that loss is acceptable depends on > what you need. For many things, close enough is ok for me, but for > manuscripts and proposals, they must be perfect, and in bib(la)tex form > for the journals I publish in. It is not that one thing is possible in > one and not the other; it is that you have to compromise one to do the > other no matter what you choose and that typically makes one thing or > the other easier to do. I am not even sure it is possible to do > everything one can do in bib(la)tex with CSL, for example, I don’t know > the equivalent of in CSL. org-ref sides on making bib(la)tex > easy, and CSL is possible. > > With org-cite, CSL can be readily used across export backends, more > bibliography database formats are supported, and it is also possible to > get LaTeX export, although there is no goal to fully support all of > bib(la)tex. A pure org approach (e.g. org-files as bibliography > database) can be used, there are a lot of CSL styles to work with, and > you can develop or adapt your own style if needed. With reasonable > defaults this should be a straightforward introduction to using > citations for new users that works out of the box. I support that. > > With org-ref, bib(la)tex export is almost fully supported, and is easy, > and other exports via CSL are possible. Of course, you must have a > working LaTeX installation, only bibtex databases are supported, and > working knowledge of bib(la)tex is required to leverage this. Whether > you want it or not, you get a lot of extra utilities for getting bibtex > entries from a DOI, and support for cross-references, indexes, > glossaries and acronyms. This is a lot to ask of people who don’t need > it, and convenient for those who do. I support this. > > Which one of these approaches is right depends on what you want to be > easy. Neither is right or wrong, that is determined by what you need at > the time and what you prioritize in your solution. It is even possible > you need both approaches at different times. The two approaches are not > compatible, but it is org-mode after all, and you can certainly convert > back and forth between them for the most part. > > Both projects have benefited from this discussion a lot. org has > org-cite now, and org-ref now handles pre/post notes like org-cite does, > it supports CSL much better, and is even a little more modular, lighter > weight, and more easily integrated with other completion backends than > ivy or helm. That should broadly be viewed as a win-win situation. > > Here are some factors that have prevented me from deprecating org-ref. I > spent about a month and half trying to get a solution to this at > <https://github.com/jkitchin/org-ref-cite>, and I don’t make these > observations lightly. That solution was complete and highly functional > for org-cite, but as I describe below not a replacement for org-ref at > this time. I still welcome a new maintainer for this code. > > Cross-references are critical for me; without them, there is no path > forward for me with org-cite. I did work on a cross-reference approach > that leveraged org-cite syntax > (<https://github.com/jkitchin/org-ref-cite/issues/16>), but there was not > much appetite for the approach so I abandoned that. There are > cross-reference capabilities in org, that may be suitable for some > applications, but they do not come close to what org-ref offers, and > that the kind of technical documents I write require. For me, any > cross-reference capability would also have to support what is possible > in LaTeX, and preferrably look similar to the LaTeX commands. It has not > been possible to write an orthogonal package that could co-exist with > org-ref to address this; this would require a new syntax for > cross-references in my opinion. My opinion is that practically citations > and cross-references are just links to a place in your document (either > a figure/table/section/etc, or an entry in a bibliography). In org-ref, > both are represented by links; of course, they have different types and > functions, but they both have follow like actions. My opinion seems to > be in the minority on this. > > I do not like the abstraction away from LaTeX cite commands in org-cite. > This is an example of a compromise between LaTeX and CSL. They do not > share common citation commands, so you can either choose one or the > other, or make a new abstraction that generalizes them. I strongly favor > the LaTeX commands because I write for LaTeX export, and there is > extensive documentation for how to cite in LaTeX and what to expect. > Clearly org-cite favors using the standardized abstractions in org-cite, > and then mapping them to the LaTeX commands I think. My perspective on > this is partially one of an educator; I have taught a lot of people how > to use org-mode for technical writing. This layer of abstraction adds > additional complexity to documentation, and in teaching people what to > do. As a LaTeX-centric user, that abstraction adds an additional > cognitive load while writing I find unwelcome. I concede that it also > reflects “what I do”, that org is not LaTeX, and that others may have a > more CSL centric perspective. org-cite is for them. I can see that the > abstraction away from the LaTeX cite commands strengthens the org is not > LaTeX philosophy, and will serve part of the community well. If I wasn’t > required to generate LaTeX documents, and teach others how to do it, I > would not feel so strongly. > > It is my opinion that the modularity of org-cite is a challenge. I think > it is too difficult to configure, and difficult to support, even more so > than org-ref. I know my opinion differs from many on the list who want > modularity and configurability. I have supported org-ref since around > 2014, and even the modularity there (helm or ivy) has been a challenge > to support. org-ref has always been configurable, but monolithic. Still, > I learned a lot from Bruce (thank you!) that pushed me to redesign parts > of org-ref to be more modular and more easily pluggable to other > completion backends, and less specific on ivy/helm where practical. > There are limitations to this I learned about, compromises one has to > choose in doing it, and consequences in maintenance, support and > documentation from them. We still don’t fully agree on some of these > points, but org-ref is closer to that ideal than it was. Maybe one day I > will abandon ivy like I did helm many years ago and feel differently > about this, but that day is sufficiently far away that I don’t see it > now. > > Finally, the org-cite code is magnificent, and written at a level well > above my coding skills. I am grateful to those who wrote it, and > especially to Nicolas, for the opportunity to learn from it. The code I > wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced > emacs-lisp techniques, and more complex data structures than I am > accustomed to. I learned a lot studying the org-cite code, but I will be > honest that I find it difficult to make contributions to. That gave me > pause in continuing to develop it. It is fair to say that org-cite > showed me some ways to address limitations of org-ref that I did not see > before, org-ref is better for it, and the writing community that uses > pre/post notes and biblatex is much better served as a result. > > Where does this leave me, org-ref and org-cite? I still have differences > of opinion on design choices between them, and those differences are > likely irreconcilable. These differences arise from my experiences in > writing, teaching, using, developing and supporting org-ref. For those > who need high fidelity LaTeX export like I do, I think org-ref is still > a superior solution. For everyone else, and especially if you do not > need sophisticated cross-references and don’t want the dependencies of > org-ref, org-cite is likely the better solution. > > I am content to agree to disagree on these points and move forward with > both packages because they solve different problems, are suitable for > different communities, and they continue to benefit each other. I can > see not everyone sees this as a positive situation though, and that has > weighed heavily upon me lately. These times are heavy enough. Anyway, > this turned out much longer than I expected, so thanks everyone who has > contributed to making org better, I hope I got things mostly correct, > you found it a fair assessment, we might still be friends, and thanks > for reading to the end. > > j ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 1:39 ` Timothy @ 2022-03-21 8:16 ` Dominik Schrempf 2022-03-21 11:51 ` Bruce D'Arcus 2022-03-21 12:19 ` John Kitchin 1 sibling, 1 reply; 73+ messages in thread From: Dominik Schrempf @ 2022-03-21 8:16 UTC (permalink / raw) To: Timothy; +Cc: Vikas Rawal, emacs-orgmode, Nicolas Goaziou, John Kitchin [-- Attachment #1: Type: text/plain, Size: 14909 bytes --] Hi, I am trying out `org-cite' right now. It works much better than the last time (I am using the `biblatex' backend right now). However, I can not find any documentation about the available /styles/. They are mentioned here: <https://orgmode.org/manual/Citations.html> But no styles are provided. For example, I need citations in the text (showing up as “Author(s) (Year)”). With BibTeX, this would be `\citet{}' (or `\textcite{}' with BibLaTeX). But there is a lot more. See: <http://tug.ctan.org/info/biblatex-cheatsheet/biblatex-cheatsheet.pdf>). Thank you for working on `org-cite', and `org-ref'! Dominik Timothy <tecosaur@gmail.com> writes: > Hi John, > > Thanks for your considered response. > > When you contrast org-cite and org-ref, you say: > >> With org-ref, bib(la)tex export is almost fully supported, and is easy, > > I find this odd as org-cite supports bib(la)tex export, and rather easily. > > ┌──── > │ #+bibliography: references.bib > │ #+cite_export: biblatex authortitle/authortitle-ibid > │ > │ (NO_ITEM_DATA:key) etc. > │ > │ #+print_bibliography: > └──── > > The limitation which I think is on your mind is that not all bib(la)tex commands > are supported, and not in the “usual” form. For instance, to get `pnotecite’ one > would use `[cite/locators:]’. However, to get a 1-to-1 name mapping, you can just > customise `org-cite-biblatex-styles’. For instance, `parencite’ is not currently > available, but if I just add `(“parencite” nil “parencite” nil nil)’ I can then do > `[cite/parencite:]’ or if I replace the first `“parencite”’ with `“paren”’, just > `[cite/paren:]’. > > A package could be created, say `org-cite-literal-biblatex’ which is just a copy > of `oc-biblatex.el’ with a different default `org-cite-biblatex-styles’ and > `org-cite-biblatex-style-shortcuts’ (or just sets those variables in > `org-cite-biblatex’). As far as I can tell this would provide exactly the > functionality you say org-cite can’t provide but org-ref does. > > You can already use `.bib’ files, and so frankly I cannot myself see the point in > org-ref’s existence beyond bifurcating the community on this. At this point the > only remaining motivation I see is old documents and current users, and for this > a migration tool seems more appropriate. > > I don’t mean to be overly critical, however this is my current honest assessment > of the situation. > > – > All the best, > Timothy > > John Kitchin <jkitchin@andrew.cmu.edu> writes: > >> I do not think it is productive for the community to say or consider it >> is a sad situation. Many good things have emerged from these >> discussions, even if it is not yet consensus on a solution. It is a >> complex problem, with many years of effort by many people on each side. >> That is an indication of how ambitious this project is and that there >> may be more than one solution that is needed. It pains me quite a bit >> there is a sentiment of fractionation, and that I may be contributing to >> it. >> >> My regular job workload the past few years has been crushing, and I have >> not had the time to participate in this that I wish I had. I am not sure >> I can add much here without sounding or feeling defensive about org-ref, >> and my decision to continue supporting and developing it. I have thought >> about this for most of the day, and in the (very long, apologies in >> advance) response that follows I will do my best to provide a balanced >> perspective (from my point of view) on the situation. >> >> Some specific context that is important to me is that I wrote org-ref >> long ago to solve a specific problem for me in the preparation of >> scientific publications that are destined for LaTeX export. I intended >> it to provide nearly equivalent bib(la)tex citation export, and as >> reasonable an export as possible for everything else. I use org-ref >> professionally, and it is a complete solution for me. I simply cannot >> compromise on the capability org-ref provides me, or wait for an >> alternative complete solution in org-mode. I have work I have to do now, >> and org-ref lets me do it. This alone is reason enough for me to >> continue using, developing and supporting org-ref. I understand org is >> not intended to be a substitute for writing LaTeX, but it is a fact of >> my job that I have to do that. >> >> There are more than 8 years of legacy org-ref documents. I have written >> 40+ scientific papers with it, and countless technical documents with >> more than 8000 cite links among them. org-ref has exceeded 190K >> downloads from MELPA, so I feel obligated to maintain org-ref for >> myself, and those users. org-ref may be heavyweight in bundling a lot of >> capability together that could be separated into individual packages, >> but it is also convenient for people who need it, and a GitHUB issue or >> pull request away from new features. I remain committed to supporting >> this, and I do it in a way I can manage, hence the monolithic package >> design. >> >> org-cite was also developed to solve some specific citation problems for >> others that org-ref did not address well at the time it was started. I >> believe those were issues like better pre/post note support, and >> integration with CSL. >> >> I think org-ref and org-cite have different priorities, they solve >> different problems with different approaches, and they have different >> pros and cons. I believe there are mutually incompatible compromises one >> must make here because the specific choices you make determine what is >> easy and what is possible. There is not a direct mapping of bib(la)tex >> and CSL as a citation processor. They are different programs and they >> don’t share citation commands, or style information. It is inevitable >> that something will be lost in the translation between these from a >> single source like org, and whether that loss is acceptable depends on >> what you need. For many things, close enough is ok for me, but for >> manuscripts and proposals, they must be perfect, and in bib(la)tex form >> for the journals I publish in. It is not that one thing is possible in >> one and not the other; it is that you have to compromise one to do the >> other no matter what you choose and that typically makes one thing or >> the other easier to do. I am not even sure it is possible to do >> everything one can do in bib(la)tex with CSL, for example, I don’t know >> the equivalent of in CSL. org-ref sides on making bib(la)tex >> easy, and CSL is possible. >> >> With org-cite, CSL can be readily used across export backends, more >> bibliography database formats are supported, and it is also possible to >> get LaTeX export, although there is no goal to fully support all of >> bib(la)tex. A pure org approach (e.g. org-files as bibliography >> database) can be used, there are a lot of CSL styles to work with, and >> you can develop or adapt your own style if needed. With reasonable >> defaults this should be a straightforward introduction to using >> citations for new users that works out of the box. I support that. >> >> With org-ref, bib(la)tex export is almost fully supported, and is easy, >> and other exports via CSL are possible. Of course, you must have a >> working LaTeX installation, only bibtex databases are supported, and >> working knowledge of bib(la)tex is required to leverage this. Whether >> you want it or not, you get a lot of extra utilities for getting bibtex >> entries from a DOI, and support for cross-references, indexes, >> glossaries and acronyms. This is a lot to ask of people who don’t need >> it, and convenient for those who do. I support this. >> >> Which one of these approaches is right depends on what you want to be >> easy. Neither is right or wrong, that is determined by what you need at >> the time and what you prioritize in your solution. It is even possible >> you need both approaches at different times. The two approaches are not >> compatible, but it is org-mode after all, and you can certainly convert >> back and forth between them for the most part. >> >> Both projects have benefited from this discussion a lot. org has >> org-cite now, and org-ref now handles pre/post notes like org-cite does, >> it supports CSL much better, and is even a little more modular, lighter >> weight, and more easily integrated with other completion backends than >> ivy or helm. That should broadly be viewed as a win-win situation. >> >> Here are some factors that have prevented me from deprecating org-ref. I >> spent about a month and half trying to get a solution to this at >> <https://github.com/jkitchin/org-ref-cite>, and I don’t make these >> observations lightly. That solution was complete and highly functional >> for org-cite, but as I describe below not a replacement for org-ref at >> this time. I still welcome a new maintainer for this code. >> >> Cross-references are critical for me; without them, there is no path >> forward for me with org-cite. I did work on a cross-reference approach >> that leveraged org-cite syntax >> (<https://github.com/jkitchin/org-ref-cite/issues/16>), but there was not >> much appetite for the approach so I abandoned that. There are >> cross-reference capabilities in org, that may be suitable for some >> applications, but they do not come close to what org-ref offers, and >> that the kind of technical documents I write require. For me, any >> cross-reference capability would also have to support what is possible >> in LaTeX, and preferrably look similar to the LaTeX commands. It has not >> been possible to write an orthogonal package that could co-exist with >> org-ref to address this; this would require a new syntax for >> cross-references in my opinion. My opinion is that practically citations >> and cross-references are just links to a place in your document (either >> a figure/table/section/etc, or an entry in a bibliography). In org-ref, >> both are represented by links; of course, they have different types and >> functions, but they both have follow like actions. My opinion seems to >> be in the minority on this. >> >> I do not like the abstraction away from LaTeX cite commands in org-cite. >> This is an example of a compromise between LaTeX and CSL. They do not >> share common citation commands, so you can either choose one or the >> other, or make a new abstraction that generalizes them. I strongly favor >> the LaTeX commands because I write for LaTeX export, and there is >> extensive documentation for how to cite in LaTeX and what to expect. >> Clearly org-cite favors using the standardized abstractions in org-cite, >> and then mapping them to the LaTeX commands I think. My perspective on >> this is partially one of an educator; I have taught a lot of people how >> to use org-mode for technical writing. This layer of abstraction adds >> additional complexity to documentation, and in teaching people what to >> do. As a LaTeX-centric user, that abstraction adds an additional >> cognitive load while writing I find unwelcome. I concede that it also >> reflects “what I do”, that org is not LaTeX, and that others may have a >> more CSL centric perspective. org-cite is for them. I can see that the >> abstraction away from the LaTeX cite commands strengthens the org is not >> LaTeX philosophy, and will serve part of the community well. If I wasn’t >> required to generate LaTeX documents, and teach others how to do it, I >> would not feel so strongly. >> >> It is my opinion that the modularity of org-cite is a challenge. I think >> it is too difficult to configure, and difficult to support, even more so >> than org-ref. I know my opinion differs from many on the list who want >> modularity and configurability. I have supported org-ref since around >> 2014, and even the modularity there (helm or ivy) has been a challenge >> to support. org-ref has always been configurable, but monolithic. Still, >> I learned a lot from Bruce (thank you!) that pushed me to redesign parts >> of org-ref to be more modular and more easily pluggable to other >> completion backends, and less specific on ivy/helm where practical. >> There are limitations to this I learned about, compromises one has to >> choose in doing it, and consequences in maintenance, support and >> documentation from them. We still don’t fully agree on some of these >> points, but org-ref is closer to that ideal than it was. Maybe one day I >> will abandon ivy like I did helm many years ago and feel differently >> about this, but that day is sufficiently far away that I don’t see it >> now. >> >> Finally, the org-cite code is magnificent, and written at a level well >> above my coding skills. I am grateful to those who wrote it, and >> especially to Nicolas, for the opportunity to learn from it. The code I >> wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced >> emacs-lisp techniques, and more complex data structures than I am >> accustomed to. I learned a lot studying the org-cite code, but I will be >> honest that I find it difficult to make contributions to. That gave me >> pause in continuing to develop it. It is fair to say that org-cite >> showed me some ways to address limitations of org-ref that I did not see >> before, org-ref is better for it, and the writing community that uses >> pre/post notes and biblatex is much better served as a result. >> >> Where does this leave me, org-ref and org-cite? I still have differences >> of opinion on design choices between them, and those differences are >> likely irreconcilable. These differences arise from my experiences in >> writing, teaching, using, developing and supporting org-ref. For those >> who need high fidelity LaTeX export like I do, I think org-ref is still >> a superior solution. For everyone else, and especially if you do not >> need sophisticated cross-references and don’t want the dependencies of >> org-ref, org-cite is likely the better solution. >> >> I am content to agree to disagree on these points and move forward with >> both packages because they solve different problems, are suitable for >> different communities, and they continue to benefit each other. I can >> see not everyone sees this as a positive situation though, and that has >> weighed heavily upon me lately. These times are heavy enough. Anyway, >> this turned out much longer than I expected, so thanks everyone who has >> contributed to making org better, I hope I got things mostly correct, >> you found it a fair assessment, we might still be friends, and thanks >> for reading to the end. >> >> j ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 8:16 ` Dominik Schrempf @ 2022-03-21 11:51 ` Bruce D'Arcus 2022-03-21 12:34 ` Dominik Schrempf 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-21 11:51 UTC (permalink / raw) To: Dominik Schrempf; +Cc: org-mode-email On Mon, Mar 21, 2022 at 4:24 AM Dominik Schrempf <dominik.schrempf@gmail.com> wrote: > I am trying out `org-cite' right now. It works much better than the last time (I > am using the `biblatex' backend right now). However, I can not find any > documentation about the available /styles/. > > They are mentioned here: <https://orgmode.org/manual/Citations.html> > > But no styles are provided. I have come to believe the best approach to handling available styles and previews is in the style selection UI. So that one can see what one is waiting when selecting. In citar, those styles and preview are currently hard-coded in a defcustom, but I'd like to figure out how to do that dynamically, using org-cite-supported-styles etc. In the meantime, Timothy's article should help (see the table on the styles): https://blog.tecosaur.com/tmio/2021-07-31-citations.html > For example, I need citations in the text (showing up as “Author(s) (Year)”). > With BibTeX, this would be `\citet{}' (or `\textcite{}' with BibLaTeX). But > there is a lot more. See: <http://tug.ctan.org/info/biblatex-cheatsheet/biblatex-cheatsheet.pdf>). You want the "text" style; [cite/text:@doe20], or with the shortcut [cite:/t:@doe20]. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 11:51 ` Bruce D'Arcus @ 2022-03-21 12:34 ` Dominik Schrempf 2022-03-21 12:52 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: Dominik Schrempf @ 2022-03-21 12:34 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: org-mode-email [-- Attachment #1: Type: text/plain, Size: 1985 bytes --] Thank you, I can use `citar-insert-edit` to perform this action. Now, I failed to create a full citation in the text. This corresponds to the `\fullcite{}' command in LaTeX. Is there an option for this? In summary, it is a bit painful to use `org-cite` compared to using `org-ref`. In my opinion, the main reasons are: • Documentation is missing for `org-cite`. • The citation commands seem to be incomplete (or at least not documented). I am aware that all this is a lot of work, and I am really grateful that we have `org-cite` and `org-ref` available! Thank you, Dominik “Bruce D’Arcus” <bdarcus@gmail.com> writes: > On Mon, Mar 21, 2022 at 4:24 AM Dominik Schrempf > <dominik.schrempf@gmail.com> wrote: > >> I am trying out `org-cite’ right now. It works much better than the last time (I >> am using the `biblatex’ backend right now). However, I can not find any >> documentation about the available /styles/. >> >> They are mentioned here: <https://orgmode.org/manual/Citations.html> >> >> But no styles are provided. > > I have come to believe the best approach to handling available styles > and previews is in the style selection UI. So that one can see what > one is waiting when selecting. > > In citar, those styles and preview are currently hard-coded in a > defcustom, but I’d like to figure out how to do that dynamically, > using org-cite-supported-styles etc. > > In the meantime, Timothy’s article should help (see the table on the styles): > > <https://blog.tecosaur.com/tmio/2021-07-31-citations.html> > >> For example, I need citations in the text (showing up as “Author(s) (Year)”). >> With BibTeX, this would be `\citet{}’ (or `\textcite{}’ with BibLaTeX). But >> there is a lot more. See: <http://tug.ctan.org/info/biblatex-cheatsheet/biblatex-cheatsheet.pdf>). > > You want the “text” style; (NO_ITEM_DATA:doe20), or with the shortcut > (/t: NO_ITEM_DATA:doe20). > > Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 12:34 ` Dominik Schrempf @ 2022-03-21 12:52 ` Bruce D'Arcus 2022-03-21 13:05 ` Dominik Schrempf 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-21 12:52 UTC (permalink / raw) To: Dominik Schrempf; +Cc: org-mode-email On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf <dominik.schrempf@gmail.com> wrote: > > Thank you, I can use `citar-insert-edit` to perform this action. You can actually just use org-cite-insert, which is context aware. > Now, I failed to create a full citation in the text. This corresponds to the > `\fullcite{}' command in LaTeX. Is there an option for this? No, but we should add one, as natbib has a similar command. And, of course, per Timothy's point, you can customize org-cite-biblatex-styles to include it in the meantime. If you want to experiment with this, contact me off-list, as there's some nuances with citar. > In summary, it is a bit painful to use `org-cite` compared to using `org-ref`. > In my opinion, the main reasons are: > > • Documentation is missing for `org-cite`. > • The citation commands seem to be incomplete (or at least not documented). The documentation is admittedly thin. Thoughts on what we should add? The styles, and how to customize them with oc-biblatex? Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 12:52 ` Bruce D'Arcus @ 2022-03-21 13:05 ` Dominik Schrempf 2022-03-21 13:24 ` Bruce D'Arcus 2022-03-23 21:27 ` Nicolas Goaziou 0 siblings, 2 replies; 73+ messages in thread From: Dominik Schrempf @ 2022-03-21 13:05 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: org-mode-email [-- Attachment #1: Type: text/plain, Size: 1745 bytes --] “Bruce D’Arcus” <bdarcus@gmail.com> writes: > On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf > <dominik.schrempf@gmail.com> wrote: >> >> Thank you, I can use `citar-insert-edit` to perform this action. > > You can actually just use org-cite-insert, which is context aware. > >> Now, I failed to create a full citation in the text. This corresponds to the >> `\fullcite{}’ command in LaTeX. Is there an option for this? > > No, but we should add one, as natbib has a similar command. > > And, of course, per Timothy’s point, you can customize > org-cite-biblatex-styles to include it in the meantime. If you want to > experiment with this, contact me off-list, as there’s some nuances > with citar. Great, that was easy, thank you: (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) (This or something similar should be added upstream). > >> In summary, it is a bit painful to use `org-cite` compared to using `org-ref`. >> In my opinion, the main reasons are: >> >> • Documentation is missing for `org-cite`. >> • The citation commands seem to be incomplete (or at least not documented). > > The documentation is admittedly thin. Thoughts on what we should add? > > The styles, and how to customize them with oc-biblatex? I know writing documentation is a lot of work. It is easy to complain, but hard to contribute. I think we need: • A complete description of styles and variants (for the actual citation command, and also for `#+cite_export: ...') or at least a link to an up-to-date table. • An improved description of the capabilities of `org-cite-insert' (i.e., that it can change the citation style and variant). > > Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 13:05 ` Dominik Schrempf @ 2022-03-21 13:24 ` Bruce D'Arcus 2022-03-23 21:27 ` Nicolas Goaziou 1 sibling, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-21 13:24 UTC (permalink / raw) To: Dominik Schrempf; +Cc: org-mode-email On Mon, Mar 21, 2022 at 9:13 AM Dominik Schrempf <dominik.schrempf@gmail.com> wrote: > > “Bruce D’Arcus” <bdarcus@gmail.com> writes: > > > On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf > > <dominik.schrempf@gmail.com> wrote: > >> > >> Thank you, I can use `citar-insert-edit` to perform this action. > > > > You can actually just use org-cite-insert, which is context aware. > > > >> Now, I failed to create a full citation in the text. This corresponds to the > >> `\fullcite{}’ command in LaTeX. Is there an option for this? > > > > No, but we should add one, as natbib has a similar command. > > > > And, of course, per Timothy’s point, you can customize > > org-cite-biblatex-styles to include it in the meantime. If you want to > > experiment with this, contact me off-list, as there’s some nuances > > with citar. > > Great, that was easy, thank you: > > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) On citar (the "nuance"), until I make the style UI smarter, you'll want to add this command and a preview to citar-org-style-preview-alist. You might want to even completely redefine it to preview using the biblatex command. > (This or something similar should be added upstream). I agree. We just need to decide what the style name should be (and also add a mapping from it for bibentry in natbib, and hopefully later csl). We already have a "full" variant for "author", so another "full" might be a little confusing. Bruce > >> In summary, it is a bit painful to use `org-cite` compared to using `org-ref`. > >> In my opinion, the main reasons are: > >> > >> • Documentation is missing for `org-cite`. > >> • The citation commands seem to be incomplete (or at least not documented). > > > > The documentation is admittedly thin. Thoughts on what we should add? > > > > The styles, and how to customize them with oc-biblatex? > > I know writing documentation is a lot of work. It is easy to complain, but hard > to contribute. I think we need: > • A complete description of styles and variants (for the actual citation > command, and also for `#+cite_export: ...') or at least a link to an > up-to-date table. > • An improved description of the capabilities of `org-cite-insert' (i.e., that > it can change the citation style and variant). > > > > > Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 13:05 ` Dominik Schrempf 2022-03-21 13:24 ` Bruce D'Arcus @ 2022-03-23 21:27 ` Nicolas Goaziou 2022-03-23 21:53 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-23 21:27 UTC (permalink / raw) To: Dominik Schrempf; +Cc: org-mode-email, Bruce D'Arcus Hello, Dominik Schrempf <dominik.schrempf@gmail.com> writes: > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) > > (This or something similar should be added upstream). I can add it, but "full" is already the name of a variant, so [cite/full: ...] and [cite/style/full: ...] would mean different things. Is this a problem, or do you think of a better style name? Also, are there possible variants for this style? Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 21:27 ` Nicolas Goaziou @ 2022-03-23 21:53 ` Bruce D'Arcus 2022-03-23 22:04 ` Nicolas Goaziou 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-23 21:53 UTC (permalink / raw) To: Dominik Schrempf, Bruce D'Arcus, org-mode-email On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > > Hello, > > Dominik Schrempf <dominik.schrempf@gmail.com> writes: > > > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil)) > > > > (This or something similar should be added upstream). > > I can add it, but "full" is already the name of a variant, so > [cite/full: ...] and [cite/style/full: ...] would mean different things. > Is this a problem, or do you think of a better style name? FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex "bibentry". That might be a reasonable alternative style name? > Also, are there possible variants for this style? AFAIK, no. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 21:53 ` Bruce D'Arcus @ 2022-03-23 22:04 ` Nicolas Goaziou 2022-03-23 22:47 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-23 22:04 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: Dominik Schrempf, org-mode-email Hello, "Bruce D'Arcus" <bdarcus@gmail.com> writes: > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: >> I can add it, but "full" is already the name of a variant, so >> [cite/full: ...] and [cite/style/full: ...] would mean different things. >> Is this a problem, or do you think of a better style name? > > FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex "bibentry". > > That might be a reasonable alternative style name? > >> Also, are there possible variants for this style? > > AFAIK, no. Hmm, OK. What about: (“fullcite” nil “fullcite” nil nil) ? Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 22:04 ` Nicolas Goaziou @ 2022-03-23 22:47 ` Bruce D'Arcus 2022-03-24 10:04 ` Dominik Schrempf 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-23 22:47 UTC (permalink / raw) To: org-mode-email On Wed, Mar 23, 2022 at 6:04 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > > Hello, > > "Bruce D'Arcus" <bdarcus@gmail.com> writes: > > > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > > >> I can add it, but "full" is already the name of a variant, so > >> [cite/full: ...] and [cite/style/full: ...] would mean different things. > >> Is this a problem, or do you think of a better style name? > > > > FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex "bibentry". > > > > That might be a reasonable alternative style name? > > > >> Also, are there possible variants for this style? > > > > AFAIK, no. > > Hmm, OK. What about: > > (“fullcite” nil “fullcite” nil nil) > > ? Seems fine by me, so long as you use the same name for natbib if and when you add bibentry support? Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 22:47 ` Bruce D'Arcus @ 2022-03-24 10:04 ` Dominik Schrempf 0 siblings, 0 replies; 73+ messages in thread From: Dominik Schrempf @ 2022-03-24 10:04 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1335 bytes --] I think `fullcite' is OK, although it will be a bit verbose: ┌──── │ [cite/fullcite:...] └──── Personally, I don’t mind using `full', and so having a duplicate between a style and a variant. But, to be honest, anything is fine with me, as long as it is readily available and documented. Thank you! Dominik “Bruce D’Arcus” <bdarcus@gmail.com> writes: > On Wed, Mar 23, 2022 at 6:04 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: >> >> Hello, >> >> “Bruce D’Arcus” <bdarcus@gmail.com> writes: >> >> > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: >> >> >> I can add it, but “full” is already the name of a variant, so >> >> [cite/full: …] and [cite/style/full: …] would mean different things. >> >> Is this a problem, or do you think of a better style name? >> > >> > FWIW, Nicolas, biblatex “fullcite” is equivalent to natbib/bibtex “bibentry”. >> > >> > That might be a reasonable alternative style name? >> > >> >> Also, are there possible variants for this style? >> > >> > AFAIK, no. >> >> Hmm, OK. What about: >> >> (“fullcite” nil “fullcite” nil nil) >> >> ? > > Seems fine by me, so long as you use the same name for natbib if and > when you add bibentry support? > > Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 1:39 ` Timothy 2022-03-21 8:16 ` Dominik Schrempf @ 2022-03-21 12:19 ` John Kitchin 2022-03-21 12:42 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-21 12:19 UTC (permalink / raw) To: Timothy; +Cc: Vikas Rawal, org-mode-email, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 14957 bytes --] On Sun, Mar 20, 2022 at 9:57 PM Timothy <tecosaur@gmail.com> wrote: > Hi John, > > Thanks for your considered response. > > When you contrast org-cite and org-ref, you say: > > > With org-ref, bib(la)tex export is almost fully supported, and is easy, > > I find this odd as org-cite supports bib(la)tex export, and rather easily. > > ┌──── > │ #+bibliography: references.bib > │ #+cite_export: biblatex authortitle/authortitle-ibid > │ > │ [cite:@key] etc. > │ > │ #+print_bibliography: > └──── > > The limitation which I think is on your mind is that not all bib(la)tex > commands > are supported, and not in the “usual” form. For instance, to get > `pnotecite' one > would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, you > can just > customise `org-cite-biblatex-styles'. For instance, `parencite' is not > currently > available, but if I just add `("parencite" nil "parencite" nil nil)' I can > then do > `[cite/parencite:]' or if I replace the first `"parencite"' with > `"paren"', just > `[cite/paren:]'. > Yes, of course I mean the citation commands. > > A package could be created, say `org-cite-literal-biblatex' which is just > a copy > of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and > `org-cite-biblatex-style-shortcuts' (or just sets those variables in > `org-cite-biblatex'). As far as I can tell this would provide exactly the > functionality you say org-cite can’t provide but org-ref does. > I wrote this package you suggest in org-ref-cite. In discussions during that development, it was clear the preference was on the more abstracted, and uniform syntax across backends cite commands in org-cite, and not this kind of variant. Of course one can do this. It is not that org-cite can't provide it, it is that it doesn't at this time. Even so, it is only a partial solution to deprecating org-ref. > > You can already use `.bib' files, and so frankly I cannot myself see the > point in > org-ref’s existence beyond bifurcating the community on this. At this > point the > only remaining motivation I see is old documents and current users, and > for this > a migration tool seems more appropriate. > I don’t mean to be overly critical, however this is my current honest > assessment > of the situation. > > – > All the best, > Timothy > > John Kitchin <jkitchin@andrew.cmu.edu> writes: > > > I do not think it is productive for the community to say or consider it > > is a sad situation. Many good things have emerged from these > > discussions, even if it is not yet consensus on a solution. It is a > > complex problem, with many years of effort by many people on each side. > > That is an indication of how ambitious this project is and that there > > may be more than one solution that is needed. It pains me quite a bit > > there is a sentiment of fractionation, and that I may be contributing to > > it. > > > > My regular job workload the past few years has been crushing, and I have > > not had the time to participate in this that I wish I had. I am not sure > > I can add much here without sounding or feeling defensive about org-ref, > > and my decision to continue supporting and developing it. I have thought > > about this for most of the day, and in the (very long, apologies in > > advance) response that follows I will do my best to provide a balanced > > perspective (from my point of view) on the situation. > > > > Some specific context that is important to me is that I wrote org-ref > > long ago to solve a specific problem for me in the preparation of > > scientific publications that are destined for LaTeX export. I intended > > it to provide nearly equivalent bib(la)tex citation export, and as > > reasonable an export as possible for everything else. I use org-ref > > professionally, and it is a complete solution for me. I simply cannot > > compromise on the capability org-ref provides me, or wait for an > > alternative complete solution in org-mode. I have work I have to do now, > > and org-ref lets me do it. This alone is reason enough for me to > > continue using, developing and supporting org-ref. I understand org is > > not intended to be a substitute for writing LaTeX, but it is a fact of > > my job that I have to do that. > > > > There are more than 8 years of legacy org-ref documents. I have written > > 40+ scientific papers with it, and countless technical documents with > > more than 8000 cite links among them. org-ref has exceeded 190K > > downloads from MELPA, so I feel obligated to maintain org-ref for > > myself, and those users. org-ref may be heavyweight in bundling a lot of > > capability together that could be separated into individual packages, > > but it is also convenient for people who need it, and a GitHUB issue or > > pull request away from new features. I remain committed to supporting > > this, and I do it in a way I can manage, hence the monolithic package > > design. > > > > org-cite was also developed to solve some specific citation problems for > > others that org-ref did not address well at the time it was started. I > > believe those were issues like better pre/post note support, and > > integration with CSL. > > > > I think org-ref and org-cite have different priorities, they solve > > different problems with different approaches, and they have different > > pros and cons. I believe there are mutually incompatible compromises one > > must make here because the specific choices you make determine what is > > easy and what is possible. There is not a direct mapping of bib(la)tex > > and CSL as a citation processor. They are different programs and they > > don’t share citation commands, or style information. It is inevitable > > that something will be lost in the translation between these from a > > single source like org, and whether that loss is acceptable depends on > > what you need. For many things, close enough is ok for me, but for > > manuscripts and proposals, they must be perfect, and in bib(la)tex form > > for the journals I publish in. It is not that one thing is possible in > > one and not the other; it is that you have to compromise one to do the > > other no matter what you choose and that typically makes one thing or > > the other easier to do. I am not even sure it is possible to do > > everything one can do in bib(la)tex with CSL, for example, I don’t know > > the equivalent of in CSL. org-ref sides on making bib(la)tex > > easy, and CSL is possible. > > > > With org-cite, CSL can be readily used across export backends, more > > bibliography database formats are supported, and it is also possible to > > get LaTeX export, although there is no goal to fully support all of > > bib(la)tex. A pure org approach (e.g. org-files as bibliography > > database) can be used, there are a lot of CSL styles to work with, and > > you can develop or adapt your own style if needed. With reasonable > > defaults this should be a straightforward introduction to using > > citations for new users that works out of the box. I support that. > > > > With org-ref, bib(la)tex export is almost fully supported, and is easy, > > and other exports via CSL are possible. Of course, you must have a > > working LaTeX installation, only bibtex databases are supported, and > > working knowledge of bib(la)tex is required to leverage this. Whether > > you want it or not, you get a lot of extra utilities for getting bibtex > > entries from a DOI, and support for cross-references, indexes, > > glossaries and acronyms. This is a lot to ask of people who don’t need > > it, and convenient for those who do. I support this. > > > > Which one of these approaches is right depends on what you want to be > > easy. Neither is right or wrong, that is determined by what you need at > > the time and what you prioritize in your solution. It is even possible > > you need both approaches at different times. The two approaches are not > > compatible, but it is org-mode after all, and you can certainly convert > > back and forth between them for the most part. > > > > Both projects have benefited from this discussion a lot. org has > > org-cite now, and org-ref now handles pre/post notes like org-cite does, > > it supports CSL much better, and is even a little more modular, lighter > > weight, and more easily integrated with other completion backends than > > ivy or helm. That should broadly be viewed as a win-win situation. > > > > Here are some factors that have prevented me from deprecating org-ref. I > > spent about a month and half trying to get a solution to this at > > <https://github.com/jkitchin/org-ref-cite>, and I don’t make these > > observations lightly. That solution was complete and highly functional > > for org-cite, but as I describe below not a replacement for org-ref at > > this time. I still welcome a new maintainer for this code. > > > > Cross-references are critical for me; without them, there is no path > > forward for me with org-cite. I did work on a cross-reference approach > > that leveraged org-cite syntax > > (<https://github.com/jkitchin/org-ref-cite/issues/16>), but there was > not > > much appetite for the approach so I abandoned that. There are > > cross-reference capabilities in org, that may be suitable for some > > applications, but they do not come close to what org-ref offers, and > > that the kind of technical documents I write require. For me, any > > cross-reference capability would also have to support what is possible > > in LaTeX, and preferrably look similar to the LaTeX commands. It has not > > been possible to write an orthogonal package that could co-exist with > > org-ref to address this; this would require a new syntax for > > cross-references in my opinion. My opinion is that practically citations > > and cross-references are just links to a place in your document (either > > a figure/table/section/etc, or an entry in a bibliography). In org-ref, > > both are represented by links; of course, they have different types and > > functions, but they both have follow like actions. My opinion seems to > > be in the minority on this. > > > > I do not like the abstraction away from LaTeX cite commands in org-cite. > > This is an example of a compromise between LaTeX and CSL. They do not > > share common citation commands, so you can either choose one or the > > other, or make a new abstraction that generalizes them. I strongly favor > > the LaTeX commands because I write for LaTeX export, and there is > > extensive documentation for how to cite in LaTeX and what to expect. > > Clearly org-cite favors using the standardized abstractions in org-cite, > > and then mapping them to the LaTeX commands I think. My perspective on > > this is partially one of an educator; I have taught a lot of people how > > to use org-mode for technical writing. This layer of abstraction adds > > additional complexity to documentation, and in teaching people what to > > do. As a LaTeX-centric user, that abstraction adds an additional > > cognitive load while writing I find unwelcome. I concede that it also > > reflects “what I do”, that org is not LaTeX, and that others may have a > > more CSL centric perspective. org-cite is for them. I can see that the > > abstraction away from the LaTeX cite commands strengthens the org is not > > LaTeX philosophy, and will serve part of the community well. If I wasn’t > > required to generate LaTeX documents, and teach others how to do it, I > > would not feel so strongly. > > > > It is my opinion that the modularity of org-cite is a challenge. I think > > it is too difficult to configure, and difficult to support, even more so > > than org-ref. I know my opinion differs from many on the list who want > > modularity and configurability. I have supported org-ref since around > > 2014, and even the modularity there (helm or ivy) has been a challenge > > to support. org-ref has always been configurable, but monolithic. Still, > > I learned a lot from Bruce (thank you!) that pushed me to redesign parts > > of org-ref to be more modular and more easily pluggable to other > > completion backends, and less specific on ivy/helm where practical. > > There are limitations to this I learned about, compromises one has to > > choose in doing it, and consequences in maintenance, support and > > documentation from them. We still don’t fully agree on some of these > > points, but org-ref is closer to that ideal than it was. Maybe one day I > > will abandon ivy like I did helm many years ago and feel differently > > about this, but that day is sufficiently far away that I don’t see it > > now. > > > > Finally, the org-cite code is magnificent, and written at a level well > > above my coding skills. I am grateful to those who wrote it, and > > especially to Nicolas, for the opportunity to learn from it. The code I > > wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced > > emacs-lisp techniques, and more complex data structures than I am > > accustomed to. I learned a lot studying the org-cite code, but I will be > > honest that I find it difficult to make contributions to. That gave me > > pause in continuing to develop it. It is fair to say that org-cite > > showed me some ways to address limitations of org-ref that I did not see > > before, org-ref is better for it, and the writing community that uses > > pre/post notes and biblatex is much better served as a result. > > > > Where does this leave me, org-ref and org-cite? I still have differences > > of opinion on design choices between them, and those differences are > > likely irreconcilable. These differences arise from my experiences in > > writing, teaching, using, developing and supporting org-ref. For those > > who need high fidelity LaTeX export like I do, I think org-ref is still > > a superior solution. For everyone else, and especially if you do not > > need sophisticated cross-references and don’t want the dependencies of > > org-ref, org-cite is likely the better solution. > > > > I am content to agree to disagree on these points and move forward with > > both packages because they solve different problems, are suitable for > > different communities, and they continue to benefit each other. I can > > see not everyone sees this as a positive situation though, and that has > > weighed heavily upon me lately. These times are heavy enough. Anyway, > > this turned out much longer than I expected, so thanks everyone who has > > contributed to making org better, I hope I got things mostly correct, > > you found it a fair assessment, we might still be friends, and thanks > > for reading to the end. > > > > j > [-- Attachment #2: Type: text/html, Size: 17253 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 12:19 ` John Kitchin @ 2022-03-21 12:42 ` Bruce D'Arcus 2022-03-21 14:06 ` John Kitchin 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-21 12:42 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode-email On Mon, Mar 21, 2022 at 8:23 AM John Kitchin <jkitchin@andrew.cmu.edu> wrote: >> A package could be created, say `org-cite-literal-biblatex' which is just a copy >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in >> `org-cite-biblatex'). As far as I can tell this would provide exactly the >> functionality you say org-cite can’t provide but org-ref does. > > > I wrote this package you suggest in org-ref-cite. In discussions during that development, it was clear the preference was on the more abstracted, and uniform syntax across backends cite commands in org-cite, and not this kind of variant. Of course one can do this. It is not that org-cite can't provide it, it is that it doesn't at this time. Just for some broader context on this particular issue. The advantage of the org-cite style/variant design reflected in the included export processors (natbib, biblatex, csl) is that the same styles will mostly generate the same final output. But that portability will only work with those styles and variants. With the new org-cite-biblatex-styles defcustom, however, one can augment or completely replace all those. But if you care about that portability, you'd want to be aware of this, and think about it. So per Timothy's point, you actually don't even need a new processor for biblatex if you want to include all the extensive list of biblatex commands. Natbib AFAIK is already fully covered. There's another POV on this though: If one doesn't like to see the org-cite styles, because of familiarity with LaTeX commands etc., I would argue that can be addressed in the style part of an insert processor and/or in an activate processor. E.g. I would argue this is a UI issue; not fundamentally about the styles names. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 12:42 ` Bruce D'Arcus @ 2022-03-21 14:06 ` John Kitchin 2022-04-19 22:37 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-21 14:06 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: org-mode-email [-- Attachment #1: Type: text/plain, Size: 3287 bytes --] Bruce and I looked into this UI approach in https://github.com/jkitchin/org-ref-cite/issues/9. Bruce and I discussed and worked on this for almost two weeks. There are 70 comments in this issue. There are opportunities now to annotate completion targets, which you can see in the link above. The annotations are not selectable though during completion, and this implementation was not too fast as I recall. You probably should also augment the tooltips like this because you have to be able to tell what a citation format is in the future too, not just at insert time, e.g. suppose you are reading work of a collaborator. It was hard to write, and ambiguous in ways, e.g. what is the export backend you want? The annotations should differ for LaTeX (where you want to see the latex command) vs HTML (where you probably want to see the formatted CSL cite)... We did not surmount these challenges at the time. Maybe others will succeed in this another day. John ----------------------------------- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Mar 21, 2022 at 8:42 AM Bruce D'Arcus <bdarcus@gmail.com> wrote: > On Mon, Mar 21, 2022 at 8:23 AM John Kitchin <jkitchin@andrew.cmu.edu> > wrote: > > >> A package could be created, say `org-cite-literal-biblatex' which is > just a copy > >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' > and > >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in > >> `org-cite-biblatex'). As far as I can tell this would provide exactly > the > >> functionality you say org-cite can’t provide but org-ref does. > > > > > > I wrote this package you suggest in org-ref-cite. In discussions during > that development, it was clear the preference was on the more abstracted, > and uniform syntax across backends cite commands in org-cite, and not this > kind of variant. Of course one can do this. It is not that org-cite can't > provide it, it is that it doesn't at this time. > > Just for some broader context on this particular issue. > > The advantage of the org-cite style/variant design reflected in the > included export processors (natbib, biblatex, csl) is that the same > styles will mostly generate the same final output. > > But that portability will only work with those styles and variants. > > With the new org-cite-biblatex-styles defcustom, however, one can > augment or completely replace all those. But if you care about that > portability, you'd want to be aware of this, and think about it. > > So per Timothy's point, you actually don't even need a new processor > for biblatex if you want to include all the extensive list of biblatex > commands. > > Natbib AFAIK is already fully covered. > > There's another POV on this though: > > If one doesn't like to see the org-cite styles, because of familiarity > with LaTeX commands etc., I would argue that can be addressed in the > style part of an insert processor and/or in an activate processor. > E.g. I would argue this is a UI issue; not fundamentally about the > styles names. > > Bruce > [-- Attachment #2: Type: text/html, Size: 4148 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 14:06 ` John Kitchin @ 2022-04-19 22:37 ` Bruce D'Arcus 0 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-04-19 22:37 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode-email On Mon, Mar 21, 2022 at 10:06 AM John Kitchin <jkitchin@andrew.cmu.edu> wrote: > > Bruce and I looked into this UI approach in https://github.com/jkitchin/org-ref-cite/issues/9. Bruce and I discussed and worked on this for almost two weeks. There are 70 comments in this issue. > > There are opportunities now to annotate completion targets, which you can see in the link above. The annotations are not selectable though during completion, and this implementation was not too fast as I recall. FWIW, an alternative I was playing with is something like this, which makes use of the new oc-biblatex styles defcustom: (defcustom style-select-latex-commands nil "Whether to use latex commands for style selection." :group 'style :type '(boolean)) (defun style-latex-alist (&optional swap) "Return org-cite-biblatex-styles as alist. By default, each car is the latex command, and the cdr the org-cite style with variant. With SWAP, they are reversed." (let ((raw-styles org-cite-biblatex-styles)) (mapcar (lambda (s) (let* ((style (elt s 0)) (variant (elt s 1)) (command (elt s 2)) (cstyle (concat style (when variant "/") variant))) (if swap (cons cstyle command) (cons command cstyle)))) raw-styles))) (defun style-select () "Select oc style." (let* ((latex-commands style-select-latex-commands) (styles (if latex-commands (style-latex-alist) (style-latex-alist t))) (choice (completing-read (if latex-commands "Biblatex command: " "Style: ") styles))) (cdr (if style-select-latex-commands (assoc choice (style-latex-alist)) (rassoc choice (style-latex-alist)))))) > You probably should also augment the tooltips like this because you have to be able to tell what a citation format is in the future too, not just at insert time, e.g. suppose you are reading work of a collaborator. It was hard to write, and ambiguous in ways, e.g. what is the export backend you want? The annotations should differ for LaTeX (where you want to see the latex command) vs HTML (where you probably want to see the formatted CSL cite)... I was thinking it'd be enough to have a tooltip preview of the citation, and allow the actual preview to be configurable. Bruce > We did not surmount these challenges at the time. Maybe others will succeed in this another day. > > John > > ----------------------------------- > Professor John Kitchin (he/him/his) > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > > > > On Mon, Mar 21, 2022 at 8:42 AM Bruce D'Arcus <bdarcus@gmail.com> wrote: >> >> On Mon, Mar 21, 2022 at 8:23 AM John Kitchin <jkitchin@andrew.cmu.edu> wrote: >> >> >> A package could be created, say `org-cite-literal-biblatex' which is just a copy >> >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and >> >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in >> >> `org-cite-biblatex'). As far as I can tell this would provide exactly the >> >> functionality you say org-cite can’t provide but org-ref does. >> > >> > >> > I wrote this package you suggest in org-ref-cite. In discussions during that development, it was clear the preference was on the more abstracted, and uniform syntax across backends cite commands in org-cite, and not this kind of variant. Of course one can do this. It is not that org-cite can't provide it, it is that it doesn't at this time. >> >> Just for some broader context on this particular issue. >> >> The advantage of the org-cite style/variant design reflected in the >> included export processors (natbib, biblatex, csl) is that the same >> styles will mostly generate the same final output. >> >> But that portability will only work with those styles and variants. >> >> With the new org-cite-biblatex-styles defcustom, however, one can >> augment or completely replace all those. But if you care about that >> portability, you'd want to be aware of this, and think about it. >> >> So per Timothy's point, you actually don't even need a new processor >> for biblatex if you want to include all the extensive list of biblatex >> commands. >> >> Natbib AFAIK is already fully covered. >> >> There's another POV on this though: >> >> If one doesn't like to see the org-cite styles, because of familiarity >> with LaTeX commands etc., I would argue that can be addressed in the >> style part of an insert processor and/or in an activate processor. >> E.g. I would argue this is a UI issue; not fundamentally about the >> styles names. >> >> Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 0:31 ` John Kitchin 2022-03-21 1:39 ` Timothy @ 2022-03-21 3:27 ` Vikas Rawal 2022-03-21 11:51 ` John Kitchin 2022-03-21 12:59 ` juh 2022-03-23 21:06 ` Nicolas Goaziou 3 siblings, 1 reply; 73+ messages in thread From: Vikas Rawal @ 2022-03-21 3:27 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode mailing list, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 3442 bytes --] Dear John, Thanks very much for taking time to write a detailed reply. I do not think it is productive for the community to say or consider it > is a sad situation. From the perspective of a user, this was only meant to express a sentiment that one finds oneself in a situation of having to choose between two good things, and that we have not been able to find a way to make both compatible with each other. It was in not meant as a disrespect in any way. My use case is very similar to yours and I have been an org-ref user for a long time (I was surely one of the earliest beneficiaries of your work), having written two books and innumerable research papers with org-ref citation syntax. Being able to export to LaTeX has been my primary use but the fact that citations were not exported easily to other formats thus far was a problem I had to struggle with every now and then. > There are more than 8 years of legacy org-ref documents. I have written > 40+ scientific papers with it, and countless technical documents with > more than 8000 cite links among them. org-ref has exceeded 190K > downloads from MELPA, so I feel obligated to maintain org-ref for > myself, and those users. Given that it is not very difficult to convert a document from old org-ref citation syntax to the org-cite syntax, at least as far as citation is concerned, this should not be a big problem. Do these documents use citation commands that are not available in org-cite? Can those not be added to org-cite? > I think org-ref and org-cite have different priorities, they solve > different problems with different approaches, and they have different > pros and cons. It might be useful to discuss specific gaps (such as citenum) that need to be plugged in org-cite for it to be usable. In fact, making org-cite usable for a heavyweight user like you is a useful goalpost. I understand that you do not particularly like the modularity and complexity of org-cite way of specifying styles and variants. But if one is able to make the two compatible, filling the gaps, they could have a friendly co-existence with some way of being able to convert a document between the two styles. And if there are some incompatibilities that cannot be resolved, it would be good to know exactly what all those are. If somebody was to write functions to convert from one format to the other, they could choose how they want to deal with those incompatibilities. > Cross-references are critical for me; without them, there is no path > forward for me with org-cite. I did work on a cross-reference approach > that leveraged org-cite syntax > (https://github.com/jkitchin/org-ref-cite/issues/16), but there was not > much appetite for the approach so I abandoned that. What org-ref seems to do with cross-references is very nice. Unfortunately this would not be available if a user chooses to use org-cite. Do the capabilities of cross-referencing have to be wedded to the citation system? Can this not be resolved? > I am content to agree to disagree on these points and move forward with > both packages because they solve different problems, are suitable for > different communities, and they continue to benefit each other. Friendly co-existence should be our goal. But can that be a situation in which one is able to choose between the best of both and, as far as possible, switch from one to the other. Thanks again for your time and effort, Vikas [-- Attachment #2: Type: text/html, Size: 4675 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 3:27 ` Vikas Rawal @ 2022-03-21 11:51 ` John Kitchin 2022-03-21 17:20 ` Vikas Rawal ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: John Kitchin @ 2022-03-21 11:51 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list, Nicolas Goaziou Vikas Rawal <vikasrawal@gmail.com> writes: > Dear John, > > Thanks very much for taking time to write a detailed reply. > > I do not think it is productive for the community to say or consider it > is a sad situation. > > From the perspective of a user, this was only meant to express a > sentiment that one finds oneself in a situation of having to choose > between two good things, and that we have not been able to find a way > to make both compatible with each other. It was in not meant as a > disrespect in any way. I don't think you have to choose. You can use org-cite for citations, and org-ref for cross-references. The citation syntax is orthogonal, you just should not mix them. You can even wire org-ref to use org-cite-insert like this: (setq org-ref-insert-cite-function (lambda () (org-cite-insert nil))) or use your own key binding if you need the prefix arg functionality of org-cite-insert. org-ref is more configurable and modular than it is given credit for. This is not an either/or choice. > > My use case is very similar to yours and I have been an org-ref user > for a long time (I was surely one of the earliest beneficiaries of > your work), having written two books and innumerable research papers > with org-ref citation syntax. Being able to export to LaTeX has been > my primary use but the fact that citations were not exported easily to > other formats thus far was a problem I had to struggle with every now > and then. with org-ref-3, this is much better, but org-cite also works well, probably even better if you use footnote styles. Either way, it is not trivial to get the same output from LaTeX and CSL for arbitrary styles. They are often close though. > There are more than 8 years of legacy org-ref documents. I have written > 40+ scientific papers with it, and countless technical documents with > more than 8000 cite links among them. org-ref has exceeded 190K > downloads from MELPA, so I feel obligated to maintain org-ref for > myself, and those users. > > Given that it is not very difficult to convert a document from old > org-ref citation syntax to the org-cite syntax, at least as far as > citation is concerned, this should not be a big problem. Do these > documents use citation commands that are not available in org-cite? > Can those not be added to org-cite? It is possible to convert, I wouldn't say not very difficult. In principle one maps over the links and citations, and then in reverse order replace the one format with the converted other format in a buffer. That basically means change & to @ (easy), and provide the mapping between org-ref link type and org-cite style. org-ref has 70ish cite commands that it supports because those are in bib(la)tex. If you only use the basic types, it "should be easy". If you use others, you will have to settle for approximately correct in some cases. > I think org-ref and org-cite have different priorities, they solve > different problems with different approaches, and they have different > pros and cons. > > It might be useful to discuss specific gaps (such as citenum) that > need to be plugged in org-cite for it to be usable. In fact, making > org-cite usable for a heavyweight user like you is a useful goalpost. citenum and bibentry are the only two I am not sure have a CSL analog. I guess that things like citedate and citetitle are not fully implemented in citeproc. That is fine, org-cite does not need to fully support all of bib(la)tex, no single user needs that. Lots of users need one part or another though, and collectively bib(la)tex exists for them. > > I understand that you do not particularly like the modularity and > complexity of org-cite way of specifying styles and variants. But if > one is able to make the two compatible, filling the gaps, they could > have a friendly co-existence with some way of being able to convert a > document between the two styles. And if there are some > incompatibilities that cannot be resolved, it would be good to know > exactly what all those are. If somebody was to write functions to > convert from one format to the other, they could choose how they want > to deal with those incompatibilities. I guess you won't know what all the incompatibilities are until you try this. In my experience with org-ref, there is a years long tail of discovery as people try different things and have corner cases of need. > > Cross-references are critical for me; without them, there is no path > forward for me with org-cite. I did work on a cross-reference approach > that leveraged org-cite syntax > (https://github.com/jkitchin/org-ref-cite/issues/16), but there was not > much appetite for the approach so I abandoned that. > > What org-ref seems to do with cross-references is very nice. > Unfortunately this would not be available if a user chooses to use > org-cite. Do the capabilities of cross-referencing have to be wedded > to the citation system? They don't have to be integrated. Someone could separate out that functionality. I don't have unlimited time to spend on these things, and org-ref is designed with the constraints I have so that I am able to develop and support it. That is all you should read into this. I don't have the time or energy develop and maintain separate packages that I use together. I do not want to separate org-ref into separate core packages for cross-references, indexes, glossary/acronyms, bibtex utilities, and packages that integrate helm, ivy, etc. > > Can this not be resolved? > > I am content to agree to disagree on these points and move forward with > both packages because they solve different problems, are suitable for > different communities, and they continue to benefit each other. > > Friendly co-existence should be our goal. But can that be a situation > in which one is able to choose between the best of both and, as far as > possible, switch from one to the other. As far as I can tell, you can already do this. > > Thanks again for your time and effort, > > Vikas -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 11:51 ` John Kitchin @ 2022-03-21 17:20 ` Vikas Rawal 2022-03-25 15:53 ` Max Nikulin 2022-03-25 17:10 ` Max Nikulin 2 siblings, 0 replies; 73+ messages in thread From: Vikas Rawal @ 2022-03-21 17:20 UTC (permalink / raw) To: John Kitchin; +Cc: org-mode mailing list, Nicolas Goaziou [-- Attachment #1: Type: text/plain, Size: 249 bytes --] > > > > I don't think you have to choose. You can use org-cite for > citations, and org-ref for cross-references. The citation syntax is > orthogonal, you just should not mix them. That is excellent then. Thanks for clarifications. Best, Vikas [-- Attachment #2: Type: text/html, Size: 544 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 11:51 ` John Kitchin 2022-03-21 17:20 ` Vikas Rawal @ 2022-03-25 15:53 ` Max Nikulin 2022-03-27 15:33 ` John Kitchin 2022-03-25 17:10 ` Max Nikulin 2 siblings, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-25 15:53 UTC (permalink / raw) To: emacs-orgmode On 21/03/2022 18:51, John Kitchin wrote: > Vikas Rawal writes: >> >> From the perspective of a user, this was only meant to express a >> sentiment that one finds oneself in a situation of having to choose >> between two good things, and that we have not been able to find a way >> to make both compatible with each other. It was in not meant as a >> disrespect in any way. > > I don't think you have to choose. You can use org-cite for > citations, and org-ref for cross-references. The citation syntax is > orthogonal, you just should not mix them. You can even wire org-ref to > use org-cite-insert like this: > > (setq org-ref-insert-cite-function (lambda () (org-cite-insert nil))) I am glad to read this. John, could you, please, update the README file for https://github.com/jkitchin/org-ref to clarify that both packages may be used within the same document while org-ref is used solely for cross-references (I may create a github issue if your prefer)? From my point of view the following phrase may be considered as prohibitive in respect to combining the packages for any purpose: > You can use both org-cite and org-ref (although you should not do > that in the same document as they are independent citation tools). I feel some ambiguity in the starting message in this thread: Vikas Rawal, Sun, 20 Mar 2022 17:38:30 +0530. https://list.orgmode.org/CALtzAB2BHULDOXaamUZFQh2H453Ekb6K7bkOHbU-dHPn98avwg@mail.gmail.com > This obviously creates many problems including that two people using > different citation systems cannot share org files. Accordingly to the org-ref README installed org-ref package does not break org-cite, so people are free to share documents. They just should have both packages configured and should adhere to a chosen package in each document (for *citations*). ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-25 15:53 ` Max Nikulin @ 2022-03-27 15:33 ` John Kitchin 2022-03-27 15:44 ` Vikas Rawal 0 siblings, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-27 15:33 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode I have updated the readme in org-ref to indicate you can use both packages. Max Nikulin <manikulin@gmail.com> writes: > On 21/03/2022 18:51, John Kitchin wrote: >> Vikas Rawal writes: >>> >>> From the perspective of a user, this was only meant to express a >>> sentiment that one finds oneself in a situation of having to choose >>> between two good things, and that we have not been able to find a way >>> to make both compatible with each other. It was in not meant as a >>> disrespect in any way. >> I don't think you have to choose. You can use org-cite for >> citations, and org-ref for cross-references. The citation syntax is >> orthogonal, you just should not mix them. You can even wire org-ref to >> use org-cite-insert like this: >> (setq org-ref-insert-cite-function (lambda () (org-cite-insert nil))) > > I am glad to read this. John, could you, please, update the README file for > https://github.com/jkitchin/org-ref to clarify that both packages may be used > within the same document while org-ref is used solely for cross-references (I > may create a github issue if your prefer)? From my point of view the following > phrase may be considered as prohibitive in respect to combining the packages for > any purpose: > >> You can use both org-cite and org-ref (although you should not do that in the >> same document as they are independent citation tools). > I feel some ambiguity in the starting message in this thread: > > Vikas Rawal, Sun, 20 Mar 2022 17:38:30 +0530. > https://list.orgmode.org/CALtzAB2BHULDOXaamUZFQh2H453Ekb6K7bkOHbU-dHPn98avwg@mail.gmail.com > >> This obviously creates many problems including that two people using >> different citation systems cannot share org files. > Accordingly to the org-ref README installed org-ref package does not break > org-cite, so people are free to share documents. They just should have both > packages configured and should adhere to a chosen package in each document (for > *citations*). -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-27 15:33 ` John Kitchin @ 2022-03-27 15:44 ` Vikas Rawal 0 siblings, 0 replies; 73+ messages in thread From: Vikas Rawal @ 2022-03-27 15:44 UTC (permalink / raw) To: John Kitchin; +Cc: Max Nikulin, org-mode mailing list [-- Attachment #1: Type: text/plain, Size: 90 bytes --] I have updated the readme in org-ref to indicate you can use both > packages. > > Thanks. [-- Attachment #2: Type: text/html, Size: 400 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 11:51 ` John Kitchin 2022-03-21 17:20 ` Vikas Rawal 2022-03-25 15:53 ` Max Nikulin @ 2022-03-25 17:10 ` Max Nikulin 2022-03-26 12:41 ` Bruce D'Arcus 2022-03-27 19:40 ` John Kitchin 2 siblings, 2 replies; 73+ messages in thread From: Max Nikulin @ 2022-03-25 17:10 UTC (permalink / raw) To: emacs-orgmode On 21/03/2022 18:51, John Kitchin wrote: > > citenum and bibentry are the only two I am not sure have a CSL analog. I read your messages once more and I should say that I feel some disagreement of this one (I removed most of it) and the earlier and longer one from Sun, 20 Mar 2022 20:31:29 -0400 https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu I admit that org-ref is carefully tuned to your workflow. I hope, it is possible to left aside decomposition of org-cite into modules for some time. Let's assume org-cite with natbib backend for citations and org-ref for cross-references. It seems, a couple of missed styles currently is not a problem due to the defcustom for the mapping. Are there still any technical limitations that prevent getting in the exported LaTeX file the same citation commands as for org-ref? In particular I am worrying concerning https://github.com/jkitchin/org-ref README (and the same phrase from the earlier message): > org-cite does not meet my citation and technical document publishing > needs, and it was not possible to integrate it into org-ref without > compromising those. Does it refer to exported result or to convenience of working with citations? Would it help if it were possible to choose style by its natbib command? I see that you do not like org-cite styles, but I can not figure out what are the real blockers that prevent producing documents having the same quality. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-25 17:10 ` Max Nikulin @ 2022-03-26 12:41 ` Bruce D'Arcus 2022-03-27 19:40 ` John Kitchin 1 sibling, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-26 12:41 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email I obviously can't speak for John, but on this: On Fri, Mar 25, 2022 at 1:11 PM Max Nikulin <manikulin@gmail.com> wrote: > > On 21/03/2022 18:51, John Kitchin wrote: > > > > citenum and bibentry are the only two I am not sure have a CSL analog. As I said in an earlier message, it's no problem to add these. Someone can always add the bibentry/fullcite style to oc-csl later, if and when Andras adds the functionality to citeproc-el. Though it's feasible, I doubt you'll ever see citenum in CSL, since those sorts of low-level commands don't really fit there. But that also is not a problem. > I read your messages once more and I should say that I feel some > disagreement of this one (I removed most of it) and the earlier and > longer one from Sun, 20 Mar 2022 20:31:29 -0400 > https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu > > I admit that org-ref is carefully tuned to your workflow. I hope, it is > possible to left aside decomposition of org-cite into modules for some time. > > Let's assume org-cite with natbib backend for citations and org-ref for > cross-references. It seems, a couple of missed styles currently is not a > problem due to the defcustom for the mapping. The mapping defcustom is currently only in oc-biblatex. It might be worth adding it to oc-natbib, and so generalizing how these mappings are handled in latex? Bruce > Are there still any technical limitations that prevent getting in the > exported LaTeX file the same citation commands as for org-ref? > > In particular I am worrying concerning > https://github.com/jkitchin/org-ref README (and the same phrase from the > earlier message): > > > org-cite does not meet my citation and technical document publishing > > needs, and it was not possible to integrate it into org-ref without > > compromising those. > Does it refer to exported result or to convenience of working with > citations? Would it help if it were possible to choose style by its > natbib command? > > I see that you do not like org-cite styles, but I can not figure out > what are the real blockers that prevent producing documents having the > same quality. > > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-25 17:10 ` Max Nikulin 2022-03-26 12:41 ` Bruce D'Arcus @ 2022-03-27 19:40 ` John Kitchin 2022-03-28 12:34 ` Max Nikulin 1 sibling, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-27 19:40 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode Max Nikulin <manikulin@gmail.com> writes: > On 21/03/2022 18:51, John Kitchin wrote: >> citenum and bibentry are the only two I am not sure have a CSL analog. > > I read your messages once more and I should say that I feel some disagreement of > this one (I removed most of it) and the earlier and longer one from Sun, 20 Mar > 2022 20:31:29 -0400 https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu > > I admit that org-ref is carefully tuned to your workflow. I hope, it is possible > to left aside decomposition of org-cite into modules for some time. > > Let's assume org-cite with natbib backend for citations and org-ref for > cross-references. It seems, a couple of missed styles currently is not a problem > due to the defcustom for the mapping. > > Are there still any technical limitations that prevent getting in the exported > LaTeX file the same citation commands as for org-ref? If all one wants is LaTeX export, there are not technical limitations. That is not all people want in general though, they also want other exports, and that they are reasonably similar, or even possible. It is easy to get \citenum and \bibentry for LaTeX. I promise though, someone wants this or some other thing for HTML. Rather than rehash a lot of experiences, I really encourage you to try writing a processor that can support this. Or even, try modifying org-ref-cite to support it. Not as some thought experiment about what should be possible, but an actual experiment that is worked out. > In particular I am worrying concerning https://github.com/jkitchin/org-ref > README (and the same phrase from the earlier message): > >> org-cite does not meet my citation and technical document publishing needs, >> and it was not possible to integrate it into org-ref without compromising >> those. I have taken this out of the readme. I still agree with the sentiment, but my needs are not the same as others (for example, I include in my needs include ease of support and development, which is not a user need), and it is possible to meet some basic needs fully. > Does it refer to exported result or to convenience of working with citations? > Would it help if it were possible to choose style by its natbib command? > > I see that you do not like org-cite styles, but I can not figure out what are > the real blockers that prevent producing documents having the same > quality. If you spend enough time teaching people how to use these things, you might feel differently about this. It is so easy to just switch away to Endnote, Papers, Paperpile, Mendeley, Zotero, Overleaf, etc. I guess I am not on the prevailing side here though. -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-27 19:40 ` John Kitchin @ 2022-03-28 12:34 ` Max Nikulin 2022-03-28 13:16 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-28 12:34 UTC (permalink / raw) To: emacs-orgmode On 28/03/2022 02:40, John Kitchin wrote: > Max Nikulin writes: >> On 21/03/2022 18:51, John Kitchin wrote: > > Rather than rehash a lot of experiences, I really encourage you to try > writing a processor that can support this. Or even, try modifying > org-ref-cite to support it. Not as some thought experiment about what > should be possible, but an actual experiment that is worked out. I have some ideas for links, other inline objects and export attributes that I should try before. >> In particular I am worrying concerning https://github.com/jkitchin/org-ref >> README (and the same phrase from the earlier message): >> >>> org-cite does not meet my citation and technical document publishing needs, >>> and it was not possible to integrate it into org-ref without compromising >>> those. > > I have taken this out of the readme. I still agree with the sentiment, > but my needs are not the same as others (for example, I include in my > needs include ease of support and development, which is not a user > need), and it is possible to meet some basic needs fully. John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) https://list.orgmode.org/m24k3jnq0k.fsf@andrew.cmu.edu you clearly stated a technical limitation that is a real reason why org-cite is not an option for you and for some other users: performance has not been optimized for large BibTeX databases. It is deserved to be mentioned. You even have managed to convince me that, besides adding missing style names, some existing ones should be adjusted. noauthor/bare for citeyear example makes for me much more sense than general words that org-cite is too CSL-oriented. So the opinion that the set of styles has not really settled yet may be precious for users choosing between org-cite and org-ref. From my point of view such arguments are more clear than your earlier message (Sun, 20 Mar 2022 20:31:29 -0400) https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu I had no intention to force to remove that phrase before the issues are fixed. I was trying to ask you about more details behind your opinion (and now we have them). ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-28 12:34 ` Max Nikulin @ 2022-03-28 13:16 ` Bruce D'Arcus 2022-03-29 15:22 ` Max Nikulin 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-28 13:16 UTC (permalink / raw) To: Max Nikulin, org-mode-email On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin <manikulin@gmail.com> wrote: > > On 28/03/2022 02:40, John Kitchin wrote: > > Max Nikulin writes: > >> On 21/03/2022 18:51, John Kitchin wrote: > > > > Rather than rehash a lot of experiences, I really encourage you to try > > writing a processor that can support this. Or even, try modifying > > org-ref-cite to support it. Not as some thought experiment about what > > should be possible, but an actual experiment that is worked out. > > I have some ideas for links, other inline objects and export attributes > that I should try before. > > >> In particular I am worrying concerning https://github.com/jkitchin/org-ref > >> README (and the same phrase from the earlier message): > >> > >>> org-cite does not meet my citation and technical document publishing needs, > >>> and it was not possible to integrate it into org-ref without compromising > >>> those. > > > > I have taken this out of the readme. I still agree with the sentiment, > > but my needs are not the same as others (for example, I include in my > > needs include ease of support and development, which is not a user > > need), and it is possible to meet some basic needs fully. > > John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) > https://list.orgmode.org/m24k3jnq0k.fsf@andrew.cmu.edu you clearly > stated a technical limitation that is a real reason why org-cite is not > an option for you and for some other users: performance has not been > optimized for large BibTeX databases. It is deserved to be mentioned. FWIW, Ihor posted a patch related to this a week or so ago. > You even have managed to convince me that, besides adding missing style > names, some existing ones should be adjusted. noauthor/bare for citeyear > example makes for me much more sense ... This does need some attention, but there are wrinkles here. Citeyear is specific to author-date styles, while noauthor is intended to be more general. Hence, initially "noauthor". This indeed was influenced by CSL implementations like Zotero and pandoc, which have a notion of "suppress author". But the names are kind of awkward admittedly, and Andras Simonyi subsequently added a "year" style in oc-csl. You can see the conversation about it here. https://github.com/andras-simonyi/oc-csl-ns/issues/1#issuecomment-895440897 I think it's probably a good idea to add "year" to the latex processors too. I will reproduce Denis' explanation from that linked comment here: ------- The reasoning behind "noauthor" vs "year" was that our priority was portability between different classes of citation styles. If we have this item "John, Doe. /A book/. 2020." the variant "noauthor" can be used to render this consistently. In-Text: a) author-year: "(2020)" b) author-title: "(/A book/)" Author-title in footnote: "/A book/. 2020." Here, it's not so much about what information should be rendered, but rather what should be ommitted. "Year" would be much less portable. That doesn't mean that "year" couldn't be legitimate, in the sense of "I really need the year here". But that raises another question: How will citeproc-el know where this year is coming from, and how the year has to be formatted? That will have to be hardcoded in the processor as styles contain no information about this. ---- Bruce Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-28 13:16 ` Bruce D'Arcus @ 2022-03-29 15:22 ` Max Nikulin 2022-03-29 16:14 ` Bruce D'Arcus 2022-03-30 21:43 ` citations: org-cite vs org-ref 3.0 John Kitchin 0 siblings, 2 replies; 73+ messages in thread From: Max Nikulin @ 2022-03-29 15:22 UTC (permalink / raw) To: emacs-orgmode On 28/03/2022 20:16, Bruce D'Arcus wrote: > On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote: >> >> John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) >> https://list.orgmode.org/m24k3jnq0k.fsf@andrew.cmu.edu you clearly >> stated a technical limitation that is a real reason why org-cite is not >> an option for you and for some other users: performance has not been >> optimized for large BibTeX databases. It is deserved to be mentioned. > > FWIW, Ihor posted a patch related to this a week or so ago. I am optimistic concerning that patch since a couple of users confirmed improvement, but it is up to John to decide if it is acceptable in comparison to org-ref. I am unsure concerning startup time. >> You even have managed to convince me that, besides adding missing style >> names, some existing ones should be adjusted. noauthor/bare for citeyear >> example makes for me much more sense ... > > This does need some attention, but there are wrinkles here. > > Citeyear is specific to author-date styles, while noauthor is intended > to be more general. Anyway citation style is rather specific for a particular CSL style. I tried some styles: https://github.com/citation-style-language/styles/blob/master/ieee.csl https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl nature.csl science.csl and for all these styles even "author" is meaningless since they are numeric styles. So it is not more general. Switching CSL style means necessity to update styles in each citations (unless it is possible to specify global or per-cite mapping). It seems modifiers are set of boolean flags (positive "year" or negative "suppress-author") in citeproc.el, set of values in natbib, and a kind of hierarchy in org-cite. From my point of view, set of constrains (flags) is the most general variant in this list. > I think it's probably a good idea to add "year" to the latex processors too. I agree. Negations are more confusing when an author needs just year. > "Year" would be much less portable. That doesn't mean that "year" > couldn't be legitimate, in the sense of "I really need the year here". I would say that if a citation style has no year than a warning should be spat, but year should not appear since it is against the style. Unsure if it is useful to have special command or style "query" that can insert e.g. year, journal, or any other field disregarding style to ensure that the text and the bibliography reference have not diverged, but it is rather for descriptive text than for a citation. > But that raises another question: How will citeproc-el know where this > year is coming from, and how the year has to be formatted? That will > have to be hardcoded in the processor as styles contain no information > about this. A fallback style (for the particular citation, for the whole document or in global user preferences) might be specified for formatters missed in the main style. I have tried the following: obt.bib: @ARTICLE{schawlow1958iao, author = {Schawlow, Arthur Leonard and Townes, Charles Hard}, title = {Infrared and Optical Masers}, journal = {Phys. Rev.}, year = {1958}, volume = {112}, pages = {1940--1949}, month = {Dec}, doi = {10.1103/PhysRev.112.1940}, issue = {6}, publisher = {American Physical Society}, } obt.org: #+bibliography: obt.bib # #+cite_export: csl # #+cite_export: csl /usr/share/citation-style-language/styles/chicago-author-date.csl # #+cite_export: csl /usr/share/citation-style-language/styles/american-physics-society.csl - Default: [cite:@schawlow1958iao]. - text: [cite/text:@schawlow1958iao]. - noauthor: [cite/noauthor:@schawlow1958iao]. - year/bare: [cite/year/bare:@schawlow1958iao]. #+print_bibliography: I am familiar with bst language used by BibTeX and I am surprised that initials instead of full names are not enforced by CSL styles. Emphasis and bold markers may appear in plain text export. Behavior of styles is not uniform in respect to adding (unbreakable?) space before citation. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-29 15:22 ` Max Nikulin @ 2022-03-29 16:14 ` Bruce D'Arcus 2022-03-30 13:50 ` Denis Maier 2022-03-31 15:10 ` Max Nikulin 2022-03-30 21:43 ` citations: org-cite vs org-ref 3.0 John Kitchin 1 sibling, 2 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-29 16:14 UTC (permalink / raw) To: org-mode-email On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin <manikulin@gmail.com> wrote: ... > >> You even have managed to convince me that, besides adding missing style > >> names, some existing ones should be adjusted. noauthor/bare for citeyear > >> example makes for me much more sense ... > > > > This does need some attention, but there are wrinkles here. > > > > Citeyear is specific to author-date styles, while noauthor is intended > > to be more general. > > Anyway citation style is rather specific for a particular CSL style. I > tried some styles: > https://github.com/citation-style-language/styles/blob/master/ieee.csl > https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl > nature.csl science.csl and for all these styles even "author" is > meaningless since they are numeric styles. Yes. I think it's more relevant in author-date to note styles. I believe biblatex has a command relevant here, but Denis knows biblatex better than I. > So it is not more general. Switching CSL style means necessity to update > styles in each citations (unless it is possible to specify global or > per-cite mapping). Not really. Arguably the most important style is "text", which applies to any output style; author-date, note-based, numeric. When you start getting into some of the others, the range of styles a given style may apply to shrinks. But you might say author-date styles are pretty dependent on such local citation modification. If those are output to a style that has no such notions (like a numeric one), then a processor can just ignore it. > It seems modifiers are set of boolean flags (positive "year" or negative > "suppress-author") in citeproc.el, set of values in natbib, and a kind > of hierarchy in org-cite. From my point of view, set of constrains > (flags) is the most general variant in this list. I think that's right, and is how it's represented in a GUI app like Zotero. But that's not so convenient in a plain text format. But it's a good way to explain the differences. > > I think it's probably a good idea to add "year" to the latex processors too. > > I agree. Negations are more confusing when an author needs just year. We might as well do that then, along with bibentry/fullcite. ... > I am familiar with bst language used by BibTeX and I am surprised that > initials instead of full names are not enforced by CSL styles. I'm not following here. Certainly one can specify initialization rules in a CSL style. WDYM by "enforced"? > Emphasis and bold markers may appear in plain text export. Behavior of styles is > not uniform in respect to adding (unbreakable?) space before citation. Sorry; not following here again. Isn't the space before a citation determined by the user? Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-29 16:14 ` Bruce D'Arcus @ 2022-03-30 13:50 ` Denis Maier 2022-03-31 15:10 ` Max Nikulin 1 sibling, 0 replies; 73+ messages in thread From: Denis Maier @ 2022-03-30 13:50 UTC (permalink / raw) To: Org Mode List Am 29.03.2022 um 18:14 schrieb Bruce D'Arcus: > On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin <manikulin@gmail.com> wrote: > ... > >>>> You even have managed to convince me that, besides adding missing style >>>> names, some existing ones should be adjusted. noauthor/bare for citeyear >>>> example makes for me much more sense ... >>> >>> This does need some attention, but there are wrinkles here. >>> >>> Citeyear is specific to author-date styles, while noauthor is intended >>> to be more general. >> >> Anyway citation style is rather specific for a particular CSL style. I >> tried some styles: >> https://github.com/citation-style-language/styles/blob/master/ieee.csl >> https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl >> nature.csl science.csl and for all these styles even "author" is >> meaningless since they are numeric styles. > > Yes. I think it's more relevant in author-date to note styles. I > believe biblatex has a command relevant here, but Denis knows biblatex > better than I. I'm not sure I understand the question here. What command should be in biblatex? There's \citeauthor if that's what you've meant. > >> So it is not more general. Switching CSL style means necessity to update >> styles in each citations (unless it is possible to specify global or >> per-cite mapping). > > Not really. Arguably the most important style is "text", which applies > to any output style; author-date, note-based, numeric. > > When you start getting into some of the others, the range of styles a > given style may apply to shrinks. > > But you might say author-date styles are pretty dependent on such > local citation modification. If those are output to a style that has > no such notions (like a numeric one), then a processor can just ignore > it. Just to add to this: When Bruce and I have worked on that list of styles we found that portability can only be ensured when using high-level commands (such as biblatex's autocite), but once you start using low-level commands like citeyear etc. you really lose that portability to a certain degree. > >> It seems modifiers are set of boolean flags (positive "year" or negative >> "suppress-author") in citeproc.el, set of values in natbib, and a kind >> of hierarchy in org-cite. From my point of view, set of constrains >> (flags) is the most general variant in this list. > > I think that's right, and is how it's represented in a GUI app like > Zotero. But that's not so convenient in a plain text format. > > But it's a good way to explain the differences. > >>> I think it's probably a good idea to add "year" to the latex processors too. >> >> I agree. Negations are more confusing when an author needs just year. Well, negations have the advantage of being more portable. Say you have this: Doe argues X and Y [cite/noauthor:@doe]. It's perfectly clear what this should mean in a author-year, author-title or note-based styles, i.e., print the citation without the author element. (That's obviously a simplification since some citations might not have an author element, but let's just go with it for the moment.) In a numeric style you can just ignore the noauthor modifier and fall back to the default numeric citation. Now, consider this instead: Doe argues X and Y [cite/year:@doe]. This might work in author-year styles, but not in author-title, not in note-based styles, and not in numeric styles. Considering the problem that some citations don't have an author element I even considered using style names like [cite/head:@doe] [cite/tail:@doe] or [cite/car:@doe] [cite/cdr:@doe] or [cite/first:@doe] [cite/rest:@doe] But that obviously a bit esoteric. Denis ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-29 16:14 ` Bruce D'Arcus 2022-03-30 13:50 ` Denis Maier @ 2022-03-31 15:10 ` Max Nikulin 2022-03-31 17:27 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-31 15:10 UTC (permalink / raw) To: emacs-orgmode On 29/03/2022 23:14, Bruce D'Arcus wrote: > On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote: >> So it is not more general. Switching CSL style means necessity to update >> styles in each citations (unless it is possible to specify global or >> per-cite mapping). > > Not really. Arguably the most important style is "text", which applies > to any output style; author-date, note-based, numeric. > > When you start getting into some of the others, the range of styles a > given style may apply to shrinks. I am from the world of in-text numeric styles. I always considered them as almost footnote style since the only difference is brackets vs. superscript. Author-date style looks quite distinct from such point of view. >> I am familiar with bst language used by BibTeX and I am surprised that >> initials instead of full names are not enforced by CSL styles. > > I'm not following here. Certainly one can specify initialization rules > in a CSL style. > > WDYM by "enforced"? My complain was wrong (besides it is unrelated to my statement that it is impossible to just specify another style, be ready to edit citations). Some journals omit even article titles to get more compact bibliography. I do not remember whether I have seen papers where names are not shortened to initials. Any description of BST BibTeX language explains how to use format.names$ function, so I was surprised when I got the following. However after your question I have checked that achicago.bst formats entry with full names as well. #+cite_export: csl /usr/share/citation-style-language/styles/chicago-author-date.csl --- >8 --- • Default (Schawlow and Townes 1958). Schawlow, Arthur Leonard, and Charles Hard Townes. 1958. “Infrared and Optical Masers.” /Phys. Rev./ 112 (December). American Physical Society:1940–49. <https://doi.org/10.1103/PhysRev.112.1940>. --- 8< ---- >> Emphasis and bold markers may appear in plain text export. Behavior of styles is >> not uniform in respect to adding (unbreakable?) space before citation. > > Sorry; not following here again. Isn't the space before a citation > determined by the user? I was lucky enough to pick a couple of styles having different behavior. Notice additional unbreakable space before "[1]" in the second example. I have checked a couple of IEEE papers and they have spaces before citations, so to switch from IEEE to APS style it is necessary to remove spaces before citations. Examples are generated using text unicode export. #+cite_export: csl /usr/share/citation-style-language/styles/ieee.csl - Default: [cite:@schawlow1958iao]. --- >8 --- • Default: [1]. [1] A. L. Schawlow and C. H. Townes, [“Infrared and optical masers,]” /Phys. rev./, vol. 112, pp. 1940–1949, Dec. 1958. [“Infrared and optical masers,] <https://doi.org/10.1103/PhysRev.112.1940> --- 8< --- #+cite_export: csl /usr/share/citation-style-language/styles/american-physics-society.csl --- >8 --- • Default: [1]. [1] A. L. Schawlow and C. H. Townes, Phys. Rev. *112*, 1940 (1958). --- 8< --- ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-31 15:10 ` Max Nikulin @ 2022-03-31 17:27 ` Bruce D'Arcus 2022-04-02 11:41 ` org-cite, CSL styles and space before citation Max Nikulin 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-31 17:27 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email On Thu, Mar 31, 2022 at 11:27 AM Max Nikulin <manikulin@gmail.com> wrote: .... > >> Emphasis and bold markers may appear in plain text export. Behavior of styles is > >> not uniform in respect to adding (unbreakable?) space before citation. > > > > Sorry; not following here again. Isn't the space before a citation > > determined by the user? > > I was lucky enough to pick a couple of styles having different behavior. > Notice additional unbreakable space before "[1]" in the second example. > I have checked a couple of IEEE papers and they have spaces before > citations, so to switch from IEEE to APS style it is necessary to remove > spaces before citations. The latter style includes a non-breaking space in the citation definition ... https://github.com/citation-style-language/styles/blob/21e2177295be5b98ef49b00dd4b8cc7e68d2143d/american-physics-society.csl#L96 ... which strikes me as odd, though would explain what you see. The former has no space. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* org-cite, CSL styles and space before citation 2022-03-31 17:27 ` Bruce D'Arcus @ 2022-04-02 11:41 ` Max Nikulin 0 siblings, 0 replies; 73+ messages in thread From: Max Nikulin @ 2022-04-02 11:41 UTC (permalink / raw) To: emacs-orgmode On 01/04/2022 00:27, Bruce D'Arcus wrote: > On Thu, Mar 31, 2022 at 11:27 AM Max Nikulin wrote: > >>>> Emphasis and bold markers may appear in plain text export. Behavior of styles is >>>> not uniform in respect to adding (unbreakable?) space before citation. >>> >>> Sorry; not following here again. Isn't the space before a citation >>> determined by the user? >> >> I was lucky enough to pick a couple of styles having different behavior. >> Notice additional unbreakable space before "[1]" in the second example. >> I have checked a couple of IEEE papers and they have spaces before >> citations, so to switch from IEEE to APS style it is necessary to remove >> spaces before citations. > > The latter style includes a non-breaking space in the citation definition ... > > https://github.com/citation-style-language/styles/blob/21e2177295be5b98ef49b00dd4b8cc7e68d2143d/american-physics-society.csl#L96 > > ... which strikes me as odd, though would explain what you see. I grepped the directory with CSL styles for "prefix" and tried annales.csl. It removes regular spaces before citations (if they exist) but preserves non-breakable one. Since the project has enormous amount of styles, it is hard to ensure that they have uniform quality and behavior e.g. in respect to responsibility for a space before citations. A test sample and result of rendering for it with a check list for style authors may help, but they will evolve in time. It is unlikely that accidental contributors of styles will manage to maintain compliance to current edition of tests. However it would be great for various tools dealing with styles. P.S. After all, it is necessary to change style when e.g. a journal declined a paper. It may mean that the quality of the paper is not high enough. Adjusting the text for another style is a burden that makes it harder to just send it to another journal and thus reduces number of low quality papers. And such efforts are negligible in comparison with attempts to mane the content better. So some oddities with particular styles are not a serious issue. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-29 15:22 ` Max Nikulin 2022-03-29 16:14 ` Bruce D'Arcus @ 2022-03-30 21:43 ` John Kitchin 1 sibling, 0 replies; 73+ messages in thread From: John Kitchin @ 2022-03-30 21:43 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode Max Nikulin <manikulin@gmail.com> writes: > On 28/03/2022 20:16, Bruce D'Arcus wrote: >> On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote: >>> >>> John, in another message (Sun, 27 Mar 2022 13:00:40 -0400) >>> https://list.orgmode.org/m24k3jnq0k.fsf@andrew.cmu.edu you clearly >>> stated a technical limitation that is a real reason why org-cite is not >>> an option for you and for some other users: performance has not been >>> optimized for large BibTeX databases. It is deserved to be mentioned. >> >> FWIW, Ihor posted a patch related to this a week or so ago. > > I am optimistic concerning that patch since a couple of users confirmed > improvement, but it is up to John to decide if it is acceptable in > comparison to org-ref. I am unsure concerning startup time. I think this will be a problem that is processor specific. It is important that org have a reasonable performance here, but I don't think it was a goal to have the fastest bibtex/json/etc. parser available, just a reasonable default that works out of the box. That is, it doesn't take too long to read the database for insertion, and fontification is not a performance breaker, on say a moderate sized database and org-file. Getting high performance from large databases and large files with lots of citations (say a dissertation or big review article) takes some work. -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 0:31 ` John Kitchin 2022-03-21 1:39 ` Timothy 2022-03-21 3:27 ` Vikas Rawal @ 2022-03-21 12:59 ` juh 2022-03-22 13:03 ` indieterminacy 2022-03-23 21:06 ` Nicolas Goaziou 3 siblings, 1 reply; 73+ messages in thread From: juh @ 2022-03-21 12:59 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] Am Sun, Mar 20, 2022 at 08:31:29PM -0400 schrieb John Kitchin: > For those who need high fidelity LaTeX export like I do, I think > org-ref is still a superior solution. For everyone else, and > especially if you do not need sophisticated cross-references and don't > want the dependencies of org-ref, org-cite is likely the better > solution. Thank you very much for the clarification. I am new to both and I need something that works together with ConTeXt export. Currently I am happy with org-cite. I used org-ref before but never got good results in ConTeXt export. So I think that I will stick wit org-cite. Org-mode is not LaTeX but I wonder if it can be a better replacement for my Markdown-->Pandoc-->EPUB/ConTeXt single source publication process. Better as I could make more use of org-roam in my writing process. Though I am a long time emacs user putting all these blocks together is a challenge, still. With your words I now see much much clearer. juh -- Autoren-Homepage: ......... http://literatur.hasecke.com Satiren & Essays: ......... http://www.sudelbuch.de Privater Blog: ............ http://www.hasecke.eu Netzliteratur-Projekt: .... http://www.generationenprojekt.de [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 12:59 ` juh @ 2022-03-22 13:03 ` indieterminacy 0 siblings, 0 replies; 73+ messages in thread From: indieterminacy @ 2022-03-22 13:03 UTC (permalink / raw) To: juh; +Cc: emacs-orgmode Hi Juh, juh <juh+emacs-orgmoden@mailbox.org> writes: > [[PGP Signed Part:Undecided]] > Am Sun, Mar 20, 2022 at 08:31:29PM -0400 schrieb John Kitchin: >> For those who need high fidelity LaTeX export like I do, I think >> org-ref is still a superior solution. For everyone else, and >> especially if you do not need sophisticated cross-references and don't >> want the dependencies of org-ref, org-cite is likely the better >> solution. > > Thank you very much for the clarification. > > I am new to both and I need something that works together with ConTeXt > export. Currently I am happy with org-cite. I used org-ref before but > never got good results in ConTeXt export. So I think that I will stick > wit org-cite. > I used to use ConTeXt and have a healthy respect for it. That feedback is good to hear. > Org-mode is not LaTeX but I wonder if it can be a better replacement for > my Markdown-->Pandoc-->EPUB/ConTeXt single source publication process. > Better as I could make more use of org-roam in my writing process. > May I recommend the mininimal Markdown format, GemText? It has a very simple syntax which is easily convertable into Orgmode syntax. It could be useful for projects where the flow starts with simple written prose. > Though I am a long time emacs user putting all these blocks together is > a challenge, still. > > With your words I now see much much clearer. > > juh Jonathan ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 0:31 ` John Kitchin ` (2 preceding siblings ...) 2022-03-21 12:59 ` juh @ 2022-03-23 21:06 ` Nicolas Goaziou 2022-03-27 17:00 ` John Kitchin 3 siblings, 1 reply; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-23 21:06 UTC (permalink / raw) To: John Kitchin; +Cc: Vikas Rawal, emacs-orgmode Hello, John Kitchin <jkitchin@andrew.cmu.edu> writes: > I do not think it is productive for the community to say or consider it > is a sad situation. Many good things have emerged from these > discussions, even if it is not yet consensus on a solution. It is a > complex problem, with many years of effort by many people on each side. > That is an indication of how ambitious this project is and that there > may be more than one solution that is needed. [...] > There are more than 8 years of legacy org-ref documents. I have written > 40+ scientific papers with it, and countless technical documents with > more than 8000 cite links among them. org-ref has exceeded 190K > downloads from MELPA, so I feel obligated to maintain org-ref for > myself, and those users. org-ref may be heavyweight in bundling a lot of > capability together that could be separated into individual packages, > but it is also convenient for people who need it, and a GitHUB issue or > pull request away from new features. I remain committed to supporting > this, and I do it in a way I can manage, hence the monolithic package > design. I think there's a misunderstanding here. Org Cite was never meant as a replacement for Org Ref. It was designed from the beginning as a framework other libraries could rely on and extend in their own way. Org Ref could have been one of them. It looks like a social problem to me. I remember well asking for feedback when implementing the various prototypes, i.e., ways to make Org Cite more useful to other libraries. I don't think I got much of it, barring the cross-references topic, which is not solved. Maybe I was not explicit enough about what I was expecting. For example, this is—please correct me if I'm wrong—the first time I read about the "BibLaTeX is not fully implemented in Org Cite" and "Org Cite is adding an extra abstraction layer on top of BibLaTeX commands" issues, which are both trivial to solve, either on the Org Cite or the Org Ref side. But then again, it is perfectly fine if Org Cite doesn't provide that, as some libraries can extend it if needed. On the other hand, there have been much activity on GitHub repositories, i.e., out of this mailing list. It seems to me Org Ref project has been trying to work around possible blockers in Org Cite project the whole time without the latter knowing about them, and having an opportunity to lift them. > Both projects have benefited from this discussion a lot. org has > org-cite now, and org-ref now handles pre/post notes like org-cite does, > it supports CSL much better, and is even a little more modular, lighter > weight, and more easily integrated with other completion backends than > ivy or helm. That should broadly be viewed as a win-win situation. But it is not. There are now two, more or less official, citations syntax. Interoperability is the big loss. Features do not count; it is perfectly fine to have different packages targeting different needs, as long as they share the same syntax. Hopefully, at some point, we'll be able to build a list of blockers that prevent Org Ref being built on top of Org Cite, and proceed. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 21:06 ` Nicolas Goaziou @ 2022-03-27 17:00 ` John Kitchin 2022-03-27 23:17 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-27 17:00 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Vikas Rawal, emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > John Kitchin <jkitchin@andrew.cmu.edu> writes: > >> I do not think it is productive for the community to say or consider it >> is a sad situation. Many good things have emerged from these >> discussions, even if it is not yet consensus on a solution. It is a >> complex problem, with many years of effort by many people on each side. >> That is an indication of how ambitious this project is and that there >> may be more than one solution that is needed. > > [...] > >> There are more than 8 years of legacy org-ref documents. I have written >> 40+ scientific papers with it, and countless technical documents with >> more than 8000 cite links among them. org-ref has exceeded 190K >> downloads from MELPA, so I feel obligated to maintain org-ref for >> myself, and those users. org-ref may be heavyweight in bundling a lot of >> capability together that could be separated into individual packages, >> but it is also convenient for people who need it, and a GitHUB issue or >> pull request away from new features. I remain committed to supporting >> this, and I do it in a way I can manage, hence the monolithic package >> design. > > I think there's a misunderstanding here. Org Cite was never meant as > a replacement for Org Ref. It was designed from the beginning as > a framework other libraries could rely on and extend in their own way. > Org Ref could have been one of them. > > It looks like a social problem to me. I remember well asking for > feedback when implementing the various prototypes, i.e., ways to make > Org Cite more useful to other libraries. I don't think I got much of it, > barring the cross-references topic, which is not solved. Maybe I was not > explicit enough about what I was expecting. For example, this is—please > correct me if I'm wrong—the first time I read about the "BibLaTeX is not > fully implemented in Org Cite" and "Org Cite is adding an extra > abstraction layer on top of BibLaTeX commands" issues, which are both > trivial to solve, either on the Org Cite or the Org Ref side. But then > again, it is perfectly fine if Org Cite doesn't provide that, as some > libraries can extend it if needed. I don't think it is the first time I have mentioned biblatex is not fully implemented, but I am not sure. I have mentioned things like \citenum somewhere, but it is not the main point. I know it is not that difficult to add support for LaTeX export in org-cite, e.g. [cite/num:]. I don't think it is all that easy to add additional backend support though, for something like [cite/num:] in HTML or other backends. No doubt, it is not impossible, if someone would just do it, and that might include extending citeproc too, or developing some pre-processing function to get a citation number, or something else. Whether cite/num or any other command exists is not the main point. What is the point is what mechanisms exist to support the addition, and the exports to various backends. Regarding that org-cite adds an abstraction layer, how else could one interpret this (from https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax) other than abstraction: [cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}? Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even, \citenum? I get it, you can define [cite/noauthor/year:] or even [cite/year:] or [cite/y:] and even [cite/citeyear:] to get the command in there, and something for each of those other ones. Maybe even the documented convention will change to some other potentially mnemonic form. I also get they are not all that common perhaps, except for a few people who use them, and maybe should be responsible for supporting it themselves, either by defcustom or their own library. This is just trading a proliferation of links for a proliferation of styles IMO, and it feels a lot like the XKCD standards issue https://xkcd.com/927/. As others have argued, it is just a bit of knowledge, maybe a UI can compensate to help you insert what you want, then know what it means later. It is my opinion that this will be a technical debt though. I am content to agree to disagree on this point. It might be a social problem, and I do not think it is trivial to solve. It is not just about having a syntax that works. I wrote and shared a whole set of processors for org-cite that did or tried to do all those things above. It was fine to use, but it was very difficult code to write for me. I don't personally want to support it in part because it was so difficult to write. I don't even want to support it for my own use at this time. This should not stop anyone who wants to do that themselves though. Maybe there is a cleaner approach I missed, or others may be better programmers, and/or have more time to figure this out. At this time, I do not have time to make for it. > On the other hand, there have been much activity on GitHub repositories, > i.e., out of this mailing list. It seems to me Org Ref project has been > trying to work around possible blockers in Org Cite project the whole > time without the latter knowing about them, and having an opportunity to > lift them. There is nothing nefarious happening here. That work happened in public, and with some interactions with people on the org-list including Bruce. Some motivation for org-cite stemmed from at least perceived limitations in org-ref, especially related to pre/post notes and CSL support. I think it is totally reasonable to learn if those were real limitations or not. >> Both projects have benefited from this discussion a lot. org has >> org-cite now, and org-ref now handles pre/post notes like org-cite does, >> it supports CSL much better, and is even a little more modular, lighter >> weight, and more easily integrated with other completion backends than >> ivy or helm. That should broadly be viewed as a win-win situation. > > But it is not. There are now two, more or less official, citations > syntax. Interoperability is the big loss. Features do not count; it is > perfectly fine to have different packages targeting different needs, as > long as they share the same syntax. > > Hopefully, at some point, we'll be able to build a list of blockers that > prevent Org Ref being built on top of Org Cite, and proceed. You can use the org-cite syntax with org-ref. If all one wants is a citation syntax for their org-files, and an occasional standard (cite/citet/citep) LaTeX export export, org-cite will probably meet their needs. As a few have reported, it works for them. If you have very large bibtex files, you may find that the basic processors don't have good performance yet, and you may need to configure org to use a performant set of processors for activation and insertion. Yes, this is being worked on in org, and you will need to use the latest version of org to benefit from it. If you have very specific needs in biblatex, you may find not every command has a corresponding org-cite implementation. You may have to add this to your own setup, or use a specific set of processors that provide it. You can do that, and still use it with org-ref. Maybe one day I will have time to try integrating org-cite with org-ref again. I have been stretched too thin by work for the past two years, and in the forseeable future to spend much time on org-cite. This is a me issue, not an org-cite issue. > > Regards, -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-27 17:00 ` John Kitchin @ 2022-03-27 23:17 ` Bruce D'Arcus 0 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-27 23:17 UTC (permalink / raw) To: John Kitchin; +Cc: Vikas Rawal, org-mode-email, Nicolas Goaziou On Sun, Mar 27, 2022 at 3:41 PM John Kitchin <jkitchin@andrew.cmu.edu> wrote: ... > Regarding that org-cite adds an abstraction layer, how else could one > interpret this (from > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax) > other than abstraction: > > [cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}? > > Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even, > \citenum? You mean why shouldn't we privilege natbib, as you have in org-ref? And let me turn the question around: how would you propose to translate those natbib-derived commands to biblatex, or CSL, so it works reliably across users and documents? The mapping has to happen someplace, after all. And from a UX POV, how well would that work for users who have no previous experience with natbib or even latex? ... > It might be a social problem, and I do not think it is trivial to solve. > It is not just about having a syntax that works. I wrote and shared a > whole set of processors for org-cite that did or tried to do all those > things above. It was fine to use, but it was very difficult code to > write for me. I don't personally want to support it in part because it > was so difficult to write. I think what Nicolas is asking is when you have time, to itemize the pain points that made development difficult for you, so that we might figure out how to improve them (perhaps new helper functions, etc.). As another data point, one of the things I've loved about org-cite is how easy I found it to develop pretty functional processors for citar with minimal code. Total LOC for citar is just under 2000, with just under 400 specific to org. But I'm deliberately developing a small, focused, modular, package. ... > Some motivation for org-cite stemmed from at least perceived limitations > in org-ref, especially related to pre/post notes and CSL support. I > think it is totally reasonable to learn if those were real limitations > or not. The org-cite citation syntax and model, I hope you would agree, is unambiguously better than natbib or the original org-ref syntax. It's simpler than biblatex in the sense of no difference between single and multicite citations, but can easily and losslessly map to and from either. Org-ref 3.0 adds essentially a copy of that syntax and model, with a trivial difference. To me, that's the biggest problem. Aside from users having incompatible documents, it forces other developers either to dedicate additional development and maintenance time to supporting both syntaxes, or to choose one. Pandoc only supports org-cite. In the case of citar, I have also decided to only support org-cite (though I leave the function to generate citations configurable, so it's easy enough for a user to configure this themselves; but I don't include this by default because I have other processor code that relies on parsed citations). Org-roam supports all three. It sounds like the biggest hold up was with reconciling the org-ref command model with more general approach of the oc style and variants. But as a first step, you could do as you originally planned to: simply use the same names for styles. If Nicolas were to allow the mapping in natbib to be handled via the defcustom, you could even do this without having to write and maintain your own export processor. And then you could save the other part (how to map those to other export processors) for another step, if and when you or your users need it or want it. Certainly that would address the most fundamental incompatibility. I guess to be direct: what value does the v3 syntax provide you, your users, or the org ecosystem in general? Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 13:19 ` Nicolas Goaziou 2022-03-20 14:08 ` Vikas Rawal 2022-03-21 0:31 ` John Kitchin @ 2022-03-21 14:40 ` Max Nikulin 2022-03-21 15:19 ` Bruce D'Arcus 2022-03-22 23:52 ` Nicolas Goaziou 2 siblings, 2 replies; 73+ messages in thread From: Max Nikulin @ 2022-03-21 14:40 UTC (permalink / raw) To: emacs-orgmode Disclaimer: I am neither org-cite no org-ref user. In the past I used LaTeX and BibTeX directly though, and it is a reason why I am reading the discussions. On 20/03/2022 20:19, Nicolas Goaziou wrote: > Vikas Rawal writes: > >> This obviously creates many problems including that two people using >> different citation systems cannot share org files. > > Indeed. >> >> What is the general view of the community about this? > > I don't know about the general view of the community, but, as a data > point, I find it very sad. Nicolas, I think, a part of problem is that you are not an org-cite user. The packages require some *polishing*, but it have to be *user-driven*. Even if the feature were perfect, it would face some tension from people who already have a working solution. A bit of routine work will alleviate some user issues: - add missed styles - improve documentation, e.g. to make backend choice more conscious. Another point is more serious. Besides citations there are internal cross-references. Org supports them but only in a rudimentary form. Actually cross-references are similar to citations in the sense that they can have style, prefixes and suffixes, and their appearance depends on target properties. Another feature is grouping. However cross-references should not be handled by citation backends, they require different handlers. Unfortunately there is no way to define custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". I can not judge if uniform UI issues are really severe and if it would be convenient if depending on prefix argument either org-cite or org-ref command would be called for a citation or for a reference. Actually "[cite:...]" construct is a kind of link with additional flexibility missed for regular links. Anything besides target and description requires some workarounds. Usual approach is proliferation of link types. E.g. inline source blocks allows almost arbitrary extra parameters. Citation syntax is rather domain specific, it allows more than regular links, but for convenience the set of properties is fixed: style, prefixes, locators, suffixes. It is impossible to add extra one. To assign additional properties, info "(org) Links in HTML export" https://orgmode.org/manual/Links-in-HTML-export.html recommends usage of "#+ATTR_HTML", but such technique has several issues: - attributes becomes specific to the export backend - the same attributes are added to the enclosing paragraph https://linevi.ch/en/org-link-extra-attrs.html - a paragraph may have more than one link. It is possible to use link target similar to form values encoded into URI, but it hardly can be considered as convenient for editing. Custom citation types may alleviate the issue with cross-references. It would be great to have more flexible links with arbitrary properties (and it would allow to consider citations and cross-references as special cases of links), but it does not fit into the Org syntax. P.S. John has a valid complain but it hardly relates to the "cite vs. cross-reference" topic. When some package is not loaded and link type is undefined then the link becomes a fuzzy one leading to user confusion. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 14:40 ` Max Nikulin @ 2022-03-21 15:19 ` Bruce D'Arcus 2022-03-21 17:00 ` John Kitchin 2022-03-22 14:41 ` Max Nikulin 2022-03-22 23:52 ` Nicolas Goaziou 1 sibling, 2 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-21 15:19 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin <manikulin@gmail.com> wrote: ... > A bit of routine work will alleviate some user issues: > - add missed styles The initial list of style-command mappings was pretty comprehensive, but we left out some of the more obscure biblatex commands because unsure if they were needed, or how best to add them (conceptually there's a mix of different kinds of commands in biblatex, which are hard to fit into a more general style system, for example). Since then: - people have occasionally asked to add new mappings, and Nicolas has added them - he's also added the styles defcustoms for biblatex, so users can do this themselves In short, I think we're good on this actually. > - improve documentation, e.g. to make backend choice more conscious. This is the bigger user-facing issue that could use attention. > Another point is more serious. Besides citations there are internal > cross-references. Org supports them but only in a rudimentary form. Indeed, the question of how to better support cross-references in org is an important one. I don't really use them much, and so am still unsure if this could be addressed with incremental improvements in existing org link support, or if it would require more significant enhancements. Perhaps we need the community to itemize what the gaps and limitations are there? Bruce > Actually cross-references are similar to citations in the sense that > they can have style, prefixes and suffixes, and their appearance depends > on target properties. Another feature is grouping. However > cross-references should not be handled by citation backends, they > require different handlers. Unfortunately there is no way to define > custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". > > I can not judge if uniform UI issues are really severe and if it would > be convenient if depending on prefix argument either org-cite or org-ref > command would be called for a citation or for a reference. > > Actually "[cite:...]" construct is a kind of link with additional > flexibility missed for regular links. Anything besides target and > description requires some workarounds. Usual approach is proliferation > of link types. E.g. inline source blocks allows almost arbitrary extra > parameters. Citation syntax is rather domain specific, it allows more > than regular links, but for convenience the set of properties is fixed: > style, prefixes, locators, suffixes. It is impossible to add extra one. > > To assign additional properties, info "(org) Links in HTML export" > https://orgmode.org/manual/Links-in-HTML-export.html recommends usage of > "#+ATTR_HTML", but such technique has several issues: > - attributes becomes specific to the export backend > - the same attributes are added to the enclosing paragraph > https://linevi.ch/en/org-link-extra-attrs.html > - a paragraph may have more than one link. > It is possible to use link target similar to form values encoded into > URI, but it hardly can be considered as convenient for editing. > > Custom citation types may alleviate the issue with cross-references. It > would be great to have more flexible links with arbitrary properties > (and it would allow to consider citations and cross-references as > special cases of links), but it does not fit into the Org syntax. > > P.S. John has a valid complain but it hardly relates to the "cite vs. > cross-reference" topic. When some package is not loaded and link type is > undefined then the link becomes a fuzzy one leading to user confusion. > > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 15:19 ` Bruce D'Arcus @ 2022-03-21 17:00 ` John Kitchin 2022-03-25 15:21 ` Max Nikulin 2022-03-22 14:41 ` Max Nikulin 1 sibling, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-21 17:00 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: Max Nikulin, emacs-orgmode "Bruce D'Arcus" <bdarcus@gmail.com> writes: > On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin <manikulin@gmail.com> wrote: > > ... > >> A bit of routine work will alleviate some user issues: >> - add missed styles > > The initial list of style-command mappings was pretty comprehensive, > but we left out some of the more obscure biblatex commands because > unsure if they were needed, or how best to add them (conceptually > there's a mix of different kinds of commands in biblatex, which are > hard to fit into a more general style system, for example). > > Since then: > > - people have occasionally asked to add new mappings, and Nicolas has added them > - he's also added the styles defcustoms for biblatex, so users can do > this themselves > > In short, I think we're good on this actually. > >> - improve documentation, e.g. to make backend choice more conscious. > > This is the bigger user-facing issue that could use attention. > >> Another point is more serious. Besides citations there are internal >> cross-references. Org supports them but only in a rudimentary form. > > Indeed, the question of how to better support cross-references in org > is an important one. > > I don't really use them much, and so am still unsure if this could be > addressed with incremental improvements in existing org link support, > or if it would require more significant enhancements. No incremental improvement is required IMO, regular links are sufficient. org-ref has handled these with regular links from the beginning. It even has an org-ref-refproc now for non-LaTeX exports that has some support for things like sorting, grouping and cleveref. You can find an example org file at https://github.com/jkitchin/org-ref/blob/master/examples/refproc.org, and see it in action at https://www.youtube.com/watch?v=rRR-5NSpKyE the video has some rough spots, but you can get the idea. You can support all kinds of things in these links (for example, I now support pre/post note text in the cite link paths), really anything you want to parse out of the path. > > Perhaps we need the community to itemize what the gaps and limitations > are there? > > > Bruce > >> Actually cross-references are similar to citations in the sense that >> they can have style, prefixes and suffixes, and their appearance depends >> on target properties. Another feature is grouping. However >> cross-references should not be handled by citation backends, they >> require different handlers. Unfortunately there is no way to define >> custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". >> >> I can not judge if uniform UI issues are really severe and if it would >> be convenient if depending on prefix argument either org-cite or org-ref >> command would be called for a citation or for a reference. >> >> Actually "[cite:...]" construct is a kind of link with additional >> flexibility missed for regular links. Anything besides target and >> description requires some workarounds. Usual approach is proliferation >> of link types. E.g. inline source blocks allows almost arbitrary extra >> parameters. Citation syntax is rather domain specific, it allows more >> than regular links, but for convenience the set of properties is fixed: >> style, prefixes, locators, suffixes. It is impossible to add extra one. >> >> To assign additional properties, info "(org) Links in HTML export" >> https://orgmode.org/manual/Links-in-HTML-export.html recommends usage of >> "#+ATTR_HTML", but such technique has several issues: >> - attributes becomes specific to the export backend >> - the same attributes are added to the enclosing paragraph >> https://linevi.ch/en/org-link-extra-attrs.html >> - a paragraph may have more than one link. >> It is possible to use link target similar to form values encoded into >> URI, but it hardly can be considered as convenient for editing. >> >> Custom citation types may alleviate the issue with cross-references. It >> would be great to have more flexible links with arbitrary properties >> (and it would allow to consider citations and cross-references as >> special cases of links), but it does not fit into the Org syntax. >> >> P.S. John has a valid complain but it hardly relates to the "cite vs. >> cross-reference" topic. When some package is not loaded and link type is >> undefined then the link becomes a fuzzy one leading to user confusion. >> >> -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 17:00 ` John Kitchin @ 2022-03-25 15:21 ` Max Nikulin 0 siblings, 0 replies; 73+ messages in thread From: Max Nikulin @ 2022-03-25 15:21 UTC (permalink / raw) To: emacs-orgmode On 22/03/2022 00:00, John Kitchin wrote: > "Bruce D'Arcus" writes: > >> Indeed, the question of how to better support cross-references in org >> is an important one. >> >> I don't really use them much, and so am still unsure if this could be >> addressed with incremental improvements in existing org link support, >> or if it would require more significant enhancements. > > No incremental improvement is required IMO, regular links are > sufficient. org-ref has handled these with regular links from the > beginning. It even has an org-ref-refproc now for non-LaTeX exports that > has some support for things like sorting, grouping and cleveref. You can > find an example org file at > https://github.com/jkitchin/org-ref/blob/master/examples/refproc.org, Interesting package. At first I thought you use keywords around links as implicit markup, but later I realized that this file is example of export, not the original source file (with different link types). > and see it in action at https://www.youtube.com/watch?v=rRR-5NSpKyE the > video has some rough spots, but you can get the idea. > > You can support all kinds of things in these links (for example, I now > support pre/post note text in the cite link paths), really anything you > want to parse out of the path. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 15:19 ` Bruce D'Arcus 2022-03-21 17:00 ` John Kitchin @ 2022-03-22 14:41 ` Max Nikulin 2022-03-22 17:20 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-22 14:41 UTC (permalink / raw) To: emacs-orgmode On 21/03/2022 22:19, Bruce D'Arcus wrote: > On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin wrote: > >> A bit of routine work will alleviate some user issues: >> - add missed styles > > The initial list of style-command mappings was pretty comprehensive, > but we left out some of the more obscure biblatex commands because > unsure if they were needed, or how best to add them (conceptually > there's a mix of different kinds of commands in biblatex, which are > hard to fit into a more general style system, for example). > > Since then: > > - people have occasionally asked to add new mappings, and Nicolas has added them > - he's also added the styles defcustoms for biblatex, so users can do > this themselves > > In short, I think we're good on this actually. John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu: > I don't know the equivalent of \citenum in CSL. From my point of view it may be a reason to add a new style to defaults. It is important whether a tool works out of the box. Custom variables make a document less portable unless they are specified as file-local ones. I think, the goal may be formulated as "John can not say the following any more" (at least in respect to citations leaving aside cross-references): > I simply cannot > compromise on the capability org-ref provides me, or wait for an > alternative complete solution in org-mode. On the other hand I do not consider the following argument as a strong one > I do not like the abstraction away from LaTeX cite commands in org-cite. > This is an example of a compromise between LaTeX and CSL. despite I believe that convenience and habits are important. Mapping of styles to commands is just a piece of knowledge. I have no particular opinion if enough efforts should be invested from both sides to allow mixing on both citation syntax constructs (org-cite and org-ref) in the same document. Bruce, you made a lot for support of CSL in org-cite, so I will stressed another direction of feature comparison since Bib(La)TeX users should feel themselves first-class citizens. The choice between org-ref and org-cite, when the former can do its job, should be matter of taste and personal preferences unrelated to technical limitations. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-22 14:41 ` Max Nikulin @ 2022-03-22 17:20 ` Bruce D'Arcus 2022-03-23 12:44 ` Max Nikulin 0 siblings, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-22 17:20 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin <manikulin@gmail.com> wrote: > > On 21/03/2022 22:19, Bruce D'Arcus wrote: > > On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin wrote: > > > >> A bit of routine work will alleviate some user issues: > >> - add missed styles > > > > The initial list of style-command mappings was pretty comprehensive, > > but we left out some of the more obscure biblatex commands because > > unsure if they were needed, or how best to add them (conceptually > > there's a mix of different kinds of commands in biblatex, which are > > hard to fit into a more general style system, for example). > > > > Since then: > > > > - people have occasionally asked to add new mappings, and Nicolas has added them > > - he's also added the styles defcustoms for biblatex, so users can do > > this themselves > > > > In short, I think we're good on this actually. > > John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. > https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu: > > > I don't know the equivalent of \citenum in CSL. Right; so John or someone else should send a message to the list requesting it specifically? That's how we've done it so far anyway. Not sure what the practical alternative is. I will say that much of this discussion is not about org-cite per se, but rather implementation decisions in the specific bundled processors. I fear these conversations get hard to track if we aren't precise about what we're talking about; citation syntax, included processor functionality or style mappings, documentation, etc. > From my point of view it may be a reason to add a new style to > defaults. It is important whether a tool works out of the box. But the question here becomes "works for whom?" Citations practices vary a fair bit by field. Primarily LaTeX/natbib users like John and other science folks, biblatex users primarily coming from the humanities as near as I can tell? Or people coming from markdown and pandoc (which has an excellent citation system that clearly inspired org-cite) and needing Word-ready documents for journals etc? The style system in the bundled processors is designed to work for all of them, and not privilege one or another. It does this by creating a new, more general, org-cite style and variant system, which then maps to different targets. That approach has obvious advantages: citations are (mostly) decoupled from particular export processors. One can write a document with these styles, and get PDF citation and bibliographic output via biblatex, for example, similar to the HTML or ODT output from the CSL export processor. And that also has advantages beyond org. For example, pandoc recently added support for org-cite, and that includes mapping between the two style/command systems. So in theory you could convert an org file to docx, letting pandoc process the citations along the way, and the result would more than acceptable. > Custom variables make a document less portable unless they are specified as > file-local ones. Indeed! Or more specifically here, it ties the citations to the export processor. But maybe for some or many people that's perfectly fine. One possible idea to consider is to allow two systems in each of LaTeX-oriented processors: what we might call a default "org-cite" one, and an optional "literal" one. So if you only use oc-natbib, and you want the natbib commands directly, you might change a variable to get that. I really don't know if that's a good idea or not, but I raise it to emphasize there's a lot of flexibility with the org-cite design, and so it's just a question of how we make use of it. > I think, the goal may be formulated as "John can not > say the following any more" (at least in respect to citations leaving > aside cross-references): > > > I simply cannot > > compromise on the capability org-ref provides me, or wait for an > > alternative complete solution in org-mode. I don't really see why these are the two choices. > On the other hand I do not consider the following argument as a strong one > > > I do not like the abstraction away from LaTeX cite commands in org-cite. > > This is an example of a compromise between LaTeX and CSL. > > despite I believe that convenience and habits are important. Mapping of > styles to commands is just a piece of knowledge. Yes. > I have no particular opinion if enough efforts should be invested from > both sides to allow mixing on both citation syntax constructs (org-cite > and org-ref) in the same document. Bruce, you made a lot for support of > CSL in org-cite, so I will stressed another direction of feature > comparison since Bib(La)TeX users should feel themselves first-class > citizens. Absolutely! In fact, Denis Meier, who has extensive biblatex knowledge, helped a lot with the initial mapping there, and some other biblatex users have contributed feedback along the way. Bruce > The choice between org-ref and org-cite, when the former can do its job, > should be matter of taste and personal preferences unrelated to > technical limitations. > > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-22 17:20 ` Bruce D'Arcus @ 2022-03-23 12:44 ` Max Nikulin 2022-03-23 14:39 ` Bruce D'Arcus 0 siblings, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-23 12:44 UTC (permalink / raw) To: emacs-orgmode On 23/03/2022 00:20, Bruce D'Arcus wrote: > On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin wrote: >> >> John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. >> https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu: >> >>> I don't know the equivalent of \citenum in CSL. > > Right; so John or someone else should send a message to the list > requesting it specifically? From my point of view he has already requested support of \citenum by that message. I am taking into account that he is the developer org-ref and he is happy with this package. John made a lot to adopt org-cite syntax to ensure feature parity. Bruce, you should know it better than me since you participated in discussions while I am merely and observer. John does not really need \citenum namely in org-cite since his tool is org-ref, but his words may affect perception of org-cite. I have an impression that the ball is on the side of the org-cite, and next steps may be to ask for real documents (e.g. open access papers) that are prepared with such format and to discuss most suitable style for CSL. > One possible idea to consider is to allow two systems in each of > LaTeX-oriented processors: what we might call a default "org-cite" > one, and an optional "literal" one. So if you only use oc-natbib, and > you want the natbib commands directly, you might change a variable to > get that. Maybe I will share my idea in response to the message from Nicolas https://list.orgmode.org/871qytlf49.fsf@nicolasgoaziou.fr Wed, 23 Mar 2022 00:52:22 +0100, this thread. Since John explicitly confirmed that org-ref for cross-references may be combined with org-cite for citations, it may be great that Org has 2 independent implementations for citations. When a user meets some corner case their has an opportunity to try another package. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 12:44 ` Max Nikulin @ 2022-03-23 14:39 ` Bruce D'Arcus 2022-03-23 15:26 ` Eric S Fraga ` (2 more replies) 0 siblings, 3 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-23 14:39 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email On Wed, Mar 23, 2022 at 8:52 AM Max Nikulin <manikulin@gmail.com> wrote: > > On 23/03/2022 00:20, Bruce D'Arcus wrote: > > On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin wrote: > >> > >> John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400. > >> https://list.orgmode.org/m2sfrc149c.fsf@andrew.cmu.edu: > >> > >>> I don't know the equivalent of \citenum in CSL. > > > > Right; so John or someone else should send a message to the list > > requesting it specifically? > > From my point of view he has already requested support of \citenum by > that message. I just mean here, in general. If people complain about missing mappings or performance issues silently, or elsewhere, without ever raising them on the list, then it's hard to address them. > I have an impression that the ball is on the side of the org-cite, and > next steps may be to ask for real documents (e.g. open access papers) > that are prepared with such format and to discuss most suitable style > for CSL. Suffice to say I disagree :-) Sorry if the below gets wordy, but it's complicated. Finding and analyzing existing papers again raises the question of which ones; citation practices look VERY different in chemistry than in art history or sociology. It also raises the question of who will do this work, and whether it's the most efficient use of their time. And finally, your suggestion seems to assume we didn't put a lot of research and thought into the existing mappings. Have you actually looked at the table of existing mappings? See table 1 here (which it seems we might want to add to the manual?): https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax Those mappings merely generalize existing systems (bibtex, natbib, biblatex, csl) used by millions of users (if you include Zotero, etc.), and already incorporate the feedback of those users. So the styles included now ARE a sound starting point, that we can iterate based on feedback. We can and should add "number" and "entry" (for "bibentry" and biblatex "fullcite") styles to those mappings, however, at least for natbib and biblatex. But the first is one of those lower-level types of commands, and probably why it's not there now. On that last point, I do want people to understand that there are places where you can't easily generalize across those systems, because the logic of them varies in places. Biblatex, most notably, has IIRC more than 50 commands, which also vary by style used. And some of those commands (like autocite) are high-level and appropriate for this sort of mapping, and others (like footcite) are low-level, and probably not. Adding every option may make a small number of power users happy, but at the expense of raising complexity for others. Which is why the new defcustom is a good compromise. CSL is different here than the LaTeX alternatives, as Andras can just add support for some feature to citeproc-el, and add a style for it to oc-csl. But CSL also has a different design than the LaTeX options, and so will always be simpler. For example, in effect, all citations in a CSL systems work like biblatex's "auto" commands. If one uses a note-based citation style, citations get automatically footnoted, for example, and so one can seamlessly change between note-based and other kinds of styles, without having to modify the document source. So missing mappings aren't necessarily an oversight; it might just be that how to implement them was unclear, or whether users would need or want them. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 14:39 ` Bruce D'Arcus @ 2022-03-23 15:26 ` Eric S Fraga 2022-03-23 17:17 ` Max Nikulin 2022-03-26 19:08 ` M. Pger 2 siblings, 0 replies; 73+ messages in thread From: Eric S Fraga @ 2022-03-23 15:26 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: Max Nikulin, org-mode-email On Wednesday, 23 Mar 2022 at 10:39, Bruce D'Arcus wrote: > Those mappings merely generalize existing systems (bibtex, natbib, > biblatex, csl) used by millions of users (if you include Zotero, > etc.), and already incorporate the feedback of those users. I just want to jump in to say that the new cite functionality works very well, at least for this LaTeX user. I'm writing a book at the moment using [cite:...]. No issues encountered and everything I need to do is there, out-of-the-box! My thanks to all that put in so much effort into this. -- : Eric S Fraga, with org release_9.5.2-407-gc9c0b9 in Emacs 29.0.50 ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 14:39 ` Bruce D'Arcus 2022-03-23 15:26 ` Eric S Fraga @ 2022-03-23 17:17 ` Max Nikulin 2022-03-23 22:50 ` Bruce D'Arcus 2022-03-26 19:08 ` M. Pger 2 siblings, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-23 17:17 UTC (permalink / raw) To: emacs-orgmode On 23/03/2022 21:39, Bruce D'Arcus wrote: > > Finding and analyzing existing papers again raises the question of > which ones; citation practices look VERY different in chemistry than > in art history or sociology. It also raises the question of who will > do this work, and whether it's the most efficient use of their time. > And finally, your suggestion seems to assume we didn't put a lot of > research and thought into the existing mappings. I think that a working solution (Eric just have confirmed it) is a great result. I am aware that even in different areas of physics citation traditions vary. I am not trying to dispute that you invest a lot of efforts. I just consider as normal when some polishing is required after the initial release. Really exhaustive research is usually prohibitively expensive. I had a hope that it was clear from the beginning that I considered a missed style as a minor issue. My point was that it should not be unconsciously ignored. Since the message was long enough, this particular complain may remain unnoticed. I can not say that I fully agree with your decision, but I respect it. I had no intention to upset you and I beg your pardon if it happened. > Have you actually looked at the table of existing mappings? See table > 1 here (which it seems we might want to add to the manual?): > > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax I have seen this post and I have even checked the org-cite code that the example from John's message is not covered by the existing mapping. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 17:17 ` Max Nikulin @ 2022-03-23 22:50 ` Bruce D'Arcus 0 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-23 22:50 UTC (permalink / raw) To: Max Nikulin; +Cc: org-mode-email On Wed, Mar 23, 2022 at 1:19 PM Max Nikulin <manikulin@gmail.com> wrote: > My point was that it should not be unconsciously ignored. Since the > message was long enough, this particular complain may remain unnoticed. > I can not say that I fully agree with your decision, but I respect it. I > had no intention to upset you and I beg your pardon if it happened. No personal offense taken. I was just a bit frustrated with the direction this discussion seemed to be going. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 14:39 ` Bruce D'Arcus 2022-03-23 15:26 ` Eric S Fraga 2022-03-23 17:17 ` Max Nikulin @ 2022-03-26 19:08 ` M. Pger 2 siblings, 0 replies; 73+ messages in thread From: M. Pger @ 2022-03-26 19:08 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: org-mode-email On Wednesday, March 23rd, 2022 at 3:39 PM, Bruce D'Arcus <bdarcus@gmail.com> wrote: > Have you actually looked at the table of existing mappings? See table 1 here (which it seems we might want to add to the manual?): > > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax Sorry for the late reaction to this. As an user I completely agree. IMO, having these mappings in the doc could clearly convince some org-ref users to give a try to org-cite. Some information about the possibility of using .bst bibliography style files would also be nice. Finally, some info about cross-ref could also be useful, so that users easily get an idea of what would imply a switch from org-ref to org-cite. For what it's worth, I think that Vanilla org becomes more and more amazing, thanks for that. Best, MP ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-21 14:40 ` Max Nikulin 2022-03-21 15:19 ` Bruce D'Arcus @ 2022-03-22 23:52 ` Nicolas Goaziou 2022-03-23 16:30 ` Max Nikulin 1 sibling, 1 reply; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-22 23:52 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode Hello, Max Nikulin <manikulin@gmail.com> writes: > Nicolas, I think, a part of problem is that you are not an org-cite > user. The packages require some *polishing*, but it have to be > *user-driven*. Just to be clear: the development was _user-driven_ from the start. I read years of discussions about citation, suggested a syntax, waited for input, amended the syntax… Then I did the same for the whole library, implementing proof of concepts, waiting for feedback, etc. > Another point is more serious. Besides citations there are internal > cross-references. Org supports them but only in a rudimentary form. > Actually cross-references are similar to citations in the sense that > they can have style, prefixes and suffixes, and their appearance > depends on target properties. Another feature is grouping. However > cross-references should not be handled by citation backends, they > require different handlers. Unfortunately there is no way to define > custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". There is too little information here for me to understand what cross-references (or grouping) are, or why they would require different handlers. In any case, if such thing are deemed necessary in Org Cite, one can always start a new thread. The goal of Org Cite is not to do everything, however. Its raison d'être is to provide building blocks around citations that external packages can use and extend. Therefore cross-references might belong to an extension instead. > To assign additional properties, info "(org) Links in HTML export" > https://orgmode.org/manual/Links-in-HTML-export.html recommends usage > of "#+ATTR_HTML", but such technique has several issues: This is a different issue. Citations are not link, and have a fixed set of properties. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-22 23:52 ` Nicolas Goaziou @ 2022-03-23 16:30 ` Max Nikulin 2022-03-23 23:04 ` Nicolas Goaziou 0 siblings, 1 reply; 73+ messages in thread From: Max Nikulin @ 2022-03-23 16:30 UTC (permalink / raw) To: emacs-orgmode On 23/03/2022 06:52, Nicolas Goaziou wrote: > Max Nikulin writes: > >> Another point is more serious. Besides citations there are internal >> cross-references. Org supports them but only in a rudimentary form. >> Actually cross-references are similar to citations in the sense that >> they can have style, prefixes and suffixes, and their appearance >> depends on target properties. Another feature is grouping. However >> cross-references should not be handled by citation backends, they >> require different handlers. Unfortunately there is no way to define >> custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]". > > There is too little information here for me to understand what > cross-references (or grouping) are, or why they would require different > handlers. In any case, if such thing are deemed necessary in Org Cite, > one can always start a new thread. Frankly speaking, for me it was enough just to use available LaTeX commands. I never thought about corner cases, but feature request requires such analysis. By grouping I mean the existing feature of org-cite: several keys with common prefix and suffix, items within such group may be sorted. Citation handlers obtain information necessary for formatting from a bibliography database. For cross-references such additional info should be pulled from other parts of the same document. There is no point to mix the code for both cases withing the same handler, it is better to combine independent handlers and to allow each type to have alternative implementations. I agree with those who say that cross-references and citations are rather independent when implementation is considered. Judging from the description, org-ref (with org-refproc as an optional addition) does the job taking advantage of multiple custom link types for the same actual standard internal link target. Sphinx has a feature that is an interesting border case between internal cross-references and external links (almost citations). Readthedocs sites host mapping tables for python packages. It is possible to fetch a file that associates e.g. anchors and section names. In generated docs anchors (similar to custom_id values) are replaced by section names and link target points to particular location in the external file. Nicolas, concerning a new thread, I have an impression that you are busy with over activities since you are participating in discussions not so frequently. So I am unsure at which moment it is appropriate to raise such question that otherwise may just be buried in the list archive. Sometimes I am in doubts if an idea deserves a dedicated thread or initial feedback may be received from a related rather generic topic. >> To assign additional properties, info "(org) Links in HTML export" >> https://orgmode.org/manual/Links-in-HTML-export.html recommends usage >> of "#+ATTR_HTML", but such technique has several issues: > > This is a different issue. Citations are not link, and have a fixed set > of properties. Outside of Org, citations are links. Along with cross-references they worked before appearance of the web. To be recognizable on paper they may have a bit special form. An author may choose what will appear in the text: page number, section number, or section text. For HTML links page number option is not meaningful. Within Org citations look like generalized links: a citation may have multiple targets, they have more properties: prefixes, suffixes (including common ones), style, and locators. However there is no description. Internal links in Org (built-in ones without additional packages) are more limited than full-fledged cross-references. When exported they have the same form. I consider fixed set of properties as a problem. At first I tried to draw attention to additional link attributes. Then I realized that block-level elements may have arbitrary attributes. It would be a great feature to have some syntax construct to assign attributes for particular inline object. People actively use link types as an additional property, but it gives just one degree of freedom. Sometimes more parameters are required and abusing link types means combinatorics explosion. Encoding extra properties inside link targets sometimes is enough (as in org-ref) but some times it is inconvenient. Advantages of arbitrary attributes for inline objects for links: - Within the same paragraph only part of links may be marked as "nofollow noopener" during exporting to HTML. - Each link may have its own title. - Link types similar to org-ref cross-references ("pageref", "nameref", "eqref", etc.) becomes an extra attribute while link type and link target remains the standard one for Org (heading text, custom id, name attribute). For citations some values may be passed to specific citation backend overriding default value derived from style. It should be similar to babel header arguments specific to particular language or export options for particular format. Leaving groups aside, attributes for inline objects may be a convenient extension. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 16:30 ` Max Nikulin @ 2022-03-23 23:04 ` Nicolas Goaziou 2022-03-25 16:30 ` Max Nikulin 2022-03-27 15:38 ` John Kitchin 0 siblings, 2 replies; 73+ messages in thread From: Nicolas Goaziou @ 2022-03-23 23:04 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode Hello, Max Nikulin <manikulin@gmail.com> writes: > Nicolas, concerning a new thread, I have an impression that you are > busy with over activities since you are participating in discussions > not so frequently. So I am unsure at which moment it is appropriate to > raise such question that otherwise may just be buried in the list > archive. I don't see how my presence (or not) on the list relates to this. If there's an idea worth a discussion, it should not be buried within a thread. > Outside of Org, citations are links. But we're on an Org mailing list so… > I consider fixed set of properties as a problem. I don't think it is a problem for citations. > At first I tried to draw attention to additional link attributes. I think link attributes were discussed a couple of times on this ML already. Nothing was implemented tho. I'm not convinced Org should generalize this to any inline object, either, mainly because it sounds messy. Of course, if you have an idea on the subject, please share it. In any case, this is another topic, neither related to citations nor to cross-references. > For citations some values may be passed to specific citation backend > overriding default value derived from style. In that situation, you can define a new style specific to the citation back-end. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 23:04 ` Nicolas Goaziou @ 2022-03-25 16:30 ` Max Nikulin 2022-03-27 15:38 ` John Kitchin 1 sibling, 0 replies; 73+ messages in thread From: Max Nikulin @ 2022-03-25 16:30 UTC (permalink / raw) To: emacs-orgmode On 24/03/2022 06:04, Nicolas Goaziou wrote: > Max Nikulin writes: > >> Nicolas, concerning a new thread, I have an impression that you are >> busy with over activities since you are participating in discussions >> not so frequently. So I am unsure at which moment it is appropriate to >> raise such question that otherwise may just be buried in the list >> archive. > > I don't see how my presence (or not) on the list relates to this. If > there's an idea worth a discussion, it should not be buried within > a thread. It was you who implemented org-cite and org-element parser. John chose a direct and practical way. He defined multiple link types and got the working solution. A more elegant approach would require some extension of syntax, so your opinion is really important. For cross-references it might be "[ref/style...]" in additional to "[cite/style...]" or attributes specific to links. >> Outside of Org, citations are links. > > But we're on an Org mailing list so… In respect to citations and cross-references Org is a tool to prepare documents for "outside of Org". > I think link attributes were discussed a couple of times on this ML > already. Nothing was implemented tho. I do not remember such thread during last couple of years. I will try to search deeper and maybe will start another thread. > I'm not convinced Org should generalize this to any inline object, > either, mainly because it sounds messy. Of course, if you have an > idea on the subject, please share it. > > In any case, this is another topic, neither related to citations nor to > cross-references. "pageref", "nameref", "eqref", "autoref" (see https://github.com/jkitchin/org-ref/blob/master/org-ref.org) may be values of the style attribute of a "[[name]]" link instead of link type as it is done in org-ref. >> For citations some values may be passed to specific citation backend >> overriding default value derived from style. > > In that situation, you can define a new style specific to the citation > back-end. Sometimes an ad-hoc adjustment at the particular place is more convenient than even file-local property. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-23 23:04 ` Nicolas Goaziou 2022-03-25 16:30 ` Max Nikulin @ 2022-03-27 15:38 ` John Kitchin 2022-03-27 23:18 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: John Kitchin @ 2022-03-27 15:38 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Max Nikulin, emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Max Nikulin <manikulin@gmail.com> writes: > >> Nicolas, concerning a new thread, I have an impression that you are >> busy with over activities since you are participating in discussions >> not so frequently. So I am unsure at which moment it is appropriate to >> raise such question that otherwise may just be buried in the list >> archive. > > I don't see how my presence (or not) on the list relates to this. If > there's an idea worth a discussion, it should not be buried within > a thread. > >> Outside of Org, citations are links. > > But we're on an Org mailing list so… > >> I consider fixed set of properties as a problem. > > I don't think it is a problem for citations. > >> At first I tried to draw attention to additional link attributes. > > I think link attributes were discussed a couple of times on this ML > already. Nothing was implemented tho. I don't think any further implementation outside the existing link framework is required to do this. The only limitations of the current framework are (I think) it is limited to a single line (i.e. not multiline), and it would be difficult to have nested links. Otherwise, you can put most things in the path, and then parse it as you see fit. I think it would be interesting to couple this with a recursive descent parser one day, and some DSL perhaps. There is a prototype of this idea at https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ I wouldn't claim it is the best way to do that, or the right thing to do. scimax-editmarks is a step further (https://github.com/jkitchin/scimax/blob/master/scimax-editmarks.org) that doesn't use org-links or any org-syntax for something more like an inline object. It mostly addresses the multiline issue, but it also doesn't support nested objects, mostly because of my limited knowledge of recursive parsing. I would not advocate for putting this in org either though. If you are interested in this kind of thing, you might find https://www.emacswiki.org/emacs/linkd.el interesting too. It leverages an S-expression approach, which makes the parsing and nesting more straightforward. I know this is a little off-track of the original thread, but I agree with Nicolas that it does not seem necessary at this point to add this into org. > > I'm not convinced Org should generalize this to any inline object, > either, mainly because it sounds messy. Of course, if you have an > idea on the subject, please share it. > > In any case, this is another topic, neither related to citations nor to > cross-references. > >> For citations some values may be passed to specific citation backend >> overriding default value derived from style. > > In that situation, you can define a new style specific to the citation > back-end. > > Regards, -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-27 15:38 ` John Kitchin @ 2022-03-27 23:18 ` Bruce D'Arcus 0 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-27 23:18 UTC (permalink / raw) To: John Kitchin; +Cc: Max Nikulin, org-mode-email, Nicolas Goaziou On Sun, Mar 27, 2022 at 12:00 PM John Kitchin <jkitchin@andrew.cmu.edu> wrote: > > > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > > > Hello, > > > > Max Nikulin <manikulin@gmail.com> writes: > > > >> Nicolas, concerning a new thread, I have an impression that you are > >> busy with over activities since you are participating in discussions > >> not so frequently. So I am unsure at which moment it is appropriate to > >> raise such question that otherwise may just be buried in the list > >> archive. > > > > I don't see how my presence (or not) on the list relates to this. If > > there's an idea worth a discussion, it should not be buried within > > a thread. > > > >> Outside of Org, citations are links. > > > > But we're on an Org mailing list so… > > > >> I consider fixed set of properties as a problem. > > > > I don't think it is a problem for citations. > > > >> At first I tried to draw attention to additional link attributes. > > > > I think link attributes were discussed a couple of times on this ML > > already. Nothing was implemented tho. > > I don't think any further implementation outside the existing link > framework is required to do this. The only limitations of the current > framework are (I think) it is limited to a single line (i.e. not > multiline), and it would be difficult to have nested links. I'm glad to hear that. FWIW, by asking earlier about possible "incremental improvements" for cross-references, I was including within that possible implementation improvements: new helper functions or interactive commands, standard link types, documentation, etc. I note, for example, that currently local links do export as LaTeX cross-references, and that if you use cleverref, the results seem pretty reasonable from my non-expert POV. But it's not easy from a UX POV to create those cross-references, particularly with a longer, more complex, document. And in my coding experiments [1] awhile back, it wasn't that straightforward to create a UI to make that easier, mostly because it wasn't unambiguous how to consistently parse common targets (sections, figures, tables, equations) [2]. Bruce [1] https://github.com/bdarcus/oxr [2] https://github.com/bdarcus/oxr/blob/28ec1345e9c8d659afea6c8569479b667697eaa2/oxr.el#L108-L128 > Otherwise, you can put most things in the path, and then parse it as you > see fit. I think it would be interesting to couple this with a recursive > descent parser one day, and some DSL perhaps. > > There is a prototype of this idea at > https://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/ > > I wouldn't claim it is the best way to do that, or the right thing to > do. > > scimax-editmarks is a step further > (https://github.com/jkitchin/scimax/blob/master/scimax-editmarks.org) > that doesn't use org-links or any org-syntax for something more like an > inline object. It mostly addresses the multiline issue, but it also > doesn't support nested objects, mostly because of my limited knowledge > of recursive parsing. I would not advocate for putting this in org > either though. > > If you are interested in this kind of thing, you might find > https://www.emacswiki.org/emacs/linkd.el interesting too. It leverages > an S-expression approach, which makes the parsing and nesting more > straightforward. > > I know this is a little off-track of the original thread, but I agree > with Nicolas that it does not seem necessary at this point to add this > into org. > > > > > I'm not convinced Org should generalize this to any inline object, > > either, mainly because it sounds messy. Of course, if you have an > > idea on the subject, please share it. > > > > In any case, this is another topic, neither related to citations nor to > > cross-references. > > > >> For citations some values may be passed to specific citation backend > >> overriding default value derived from style. > > > > In that situation, you can define a new style specific to the citation > > back-end. > > > > Regards, > > > -- > 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 > Pronouns: he/him/his > ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal 2022-03-20 13:19 ` Nicolas Goaziou @ 2022-03-20 13:32 ` Bruce D'Arcus 2022-03-20 13:42 ` Ihor Radchenko 2 siblings, 0 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-20 13:32 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list On Sun, Mar 20, 2022 at 8:09 AM Vikas Rawal <vikasrawal@gmail.com> wrote: > What is the general view of the community about this? Is there a comprehensive discussion of pros and cons of each? Not really, but there's John's summary here: https://github.com/jkitchin/org-ref#what-about-org-cite The high-level discussion at the beginning, including the enumerated points, seems right to me. The following point that "org-cite does not meet my citation and technical document publishing needs, and it was not possible to integrate it into org-ref without compromising those" is more subject to debate, particularly the first clause. I don't see any practical advantage to the org-ref syntax and model, unless you include cross-references and such. But that's because I just don't think cross-references and indexes should be handled in org-cite; I think if we need improvements in existing cross-references etc support, we should add those there. I suspect he's also meaning the different ways that citation commands/styles are handled in the two systems. Here's an example from org-ref 3: [[citealp:See &kitchin-2015-examp page 2]] Note that first piece: "citealp". That's the command, which org-ref will output directly to LaTeX/Natbib as \citealp. Note that command only makes sense for natbib. Org-cite has a different abstraction here: the style/substyle system. So the above would be ... [cite/bare:See @kitchin-2015-examp page 2] ... and then whatever export processor would map that "bare" style to the appropriate output. So that leaves the last bit; the "not possible" point, which I can't address. It would obviously be nice if org-ref supported org-cite in the future. > What is everyone doing? I was an org-ref user for long before I switched to org-cite. I can now shift to citar but since I am an ivy user, the switch is not trivial. Also, I like many helper functions that John has created, and would have to miss those if I do not use org-ref/org-ref-cite. A month or so ago, John offered to turn over maintenance of org-ref-cite to someone else, which might be one good option for someone who uses ivy, in particular, and interested in developing it further. More generally, the modular design of org-cite should result, in time, with diverse components, including for different completion frameworks. For example, I think it'd be pretty easy to create an insert process for helm-bibtex or ivy-bibtex, and a follow processor for bibtex-completion. Or alternatively, as citar now no longer requires bibtex-completion, someone could write a small citar front-end for ivy as an insert processor. The whole point of the org-ctite design is it should be easy for users to mix-and-match different pieces, and for documents to remain compatible across users and export backends. It also allows developers to focus on those small components. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal 2022-03-20 13:19 ` Nicolas Goaziou 2022-03-20 13:32 ` Bruce D'Arcus @ 2022-03-20 13:42 ` Ihor Radchenko 2022-03-20 18:12 ` Thomas S. Dye 2022-03-20 19:44 ` Bruce D'Arcus 2 siblings, 2 replies; 73+ messages in thread From: Ihor Radchenko @ 2022-03-20 13:42 UTC (permalink / raw) To: Vikas Rawal; +Cc: org-mode mailing list Vikas Rawal <vikasrawal@gmail.com> writes: > What is the general view of the community about this? Is there a > comprehensive discussion of pros and cons of each? Prof. Kitchin himself provided a summary on why he decided to give up on using org-cite. See https://github.com/jkitchin/org-ref/issues/892 > What is everyone doing? I was an org-ref user for long before I switched to > org-cite. I can now shift to citar but since I am an ivy user, the switch > is not trivial. Also, I like many helper functions that John has created, > and would have to miss those if I do not use org-ref/org-ref-cite. I personally used org-ref for a long time simply because no alternatives. I dislike org-ref because Prof. Kitchin prefers to do things in very specific way and it is not always possible to customise them. It is hard to use only a part of org-ref without using everything and getting surprising behaviour. Now, I am trying to switch to org-cite + .org files as bibliography. But the whole thing is an ad-hoc mess. For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. Best, Ihor ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 13:42 ` Ihor Radchenko @ 2022-03-20 18:12 ` Thomas S. Dye 2022-03-20 20:13 ` Dominik Schrempf 2022-03-20 19:44 ` Bruce D'Arcus 1 sibling, 1 reply; 73+ messages in thread From: Thomas S. Dye @ 2022-03-20 18:12 UTC (permalink / raw) To: emacs-orgmode; +Cc: Vikas Rawal Ihor Radchenko <yantar92@gmail.com> writes: > Vikas Rawal <vikasrawal@gmail.com> writes: > >> What is the general view of the community about this? Is there >> a >> comprehensive discussion of pros and cons of each? > > Prof. Kitchin himself provided a summary on why he decided to > give up on > using org-cite. See > https://github.com/jkitchin/org-ref/issues/892 > This claim in Kitchin's summary surprised me: "It comes down to org-ref using bibtex/biblatex as the predominant citation processor, and org-cite using CSL. These two processors have different syntaxes, and I don't think it is possible to have a single approach that works for both of them without making compromises in capability." I wonder what are the "compromises in capability" required to support both? I haven't found them yet, though I'm just now finishing old projects started prior to the release of org-cite and haven't worked through a LaTeX export project with it. My first, and so far only, project with org-cite was for a simple html-based presentation using CSL, and I was pleased with the results and relative ease of setup. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 18:12 ` Thomas S. Dye @ 2022-03-20 20:13 ` Dominik Schrempf 2022-03-20 20:30 ` Vikas Rawal 2022-03-20 20:34 ` Bruce D'Arcus 0 siblings, 2 replies; 73+ messages in thread From: Dominik Schrempf @ 2022-03-20 20:13 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Vikas Rawal, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1953 bytes --] “Thomas S. Dye” <tsd@tsdye.online> writes: > Ihor Radchenko <yantar92@gmail.com> writes: > >> Vikas Rawal <vikasrawal@gmail.com> writes: >> >>> What is the general view of the community about this? Is there a >>> comprehensive discussion of pros and cons of each? >> >> Prof. Kitchin himself provided a summary on why he decided to give up on >> using org-cite. See <https://github.com/jkitchin/org-ref/issues/892> >> > This claim in Kitchin’s summary surprised me: > > “It comes down to org-ref using bibtex/biblatex as the predominant citation > processor, and org-cite using CSL. These two processors have different syntaxes, > and I don’t think it is possible to have a single approach that works for both > of them without making compromises in capability.” > > I wonder what are the “compromises in capability” required to support both? > > I haven’t found them yet, though I’m just now finishing old projects started > prior to the release of org-cite and haven’t worked through a LaTeX export > project with it. My first, and so far only, project with org-cite was for a > simple html-based presentation using CSL, and I was pleased with the results and > relative ease of setup. > > All the best, > Tom For what it’s worth, I use `org-ref` because fine-grained citation export with LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with `org-cite`. If I remember correctly, `org-cite` exports the formatted citations into the LaTeX file, which is a no-go for me (let me know if I am wrong). Then, for example, it is really difficult to use different style files, etc. With `org-ref`, I can use BibLaTeX with specific style files. (Journal require different style files). I can even use my personal LaTeX classes (with specific bibliography styles) for Org export. Not sure if this helps…, but this is maybe what John Kitchin is referring to. Dominik ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 20:13 ` Dominik Schrempf @ 2022-03-20 20:30 ` Vikas Rawal 2022-03-20 20:34 ` Bruce D'Arcus 1 sibling, 0 replies; 73+ messages in thread From: Vikas Rawal @ 2022-03-20 20:30 UTC (permalink / raw) To: Dominik Schrempf; +Cc: org-mode mailing list [-- Attachment #1: Type: text/plain, Size: 944 bytes --] > > > > For what it’s worth, I use `org-ref` because fine-grained citation export > with > LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with > `org-cite`. > It would help if you can explain what you mean. If I remember correctly, `org-cite` exports the formatted citations into the > LaTeX file, which is a no-go for me (let me know if I am wrong). This is not correct. org-cite exports citation commands to LaTeX, and LaTeX does rest of the processing. I do not think there is any difference in the approach between org-cite and org-ref. > Then, for > example, it is really difficult to use different style files, etc. With > `org-ref`, I can use BibLaTeX with specific style files. (Journal require > different style files). I can even use my personal LaTeX classes (with > specific > bibliography styles) for Org export. > > Surely org-cite allows you to do all of this. Vikas [-- Attachment #2: Type: text/html, Size: 1514 bytes --] ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 20:13 ` Dominik Schrempf 2022-03-20 20:30 ` Vikas Rawal @ 2022-03-20 20:34 ` Bruce D'Arcus 2022-03-20 22:10 ` Dominik Schrempf 1 sibling, 1 reply; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-20 20:34 UTC (permalink / raw) To: Dominik Schrempf; +Cc: Vikas Rawal, org-mode-email On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf <dominik.schrempf@gmail.com> wrote: > For what it’s worth, I use `org-ref` because fine-grained citation export with > LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with > `org-cite`. Part of the challenge is this isn't an apples-apples comparison; org-cite a framework, and it's the processors that really provide the functionality. > If I remember correctly, `org-cite` exports the formatted citations into the > LaTeX file ... This is not true. Or rather, it's only true if you use the oc-csl export processor; you can use other export processors (like oc-biblatex) to get whatever LaTeX output you want, and ... > .... it is really difficult to use different style files, etc. With > `org-ref`, I can use BibLaTeX with specific style files. (Journal require > different style files). I can even use my personal LaTeX classes (with specific > bibliography styles) for Org export. ... I believe Nicolas recently added support for customizing the export styles for biblatex. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 20:34 ` Bruce D'Arcus @ 2022-03-20 22:10 ` Dominik Schrempf 0 siblings, 0 replies; 73+ messages in thread From: Dominik Schrempf @ 2022-03-20 22:10 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: Vikas Rawal, org-mode-email [-- Attachment #1: Type: text/plain, Size: 1469 bytes --] “Bruce D’Arcus” <bdarcus@gmail.com> writes: > On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf > <dominik.schrempf@gmail.com> wrote: > >> For what it’s worth, I use `org-ref` because fine-grained citation export with >> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with >> `org-cite`. > > Part of the challenge is this isn’t an apples-apples comparison; > org-cite a framework, and it’s the processors that really provide the > functionality. > >> If I remember correctly, `org-cite` exports the formatted citations into the >> LaTeX file … > > This is not true. Thanks for correcting me on that. I remember having LaTeX files with full citations in them, but maybe I messed something up. > > Or rather, it’s only true if you use the oc-csl export processor; you > can use other export processors (like oc-biblatex) to get whatever > LaTeX output you want, and … > >> …. it is really difficult to use different style files, etc. With >> `org-ref`, I can use BibLaTeX with specific style files. (Journal require >> different style files). I can even use my personal LaTeX classes (with specific >> bibliography styles) for Org export. > > … I believe Nicolas recently added support for customizing the > export styles for biblatex. > > Bruce When I tried setting `org-cite` up, it didn’t work. Maybe I should give it another try at some point. For now, I am happy with `org-ref`. ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 13:42 ` Ihor Radchenko 2022-03-20 18:12 ` Thomas S. Dye @ 2022-03-20 19:44 ` Bruce D'Arcus 2022-03-20 21:14 ` chris 2022-03-21 14:10 ` John Kitchin 1 sibling, 2 replies; 73+ messages in thread From: Bruce D'Arcus @ 2022-03-20 19:44 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Vikas Rawal, org-mode mailing list On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko <yantar92@gmail.com> wrote: > For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. Not really; or rather minimally. Ivy-bibtex supports, for example, inserting of org-cite citations, but not via org-cite-insert. So there are currently no org-cite processors for ivy-bibtex etc. Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 19:44 ` Bruce D'Arcus @ 2022-03-20 21:14 ` chris 2022-03-21 14:21 ` John Kitchin 2022-03-21 14:10 ` John Kitchin 1 sibling, 1 reply; 73+ messages in thread From: chris @ 2022-03-20 21:14 UTC (permalink / raw) To: emacs-orgmode On Sunday, 20 March 2022 20:44:50 CET Bruce D'Arcus wrote: > On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko <yantar92@gmail.com> wrote: > > For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. > > Not really; or rather minimally. I use `org-cite` with a very minimal configuration, and it works very well. I don't use `ivy` at all. I don't use `helm` at all. Those are very large framework and should not be forced to people. (I don't use `org-ref`.) I only use `citar` with minimal configuration. I use `vertico` for the completion. `citar` is simple enough for me to be able to read and understand a large part of it. IMO the more layers of code there are, the more difficult it is to have things work right. And similarly with the size of the code. Chris > > Ivy-bibtex supports, for example, inserting of org-cite citations, but > not via org-cite-insert. And I have `org-cite-insert` working straight out of the box. > > So there are currently no org-cite processors for ivy-bibtex etc. > > Bruce ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 21:14 ` chris @ 2022-03-21 14:21 ` John Kitchin 0 siblings, 0 replies; 73+ messages in thread From: John Kitchin @ 2022-03-21 14:21 UTC (permalink / raw) To: chris; +Cc: emacs-orgmode chris <inkbottle007@gmail.com> writes: > On Sunday, 20 March 2022 20:44:50 CET Bruce D'Arcus wrote: >> On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko <yantar92@gmail.com> wrote: >> > For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. >> >> Not really; or rather minimally. > > I use `org-cite` with a very minimal configuration, and it works very well. I > don't use `ivy` at all. I don't use `helm` at all. Those are very large > framework and should not be forced to people. (I don't use `org-ref`.) These days org-ref does not require helm or ivy, and it does not install them. You can use the core library with any completion backend you want. It uses vanilla completing-read. org-ref does rely exclusively on bibtex-completion at this time. I have not abstracted that out to allow pluggable alternatives like citar. > > I only use `citar` with minimal configuration. I use `vertico` for the > completion. `citar` is simple enough for me to be able to read and understand > a large part of it. > > IMO the more layers of code there are, the more difficult it is to have things > work right. And similarly with the size of the code. > > Chris > >> >> Ivy-bibtex supports, for example, inserting of org-cite citations, but >> not via org-cite-insert. > > And I have `org-cite-insert` working straight out of the box. > >> >> So there are currently no org-cite processors for ivy-bibtex etc. >> >> Bruce -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: citations: org-cite vs org-ref 3.0 2022-03-20 19:44 ` Bruce D'Arcus 2022-03-20 21:14 ` chris @ 2022-03-21 14:10 ` John Kitchin 1 sibling, 0 replies; 73+ messages in thread From: John Kitchin @ 2022-03-21 14:10 UTC (permalink / raw) To: Bruce D'Arcus; +Cc: Vikas Rawal, emacs-orgmode, Ihor Radchenko "Bruce D'Arcus" <bdarcus@gmail.com> writes: > On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko <yantar92@gmail.com> wrote: > >> For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK. > > Not really; or rather minimally. > > Ivy-bibtex supports, for example, inserting of org-cite citations, but > not via org-cite-insert. > > So there are currently no org-cite processors for ivy-bibtex etc. I think this one in https://github.com/jkitchin/org-ref-cite/blob/main/org-ref-cite-insert.el provides an insert processor based on bibtex-completion, and that provides ivy-bibtex actions. The commentary in this file also discusses some challenges in relying exclusively on completing-read. My opinion of course. I don't think you need a special processor for ivy-bibtex. It could be wired to insert org-cites on its own. > > Bruce -- 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 Pronouns: he/him/his ^ permalink raw reply [flat|nested] 73+ messages in thread
end of thread, other threads:[~2022-04-19 22:38 UTC | newest] Thread overview: 73+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal 2022-03-20 13:19 ` Nicolas Goaziou 2022-03-20 14:08 ` Vikas Rawal 2022-03-20 14:38 ` Bruce D'Arcus 2022-03-21 0:31 ` John Kitchin 2022-03-21 1:39 ` Timothy 2022-03-21 8:16 ` Dominik Schrempf 2022-03-21 11:51 ` Bruce D'Arcus 2022-03-21 12:34 ` Dominik Schrempf 2022-03-21 12:52 ` Bruce D'Arcus 2022-03-21 13:05 ` Dominik Schrempf 2022-03-21 13:24 ` Bruce D'Arcus 2022-03-23 21:27 ` Nicolas Goaziou 2022-03-23 21:53 ` Bruce D'Arcus 2022-03-23 22:04 ` Nicolas Goaziou 2022-03-23 22:47 ` Bruce D'Arcus 2022-03-24 10:04 ` Dominik Schrempf 2022-03-21 12:19 ` John Kitchin 2022-03-21 12:42 ` Bruce D'Arcus 2022-03-21 14:06 ` John Kitchin 2022-04-19 22:37 ` Bruce D'Arcus 2022-03-21 3:27 ` Vikas Rawal 2022-03-21 11:51 ` John Kitchin 2022-03-21 17:20 ` Vikas Rawal 2022-03-25 15:53 ` Max Nikulin 2022-03-27 15:33 ` John Kitchin 2022-03-27 15:44 ` Vikas Rawal 2022-03-25 17:10 ` Max Nikulin 2022-03-26 12:41 ` Bruce D'Arcus 2022-03-27 19:40 ` John Kitchin 2022-03-28 12:34 ` Max Nikulin 2022-03-28 13:16 ` Bruce D'Arcus 2022-03-29 15:22 ` Max Nikulin 2022-03-29 16:14 ` Bruce D'Arcus 2022-03-30 13:50 ` Denis Maier 2022-03-31 15:10 ` Max Nikulin 2022-03-31 17:27 ` Bruce D'Arcus 2022-04-02 11:41 ` org-cite, CSL styles and space before citation Max Nikulin 2022-03-30 21:43 ` citations: org-cite vs org-ref 3.0 John Kitchin 2022-03-21 12:59 ` juh 2022-03-22 13:03 ` indieterminacy 2022-03-23 21:06 ` Nicolas Goaziou 2022-03-27 17:00 ` John Kitchin 2022-03-27 23:17 ` Bruce D'Arcus 2022-03-21 14:40 ` Max Nikulin 2022-03-21 15:19 ` Bruce D'Arcus 2022-03-21 17:00 ` John Kitchin 2022-03-25 15:21 ` Max Nikulin 2022-03-22 14:41 ` Max Nikulin 2022-03-22 17:20 ` Bruce D'Arcus 2022-03-23 12:44 ` Max Nikulin 2022-03-23 14:39 ` Bruce D'Arcus 2022-03-23 15:26 ` Eric S Fraga 2022-03-23 17:17 ` Max Nikulin 2022-03-23 22:50 ` Bruce D'Arcus 2022-03-26 19:08 ` M. Pger 2022-03-22 23:52 ` Nicolas Goaziou 2022-03-23 16:30 ` Max Nikulin 2022-03-23 23:04 ` Nicolas Goaziou 2022-03-25 16:30 ` Max Nikulin 2022-03-27 15:38 ` John Kitchin 2022-03-27 23:18 ` Bruce D'Arcus 2022-03-20 13:32 ` Bruce D'Arcus 2022-03-20 13:42 ` Ihor Radchenko 2022-03-20 18:12 ` Thomas S. Dye 2022-03-20 20:13 ` Dominik Schrempf 2022-03-20 20:30 ` Vikas Rawal 2022-03-20 20:34 ` Bruce D'Arcus 2022-03-20 22:10 ` Dominik Schrempf 2022-03-20 19:44 ` Bruce D'Arcus 2022-03-20 21:14 ` chris 2022-03-21 14:21 ` John Kitchin 2022-03-21 14:10 ` John Kitchin
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).