Thanks, Detlef, I re-installed this essential package for me. El 28/03/2022 a las 18:00, emacs-orgmode-request@gnu.org escribió: > Send Emacs-orgmode mailing list submissions to > emacs-orgmode@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/emacs-orgmode > or, via email, send a message with subject or body 'help' to > emacs-orgmode-request@gnu.org > > You can reach the person managing the list at > emacs-orgmode-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emacs-orgmode digest..." > > > Today's Topics: > > 1. Re: citations: org-cite vs org-ref 3.0 (John Kitchin) > 2. Re: citations: org-cite vs org-ref 3.0 (John Kitchin) > 3. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 4. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 5. Re: Is there a maintained calf-calendar fork? (Detlef Steuer) > 6. Re: [PATCH] Fix typo in org-todo-list doc string (Bastien) > 7. Re: Bug: Incorrect weekday in The Org Manual [9.3 > (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] (Bastien) > 8. Re: citations: org-cite vs org-ref 3.0 (Max Nikulin) > 9. Re: Faulty SVG width in default HTML export style (Bastien) > 10. Re: Custom TODO states for one item (Bastien) > 11. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 12. ox-latex table tabbing support. (emacs@vergauwen.me) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 27 Mar 2022 13:00:40 -0400 > From: John Kitchin > To: Nicolas Goaziou > Cc: Vikas Rawal,emacs-orgmode@gnu.org > Subject: Re: citations: org-cite vs org-ref 3.0 > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > Nicolas Goaziou writes: > >> Hello, >> >> John Kitchin 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, >