On Sun, Mar 27, 2022 at 12:00 PM John Kitchin <jkitc...@andrew.cmu.edu> wrote: > > > Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > > > Hello, > > > > Max Nikulin <maniku...@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 >
