emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: citations: org-cite vs org-ref 3.0


From: John Kitchin
Subject: Re: citations: org-cite vs org-ref 3.0
Date: Sun, 27 Mar 2022 11:38:26 -0400
User-agent: mu4e 1.6.10; emacs 28.0.90

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]