Re: Emacs-orgmode Digest, Vol 193, Issue 30

Re: Emacs-orgmode Digest, Vol 193, Issue 30

[Ypo]

[-- Attachment #1: Type: text/plain, Size: 9539 bytes --]

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<jkitchin@andrew.cmu.edu>
> To: Nicolas Goaziou<mail@nicolasgoaziou.fr>
> Cc: Vikas Rawal<vikasrawal@gmail.com>,emacs-orgmode@gnu.org
> Subject: Re: citations: org-cite vs org-ref 3.0
> Message-ID:<m24k3jnq0k.fsf@andrew.cmu.edu>
> Content-Type: text/plain; charset=utf-8
>
>
> 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,
>

[-- Attachment #2: Type: text/html, Size: 11959 bytes --]