Re: #2 Org mode profiling meetup on Sat, Mar 26 (was: Org mode profiling meetup on Sat, Feb 26 (was: profiling latency in large org-mode buffers (under both main & org-fold feature)))

[Ihor Radchenko]

Ihor Radchenko  writes:

>> The time will be the same: 9pm SG time (4pm Moscow; 8am New York; 1pm
>> London). Sat, Mar 26
>>
>> I will post the link to the meeting one hour before the meeting start.
>
> Here is the link https://teamjoin.de/Org-dev-profiling-20220326-d708k

The recording is available at
https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9

Summary of the talk:

Table of Contents
─

1. Testing bugs in clean environment and latest Org
.. 1. Org manual!
.. 2. Alternative demo
.. 3. What to report
2. Testing bugs in personal config (bisecting config)
3. Using Emacs profiler and sharing profiler results
.. 1. The basic idea
.. 2. Profile buffer
.. 3. Caveats   :ATTACH:


1 Testing bugs in clean environment and latest Org
══

1.1 Org manual!
───

   -> Contribute -> Feedback (yes, it is a bit
  obscure) -> 


1.2 Alternative demo


  • Fetch the latest Org 
┌
│  cd /tmp/ # on Linux, can be any other dir.
│  git clone git://git.sv.gnu.org/emacs/org-mode.git # You need git to 
be installed. 
└
Alternative:  (only latest
stable version aka bugfix branch)
  • Create minimal working environment
┌
│  cd org-mode
│  git checkout main 
│  # or
│  # git checkout bugfix
│  make cleanall # useful if you re-use the already downloaded dir
│  make autoloads # auto-generate some files for Emacs
└
  • Run clean Emacs
┌
│  emacs -Q -L ./lisp -l org
│  # or to open a clean org buffer
│  # emacs -Q -L ./lisp -l org /tmp/test.org
│  # or use a minimal configuration saved in /tmp/test.el, if required
│  emacs -Q -L ./lisp -l org -l /tmp/test.el /tmp/test.org
└
  • Enable extra debugging Put the following into test.el
┌
│  ;; Activate generic debugging.
│  (setq debug-on-error t
│debug-on-signal nil
│debug-on-quit nil)
│  ;; Activate org-element debugging.
│  (setq org-element--cache-self-verify 'backtrace
│org-element--cache-self-verify-frequency 1.0 ; can be less if 
there are lags.
│org-element--cache-map-statistics t)
└


1.3 What to report
──

  There is some common information we find extremely useful when
  diagnosing bug reports.

  • The easiest is using M-x `org-submit-bug-report'
• Most of common require info will be auto-inserted into email
• You don't have to configure Emacs for sending email. Can simply
  use `org-submit-bug-report' and copy-paste the text into email
  client of choice.
  • If there are warnings, can also share what is inside `*Warnings*'
buffer: M-: `(switch-to-buffer "*Warnings*")'
  • Same for `*Messages*' M-: `(switch-to-buffer "*Messages*")'
  • Screenshots are often helpful


2 Testing bugs in personal config (bisecting config)


  

  • M-x `bug-hunter-init-file'
  • Usually works out of the box, but may not give useful results when
`init.el' is a single sexp block
┌
│   (let ((org-file '"/home/yantar92/Git/emacs-config/config.org")
│   (el-file '"~/.emacs.d/config.el"))
│   (setq init-flag t)
│   (setq comp-deferred-compilation-deny-list '("pdf-cache" 
"org-protocol"))
│   (load el-file))
└
• Then, need to dump the actual config into `init.el'
  • Sometimes, a bug in personal config is caused by interaction between
two packages
┌
│   (require 'package1)
│   ;; some setting causing package1 to break, but only when package2 below 
is loaded
│   (require 'package2)
└
• `bug-hunter' will then point to `(require 'package2)' as the
  problematic line, instead of the actual setting
• It can help then to reshuffle the config, so that `package1' and
  `package2' are loaded early:
  ┌
  │ (require 'package1)
  │ (require 'package2)
  │ ;; some setting causing package1 to break, but only when package2 
below is loaded
  └


3 Using Emacs profiler and sharing profiler results
═══

3.1 The basic idea
──

  1. M-x `profiler-stop' *Important*: if a profiler is already running,
 the report will contain irrelevant data
 • `profiler-stop' may not be available right after Emacs start. If
   it is not listed in M-x completions, no need to run it
  2. M-x `profiler-start'  `cpu' 
  3. Do slow staff you want to test
  4. M-x `profiler-report'
  5. M-x `profiler-report-write-profile'
  6. Attach the report f

Re: Problem with org-babel and geiser

[Rudolf Adamkovič]

Neil Jerram  writes:

Hi Neil!

> What do you see if you add ":results output" to the "#+begin_src"
> line, and then C-c C-c again?

#+BEGIN_SRC scheme :results output verbatim
(+ 1 1)
#+END_SRC

#+RESULTS:
: Geiser Interpreter produced no output

> Did the patch help in your case?

I had to update the file name inside of the patch:

- old: lisp/org/ob-scheme.el
- new: lisp/ob-scheme.el

After that, the patch applied cleanly on top of 'main'.

So, I restarted Emacs and tried:

#+BEGIN_SRC scheme
(+ 1 1)
#+END_SRC

#+RESULTS:
: 2

Further, I also tried to execute '(display "ABC")' while capturing
standard output using ':results output verbatim'.  It worked.

Lastly, I tried to use a persistent ':session' to avoid waiting for the
Geiser/Guile when executing code blocks.  It worked as well.

TL;DR The patch works.

P.S.

We should add 'testing/lisp/test-ob-scheme.el' or it will break again
sooner or later.  Can we make the Org test suite depend on Geiser and
Guile?  Given that Org uses Geiser out of the box, I think we should.
What do you think?

Rudy
-- 
"The whole science is nothing more than a refinement of everyday
thinking."
-- Albert Einstein, 1879-1955

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Problem with org-babel and geiser

[Rudolf Adamkovič]

Zelphir Kaltstahl  writes:

Hi Zelphir,

> Geiser seems to work, if I use /bin/sh with some arguments instead of
> GNU Bash.

I have no idea it means to "use /bin/sh with some arguments instead of
GNU Bash" in the context of Org Babel, Geiser, and Guile.  Then, please
see my other mail, the reply to Neil, where I test the patch posted
upthread and find that it indeed works well!

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)

[Ihor Radchenko]

Ihor Radchenko  writes:

> 2. Extend the alist with new options, like ${keyword} expansion, hooks,
>contexts, children, etc Maybe in a sequence of patches.

For reference, someone proposed a patch to extend org-capture-templates
and support per-template hooks:
https://list.orgmode.org/orgmode/20220206140551.1263130-1-herr.valentin.m...@gmail.com/

Best,
Ihor

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

[John Kitchin]

I have updated the readme in org-ref to indicate you can use both
packages.

Max Nikulin  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-dhpn98a...@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

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

[Vikas Rawal]

I have updated the readme in org-ref to indicate you can use both
> packages.
>
> Thanks.

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

[John Kitchin]

Nicolas Goaziou  writes:

> Hello,
>
> 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.
>
>> 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

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

[John Kitchin]

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 w

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

[John Kitchin]

Max Nikulin  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@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

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

[Bruce D'Arcus]

On Sun, Mar 27, 2022 at 3:41 PM John Kitchin  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

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

[Bruce D'Arcus]

On Sun, Mar 27, 2022 at 12:00 PM John Kitchin  wrote:
>
>
> Nicolas Goaziou  writes:
>
> > Hello,
> >
> > 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.
> >
> >> 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
>