Re: Have org-cite insert links to references not just add text with the reference directly when exporting to latex

[Bruce D'Arcus]

You're probably using the CSL export processor then.

On Fri, Apr 14, 2023, 9:47 AM Durham Smith  wrote:

> When inserting a link a reference using org-cite (e.g
> `[cite:@name_of_ref_in_bib_file]`) and generating the latex instead of
> generating code like `\cite{name_of_ref_in_bib_file}` what get in the
> generated .tex file is the actual citation written out in full. Is there
> any way to change this behavior to generate links instead (i.e have
> `\cite{name_of_ref_in_bib_file}` appear in the .tex file)?
>

Re: org-noter

[Bruce D'Arcus]

This is really cool, but doesn't there really need to be a single repo for
distribution, issue reporting, etc.?

Do you have a plan for which fork would become primary?


On Sat, Mar 11, 2023, 11:35 PM Peter Mao  wrote:

> Dear Org maintainers:
>
> I don't think org-noter is part of any official org distribution, having
> been a MELPA-distributed package since inception (2017), but in the course
> of discussing transfer of maintenance duties with Jonas Bernoulli (in his
> MELPA-maintainer role), he suggested that we inform you of the impending
> change to the maintenance of this package.
>
> In short, Dmitry and I have stabilized new features brought into the code
> since Gonçalos' last commit in 2019 and brought in CI and a few new
> features ourselves.  We have tried to contact Gonçalos since early Dec
> 2022, but have not heard from him.
>
> Here are links to the relevant "issue" tickets on MELPA and the original
> org-noter repository where we have made our proposal to maintain the
> project:
> https://github.com/weirdNox/org-noter/issues/173
> https://github.com/melpa/melpa/issues/8413
>
> No action is needed on your part, but comments and suggestions are
> welcomed.
>
> Peter
>
>
>

Re: Hiding citations

[Bruce D'Arcus]

On Sat, Feb 25, 2023 at 7:31 AM M. ‘quintus’ Gülker
 wrote:

> is there a way to visually hide citations in the org buffer, much like
> links are hidden?

Not exactly what you're asking for, but have you seen this activate processor?

https://github.com/andras-simonyi/org-cite-csl-activate

Bruce

Re: [POLL] Naming of "export features"

[Bruce D'Arcus]

On Wed, Feb 22, 2023 at 7:23 AM Ihor Radchenko  wrote:
>
> Timothy  writes:
>
> > Here is a list of terms which I’d feel comfortable applying to the system:
> > ⁃ export features
> > ⁃ export capabilities
> > ⁃ export snippets
>
> I am looking at the concept again, and I feel that we may be missing
> some flexibility here. I do not like the fact that each feature can only
> have a simple implementation within specific backend.

I'm not really following this discussion, but is this perhaps similar
to pandoc/djot's notion of "filters"?

https://github.com/jgm/djot.js#filters

Bruce

Re: citar--library-file-action

[Bruce D'Arcus]

For citar support/bugs, you should report on the github issue tracker.

But my guess: you need to install citar-embark, as a while ago, we
moved the embark-related functionality into a separate package. If
it's been a few months since you've updated, that would likely explain
it.

On Tue, Oct 25, 2022 at 4:23 PM Henrik Frisk  wrote:
>
> Hi,
>
> After updating a bunch of packages I'm getting this error message when I try 
> to open an associated file via a reference:
>
> [cite:@key]
>
> Before it was working fine via emark either by clicking on the reference or 
> by running embark-act on it. Now I get this instead:
>
> citar--library-file-action: Symbol’s function definition is void: open
>
> Any suggestions?
>
> /Henrik
>

Re: [BUG] Mention #+PRINT_BIBLIOGRAPHY in the Org manual

[Bruce D'Arcus]

I'm not sure what I think about this. I can't ever recall having a
practical issue with this example (I'd expect it's more common for
people with very long cite keys?), though in the past I have had
issues with whitespace when moving around citation-references
programmatically (as, for example, with
~citar-org-shift-reference-left~ and such).

On Sat, Oct 22, 2022 at 2:14 AM Ihor Radchenko  wrote:
>
> Rudolf Adamkovič  writes:
>
> > Ihor Radchenko  writes:
> >
> >> Feel free to submit a patch for org-cite-make-insert-processor.
> >
> > Could the patch make '[cite: @key]' the new default when inserting
> > citations, or should it introduce a new customization point?
>
> I think it can be the new default.
> However, please send the patch in a separate thread, so that people can
> see it and oppose if they have objections.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Org ML integration with an existing Discourse instance (was: IM dev discussions?)

[Bruce D'Arcus]

On Tue, Sep 27, 2022 at 2:25 PM Tim Cross  wrote:

> Discourse is not free - either you have to pay or you have to self host.

IIRC, it is for open source projects.

Yes:

https://blog.discourse.org/2018/11/free-hosting-for-open-source-v2/

Bruce

Re: Could a .bib file be edited and organized in an "org-mode" way and still work as a .bib file?

[Bruce D'Arcus]

Yes, but there are some tricky performance issues with large org files
that change a lot, since currently citar will reload the file(s)
whenever they change, but an org file that mixes notes and bib data
may change a lot even if the bib data doesn't. If you have everything
in one file, that becomes a problem.

https://github.com/emacs-citar/citar/issues/397#issuecomment-1221604952

On Tue, Aug 23, 2022 at 7:42 AM Ypo  wrote:
>
> I asked some months ago about the possibility of using an ORG file at the 
> same time as bibliography and as a notebook.
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2021-10/msg00619.html
>
>
> It seems someone is making it possible :-D
>
> https://gist.github.com/andras-simonyi/eda0daa0b677838022fd7c438b6eadfa
>
> https://www.reddit.com/r/emacs/comments/wqjare/comment/iku77h0/?utm_source=share_medium=web2x=3
>
>
>
>
>

Re: Maintaining oc-csl

[Bruce D'Arcus]

Yes please; and thanks for volunteering!

On Sat, Aug 13, 2022, 8:47 AM András Simonyi 
wrote:

> Dear All,
>
> I'd like to volunteer to maintain oc-csl.el, which currently doesn't
> have an official maintainer as far as I can tell. As the author and
> maintainer of citeproc-el and the author of oc-csl's precursor,
> citeproc-org, I think I'm reasonably well positioned to handle issues
> and make improvements.
>
> thanks for your consideration & best wishes,
> András
>
>

Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles

[Bruce D'Arcus]

On Sat, Aug 13, 2022 at 8:30 AM András Simonyi  wrote:
>
> Dear All,
>
> On Tue, 9 Aug 2022 at 17:38, Rudolf Adamkovič  wrote:
>
> > THANK YOU for working on this!  I have tried the "locators" style, and
> > it works great.  At last, we can write in the APA style with no hacks!
>
> thanks for your kind words, I'm glad that you find the additions useful.
>
> > P.S.  Not a fan of using "ti" for the title.  I would go for "T" for
> > "Title", or "p" for "publication", or "s" for "subject", or something
> > like that.
>
> interesting, it didn't occur to me that we could use capital letters
> as well, certainly an alternative to consider.

I'm not a fan; I think it would open a can-of-worms vis-a-vis the
latex processors and commands.

> Another solution could be to make the whole mapping customizable as
> it's done, I think, in the case of  the biblatex export processor.

I actually think the case for this is weakest with the oc-csl processor.

Here, there is no style -> command mapping; it's just direct.

So effectively the style names and shortcuts are just aesthetic.

And changing them means the citations are then tied to the export
processor, and the specific user.

Bruce

Re: org-cite-insert + fido-mode

[Bruce D'Arcus]

You need to use whatever keybinding exits.

On Fri, Aug 12, 2022, 8:53 PM Tyler Grinn  wrote:

>
> I need help inserting a citation with fido-mode (icomplete) enabled.  I
> call org-cite-insert, select the citation I want, and press return, and
> it asks for another citation to add, filling the minibuffer with the
> most likely option.  I see no way to insert the citations I've already
> selected, it always puts me back in this loop.
>
> Steps to reproduce:
>
> M-x fido-mode
> M-x org-cite-insert
>
> Best,
>
> Tyler
>
>

Re: [RFC PATCH] oc-csl: Add support for title, locators and bibentry styles

[Bruce D'Arcus]

On Tue, Aug 2, 2022 at 7:14 AM András Simonyi  wrote:

> the attached patch adds support for three new citation styles which
> recently got supported by citeproc-el:
>
> - cite/title or cite/ti to cite only the title of an item,
> - cite/locators or cite/l to cite only the locators, and
> - cite/bibentry or cite/b to cite the full bibliography entry.
>
> I put "RFC" in the subject because I'm not entirely sure about naming
> the "bibentry" style, since "bibentry" is natbib terminology, I think,
> and biblatex's corresponding command is \fullcite, but I find
> "bibentry" slightly more adequate.

I agree; there's no ideal name that I can see, and it fits better in
the existing style naming scheme.

We (well someone :-)) should add the same to the natbib and biblatex
processors, though I believe natbib has a wrinkle where you also have
to add a preamble line or something.

> Also, do we need the "ti" abbreviation for the "title" style?

I think so.

Bruce

Re: [PATCH] oc-csl: Add support for sub-bibliographies

[Bruce D'Arcus]

On Mon, Jul 25, 2022 at 2:26 PM András Simonyi  wrote:
>
> Dear All,
>
> On Sun, 24 Jul 2022 at 09:41, Ihor Radchenko  wrote:
> >
> > Thanks!
> >
> > I have made some changes to the patch, mostly fixing grammar issues (the
> > ones I can notice). I also changed the sub-section from "Bibliography
> > options" to "Bibliography options in "biblatex" and "csl" export processors"
> >
> > See the attached.
>
> Thanks a lot for the improvements! The only suggested change which I'm
> not sure about is the renaming of the section "Bibliography printing"
> to "Printing bibliography" Neither of them are ideal but it's
> difficult to find a formulation which sounds OK and is noncommittal
> regarding the number of bibliographies (a single one vs. several). Of
> the two, I feel that "Printing bibliography" is slightly worse because
> of the missing determiner before "bibliography", maybe "Printing
> bibliographies" would be better? Admittedly, as a non-native user of
> English my intuitions do not count for much, so it'd be nice to hear
> the opinion of some of the native speaker list members.

I'm a native speaker.

I think "Bibliography printing" sounds like the best option, since it
doesn't really preclude there are multiple.

"Printing bibliographies" would also be OK.

I don't think "Printing bibliography" really works.

Bruce

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Bruce D'Arcus]

On Tue, Jul 19, 2022 at 4:37 PM Joost Kremers  wrote:
>
>
> On Sun, Jul 17 2022, Ihor Radchenko wrote:
> > alain.coch...@unistra.fr writes:
> >
> >> My .bib file is
> >>
> >>@string{jgr="J. Geophys. Res."}
> >>@ARTICLE{chouet88,
> >>journal=jgr,
> >>author={Chouet, B.}, title={Resonance of a fluid-driven crack: [...]},
> >>year={1988}, volume={93}, number={B5}, pages={4375-4400}
> >
> > Fixed on main via c550a4290.
> >
> > After discussion with Emacs devs, it turned out that there is a way to
> > make bibtex.el parse and substitute @string abbreviations.
>
> So does this mean there is no longer any reason to add parsebib to (Non-)GNU
> ELPA?

No, since parsebib is an important dependency for citeproc-el, and
Ihor was suggesting Andras try to get that in ELPA.

Bruce

Re: @string abbreviation in bib file not honored in (basic) org-cite [and a minimal working example with natbib]

[Bruce D'Arcus]

On Sat, Jul 9, 2022 at 2:10 AM  wrote:

> I take the opportunity to say that I think that the simple
> self-contained example
>
>#+bibliography: references.bib
>[cite:@key]
>#+print_bibliography:
>
> should be part of the manual, especially since the
> 2021-07-31-citations post does not seem to be referred to in the
> manual any more (I have org version 9.5.4).

The terseness of this section of the manual is a known problem.

I'll try to find time to do a patch to include your suggestions, which
make sense.

Bruce

Re: LaTeX export: when is it more useful to use LuaTeX instead of pdfTeX?

[Bruce D'Arcus]

Today, I think the only advantage pdftex has is speed; it's a lot
faster to compile documents than luatex.

And maybe some advanced microtypography features, though I haven't tracked that.

Bruce

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Bruce D'Arcus]

On Fri, Jul 8, 2022 at 7:25 AM  wrote:

> As I do not know which of these alternatives
>
>- it is normal, this feature should not be there,
>- it is an oversight,
>- this feature is not implemented yet,

I believe this is the answer, and it's arguable (I have no opinion,
and could see reasonable arguments either way) whether a "basic"
processor should support it?

The parsebib library, which most third party packages use (for
org-cite, there's my citar), does support this feature.

>- it does not work for me for some reason,
>- other,

Bruce

Re: [PATCH] oc-csl: Add support for nocite citations

[Bruce D'Arcus]

On Tue, Jul 5, 2022 at 3:28 PM Bruce D'Arcus  wrote:

> > Except, and I'm not sure if I'm misunderstanding some org detail, but
> > this doesn't suppress the global bibliography. Should it?
>
> Yes, and it does in oc-biblatex.

Sorry for the noise; disregard.

It was something with my testing setup.

Bruce

Re: [PATCH] oc-csl: Add support for nocite citations

[Bruce D'Arcus]

On Tue, Jul 5, 2022 at 3:17 PM Bruce D'Arcus  wrote:
>
> On Mon, Jul 4, 2022 at 7:54 AM Ihor Radchenko  wrote:
>
> > Since the fontification part appears to be unrelated to this particular
> > patch, I'd like to ask people who use CSL to test the patch.
>
> I just tested it, and it works as expected.
>
> Except, and I'm not sure if I'm misunderstanding some org detail, but
> this doesn't suppress the global bibliography. Should it?

Yes, and it does in oc-biblatex.

Bruce

Re: [PATCH] oc-csl: Add support for nocite citations

[Bruce D'Arcus]

On Mon, Jul 4, 2022 at 7:54 AM Ihor Radchenko  wrote:

> Since the fontification part appears to be unrelated to this particular
> patch, I'd like to ask people who use CSL to test the patch.

I just tested it, and it works as expected.

Except, and I'm not sure if I'm misunderstanding some org detail, but
this doesn't suppress the global bibliography. Should it?

#+bibliography: test.bib
#+cite_export: csl
[cite/nocite:@*]
#+print_bibliography:

# Local Variables:
# org-cite-global-bibliography: nil
# End:

Bruce

Re: re-scanning bibliography for org-cite

[Bruce D'Arcus]

On Thu, Jun 9, 2022 at 12:00 PM Fraga, Eric  wrote:
>
> On Thursday,  9 Jun 2022 at 10:34, Bruce D'Arcus wrote:
> > It should take another few days of development and testing before I'm
> > ready to merge it, but it pretty much works now, and any help with
> > code review and/or testing would be much appreciated.
>
> Okay, let me know.  It's easy enough for me to replace 'basic with
> 'citar again!

Took a bit longer than "days," because we ended up making a ton of
other changes, but it's now merged.

The result should be a snappy UI that appropriately adapts to local
buffer context, and updates the cache as needed.

Re: [BUG] @* in [cite/nocite:@*] is a valid special LaTeX bibliography key, but it is highlighted using "error" face by oc.el (was: [PATCH] oc-csl: Add support for nocite citations)

[Bruce D'Arcus]

On Mon, Jul 4, 2022 at 8:57 AM András Simonyi  wrote:
> It seems to me that "*" as a key is sophisticated enough that if we have to 
> make a decision
> about the default fontification then it is better to err on the side
> of supposing that a user using it knows what they are doing,

+1

Bruce

Re: [PATCH] oc-csl: Add support for nocite citations

[Bruce D'Arcus]

I don't know the internals, I just know it works from org, though I'm not
near a computer ATM.

On Sun, Jul 3, 2022, 8:34 AM Ihor Radchenko  wrote:

> "Bruce D'Arcus"  writes:
>
> > Ihor - on *, he is bringing oc-csl in line with the oc-natbib and
> > oc-biblatex processors.
>
> I am sorry, but I still do not understand. AFAIK, \nocite{*} is not a
> valid LaTeX command.
>
> Best,
> Ihor
>

Re: [PATCH] oc-csl: Add support for nocite citations

[Bruce D'Arcus]

Ihor - on *, he is bringing oc-csl in line with the oc-natbib and
oc-biblatex processors.

On Sun, Jul 3, 2022, 7:57 AM Ihor Radchenko  wrote:

> András Simonyi  writes:
>
> >> By "*", do you mean something like [cite/n:@*]?
> >> If so, will it be correctly fontified as an existing citation?
> >
> > ... As for fontification, this is a very good
> > question! I've checked it now with the built-in "basic"
> > activation processor and it shows the "*" with an "error" face,
> > indicating that it's not a key in the bibliography file(s), which
> > might not be ideal. Nonetheless, this problem is not limited to or
> > introduced by this patch, because the same construct and
> > functionality is also supported by the "biblatex" and "natbib" export
> > processors.  Actually, the possibility of using "*" as a key comes
> > simply
> > from a citeproc-el change, not from oc-csl, I just thought that it is
> > obscure enough to merit an explicit mention in the NEWS file.
>
> I do understand that @* syntax is coming from citeproc-el. However, we
> are talking about changes to Org core. If Org highlights @* with 'error
> face, some users will be confused.
>
> Could you please elaborate about "the same construct and functionality
> is also supported by the "biblatex" and "natbib" export processors"?
> I cannot call myself expert in LaTeX, but I've never heard about LaTeX
> \cite/\nocite commands supporting "*" argument. I cannot find any traces
> of "*" functionality in oc-bibtelatex/oc-natbib as well.
>
> Best,
> Ihor
>
>
>

Re: [STYLE] :version tags in defcustom definitions (was: [PATCH] Improve look of agenda on graphical displays)

[Bruce D'Arcus]

On Wed, Jun 29, 2022 at 10:23 AM Timothy  wrote:
>
> Hi Ihor and Stefan,
>
> >> Sure. Just trying to clarify my confusion. The inconsistency with some
> >> defcustoms using :version and some not is bugging me.
> >
> > Agreed.  It would be better to be consistent with this.
>
> Given that org-mode is distributed separately to Emacs, and I get the 
> impression
> having a newer org-mode version that Emacs version is not uncommon, I think it
> would make sense to have /just/ org-mode version tags.

+1

Bruce

Re: org-cite: only last names and et al. for more than two coauthors

[Bruce D'Arcus]

On Tue, Jun 28, 2022 at 10:10 AM M. Pger  wrote:

> A last question though: is it possible to set the 'round' option without 
> having to insert the latex header
> ```
> #+LATEX_HEADER: \usepackage[round]{natbib}
> ```
> ?

I haven't used it, but I believe the ~org-cite-natbib-options~
defcustom is what you need.

Bruce

Re: org-cite: only last names and et al. for more than two coauthors

[Bruce D'Arcus]

On Mon, Jun 27, 2022 at 1:13 AM M. Pger  wrote:

> I've recently tried to switch to org-cite, but I still have some problems 
> with the basics.

First, org-cite is a framework for citations. When reporting issues
related to it, you really need to identify what processor(s) you are
seeing the behavior with.

> Consider the following entry:
>
> @article{akey2022,
>   title = {This is the title},
>   shorttitle = {This is the short title},
>   author = {Surname1, Name1 and Surname2, Name2 and Surname3, Name3},
>   year = {2022},
>   (truncated)
> }
>
> I want to have something like: "as shown by Surname1 et al. (2022), ...", 
> i.e. something one can get with natbib \citet command. With org-ref it worked 
> like a charm.
>
> I've tried the syntax presented in 
> https://blog.tecosaur.com/tmio/2021-07-31-citations.html#more-exporting, that 
> is:
> [cite/t/c:@akey2022]
> but I ended with a 'wrong type argument' error.
>
> I then tried [cite/t:@akey2022]: exporting succeeds. However, I end up with 
> "as shown by Surname1, Name1 and Surname2, Name2 and Surname3, Name3 (2022), 
> ...".
>
> How can I correctly specify the options mentioned above? Is there a complete 
> and updated tutorial available somewhere?

[cite/t:@key] should work as you expect in natbib, biblatex, csl.

Possible issues, depending on which of those you're using:

- some error with the bib file; or a mismatch between the file and the
bibtex dialect or something
- the citation style

A complete MWE would help.

Bruce

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

[Bruce D'Arcus]

On Mon, Jun 20, 2022 at 10:13 AM David Lukeš  wrote:
...

> > it's likely we'll change the date property to prefer an
> > EDTF string
>
> Will that be stored in the `raw` or `literal` field? In that case, the
> current implementation should work with (not too wild) EDTF strings.
> If not, code will have to be added to extract the value from the
> appropriate field.

I need to emphasize a major caveat: this is subject to change,
discussion, etc., and would take time regardless to see in the wild.
So you shouldn't do anything with this information ATM; I just mention
it because it may be relevant in the future.

And of course, we welcome feedback.

But currently, the draft schema for the next major release allows this
as an option (this is an EDTF date range):

"issued": "2020-07/2020-08",

E.g. a (preferred) EDTF string, OR the current date object.

In general, I should add, there are some competing priorities here.
The CSL JSON was first created for the citeproc-js project, whose
initial and primary consumer is Zotero, which embeds that data in word
processing documents.

In that case, machines are the only consumers.

But it's since become more widely used, including in pandoc, and now
in org. So the planned move to EDTF is in part to balance those
priorities.

But as I say, we still need feedback from the different constituencies.

Bruce

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

[Bruce D'Arcus]

On Mon, Jun 20, 2022 at 8:04 AM Ihor Radchenko  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > I created CSL, and have helped develop the data schema.
> >
> > BTW, just to look forward, it's likely we'll change the date property
> > to prefer an EDTF string; same as biblatex does now.
>
> Have you ever checked if oc-basic parser complies with the schema?
> It is clear that is not for year field, but I am wondering about other
> fields.

I had not. But the schema doesn't have a lot of rules.

Aside from dates, the other structured object definition is for
(author etc) names.

oc-basic ignores the properties beyond "family" and "given" names,
most of which probably don't matter for this purpose, except maybe
"literal" (for organizational authors).

Bruce

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

[Bruce D'Arcus]

On Sat, Jun 18, 2022 at 11:31 PM David Lukeš  wrote:
>
> > I suspect that multiple json formats may be available in the wild. Some
> > parsed as a list of strings and some parsed as a list of numbers.
>
> > The JSON schema allows either:
>
> Ah, thanks for looking this up!

I created CSL, and have helped develop the data schema.

BTW, just to look forward, it's likely we'll change the date property
to prefer an EDTF string; same as biblatex does now.

Bruce

Re: oc-basic: CSL-JSON year as number vs. string (nativecomp?)

[Bruce D'Arcus]

On Sat, Jun 18, 2022 at 9:43 PM Ihor Radchenko  wrote:
>
> David Lukeš  writes:
>
> > I recently started to get errors like the following:
> >
> > Error during redisplay: (jit-lock-function 544) signaled
> > (wrong-type-argument "Argument is not a string or a secondary string:
> > 2007")
> >
> > This patch makes them go away:
> >
> > -(caar date))
> > +(number-to-string (caar date)))
>
> Can you provide an example json file demonstrating the problem?
> I suspect that multiple json formats may be available in the wild. Some
> parsed as a list of strings and some parsed as a list of numbers.

The JSON schema allows either:

https://github.com/citation-style-language/schema/blob/5b8bbc824e026959417757d4ce4012a26b10e637/schemas/input/csl-data.json#L512

Bruce

Re: re-scanning bibliography for org-cite

[Bruce D'Arcus]

BTW, just to give some context of why we didn't implement it by
default earlier; there are two reasons:

1. it seems vast differences in the size of user bib files, and those
with very large ones would be annoyed if it re-generated the
completions on every change.
2. citar also covers notes and related files, which get complicated,
and subject to further user variety; and the UI needs to keep this in
sync with the bib data

I think we understand the problem better now, however.

On Thu, Jun 9, 2022 at 12:00 PM Fraga, Eric  wrote:
>
> On Thursday,  9 Jun 2022 at 10:34, Bruce D'Arcus wrote:
> > It should take another few days of development and testing before I'm
> > ready to merge it, but it pretty much works now, and any help with
> > code review and/or testing would be much appreciated.
>
> Okay, let me know.  It's easy enough for me to replace 'basic with
> 'citar again!
>
> --
> : Eric S Fraga, with org release_9.5.4-521-g1105da in Emacs 29.0.50

Re: re-scanning bibliography for org-cite

[Bruce D'Arcus]

On Thu, Jun 9, 2022 at 10:19 AM Fraga, Eric  wrote:
>
> On Thursday, 26 May 2022 at 18:24, Ihor Radchenko wrote:
> > The relevant function is org-cite-basic--parse-bibliography.
>
> To finally follow up on this, the problem is not with org-cite but
> appears to be due to my use of citar.  Citar seems to cache the keys
> somewhere/somehow and this cache is not updated when the bibliography
> file changes.

Yes; not currently by default, but can be configured.

https://github.com/emacs-citar/citar#refreshing-the-library-display

But more importantly I'm currently working on a major change in the
caching and completion architecture of citar, where I've actually
borrowed ideas and code from oc-basic, so it should work the same WRT
to cache updating, without need for any configuration.

https://github.com/emacs-citar/citar/pull/628

It should take another few days of development and testing before I'm
ready to merge it, but it pretty much works now, and any help with
code review and/or testing would be much appreciated.

Bruce

Re: How to debug a CSL problem

[Bruce D'Arcus]

On Sun, Jun 5, 2022 at 6:48 PM Alan Tyree  wrote:

> I need some help with a debugging problem:
>
> I'm using
>
> #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>
> where AGLC-intext.csl is a custom csl file.

I'm not sure if citeproc-el checks validity before running, but have
you confirmed it's a valid style?

This is the easiest way to do that, if you don't have a relax ng
validator setup, with the schemas and such.

https://validator.citationstyles.org/

If yes, and it is valid, I would report it to the citeproc-el issue tracker.

If your bib file(s) work fine with other CSL styles, it seems likely
it's something with the style or the style and citeproc-el.

Bruce

Re: Opening org-cite links with different application

[Bruce D'Arcus]

On Wed, May 25, 2022 at 12:47 PM Max Nikulin  wrote:

> I have had a quick glance into the code I have an additional question
> why `browse-url' is not used for `citar-file-open-external'.

The "external" here means opening files external to emacs.

The typical use case is someone wanting to use a system PDF or image viewer.

I had actually forgotten about that function when initially replying!

Bruce

Re: Opening org-cite links with different application

[Bruce D'Arcus]

On Wed, May 25, 2022 at 11:26 AM Max Nikulin  wrote:
>
> On 25/05/2022 21:10, Alessandro Bertulli wrote:
> >
> > I'm not sure if it's the best way to do so, but it worked for me by
> > using a lambda:
> >
> > (setq citar-file-open-function '(lambda (file)
> > (async-shell-command (format-message "sioyek \"%s\"" file
>
> First of all, it is unsafe. File names for papers downloaded from
> various sources may have enough fancy characters including double
> quotes, etc. having special meaning for shell.
>
> Use at least `shell-quote-argument' instead of adding double quotes.
>
> Depending on your OS I suggest to have a look at the implementation of
> `browse-url-xdg-open', `browse-url-default-macosx-browser',
> `browse-url-default-windows-browser' for an example how to start
> external viewer process.
>
> On 25/05/2022 18:00, Bruce D'Arcus wrote:
> > You just need to set `citar-file-open-function` to your preferred
> > function; say xdg-open.
>
> Is there a reason to avoid emacs global or even system global settings
> obtained through mailcap.el? While `mailcap-view-file' is quite new
> addition, the function was inspired by `org-open-file' and the latter
> queries mailcap settings.

No reason, other than that nobody suggested it.

It could be, however, that when using citar, some users may have more
specialized needs. For example, maybe Alessandro wants to use Sioyek
when reading PDFs of scholarly articles and such, but the standard
system PDF viewer otherwise.

But I suppose these aren't mutually exclusive; citar could always,
notwithstanding the bug you note below, fallback to making use of
mailcap?

> Actually I suspect that there may be some problems especially with
> Emacs-27 (see "org--file-default-apps" thread), but the consequences is
> not clear for me yet.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247
> mailcap-mime-data erased when parsing mime parts
>

Re: Opening org-cite links with different application

[Bruce D'Arcus]

Just curious:

I'm not familiar with Sioyek (though it looks cool!); why do you need
a lambda there?

On Wed, May 25, 2022 at 10:10 AM Alessandro Bertulli
 wrote:
>
> Thanks! Precise as always.
>
> I'm not sure if it's the best way to do so, but it worked for me by
> using a lambda:
>
> (setq citar-file-open-function '(lambda (file)
>   (async-shell-command (format-message "sioyek \"%s\"" file
>
> Moreover, since I don't really care about the terminal output of the PDF
> viewer, I followed an Emacs SE suggestion
> (https://emacs.stackexchange.com/a/58341/29817) and made the output
> buffer not brought up:
>
> (add-to-list 'display-buffer-alist '("*Async Shell Command*"
> display-buffer-no-window (nil)))
>
> which, in case I want to inspect it, it's still visitable with the usual
> C-x b.
>
> Thank you!
>
> Alessandro

Re: Opening org-cite links with different application

[Bruce D'Arcus]

On Wed, May 25, 2022 at 6:53 AM Alessandro Bertulli
 wrote:

> How can I make Org open the PDF file of a resource, using an external
> application?
>
> Let me explain: with the point on a org-cite link, pressing C-c C-o asks
> me for the resource to open. Selecting the PDF file opens it with
> DocView. I want instead to open it with an external PDF viewer
> (specifically, Sioyek). But I can't make it do so! Changing
> org-file-apps works only when I open "file:" type links. Apparently,
> org-cite links don't read that value.
>
> So I'm asking, particularly to org-cite people: is there a way to do so?

This is not an org-cite issue per se; it's a citar issue, since that
package provides the org-cite "follow" functionality.

You just need to set `citar-file-open-function` to your preferred
function; say xdg-open.

Note that this may change in the future; I'm contemplating making it
an alist so you can set different ones for different extensions.

Bruce

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Thu, Apr 21, 2022 at 4:06 AM Nicolas Goaziou  wrote:

> If there's no objection, I'll add asterisk character to the list of
> allowed characters in citation style.

It's been a month without objection. Could we please add this then?


Bruce

Re: Org-cite/Citar cannot recognize neither biblatex nor natbib

[Bruce D'Arcus]

On Fri, May 13, 2022 at 9:32 AM Alessandro Bertulli
 wrote:

> Last thing: I heard that the citation part of the manual is still
> undocumented. Is this right? If so, do you think what we discovered
> (especially about manually requiring libraries) may be useful? May I
> help?

It's not undocumented; it's poorly documented :-)

https://orgmode.org/manual/Citation-handling.html#Citation-handling

I don't know the process here on this, but definitely it needs improvements.

I'm not actually sure about the processor loading issue, given that it
should have been addressed months ago?

Bruce

Re: Org-cite/Citar cannot recognize neither biblatex nor natbib

[Bruce D'Arcus]

On Fri, May 13, 2022 at 9:15 AM Alessandro Bertulli
 wrote:

...

> So, shall we conclude that latexmk has an issue with correctly
> recognizing natbib and calling bibtex?

Yes!

I just tried it now, and see the same thing. It's weird, because I
don't recall seeing that before.

I'd call that a bug.

Bruce

Re: Org-cite/Citar cannot recognize neither biblatex nor natbib

[Bruce D'Arcus]

On Fri, May 13, 2022 at 6:54 AM Eric S Fraga  wrote:
>
> On Friday, 13 May 2022 at 11:55, Alessandro Bertulli wrote:
> >> Check out org-latex-pdf-process maybe?
> >
> > I don't know the library so in depth, but I'll try, thank you!
>
> I have the following in my init file:
>
> (setq org-latex-pdf-process '("pdflatex -output-directory %o %f"
>   "bibtex %b"
>   "pdflatex -output-directory %o %f"
>   "pdflatex -output-directory %o %f"))
>
> which tells org to run pdflatex, then bibtex, and then pdflatex twice
> more to ensure that all references are satisfied.

I thought org now by default, if available, uses latexmk, which should
take care of all this?

At least, it does for me.

Bruce

Re: Org-cite/Citar cannot recognize neither biblatex nor natbib

[Bruce D'Arcus]

On Thu, May 12, 2022 at 2:31 PM Alessandro Bertulli
 wrote:
>
> Hi Bruce,
> thank you for your help. Indeed, loading both functionalities
> (require 'oc-biblatex)
> (require 'oc-natbib)
> did the trick. That's strange, though: my version of Org (get from M-x
> org-version) is Org mode version 9.5.3 (9.5.3-g69c588 @
> /home/alessandro/.emacs.d/elpa/org-9.5.3/). Shouldn't it already be
> fixed?

IDK; my version is newer:

Org mode version 9.6 (9.6-??-2bd34edb64 @
/home/bruce/.config/emacs/.local/straight/build-29.0.50/org/)

I'm using doom, which as you can tell is using straight.

Bruce

Re: Org-cite/Citar cannot recognize neither biblatex nor natbib

[Bruce D'Arcus]

On Thu, May 12, 2022 at 10:48 AM Alessandro Bertulli
 wrote:
>
> Hi again.
>
> After fixing org-ref, I was exploring org-cite and citar. Again, I'm not
> sure how to make everything work. When I try to export to a LaTeX pdf
> file, I got the error "user-error: Unknown processor natbib", despite
> I put the exact header suggested in the manual
> (https://orgmode.org/manual/Citation-export-processors.html).
> Note that the same happens if I put
> #+cite_export: biblatex
> in which case of course I get "user-error: Unknown processor biblatex".
>
> What am I doing wrong this time?

It just means org hasn't loaded that export processor.

There was a change a few months ago that should correctly autoload
processors in these situations. So assuming you're running an older
version, you have two options:

1. update your org
2. manually configure the oc-biblatex processor loading using require
or use-package

Bruce

Re: citation-style-language: new LaTeX package in TL 2022

[Bruce D'Arcus]

On Thu, May 12, 2022 at 7:11 AM Juan Manuel Macías
 wrote:

> I'm not sufficiently familiar (at the moment) with org-cite, but I share
> the news here in case this new LaTeX package could have some kind of use
> for org-cite export options.

I've played with it a bit, and it does look promising.

I think whether and where it might fit in org-cite (a feature added to
oc-csl, or a new export processor) might depend on how its command
options evolve. Right now, it has a single "cite" command.

Bruce

Re: Org-ref not working when exporting to LaTeX

[Bruce D'Arcus]

This is an aside, but I recently learned about citeproc-lua, which adds CSL
processing directly to tex and latex.

https://github.com/zepinglee/citeproc-lua

Now included in texlive 2022.

As that evolves more (there are still missing features), it could be
another viable alternative.

On Wed, May 11, 2022 at 2:19 PM John Kitchin 
wrote:
>
> The regular export is preferred for LaTeX (C-c C-e l o) is preferred for
LaTeX export as it generates the LaTeX cite commands. The version in C-c
C-e r p uses CSL for the formatting, not LaTeX, and it allows you to get
nicely formatted results without using bibtex/biblatex as the citation
processor.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Wed, May 11, 2022 at 2:15 PM Daniel Fleischer 
wrote:
>>
>> Alessandro Bertulli [2022-05-11 Wed 19:41] wrote:
>>
>> > I'm going to post my setup in a minute. The
>> > point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF
file
>> > gets produced, but it doesn't process the citation keys. For example,
in
>> > my file (see below), I got the key "acm:code" literally printed on the
>> > PDF file, in a bold font.
>>
>> Hi, org-ref uses its own export engine which you call via (C-c C-e r p).
>> Please try that and report back if there are still issues.
>>
>> --
>>
>> Daniel Fleischer
>>

Re: [oc] multiple cite_export keywords for multiple export processors?

[Bruce D'Arcus]

On Wed, May 11, 2022 at 9:55 AM Ihor Radchenko  wrote:
>
> "Bruce D'Arcus"  writes:
>
> >> Emm. org-cite-export-processors?
> >
> > So I recognize I don't fully understand the org export system, but
> > that sets global defaults.
> >
> > What if I want to set a different style on a specific document?
>
> There is also #+cite_export: keyword, but it only sets global processor.
> You cannot choose per-export backend options. So, you can use #+bind to
> set org-exportprocessors explicitly in buffer.

OIC; that's the part I was missing.

So something like this?

#+bind: org-cite-export-processors ((latex biblatex "verbose"))

It doesn't seem to work though. Is there something wrong with my syntax?

Bruce

Re: [oc] multiple cite_export keywords for multiple export processors?

[Bruce D'Arcus]

On Wed, May 11, 2022 at 9:21 AM Ihor Radchenko  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > I just saw a post on reddit that reminded me of this issue.
> >
> > User wants to use the oc-biblatex export processor for latex export,
> > but otherwise use oc-csl.
> >
> > They want to specify styles for each.
> >
> > This isn't possible currently; one has to modify the org source file
> > for each export target.
> >
> > Is there a relatively easy way to fix this?
>
> Emm. org-cite-export-processors?

So I recognize I don't fully understand the org export system, but
that sets global defaults.

What if I want to set a different style on a specific document?

Bruce

Re: citation biblatex fullcite

[Bruce D'Arcus]

On Wed, May 11, 2022 at 6:43 AM Andreas Leha
 wrote:
>
> "Bruce D'Arcus"  writes:
>
> > On Tue, May 10, 2022, 11:20 PM Andreas Leha
> >  wrote:
> >>
> >> Hi all,
> >>
> >> how can I use the (rather) new citation engine with the biblatex backend
> >> to export to \fullcite ?
> >
> > We should add a style for this that maps to biblatex fullcite and
> > natbib bibentry, and which ultimately would work as well in oc-csl.
> >
> > But in the meantime, you can create a custom one.
> >
> > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
> >
>
> Dear Bruce and Dominik,
>
> Thanks for the swift reply!  I seem to be missing something:
>
> Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles)
>
> What am I missing?

That variable was added more recently, after org-cite was merged.

Perhaps you have an older version?

Bruce

Re: citation biblatex fullcite

[Bruce D'Arcus]

On Tue, May 10, 2022, 11:20 PM Andreas Leha
 wrote:
>
> Hi all,
>
> how can I use the (rather) new citation engine with the biblatex backend
> to export to \fullcite ?

We should add a style for this that maps to biblatex fullcite and
natbib bibentry, and which ultimately would work as well in oc-csl.

But in the meantime, you can create a custom one.

(add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

Bruce

> The use-case:
> When creating (beamer) presentations I prefer to have the full citation
> on the slide rather than an abbreviation.
>
> Thanks in advance!
>
> Best,
> Andreas
>
>

[oc] multiple cite_export keywords for multiple export processors?

[Bruce D'Arcus]

I just saw a post on reddit that reminded me of this issue.

User wants to use the oc-biblatex export processor for latex export,
but otherwise use oc-csl.

They want to specify styles for each.

This isn't possible currently; one has to modify the org source file
for each export target.

Is there a relatively easy way to fix this?

Bruce

Re: Citation glitch

[Bruce D'Arcus]

You don't need citeproc-org, which is deprecated AFAIK.

Do update citeproc-el. I'm not sure when he tagged v0.9, but this is
the commit that should have fixed it.

https://github.com/andras-simonyi/citeproc-el/commit/a702e73dcbd34cbda3a7465cf0cace7529f41dcd

If you still have problems, you might report it to that project?

On Wed, May 4, 2022 at 8:45 PM Alan Tyree  wrote:
>
> I'm not sure.
>
> citeproc-0.9
> citeproc-org-0.2.4
>
> On Thu, 5 May 2022 at 10:34, Bruce D'Arcus  wrote:
>>
>> It seems this should have been fixed late in citeproc-el in 2021:
>>
>> https://github.com/andras-simonyi/citeproc-el/issues/72
>>
>> Are you using the most up-to-date code?
>>
>> On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:
>>>
>>> G'day,
>>> I have a citation problem. The bibtex entry is:
>>> @TechReport{name32:_some,
>>>   author = {{Some Company Name}},
>>>   title = {Some silly internal document},
>>>   institution =  {Some Company Name Ltd},
>>>   year = 1832}
>>>
>>> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>>>
>>> Org exports to html: Name, Some Company, Some Silly Internal Document (Some 
>>> Company Name Ltd, 1832).
>>>
>>> I thought it was a CSL problem, but pandoc exports it correctly as Some 
>>> Company Name, etc.
>>>
>>> Any help appreciated,
>>> Alan
>>>
>>>
>>> --
>>> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>>>
>
>
> --
> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>

Re: Citation glitch

[Bruce D'Arcus]

It seems this should have been fixed late in citeproc-el in 2021:

https://github.com/andras-simonyi/citeproc-el/issues/72

Are you using the most up-to-date code?

On Wed, May 4, 2022, 8:19 PM Alan Tyree  wrote:

> G'day,
> I have a citation problem. The bibtex entry is:
> @TechReport{name32:_some,
>   author = {{Some Company Name}},
>   title = {Some silly internal document},
>   institution =  {Some Company Name Ltd},
>   year = 1832}
>
> The exporter is: #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>
> Org exports to html: Name, Some Company, *Some Silly Internal Document*
> (Some Company Name Ltd, 1832).
>
> I thought it was a CSL problem, but pandoc exports it correctly as Some
> Company Name, etc.
>
> Any help appreciated,
> Alan
>
>
> --
> Alan L Tyreehttp://www2.austlii.edu.au/~alan
>
>

Re: overlap between cite syntax and link activation

[Bruce D'Arcus]

Nicolas (or Ihor?) - can you take a look at this too?

It's the second of the two stoppers that John identified.

He seems to have reported a related issue last August, but it slipped
through the cracks.

https://lists.gnu.org/archive/html/emacs-orgmode/2021-08/msg00303.html


On Sun, Apr 3, 2022 at 8:55 PM Bruce D'Arcus  wrote:
>
> On Sun, Apr 3, 2022 at 7:46 PM John Kitchin  wrote:
> ...
>
> > When I put my cursor on the org-cite line and press spc, I see a message 
> > box pop up, and the @key has a tooltip of "BARE LINK".
>
> 
>
> > Does anyone else see this?
>
> Yes; I see the same thing with your example.
>
> Bruce

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Thu, Apr 21, 2022 at 4:06 AM Nicolas Goaziou  wrote:

> If there's no objection, I'll add asterisk character to the list of
> allowed characters in citation style.
>
> More generally, what other characters should be allowed ?

This request is to accommodate latex command names, and the only
non-letter characters those use are asterisks.

I think it's fine to stop there.

Bruce

Re: [PATCH] oc-basic: Detect malformed bibtex bibliographies

[Bruce D'Arcus]

On Wed, Apr 20, 2022 at 8:28 AM Ihor Radchenko  wrote:
>
> There is an edge case triggering infinite loop in oc-basic.
>
> It is caused by bibtex-map-entries (used in
> org-cite-basic--parse-bibtex) when ran on a malformed bibtex buffer [1].
>
> The proposed patch validates the bibtex buffer before processing and
> throws an error if issues are found.  `bibtex-validate` also
> conveniently displays a list of errors with clickable links to
> problematic lines.
>
> I believe that it is useful for the users to see such issues instead of,
> say, failing silently on malformed bibliographies.
>
> WDYT?

I haven't tested it, but this is an excellent idea!

Bruce

> Best,
> Ihor
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55036
>
> * lisp/oc-basic.el (org-cite-basic--parse-bibtex): Validate the
> bibliography before parsing.  Display list of issues if any (via
> `bibtex-validate`).
> (org-cite-basic--parse-bibliography): Set buffer file name needed by
> `bibtex-validate`.  Empty the cache in case of error.
> ---
>  lisp/oc-basic.el | 38 --
>  1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el
> index 873986d07..79f7a4844 100644
> --- a/lisp/oc-basic.el
> +++ b/lisp/oc-basic.el
> @@ -214,6 +214,10 @@ (defun org-cite-basic--parse-bibtex (dialect)
>(let ((entries (make-hash-table :test #'equal))
>  (bibtex-sort-ignore-string-entries t))
>  (bibtex-set-dialect dialect t)
> +;; Throw an error if bibliography is malformed.
> +(unless (bibtex-validate)
> +  (user-error "Malformed bibliography at %S"
> +  (or (buffer-file-name) (current-buffer
>  (bibtex-map-entries
>   (lambda (key  _)
> ;; Normalize entries: field names are turned into symbols
> @@ -258,21 +262,27 @@ (defun org-cite-basic--parse-bibliography ( 
> info)
>  (when (or (org-file-has-changed-p file)
>(not (gethash file org-cite-basic--file-id-cache)))
>(insert-file-contents file)
> +  (setf (buffer-file-name) file)
>(puthash file (org-buffer-hash) org-cite-basic--file-id-cache))
> -   (let* ((file-id (cons file (gethash file 
> org-cite-basic--file-id-cache)))
> -   (entries
> -(or (cdr (assoc file-id 
> org-cite-basic--bibliography-cache))
> -(let ((table
> -   (pcase (file-name-extension file)
> - ("json" (org-cite-basic--parse-json))
> - ("bib" (org-cite-basic--parse-bibtex 
> 'biblatex))
> - ("bibtex" (org-cite-basic--parse-bibtex 
> 'BibTeX))
> - (ext
> -  (user-error "Unknown bibliography 
> extension: %S"
> -  ext)
> -  (push (cons file-id table) 
> org-cite-basic--bibliography-cache)
> -  table
> -  (push (cons file entries) results)
> +(unwind-protect
> +(condition-case nil
> +(unwind-protect
> +   (let* ((file-id (cons file (gethash file 
> org-cite-basic--file-id-cache)))
> +   (entries
> +(or (cdr (assoc file-id 
> org-cite-basic--bibliography-cache))
> +(let ((table
> +   (pcase (file-name-extension file)
> + ("json" 
> (org-cite-basic--parse-json))
> + ("bib" 
> (org-cite-basic--parse-bibtex 'biblatex))
> + ("bibtex" 
> (org-cite-basic--parse-bibtex 'BibTeX))
> + (ext
> +  (user-error "Unknown 
> bibliography extension: %S"
> +  ext)
> +  (push (cons file-id table) 
> org-cite-basic--bibliography-cache)
> +  table
> +  (push (cons file entries) results))
> +  (setf (buffer-file-name) nil))
> +  (error (setq org-cite-basic--file-id-cache nil)))
>(when info (plist-put info :cite-basic/bibliography results))
>results)))
>
> --
> 2.35.1
>
>
>
> --
> Ihor Radchenko,
> PhD,
> Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
> State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
> University, Xi'an, China
> Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
>

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 10:06 AM John Kitchin  wrote:
>
> Bruce and I looked into this UI approach in 
> https://github.com/jkitchin/org-ref-cite/issues/9. Bruce and I discussed and 
> worked on this for almost two weeks. There are 70 comments in this issue.
>
> There are opportunities now to annotate completion targets, which you can see 
> in the link above. The annotations are not selectable though during 
> completion, and this implementation was not too fast as I recall.

FWIW, an alternative I was playing with is something like this, which
makes use of the new oc-biblatex styles defcustom:

(defcustom style-select-latex-commands nil
  "Whether to use latex commands for style selection."
  :group 'style
  :type '(boolean))

(defun style-latex-alist ( swap)
  "Return org-cite-biblatex-styles as alist.
By default, each car is the latex command, and the cdr the
org-cite style with variant. With SWAP, they are reversed."
  (let ((raw-styles org-cite-biblatex-styles))
(mapcar
 (lambda (s)
   (let* ((style (elt s 0))
  (variant (elt s 1))
  (command (elt s 2))
  (cstyle (concat style (when variant "/") variant)))
 (if swap
 (cons cstyle command)
 (cons command cstyle
 raw-styles)))

(defun style-select ()
  "Select oc style."
  (let* ((latex-commands style-select-latex-commands)
 (styles
 (if latex-commands (style-latex-alist)
   (style-latex-alist t)))
 (choice
  (completing-read
   (if latex-commands "Biblatex command: "
 "Style: ") styles)))
(cdr
 (if style-select-latex-commands (assoc choice (style-latex-alist))
   (rassoc choice (style-latex-alist))

> You probably should also augment the tooltips like this because you have to 
> be able to tell what a citation format is in the future too, not just at 
> insert time, e.g. suppose you are reading work of a collaborator. It was hard 
> to write, and ambiguous in ways, e.g. what is the export backend you want? 
> The annotations should differ for LaTeX (where you want to see the latex 
> command) vs HTML (where you probably want to see the formatted CSL cite)...

I was thinking it'd be enough to have a tooltip preview of the
citation, and allow the actual preview to be configurable.

Bruce

> We did not surmount these challenges at the time. Maybe others will succeed 
> in this another day.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Mon, Mar 21, 2022 at 8:42 AM Bruce D'Arcus  wrote:
>>
>> On Mon, Mar 21, 2022 at 8:23 AM John Kitchin  wrote:
>>
>> >> A package could be created, say `org-cite-literal-biblatex' which is just 
>> >> a copy
>> >> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' 
>> >> and
>> >> `org-cite-biblatex-style-shortcuts' (or just sets those variables in
>> >> `org-cite-biblatex'). As far as I can tell this would provide exactly the
>> >> functionality you say org-cite can’t provide but org-ref does.
>> >
>> >
>> > I wrote this package you suggest in org-ref-cite. In discussions during 
>> > that development, it was clear the preference was on the more abstracted, 
>> > and uniform syntax across backends cite commands in org-cite, and not this 
>> > kind of variant. Of course one can do this. It is not that org-cite can't 
>> > provide it, it is that it doesn't at this time.
>>
>> Just for some broader context on this particular issue.
>>
>> The advantage of the org-cite style/variant design reflected in the
>> included export processors (natbib, biblatex, csl) is that the same
>> styles will mostly generate the same final output.
>>
>> But that portability will only work with those styles and variants.
>>
>> With the new org-cite-biblatex-styles defcustom, however, one can
>> augment or completely replace all those. But if you care about that
>> portability, you'd want to be aware of this, and think about it.
>>
>> So per Timothy's point, you actually don't even need a new processor
>> for biblatex if you want to include all the extensive list of biblatex
>> commands.
>>
>> Natbib AFAIK is already fully covered.
>>
>> There's another POV on this though:
>>
>> If one doesn't like to see the org-cite styles, because of familiarity
>> with LaTeX commands etc., I would argue that can be addressed in the
>> style part of an insert processor and/or in an activate processor.
>> E.g. I would argue this is a UI issue; not fundamentally about the
>> styles names.
>>
>> Bruce

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Mon, Apr 18, 2022, 5:08 AM Ihor Radchenko  wrote:

> John Kitchin  writes:
>
> >> In contrast, [cite/citet*:@key] is likely to be used fairly frequently
> >> and has much higher chance to break things.
> >
> >
> > We have had a citet*:key link (and all the other * variants) for a long
> > time in org-ref, with no reported issues I can recall.
>
> I respect your experience in this regard. If the discussed issue is
> uncommon in practice, we may simply provide citet* and similar styles +
> fallback citet*/ as an alias. The citet* will be the default while
> citet*/ may be suggested, say, by org-lint if we add a new checker for
> this.
>

Just to clarify, I don't believe the discussion is to add such styles to
the included org-cite processors (which already support such
functionality), but rather to allow it, for example for third party ones;
say a hypothetical org-ref one.

Bruce



> P.S. Thinking more about org-lint, I imagine that it could be a good
> practice to run org-lint before every export. For example, it can save
> people from a common problem with handling broken links during export.
>
> Best,
> Ihor
>

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Thu, Apr 7, 2022 at 7:30 AM John Kitchin  wrote:

> On Thu, Apr 7, 2022 at 12:17 AM Ihor Radchenko  wrote:
>
>> "Bruce D'Arcus"  writes:
>>
>> > On Sun, Apr 3, 2022 at 5:07 PM John Kitchin 
>> wrote:
>> >>
>> >> I was looking into using latex commands as styles in org-cite, e.g.
>> >>
>> >> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is
>> not allowed. Could that be allowed?
>> >
>> > I have no insight into the restriction, but I hope it can be removed.
>>
>> I do like the proposal in general, but I can see a potential issue for
>> users. Constructs like "word*:" can be recognised as a valid bold
>> emphasis ending. For example:
>>
>> >>> Some *bold emphasis with reference [cite/citet*:@key] will end
>> >>> at "citet*", but not here*.
>>
>
> That is a fair point, and also an issue with links that have * in them
> (which is also already allowed). I can't say it has ever been reported as
> an issue though.
>
>>
>> Note that inserting zero-width space will not only be awkward here, but
>> also breaks parser: e.g. [cite/citet:@key] is not currently
>> recognised as a citation.
>
>
> A less awkward solution (IMO) would be to use an entity like ⋆.  It is
> straightforward to add that to the org-element-citation-prefix-re. Then I
> see something like this.
>
> [image: image.png]
> I don't know how difficult it would be to improve the emphasis handling,
> it seems like the start/end markers should not cross some element
> boundaries.
>

So Ihor, is there any problem with John's proposed change here?

Seems sensible to me.

Bruce



>
>
>>
>> Best,
>> Ihor
>>
>

Re: [BUG] org-cite does not support techreport, mastersthesis, phdthesis, and conference entries [9.5.2 (release_9.5.2-426-gf6813d @ /usr/share/emacs/site-lisp/org/)]

[Bruce D'Arcus]

On Fri, Apr 8, 2022 at 3:51 PM Rick Lupton  wrote:
>
> I also found this recently. The reason is that BibTeX-dialect is set by 
> org-cite-basic--parse-bibliography in oc-basic.el based on the file 
> extension. Renaming your bibliography file to end in “.bibtex” instead of 
> “.bib” should make it be parsed using the bibtex rather than biblatex dialect.
>
> I did find this surprising, as I’ve always just used “.bib” for both dialects 
> ...

Yeah.

Perhaps the code should instead use of ~bibtex-dialect~, rather than,
as now, reset that variable based on the file extension?

Bruce

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Tue, Apr 5, 2022 at 12:11 PM John Kitchin  wrote:
>
> Would you find it suitable to use [cite/command:pre @key post] in general?

I think it's a reasonable approach that would appeal to some users who
would treat org as a front-end to LaTeX primarily, and obviously
previous org-ref users, and that it's better than supporting this in a
parallel but incompatible syntax.

> For portability, I suppose there could be a defcustom mapping if one wanted 
> to leverage the oc-csl library with pretty minimal effort.

Right.

I'm not sure what the precise right solution is, where, but something like that.

oc-biblatex, for example, has the new org-cite-biblatex-styles
defcustom, whose list entries look like:

("author"   "caps"  "Citeauthor*" nil nil)

So with that, a oc-biblatex user can already do this presumably.

("Citeauthor*"   nil  "Citeauthor*" nil nil)

But could also have a new org-ref processor with a simpler defcustom like:

("Citeauthor*" . "author/caps")

> I think two things need to be addressed to fix that. First is allowing a * in 
> the style/variant section; there are probably 17 or so of these commands in 
> natbib/biblatex. Second is fixing org-activate-link so that link activation 
> functions don't get called on something like [cite/citet:@key]. This is 
> necessary for org-ref and org-cite to co-exist, but also other packages or 
> users might also define links like cite:.

+1

Bruce

Re: org-cite styles don't allow * in them

[Bruce D'Arcus]

On Sun, Apr 3, 2022 at 5:07 PM John Kitchin  wrote:
>
> I was looking into using latex commands as styles in org-cite, e.g.
>
> [cite/citet:@key]. That example works fine, but [cite/citet*:@key] is not 
> allowed. Could that be allowed?

I have no insight into the restriction, but I hope it can be removed.

It occurs to me in that scenario it should be easy to write a function
that allows users to toggle between the two sets of styles: the direct
latex ones, and the more general default org-cite ones.

Bruce

Re: overlap between cite syntax and link activation

[Bruce D'Arcus]

On Sun, Apr 3, 2022 at 7:46 PM John Kitchin  wrote:
...

> When I put my cursor on the org-cite line and press spc, I see a message box 
> pop up, and the @key has a tooltip of "BARE LINK".



> Does anyone else see this?

Yes; I see the same thing with your example.

Bruce

Re: org-cite and text/Unicode export

[Bruce D'Arcus]

On Sat, Apr 2, 2022 at 10:50 AM Max Nikulin  wrote:

> I am unsure to what degree it is Org issue, it may be partially
> citeproc.el or CSL style issues.

One quick way to narrow this down is to run it through pandoc, which
supports org-cite.

It uses a different, haskell-based, CSL processor.

Bruce

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

[Bruce D'Arcus]

On Thu, Mar 31, 2022 at 11:27 AM Max Nikulin  wrote:



> >> Emphasis and bold markers may appear in plain text export. Behavior of 
> >> styles is
> >> not uniform in respect to adding (unbreakable?) space before citation.
> >
> > Sorry; not following here again. Isn't the space before a citation
> > determined by the user?
>
> I was lucky enough to pick a couple of styles having different behavior.
> Notice additional unbreakable space before "[1]" in the second example.
> I have checked a couple of IEEE papers and they have spaces before
> citations, so to switch from IEEE to APS style it is necessary to remove
> spaces before citations.

The latter style includes a non-breaking space in the citation definition ...

https://github.com/citation-style-language/styles/blob/21e2177295be5b98ef49b00dd4b8cc7e68d2143d/american-physics-society.csl#L96

... which strikes me as odd, though would explain what you see.

The former has no space.

Bruce

Re: org-cite styles as flags (idea)

[Bruce D'Arcus]

On Wed, Mar 30, 2022 at 8:36 AM Max Nikulin  wrote:
>
> Hi,
>
> In a recent thread it was discussed that currently style selection is
> not always obvious:
>
> John Kitchin. citations: org-cite vs org-ref 3.0.
> Sun, 27 Mar 2022 13:00:40 -0400.
> https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu
>
> > [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.
>
> It seems, no backends uses hierarchy of substyles. Please, correct me, I
> may be wrong since I was BibTeX user and have not tried BibLaTeX.
>
> I have an idea to consider each component started from slash as
> independent boolean flags (or constraints), so they can be reordered
>
> /author/bare/caps = /caps/bare/author

An earlier version of the oc processors had that syntax, but Nicolas
found it too complex to implement.

But I'm not sure; it's possible your suggestion differs from that
beyond the syntax.

Practically speaking, it's useful for portability if an author does
"text/x" and an export processor doesn't support "x", that it still
will use "text".

Bruce

> For citeproc.el it is a natural mapping since e.g. noauthor is
> implemented as a value of suppress-author parameter. For BibTeX commands
> it may be described as set of properties, so the code discards ones
> inconsistent with provided criteria. E.g. (:bare t :author nil :noauthor
> t :full nil) for \citeyear, :caps does not matter.
>
> As at was suggested earlier, /year modifier existing in oc-csl should be
> implemented for oc-natbib.
>
> [cite/author/noauthor:...] should generate a warning as an impossible
> combination and fallback to defaults.
>
> The origin of the proposal is the following part of the discussion:
>
> Bruce D'Arcus, Tue, 29 Mar 2022 12:14:03 -0400
> https://list.orgmode.org/caf-fpgocm5m5jzsou-37v77me76ewwg_xcd4d7k30ffxs0h...@mail.gmail.com
> > On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote:
> >
> >> It seems modifiers are set of boolean flags (positive "year" or negative
> >> "suppress-author") in citeproc.el, set of values in natbib, and a kind
> >> of hierarchy in org-cite. From my point of view, set of constrains
> >> (flags) is the most general variant in this list.
> >
> > I think that's right, and is how it's represented in a GUI app like
> > Zotero. But that's not so convenient in a plain text format.
>
> I may easily miss something important making such idea broken. At least
> it looks like a backward-compatible change if old /caps-full is mapped
> to new /caps/full (or /full/caps).
>
>

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

[Bruce D'Arcus]

On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin  wrote:
...

> >> You even have managed to convince me that, besides adding missing style
> >> names, some existing ones should be adjusted. noauthor/bare for citeyear
> >> example makes for me much more sense ...
> >
> > This does need some attention, but there are wrinkles here.
> >
> > Citeyear is specific to author-date styles, while noauthor is intended
> > to be more general.
>
> Anyway citation style is rather specific for a particular CSL style. I
> tried some styles:
> https://github.com/citation-style-language/styles/blob/master/ieee.csl
> https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl
> nature.csl science.csl and for all these styles even "author" is
> meaningless since they are numeric styles.

Yes. I think it's more relevant in author-date to note styles. I
believe biblatex has a command relevant here, but Denis knows biblatex
better than I.

> So it is not more general. Switching CSL style means necessity to update
> styles in each citations (unless it is possible to specify global or
> per-cite mapping).

Not really. Arguably the most important style is "text", which applies
to any output style; author-date, note-based, numeric.

When you start getting into some of the others, the range of styles a
given style may apply to shrinks.

But you might say author-date styles are pretty dependent on such
local citation modification. If those are output to a style that has
no such notions (like a numeric one), then a processor can just ignore
it.

> It seems modifiers are set of boolean flags (positive "year" or negative
> "suppress-author") in citeproc.el, set of values in natbib, and a kind
> of hierarchy in org-cite. From my point of view, set of constrains
> (flags) is the most general variant in this list.

I think that's right, and is how it's represented in a GUI app like
Zotero. But that's not so convenient in a plain text format.

But it's a good way to explain the differences.

> > I think it's probably a good idea to add "year" to the latex processors too.
>
> I agree. Negations are more confusing when an author needs just year.

We might as well do that then, along with bibentry/fullcite.

...

> I am familiar with bst language used by BibTeX and I am surprised that
> initials instead of full names are not enforced by CSL styles.

I'm not following here. Certainly one can specify initialization rules
in a CSL style.

WDYM by "enforced"?

> Emphasis and bold markers may appear in plain text export. Behavior of styles 
> is
> not uniform in respect to adding (unbreakable?) space before citation.

Sorry; not following here again. Isn't the space before a citation
determined by the user?

Bruce

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

[Bruce D'Arcus]

On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin  wrote:
>
> On 28/03/2022 02:40, John Kitchin wrote:
> > Max Nikulin writes:
> >> On 21/03/2022 18:51, John Kitchin wrote:
> >
> > 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.
>
> I have some ideas for links, other inline objects and export attributes
> that I should try before.
>
> >> 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.
>
> John, in another message (Sun, 27 Mar 2022 13:00:40 -0400)
> https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly
> stated a technical limitation that is a real reason why org-cite is not
> an option for you and for some other users: performance has not been
> optimized for large BibTeX databases. It is deserved to be mentioned.

FWIW, Ihor posted a patch related to this a week or so ago.

> You even have managed to convince me that, besides adding missing style
> names, some existing ones should be adjusted. noauthor/bare for citeyear
> example makes for me much more sense ...

This does need some attention, but there are wrinkles here.

Citeyear is specific to author-date styles, while noauthor is intended
to be more general.

Hence, initially "noauthor".

This indeed was influenced by CSL implementations like Zotero and
pandoc, which have a notion of "suppress author".

But the names are kind of awkward admittedly, and Andras Simonyi
subsequently added a "year" style in oc-csl.

You can see the conversation about it here.

https://github.com/andras-simonyi/oc-csl-ns/issues/1#issuecomment-895440897

I think it's probably a good idea to add "year" to the latex processors too.

I will reproduce Denis' explanation from that linked comment here:

---
The reasoning behind "noauthor" vs "year" was that our priority was
portability between different classes of citation styles. If we have
this item "John, Doe. /A book/. 2020." the variant "noauthor" can be
used to render this consistently.

In-Text:
a) author-year: "(2020)"
b) author-title: "(/A book/)"

Author-title in footnote: "/A book/. 2020."

Here, it's not so much about what information should be rendered, but
rather what should be ommitted.

"Year" would be much less portable. That doesn't mean that "year"
couldn't be legitimate, in the sense of "I really need the year here".
But that raises another question: How will citeproc-el know where this
year is coming from, and how the year has to be formatted? That will
have to be hardcoded in the processor as styles contain no information
about this.


Bruce


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
>

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]

I obviously can't speak for John, but on this:

On Fri, Mar 25, 2022 at 1:11 PM Max Nikulin  wrote:
>
> On 21/03/2022 18:51, John Kitchin wrote:
> >
> > citenum and bibentry are the only two I am not sure have a CSL analog.

As I said in an earlier message, it's no problem to add these. Someone
can always add the bibentry/fullcite style to oc-csl later, if and
when Andras adds the functionality to citeproc-el.

Though it's feasible, I doubt you'll ever see citenum in CSL, since
those sorts of low-level commands don't really fit there.

But that also is not a problem.

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

The mapping defcustom is currently only in oc-biblatex. It might be
worth adding it to oc-natbib, and so generalizing how these mappings
are handled in latex?

Bruce

> Are there still any technical limitations that prevent getting in the
> exported LaTeX file the same citation commands as for org-ref?
>
> 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.
> 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.
>
>

Re: [oc] provide style/citation preview?

[Bruce D'Arcus]

On Fri, Mar 25, 2022 at 8:55 AM John Kitchin 
wrote:

> I think this kind of preview is well-suited for external packages.

You may be right.

> There is a subtle point I ran into with this preview approach though,
> and that is what is the backend export you want to see? People expect
> one source (org) to export to different backends, and even use one
> source to make a PDF and HTML (and maybe others). Now it also possible
> to use different citation styles for different backends, and the
> backends may use different citation processors (e.g. bib(la)tex or CSL).
> I felt this was too complex to try to get right in one package. External
> packages could provide any subset of these they want, e.g. the way
> https://github.com/andras-simonyi/org-cite-csl-activate does. My opinion
> of course.

oc-csl-activate uses org-cite-csl--fallback-style-file for the preview
style, but also has a org-cite-csl-activate-use-document-style defcustom to
optionally override that. A LaTeX preview wouldn't need this.

Seems more generally a user would need to be able to specify what the
export target is.

But I guess per your point, one could do configuration by simply selecting
whatever preferred activate processor. So, for example, we could have one
for latex preview.

> I think the basic CSL styled citation tooltip that is independent of the
> final state is a good compromise. The point is to give enough context
> about the key to tell you what it is without visiting the source, and if
> you need more, you go visit the source (bibtex file, org file, etc.).

Indeed.

Bruce

Re: [oc] provide style/citation preview?

[Bruce D'Arcus]

On Thu, Mar 24, 2022 at 12:33 PM Vikas Rawal  wrote:

>> So I'm just wondering how best to dynamically generate those previews,
>> perhaps even just using a pre-selected reference*, and if maybe oc
>> could make that easier?
>>
>
> Some kind of overlay that shows citations as they would (at least as close as 
> possible) look in the export?

Something like this?

https://github.com/andras-simonyi/org-cite-csl-activate

I think he was hoping to incorporate that into the oc-csl processor at
some point, and that would indeed be another approach to in-buffer
previewing.

The issue I have is more just generating the preview content for
incorporation into the completion annotations.

Bruce

[oc] provide style/citation preview?

[Bruce D'Arcus]

This is an idea related to an issue John Kitchin and I were trying to
sort out a few months back, that he mentioned in another thread.

https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00274.html

The question is how to help users understand the relation between oc
styles and target output.

There are two places where this matters:

1. selecting the style (say in a completion list)
2. previewing the citation after the fact (for example, hovering over
it in the buffer)

On 2, right now in oc-basic, if one hovers over a key, one gets a
tooltip preview of the rendered bibliographic entry, which is very
handy.

Picking up an idea that John mentioned in the above message, would it
be feasible when hovering over the prefix (the part before the colon)
to get a preview of the citation? By "feasible" I mean a good idea
from a UX POV, and without any obvious performance penalties.

As for the point he raises about which export backend to preview,
perhaps that should just be via a "citation-preview" defcustom?

So if one selected, say, natbib, one would see something like "\textt"
in the tooltip.

On 1, in citar I currently have a UI with a grouped list of
style/variants, and a user-defined static preview for each, something
like this:

- default 
/ (de Ville, 2020)
...
--- text --
/text   de Ville (2020)
/text/caps   De Ville (2020)
...

So I'm just wondering how best to dynamically generate those previews,
perhaps even just using a pre-selected reference*, and if maybe oc
could make that easier?

* One wrinkle in general here is that in the LaTeX intermediate export
targets, you really don't care about the reference data, or even the
key; you just care about what the command is. With the CSL rendered
output, you do care about that.

Bruce

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)))

[Bruce D'Arcus]

On Wed, Mar 23, 2022 at 7:10 AM Ihor Radchenko  wrote:
>
> Dear all,
>
> There were several people who came to the last meetup looking for
> information about debugging Org mode. The last meetup was rather
> unhelpful in this regard since we dove into a specific use-case.
>
> I plan to try once more providing a more general introduction to Org
> (and Emacs) debugging. Tentatively, I plan to talk about:
> 1. Running Emacs with clean configuration + latest version of Org
> 2. Bisecting config to find configuration-related issues
> 3. Using Emacs profiler and sharing profiler results
> 4. Answer any questions on the first three topics

This is a great idea, Ihor. Have you considered recording this part
and sharing it?

Bruce

> After the introduction, we can continue with interactive debugging if
> there is anyone experiencing performance (or other) issues with Org and
> willing to share screen.
>
> Note that using microphone and/or camera should not be required. Jitsi
> does have chat.
>
> 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.
>
> Best,
> Ihor
>

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

[Bruce D'Arcus]

On Wed, Mar 23, 2022 at 1:19 PM Max Nikulin  wrote:

> My point was that it should not be unconsciously ignored. Since the
> message was long enough, this particular complain may remain unnoticed.
> I can not say that I fully agree with your decision, but I respect it. I
> had no intention to upset you and I beg your pardon if it happened.

No personal offense taken. I was just a bit frustrated with the
direction this discussion seemed to be going.

Bruce

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

[Bruce D'Arcus]

On Wed, Mar 23, 2022 at 6:04 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou  
> > wrote:
>
> >> I can add it, but "full" is already the name of a variant, so
> >> [cite/full: ...] and [cite/style/full: ...] would mean different things.
> >> Is this a problem, or do you think of a better style name?
> >
> > FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex 
> > "bibentry".
> >
> > That might be a reasonable alternative style name?
> >
> >> Also, are there possible variants for this style?
> >
> > AFAIK, no.
>
> Hmm, OK. What about:
>
>   (“fullcite” nil “fullcite” nil nil)
>
> ?

Seems fine by me, so long as you use the same name for natbib if and
when you add bibentry support?

Bruce

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

[Bruce D'Arcus]

On Wed, Mar 23, 2022 at 5:27 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> Dominik Schrempf  writes:
>
> > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
> >
> > (This or something similar should be added upstream).
>
> I can add it, but "full" is already the name of a variant, so
> [cite/full: ...] and [cite/style/full: ...] would mean different things.
> Is this a problem, or do you think of a better style name?

FWIW, Nicolas, biblatex "fullcite" is equivalent to natbib/bibtex "bibentry".

That might be a reasonable alternative style name?

> Also, are there possible variants for this style?

AFAIK, no.

Bruce

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

[Bruce D'Arcus]

On Wed, Mar 23, 2022 at 8:52 AM Max Nikulin  wrote:
>
> On 23/03/2022 00:20, Bruce D'Arcus wrote:
> > On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin wrote:
> >>
> >> John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400.
> >> https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu:
> >>
> >>> I don't know the equivalent of \citenum in CSL.
> >
> > Right; so John or someone else should send a message to the list
> > requesting it specifically?
>
>  From my point of view he has already requested support of \citenum by
> that message.

I just mean here, in general. If people complain about missing
mappings or performance issues silently, or elsewhere, without ever
raising them on the list, then it's hard to address them.

> I have an impression that the ball is on the side of the org-cite, and
> next steps may be to ask for real documents (e.g. open access papers)
> that are prepared with such format and to discuss most suitable style
> for CSL.

Suffice to say I disagree :-)

Sorry if the below gets wordy, but it's complicated.

Finding and analyzing existing papers again raises the question of
which ones; citation practices look VERY different in chemistry than
in art history or sociology. It also raises the question of who will
do this work, and whether it's the most efficient use of their time.
And finally, your suggestion seems to assume we didn't put a lot of
research and thought into the existing mappings.

Have you actually looked at the table of existing mappings? See table
1 here (which it seems we might want to add to the manual?):

https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax

Those mappings merely generalize existing systems (bibtex, natbib,
biblatex, csl) used by millions of users (if you include Zotero,
etc.), and already incorporate the feedback of those users.

So the styles included now ARE a sound starting point, that we can
iterate based on feedback.

We can and should add "number" and "entry" (for "bibentry" and
biblatex "fullcite") styles to those mappings, however, at least for
natbib and biblatex. But the first is one of those lower-level types
of commands, and probably why it's not there now.

On that last point, I do want people to understand that there are
places where you can't easily generalize across those systems, because
the logic of them varies in places. Biblatex, most notably, has IIRC
more than 50 commands, which also vary by style used. And some of
those commands (like autocite) are high-level and appropriate for this
sort of mapping, and others (like footcite) are low-level, and
probably not. Adding every option may make a small number of power
users happy, but at the expense of raising complexity for others.
Which is why the new defcustom is a good compromise.

CSL is different here than the LaTeX alternatives, as Andras can just
add support for some feature to citeproc-el, and add a style for it to
oc-csl. But CSL also has a different design than the LaTeX options,
and so will always be simpler. For example, in effect, all citations
in a CSL systems work like biblatex's "auto" commands. If one uses a
note-based citation style, citations get automatically footnoted, for
example, and so one can seamlessly change between note-based and other
kinds of styles, without having to modify the document source.

So missing mappings aren't necessarily an oversight; it might just be
that how to implement them was unclear, or whether users would need or
want them.



Bruce

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

[Bruce D'Arcus]

On Tue, Mar 22, 2022 at 10:42 AM Max Nikulin  wrote:
>
> On 21/03/2022 22:19, Bruce D'Arcus wrote:
> > On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin wrote:
> >
> >> A bit of routine work will alleviate some user issues:
> >> - add missed styles
> >
> > The initial list of style-command mappings was pretty comprehensive,
> > but we left out some of the more obscure biblatex commands because
> > unsure if they were needed, or how best to add them (conceptually
> > there's a mix of different kinds of commands in biblatex, which are
> > hard to fit into a more general style system, for example).
> >
> > Since then:
> >
> > - people have occasionally asked to add new mappings, and Nicolas has added 
> > them
> > - he's also added the styles defcustoms for biblatex, so users can do
> > this themselves
> >
> > In short, I think we're good on this actually.
>
> John Kitchin, this thread, Sun, 20 Mar 2022 20:31:29 -0400.
> https://list.orgmode.org/m2sfrc149c@andrew.cmu.edu:
>
> > I don't know the equivalent of \citenum in CSL.

Right; so John or someone else should send a message to the list
requesting it specifically?

That's how we've done it so far anyway. Not sure what the practical
alternative is.

I will say that much of this discussion is not about org-cite per se,
but rather implementation decisions in the specific bundled
processors. I fear these conversations get hard to track if we aren't
precise about what we're talking about; citation syntax, included
processor functionality or style mappings, documentation, etc.

>  From my point of view it may be a reason to add a new style to
> defaults. It is important whether a tool works out of the box.

But the question here becomes "works for whom?" Citations practices
vary a fair bit by field.

Primarily LaTeX/natbib users like John and other science folks,
biblatex users primarily coming from the humanities as near as I can
tell? Or people coming from markdown and pandoc (which has an
excellent citation system that clearly inspired org-cite) and needing
Word-ready documents for journals etc?

The style system in the bundled processors is designed to work for all
of them, and not privilege one or another. It does this by creating a
new, more general, org-cite style and variant system, which then maps
to different targets.

That approach has obvious advantages: citations are (mostly) decoupled
from particular export processors. One can write a document with these
styles, and get PDF citation and bibliographic output via biblatex,
for example, similar to the HTML or ODT output from the CSL export
processor.

And that also has advantages beyond org. For example, pandoc recently
added support for org-cite, and that includes mapping between the two
style/command systems. So in theory you could convert an org file to
docx, letting pandoc process the citations along the way, and the
result would more than acceptable.

> Custom variables make a document less portable unless they are specified as
> file-local ones.

Indeed!

Or more specifically here, it ties the citations to the export processor.

But maybe for some or many people that's perfectly fine.

One possible idea to consider is to allow two systems in each of
LaTeX-oriented processors: what we might call a default "org-cite"
one, and an optional "literal" one. So if you only use oc-natbib, and
you want the natbib commands directly, you might change a variable to
get that.

I really don't know if that's a good idea or not, but I raise it to
emphasize there's a lot of flexibility with the org-cite design, and
so it's just a question of how we make use of it.

> I think, the goal may be formulated as "John can not
> say the following any more" (at least in respect to citations leaving
> aside cross-references):
>
> > I simply cannot
> > compromise on the capability org-ref provides me, or wait for an
> > alternative complete solution in org-mode.

I don't really see why these are the two choices.

> On the other hand I do not consider the following argument as a strong one
>
> > I do not like the abstraction away from LaTeX cite commands in org-cite.
> > This is an example of a compromise between LaTeX and CSL.
>
> despite I believe that convenience and habits are important. Mapping of
> styles to commands is just a piece of knowledge.

Yes.

> I have no particular opinion if enough efforts should be invested from
> both sides to allow mixing on both citation syntax constructs (org-cite
> and org-ref) in the same document. Bruce, you made a lot for support of
> CSL in org-cite, so I will stressed another direction of feature
> comparison since Bib(La)TeX users should feel themselves first-class
> citizens.

Absolutely! In fact, Denis M

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 10:41 AM Max Nikulin  wrote:

...

> A bit of routine work will alleviate some user issues:
> - add missed styles

The initial list of style-command mappings was pretty comprehensive,
but we left out some of the more obscure biblatex commands because
unsure if they were needed, or how best to add them (conceptually
there's a mix of different kinds of commands in biblatex, which are
hard to fit into a more general style system, for example).

Since then:

- people have occasionally asked to add new mappings, and Nicolas has added them
- he's also added the styles defcustoms for biblatex, so users can do
this themselves

In short, I think we're good on this actually.

> - improve documentation, e.g. to make backend choice more conscious.

This is the bigger user-facing issue that could use attention.

> Another point is more serious. Besides citations there are internal
> cross-references. Org supports them but only in a rudimentary form.

Indeed, the question of how to better support cross-references in org
is an important one.

I don't really use them much, and so am still unsure if this could be
addressed with incremental improvements in existing org link support,
or if it would require more significant enhancements.

Perhaps we need the community to itemize what the gaps and limitations
are there?


Bruce

> Actually cross-references are similar to citations in the sense that
> they can have style, prefixes and suffixes, and their appearance depends
> on target properties. Another feature is grouping. However
> cross-references should not be handled by citation backends, they
> require different handlers. Unfortunately there is no way to define
> custom "citation" type e.g. "[ref:...]" in addition to "[cite:...]".
>
> I can not judge if uniform UI issues are really severe and if it would
> be convenient if depending on prefix argument either org-cite or org-ref
> command would be called for a citation or for a reference.
>
> Actually "[cite:...]" construct is a kind of link with additional
> flexibility missed for regular links. Anything besides target and
> description requires some workarounds. Usual approach is proliferation
> of link types. E.g. inline source blocks allows almost arbitrary extra
> parameters. Citation syntax is rather domain specific, it allows more
> than regular links, but for convenience the set of properties is fixed:
> style, prefixes, locators, suffixes. It is impossible to add extra one.
>
> To assign additional properties, info "(org) Links in HTML export"
> https://orgmode.org/manual/Links-in-HTML-export.html recommends usage of
> "#+ATTR_HTML", but such technique has several issues:
> - attributes becomes specific to the export backend
> - the same attributes are added to the enclosing paragraph
>https://linevi.ch/en/org-link-extra-attrs.html
> - a paragraph may have more than one link.
> It is possible to use link target similar to form values encoded into
> URI, but it hardly can be considered as convenient for editing.
>
> Custom citation types may alleviate the issue with cross-references. It
> would be great to have more flexible links with arbitrary properties
> (and it would allow to consider citations and cross-references as
> special cases of links), but it does not fit into the Org syntax.
>
> P.S. John has a valid complain but it hardly relates to the "cite vs.
> cross-reference" topic. When some package is not loaded and link type is
> undefined then the link becomes a fuzzy one leading to user confusion.
>
>

Re: =org-cite= links do not work in the =#+title=

[Bruce D'Arcus]

There are restrictions on where citations are allowed, and this is one of them.

Citar, and I think the oc-basic, insert processors won't allow you to
insert citations in those places.

Usually there are technical reasons for the restrictions (IIRC having
to do with fontification?), but sometimes Nicolas has loosened such a
restriction if it wouldn't cause any harm.


On Mon, Mar 21, 2022 at 9:23 AM Dominik Schrempf
 wrote:
>
> When using a citation in the title, it does not seem to work when exporting 
> to LaTeX.
>
> For example (in the .org file):
>
> Exports to (in the .tex file):
>
> I am using the biblatex processor.
>
> Did anybody else encounter this problem?
>
> Dominik

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 9:13 AM Dominik Schrempf
 wrote:
>
> “Bruce D’Arcus”  writes:
>
> > On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf
> >  wrote:
> >>
> >> Thank you, I can use `citar-insert-edit` to perform this action.
> >
> > You can actually just use org-cite-insert, which is context aware.
> >
> >> Now, I failed to create a full citation in the text. This corresponds to 
> >> the
> >> `\fullcite{}’ command in LaTeX. Is there an option for this?
> >
> > No, but we should add one, as natbib has a similar command.
> >
> > And, of course, per Timothy’s point, you can customize
> > org-cite-biblatex-styles to include it in the meantime. If you want to
> > experiment with this, contact me off-list, as there’s some nuances
> > with citar.
>
> Great, that was easy, thank you:
>
> (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

On citar (the "nuance"), until I make the style UI smarter, you'll
want to add this command and a preview to
citar-org-style-preview-alist.

You might want to even completely redefine it to preview using the
biblatex command.

> (This or something similar should be added upstream).

I agree.

We just need to decide what the style name should be (and also add a
mapping from it for bibentry in natbib, and hopefully later csl). We
already have a "full" variant for "author", so another "full" might be
a little confusing.

Bruce

> >> In summary, it is a bit painful to use `org-cite` compared to using 
> >> `org-ref`.
> >> In my opinion, the main reasons are:
> >>
> >> • Documentation is missing for `org-cite`.
> >> • The citation commands seem to be incomplete (or at least not documented).
> >
> > The documentation is admittedly thin. Thoughts on what we should add?
> >
> > The styles, and how to customize them with oc-biblatex?
>
> I know writing documentation is a lot of work. It is easy to complain, but 
> hard
> to contribute. I think we need:
> • A complete description of styles and variants (for the actual citation
>   command, and also for `#+cite_export: ...') or at least a link to an
>   up-to-date table.
> • An improved description of the capabilities of `org-cite-insert' (i.e., that
>   it can change the citation style and variant).
>
> >
> > Bruce

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 8:41 AM Dominik Schrempf
 wrote:
>
> Thank you, I can use `citar-insert-edit` to perform this action.

You can actually just use org-cite-insert, which is context aware.

> Now, I failed to create a full citation in the text. This corresponds to the
> `\fullcite{}' command in LaTeX. Is there an option for this?

No, but we should add one, as natbib has a similar command.

And, of course, per Timothy's point, you can customize
org-cite-biblatex-styles to include it in the meantime. If you want to
experiment with this, contact me off-list, as there's some nuances
with citar.

> In summary, it is a bit painful to use `org-cite` compared to using `org-ref`.
> In my opinion, the main reasons are:
>
> • Documentation is missing for `org-cite`.
> • The citation commands seem to be incomplete (or at least not documented).

The documentation is admittedly thin. Thoughts on what we should add?

The styles, and how to customize them with oc-biblatex?

Bruce

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 8:23 AM John Kitchin  wrote:

>> A package could be created, say `org-cite-literal-biblatex' which is just a 
>> copy
>> of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and
>> `org-cite-biblatex-style-shortcuts' (or just sets those variables in
>> `org-cite-biblatex'). As far as I can tell this would provide exactly the
>> functionality you say org-cite can’t provide but org-ref does.
>
>
> I wrote this package you suggest in org-ref-cite. In discussions during that 
> development, it was clear the preference was on the more abstracted, and 
> uniform syntax across backends cite commands in org-cite, and not this kind 
> of variant. Of course one can do this. It is not that org-cite can't provide 
> it, it is that it doesn't at this time.

Just for some broader context on this particular issue.

The advantage of the org-cite style/variant design reflected in the
included export processors (natbib, biblatex, csl) is that the same
styles will mostly generate the same final output.

But that portability will only work with those styles and variants.

With the new org-cite-biblatex-styles defcustom, however, one can
augment or completely replace all those. But if you care about that
portability, you'd want to be aware of this, and think about it.

So per Timothy's point, you actually don't even need a new processor
for biblatex if you want to include all the extensive list of biblatex
commands.

Natbib AFAIK is already fully covered.

There's another POV on this though:

If one doesn't like to see the org-cite styles, because of familiarity
with LaTeX commands etc., I would argue that can be addressed in the
style part of an insert processor and/or in an activate processor.
E.g. I would argue this is a UI issue; not fundamentally about the
styles names.

Bruce

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

[Bruce D'Arcus]

On Mon, Mar 21, 2022 at 4:24 AM Dominik Schrempf
 wrote:

> I am trying out `org-cite' right now. It works much better than the last time 
> (I
> am using the `biblatex' backend right now). However, I can not find any
> documentation about the available /styles/.
>
> They are mentioned here: 
>
> But no styles are provided.

I have come to believe the best approach to handling available styles
and previews is in the style selection UI. So that one can see what
one is waiting when selecting.

In citar, those styles and preview are currently hard-coded in a
defcustom, but I'd like to figure out how to do that dynamically,
using org-cite-supported-styles etc.

In the meantime, Timothy's article should help (see the table on the styles):

https://blog.tecosaur.com/tmio/2021-07-31-citations.html

> For example, I need citations in the text (showing up as “Author(s) (Year)”).
> With BibTeX, this would be `\citet{}' (or `\textcite{}' with BibLaTeX). But
> there is a lot more. See: 
> ).

You want the "text" style; [cite/text:@doe20], or with the shortcut
[cite:/t:@doe20].

Bruce

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

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf
 wrote:

> For what it’s worth, I use `org-ref` because fine-grained citation export with
> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
> `org-cite`.

Part of the challenge is this isn't an apples-apples comparison;
org-cite a framework, and it's the processors that really provide the
functionality.

> If I remember correctly, `org-cite` exports the formatted citations into the
> LaTeX file ...

This is not true.

Or rather, it's only true if you use the oc-csl export processor; you
can use other export processors (like oc-biblatex) to get whatever
LaTeX output you want, and ...

>   it is really difficult to use different style files, etc. With
> `org-ref`, I can use BibLaTeX with specific style files. (Journal require
> different style files). I can even use my personal LaTeX classes (with 
> specific
> bibliography styles) for Org export.

... I believe Nicolas recently added support for customizing the
export styles for biblatex.

Bruce

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

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko  wrote:

> For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK.

Not really; or rather minimally.

Ivy-bibtex supports, for example, inserting of org-cite citations, but
not via org-cite-insert.

So there are currently no org-cite processors for ivy-bibtex etc.

Bruce

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

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 10:08 AM Vikas Rawal  wrote:
>>
>> > What is the general view of the community about this?
>>
>> I don't know about the general view of the community, but, as a data
>> point, I find it very sad.
>
>
> Exactly how I feel. Particularly so because org-cite was indeed inspired from 
> org-ref and all the great work John has done on this over the years. I do not 
> see any substantive discussion of the limitations that John has pointed out 
> with org-cite in the archives of the mailing list. We should have a 
> conversation about those.
>
> If I understand correctly, the main limitation according to him is that 
> org-cite does not handle cross-references. Is that the only problem? What do 
> others think about it? Do we want the citation system to be able to handle 
> cross-references? If not, do we need a separate system that handles 
> cross-references beyond what is available in org-mode already? Can that 
> system not be created in a manner that would not break the org-cite syntax?
>
> I think we should have a conversation and collectively think of what is the 
> best way forward.

Yes, and no.

Conversation on org-cite took place on this list for years, with
diverse people, with diverse expertise and POV, cycling in and out
over that time.

John raised the cross-reference question towards the very end, during
the testing period, when it was almost merged.

https://www.mail-archive.com/emacs-orgmode@gnu.org/msg138349.html

I still think the path forward on that is TBD, though as I said, I
don't think it should be in scope for org-cite per se, but org more
generally yes.

If he has some other issues (which I suspect he does; maybe related to
fontification?) that might be addressed, I'm sure he'll raise them.

Bruce

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

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 8:09 AM Vikas Rawal  wrote:

> What is the general view of the community about this? Is there a 
> comprehensive discussion of pros and cons of each?

Not really, but there's John's summary here:

https://github.com/jkitchin/org-ref#what-about-org-cite

The high-level discussion at the beginning, including the enumerated
points, seems right to me.

The following point that "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" is more subject
to debate, particularly the first clause.

I don't see any practical advantage to the org-ref syntax and model,
unless you include cross-references and such.

But that's because I just don't think cross-references and indexes
should be handled in org-cite; I think if we need improvements in
existing cross-references etc support, we should add those there.

I suspect he's also meaning the different ways that citation
commands/styles are handled in the two systems.

Here's an example from org-ref 3:

[[citealp:See  page 2]]

Note that first piece: "citealp". That's the command, which org-ref
will output directly to LaTeX/Natbib as \citealp. Note that command
only makes sense for natbib.

Org-cite has a different abstraction here: the style/substyle system.
So the above would be ...

[cite/bare:See @kitchin-2015-examp page 2]

... and then whatever export processor would map that "bare" style to
the appropriate output.

So that leaves the last bit; the "not possible" point, which I can't
address. It would obviously be nice if org-ref supported org-cite in
the future.

> What is everyone doing? I was an org-ref user for long before I switched to 
> org-cite. I can now shift to citar but since I am an ivy user, the switch is 
> not trivial. Also, I like many helper functions that John has created, and 
> would have to miss those if I do not use org-ref/org-ref-cite.

A month or so ago, John offered to turn over maintenance of
org-ref-cite to someone else, which might be one good option for
someone who uses ivy, in particular, and interested in developing it
further.

More generally, the modular design of org-cite should result, in time,
with diverse components, including for different completion
frameworks. For example, I think it'd be pretty easy to create an
insert process for helm-bibtex or ivy-bibtex, and a follow processor
for bibtex-completion.

Or alternatively, as citar now no longer requires bibtex-completion,
someone could write a small citar front-end for ivy as an insert
processor.

The whole point of the org-ctite design is it should be easy for users
to mix-and-match different pieces, and for documents to remain
compatible across users and export backends. It also allows developers
to focus on those small components.

Bruce

Re: [BUG] org-cite: 10 second hang opening a ~4k org file with 10MB bibtex library [9.5.2 (9.5.2-g91681f @ /home/jdm204/.config/emacs/straight/build/org/)]

[Bruce D'Arcus]

Thanks for posting this!

For Nicolas et al, my more general question about performance with
oc-basic was related to this, so you can ignore that.

On Tue, Mar 15, 2022 at 1:01 PM Jamie Matthews  wrote:
>
> # Issue
> Starting emacs with emacs -Q, then navigating to a minimal example org file 
> with C-x C-f yields a ~10 second hang on an 8-core/16GB RAM machine with 
> nothing else running. Also, scrolling commands like C-v are often laggy after 
> the initial hang.
>
> The minimal org file begins:
> """
> #+bibliography: ~/cloud/library/lib.bib
>
> [cite:@tillyPrimaryAnaplasticLargeCell1997]
> """
> with another 80 citations afterwards, one-by-line, but nothing else. As 
> mentioned in the title, the lib.bib file is ~10MB - if I swap this out for a 
> non-existent or tiny bibtex file the problem goes away, and the in-buffer 
> citations are rendered in a red face. Clearly from this and the below profile 
> the issue is something to do with checking etc the citations for 
> fontification purposes.
>
> # profile
>
> ## cpu
>   1,542,884,496  99% - redisplay_internal (C function)
>   1,542,860,504  99%  - jit-lock-function
>   1,542,860,504  99%   - jit-lock-fontify-now
>   1,542,860,504  99%- jit-lock--run-functions
>   1,542,860,504  99% - run-hook-wrapped
>   1,542,860,504  99%  - #
>   1,542,860,504  99%   - font-lock-fontify-region
>   1,542,860,504  99%- font-lock-default-fontify-region
>   1,542,792,728  99% - font-lock-fontify-keywords-region
>   1,542,661,211  99%  - org-cite-activate
>   1,542,542,267  99%   - org-cite-basic-activate
> 787,037,416  50%- org-cite-basic--get-entry
>   4,065,194   0% + org-cite-basic--parse-bibliography
> 754,769,872  48%- org-cite-basic--all-keys
>   6,151,200   0% + seq-mapcat
>   3,850,126   0% + org-cite-basic--parse-bibliography
> 481,332   0%+ org-element-interpret-data
> 129,376   0%+ org-cite-basic--print-entry
> 109,615   0%+ org-cite-get-references
>  87,264   0% org-element-citation-parser
>   5,988   0%org-activate-links
>   5,677   0%org-do-emphasis-faces
>   3,524   0%org-fontify-meta-lines-and-blocks
>   3,072   0%  + org-activate-footnote-links
>   3,072   0%org-do-latex-and-related
>   7,392   0%  - eval
>   7,392   0% if
>   3,072   0%kill-this-buffer-enabled-p
>   2,112   0%  - tool-bar-make-keymap
>   2,112   0%   - tool-bar-make-keymap-1
>   2,112   0%- mapcar
>   2,112   0%   #
>   1,176   0%menu-bar-update-buffers
>   6,219,935   0% + command-execute
>   1,280   0% + timer-event-handler
>  24   0% + eldoc-schedule-timer
>  21   0% + #
>   0   0%   ...
>
> ## memory
>
> 5778  95% - redisplay_internal (C function)
> 5778  95%  - jit-lock-function
> 5778  95%   - jit-lock-fontify-now
> 5778  95%- jit-lock--run-functions
> 5778  95% - run-hook-wrapped
> 5778  95%  - #
> 5778  95%   - font-lock-fontify-region
> 5778  95%- font-lock-default-fontify-region
> 5778  95% - font-lock-fontify-keywords-region
> 5774  95%  - org-cite-activate
> 5762  95%   - org-cite-basic-activate
> 2939  48%- org-cite-basic--get-entry
> 1631  26% - org-cite-basic--parse-bibliography
>  400   6%  - set-auto-coding
>  400   6% find-auto-coding
>   20   0%  + org-cite-list-bibliography-files
>4   0%  + #
>4   0%after-insert-file-set-coding
> 2819  46%- org-cite-basic--all-keys
> 1515  25% - org-cite-basic--parse-bibliography
>  364   6%  - set-auto-coding
>  364   6% find-auto-coding
>   16   0%  - org-cite-list-bibliography-files
>8   0%   + org-collect-keywords
>4   0% # F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_23>
>   32   0% + seq-mapcat
>4   0%+ org-cite-basic--print-entry
>4   0% org-element-citation-parser
>4   0%org-activate-links
>  233   3% - command-execute
>  218   3%  - byte-code
>  149   2%   + read-extended-command
>   69   1%   - find-file-read-args
>   69   1%- read-file-name
>   69   1% - read-file-name-default
>   15   0%  - completing-read-default
>1   0%   - command-execute
>1   0%- 

Re: oc-basic load performance

[Bruce D'Arcus]

Actually, this was prompted by this reddit post, where the OP also
notes impaired scrolling performance after loading an org file with
citations.

https://www.reddit.com/r/orgmode/comments/td76wz/org_very_slow_load_with_orgcite_and_a_large/

I encouraged them to post the report here; not really sure why
scrolling would be impacted.

On Sun, Mar 13, 2022 at 7:28 PM Bruce D'Arcus  wrote:
>
> I've seen a number of people note how slow loading of BibTeX files is in 
> oc-basic.
>
> Just wondering: do we know why, and whether there are opportunities to 
> improve it?
>
> For comparison, parsebib (which I use in citar) is much faster.
>
> Bruce

oc-basic load performance

[Bruce D'Arcus]

I've seen a number of people note how slow loading of BibTeX files is in
oc-basic.

Just wondering: do we know why, and whether there are opportunities to
improve it?

For comparison, parsebib (which I use in citar) is much faster.

Bruce

Re: Bibliographies on export with ox-context and ox-epub

[Bruce D'Arcus]

On Wed, Jan 12, 2022 at 11:42 AM juh  wrote:
>
> On 12.01.22 15:53, Nicolas Goaziou wrote:
> > Note that Org Cite and Org Ref are, unfortunately, incompatible
> > projects. Org Cite defines citations as a new kind of object, whereas
> > Org Ref extends links to create citations. In short, you cannot mix
> > both.
>
> Do I have to erase every trace of Org Ref in my setup?

No, you don't.

You just can't mix the two (well, I guess now three) types of
citations in the same document and expect things to work correctly.

Bruce

[org-cite] pandoc adds initial read/write support

[Bruce D'Arcus]

John MacFarlane merged initial support for org-cite to the pandoc org
reader and writer.

Only available in master ATM, but could use real-world testing,
including of the org-ref -> org-cite conversion, which you can get by
using org as both input and output format.

Bruce

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Wed, Dec 8, 2021 at 8:17 AM Daniel Nemenyi  wrote:

> > With Selectrum, ... (don't know what the keybinding here is)
>
> Just installed Selectrum to find out. C-j (selectrum-submit-exact-input) does 
> the trick.

If you like Selectrum (Vertico is another recent, similar,
alternative), you might give citar a try.

https://github.com/bdarcus/citar

Bruce

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 9:33 AM Daniel Nemenyi  wrote:
> Apologies, I did ('Thanks org-ref I'm done...'), slip of the tongue.

Oh, I missed that; sorry John.

> Could have a go though if someone could give me a pointer? But if this is 
> left to the user, perhaps we should include a line in the documentation 
> telling them?

The completion UIs have different keybindings for this. What should
the documentation say?

Bruce

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 8:51 AM John Kitchin  wrote:

> org-ref should not get any credit for this.

Certainly not, but I don't believe anyone mentioned org-ref in this thread?

Bruce

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

On Mon, Dec 6, 2021 at 8:09 AM Bruce D'Arcus  wrote:

> Perhaps you could customize the keybinding for exiting to get the
> behavior you want?

Or perhaps a better solution is for someone to write an
insert-processor for helm-bibtex.

It's not hard to write them.

Bruce

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Bruce D'Arcus]

Presumably you're using the default "basic" org-cite-insert-processor?

If yes, that's just how it's designed, using completing-read.

Perhaps you could customize the keybinding for exiting to get the
behavior you want?

On Mon, Dec 6, 2021 at 7:56 AM Daniel Nemenyi  wrote:
>
>
> Hello,
>
> I'm finding myself stuck in the `HELM Org Cite Insert` buffer that lists 
> possible citations after calling org-cite-insert using Helm. After selecting 
> a reference I am prompted to select more, and there isn't an obvious way to 
> say, 'Thanks org-ref I'm done, kill this minibuffer and insert the refs I 
> have chosen.'
>
> I was eventually told on Stack Overflow that M-RET does the job, but I would 
> have expected either the first option in the HELM buffer to do this, or else 
> there to be an option in the HELM Select Action list?
>
> Thanks!
> Daniel
>
> Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
> cairo version 1.16.0)
> Package: Org mode version 9.5.1 (9.5.1-g36086a @ 
> /home/dan/.emacs.d/elpa/org-9.5.1/). Helm (20211205.)
>