Re: Update Schedule for orgmode

[Bruce D'Arcus]

Yes, 9.5.

I'm curious about the timeline too.

On Wed, Jul 21, 2021, 8:36 AM Denis Maier  wrote:

> Hi,
> I'm helping a scholar at my institution with his emacs/org-mode
> installation. As he'll would like to have automatic citations I
> suggested he should try the new org-cite features, but he does not
> really want to run the dev version. Is it already predictable when 9.5
> will be released? IIUC, the new citation features will be part of 9.5,
> right?
> Best,
> Denis
>
>

Re: [org-cite] issues with org-cite-make-insert-processor select-style

[Bruce D'Arcus]

Matt - that's not really the problem.

In general, these core org-cite functions
(org-cite-make-insert-processor and org-cite-register-processor) must
be loaded after anything they refer to; e.g. placed at the end of the
package file.

But if they aren't, the resulting error message is really confusing,
and emacs shouldn't break.

On Thu, Jul 22, 2021 at 9:27 AM Matt Price  wrote:
>
> Bruce, are you loading this code with use-package? If so, and if I'm reading 
> this right, you can perhaps add the missing functions to the
>
> :commands
>
> directive for org-mode? IIUC that should ensure that they are available to 
> your package, as long as you have an
> :after (org oc)
> line in the package's use-package directive.
>
> On Thu, Jul 22, 2021 at 6:31 AM Bruce D'Arcus  wrote:
>>
>> The problem was load order I guess; putting this of the file fixes it.
>>
>> So when org-citemake-insert-processor is first loaded, it looks for
>> the two functions, which haven't been loaded yet.
>>
>> I still think a) the error message could say that (that the functions
>> aren't found or some such), and b) that it shouldn't break starting
>> Emacs.
>>
>> On Thu, Jul 22, 2021 at 4:27 AM Bruce D'Arcus  wrote:
>>
>> > If I comment out those lines and use the oc-basic style selector
>> > instead to start emacs, and from there reactivate this function and
>> > compile and reload the code from the buffer, THEN it works without
>> > error.
>>

Re: [org-cite] issues with org-cite-make-insert-processor select-style

[Bruce D'Arcus]

The problem was load order I guess; putting this of the file fixes it.

So when org-citemake-insert-processor is first loaded, it looks for
the two functions, which haven't been loaded yet.

I still think a) the error message could say that (that the functions
aren't found or some such), and b) that it shouldn't break starting
Emacs.

On Thu, Jul 22, 2021 at 4:27 AM Bruce D'Arcus  wrote:

> If I comment out those lines and use the oc-basic style selector
> instead to start emacs, and from there reactivate this function and
> compile and reload the code from the buffer, THEN it works without
> error.

Re: [org-cite] issues with org-cite-make-insert-processor select-style

[Bruce D'Arcus]

Another odd thing.

If I comment out those lines and use the oc-basic style selector
instead to start emacs, and from there reactivate this function and
compile and reload the code from the buffer, THEN it works without
error.

On Wed, Jul 21, 2021 at 10:17 PM Bruce D'Arcus  wrote:
>
> BTW, here's the info from the debugger:
>
> Debugger entered--Lisp error: (error "Wrong argument type(s)")
> error("Wrong argument type(s)")
> org-cite-make-insert-processor(bibtex-actions-org-cite-insert
> bibtex-actions-org-cite-select-style)
> (org-cite-register-processor 'bibtex-actions-org-cite
> :insert (org-cite-make-insert-processor
> #'bibtex-actions-org-cite-insert
> #'bibtex-actions-org-cite-select-style)
> :follow #'bibtex-actions-org-cite-follow)
> load-with-code-conversion("/home/bruce/.config/emacs/.local/straight/build-28..."
> "/home/bruce/.config/emacs/.local/straight/build-28..." nil t)
> require(bibtex-actions-org-cite nil nil)
>
> On Wed, Jul 21, 2021 at 11:14 AM Bruce D'Arcus  wrote:
> >
> > I have run into a problem in implementing a "select-style" function
> > for an org-cite-insert-processor.
> >
> > The WIP code is here:
> >
> > https://github.com/bdarcus/bibtex-actions/pull/182
> >
> > It was running correctly yesterday morning, but now it doesn't.
> >
> > I have two related issues:
> >
> > 1. I think, but am not sure, I may have run into a bug in
> > org-cite-make-insert-processor, as the function I am using for the
> > select-style parameter runs correctly outside of the insert processor,
> > and returns the same results as the "org-cite-basic--complete-style"
> > function. But when I uncomment the parameter to use it on the org-cite
> > insert processor, it not only doesn't work correctly, but Emacs won't
> > even load fully.
> >
> > 2. The error I get "wrong type" is so general it literally took me
> > hours to realize it was coming from this function; I was looking
> > elsewhere for the issue.
> >
> > So if I'm right about a bug, obviously it would be great if that could be 
> > fixed.
> >
> > But better error handling and reporting would also be really great.
> >
> > Bruce
> >
> > PS - I"m still learning elisp, and so am not super knowledgeable about
> > debugging in general. If anyone has any tips on that, that could help
> > me narrow down the source of the error, that would be much
> > appreciated.

Re: [org-cite] issues with org-cite-make-insert-processor select-style

[Bruce D'Arcus]

BTW, here's the info from the debugger:

Debugger entered--Lisp error: (error "Wrong argument type(s)")
error("Wrong argument type(s)")
org-cite-make-insert-processor(bibtex-actions-org-cite-insert
bibtex-actions-org-cite-select-style)
(org-cite-register-processor 'bibtex-actions-org-cite
:insert (org-cite-make-insert-processor
#'bibtex-actions-org-cite-insert
#'bibtex-actions-org-cite-select-style)
:follow #'bibtex-actions-org-cite-follow)
load-with-code-conversion("/home/bruce/.config/emacs/.local/straight/build-28..."
"/home/bruce/.config/emacs/.local/straight/build-28..." nil t)
require(bibtex-actions-org-cite nil nil)

On Wed, Jul 21, 2021 at 11:14 AM Bruce D'Arcus  wrote:
>
> I have run into a problem in implementing a "select-style" function
> for an org-cite-insert-processor.
>
> The WIP code is here:
>
> https://github.com/bdarcus/bibtex-actions/pull/182
>
> It was running correctly yesterday morning, but now it doesn't.
>
> I have two related issues:
>
> 1. I think, but am not sure, I may have run into a bug in
> org-cite-make-insert-processor, as the function I am using for the
> select-style parameter runs correctly outside of the insert processor,
> and returns the same results as the "org-cite-basic--complete-style"
> function. But when I uncomment the parameter to use it on the org-cite
> insert processor, it not only doesn't work correctly, but Emacs won't
> even load fully.
>
> 2. The error I get "wrong type" is so general it literally took me
> hours to realize it was coming from this function; I was looking
> elsewhere for the issue.
>
> So if I'm right about a bug, obviously it would be great if that could be 
> fixed.
>
> But better error handling and reporting would also be really great.
>
> Bruce
>
> PS - I"m still learning elisp, and so am not super knowledgeable about
> debugging in general. If anyone has any tips on that, that could help
> me narrow down the source of the error, that would be much
> appreciated.

[org-cite] issues with org-cite-make-insert-processor select-style

[Bruce D'Arcus]

I have run into a problem in implementing a "select-style" function
for an org-cite-insert-processor.

The WIP code is here:

https://github.com/bdarcus/bibtex-actions/pull/182

It was running correctly yesterday morning, but now it doesn't.

I have two related issues:

1. I think, but am not sure, I may have run into a bug in
org-cite-make-insert-processor, as the function I am using for the
select-style parameter runs correctly outside of the insert processor,
and returns the same results as the "org-cite-basic--complete-style"
function. But when I uncomment the parameter to use it on the org-cite
insert processor, it not only doesn't work correctly, but Emacs won't
even load fully.

2. The error I get "wrong type" is so general it literally took me
hours to realize it was coming from this function; I was looking
elsewhere for the issue.

So if I'm right about a bug, obviously it would be great if that could be fixed.

But better error handling and reporting would also be really great.

Bruce

PS - I"m still learning elisp, and so am not super knowledgeable about
debugging in general. If anyone has any tips on that, that could help
me narrow down the source of the error, that would be much
appreciated.

Re: org-cite: how to include a cite with no key?

[Bruce D'Arcus]

On Tue, Jul 20, 2021 at 8:50 AM Denis Maier  wrote:

> > Certainly in the CSL world, this has never been supported, and I don't
> > ever recall it ever coming up (though I'm sure someone on the Zotero
> > forum raised it at some point)
>
> I'm pretty sure I've brought that up at some point :-)

:-)

> FWIW, Biblatex knows a similar command \mancite.
>
> Use cases:
> Beyond personal communication, which I personally have never used, there
> are disciplines (classics, theology, religious studies) that refer to
> some classical works (Bible, Quran, etc.) with certain well-known
> abbrevations. Usually those works don't appear in the bibliography.

The cases here a little different though.

This is basically work so well-known in a field that they are omitted
from the bibliography.

Effectively, the opposite of "nocite"; so "nobib"?

The example of personal communications that John raised is a little different.

I still think it's either a citation with a reference, or it's not;
just an in-text note.

> This leads to problems with automatic citations, especially when you also use
> "ibid." and such...
>
> Bla [cite:@doe].
> Blabla (Gen 1).
> Bla [cite:@doe].
>
> =>
> Bla (Doe 2020).
> Blabla (Gen 1).
> Bla (ibid.).
>
>
> With biblatex you can use \mancite to reset the citation trackers.

Can one workaround this now?

Or if not, by adding a "nobib" style per above at some point?

Bruce

[org-mode] make citation object available to org-cite-make-insert-processor SELECT-STYLE?

[Bruce D'Arcus]

I'm working on a select-style function for org-cite, where I am adding
previews to the style list.

Current screenshot, with the natbib mapping:

https://user-images.githubusercontent.com/1134/126326341-15ec2046-bf34-411a-a7d8-f2cbe85769c3.png

But to do that best and most consistently (next step is CSL, for
example), I need the citation accessible from there, so I can run the
export processors to generate the previews.

Could we possibly tweak SELECT-STYLE to take one argument: citation?

Or am I missing something?

Bruce

Re: org-cite: how to include a cite with no key?

[Bruce D'Arcus]

On Mon, Jul 19, 2021 at 8:48 PM John Kitchin  wrote:
>
> On Mon, Jul 19, 2021 at 7:28 PM Emmanuel Charpentier 
>  wrote:
>>
>> > In natbib there is \citetext{priv.\ comm.} which is used to add a
>> > textual citation to the bibliography that doesn't have a key
>> > associated with it.
>>
>> Hmmm... why should you bother to reference a personal communication ?
>> Such private communications may be mentionned in the text (possibly by
>> a footnote) but can't be properly referenced (since there is nothing to
>> refer to). If you feel that this communication must be referred to, you
>> should give it some (written) support and (properly) reference this
>> support.
>
>
> Who is to say why someone would bother. It is a command on page two of
> http://tug.ctan.org/macros/latex/contrib/natbib/natnotes.pdf that one can use.
>
> It is also possible to use  \nocite{*} as a cite, which includes all
> references from a bibliography, and yet contains no key. Even funnier in a 
> way is \nocite{key} which just adds entries to the bibliography, but does not 
> cite them in the body of a document.
>
> Footnotes are not always allowed in publications, and for various reasons not 
> worth defending, in proposals one might want to put this in the references 
> because of space limitations.

If not a footnote, a parenthetical note?

What's the value of a citation and bibliography processor handling
formatting here?

Certainly in the CSL world, this has never been supported, and I don't
ever recall it ever coming up (though I'm sure someone on the Zotero
forum raised it at some point).

I will point out the syntax discussion long predates my participation
in the last year or so.

Perhaps it was raised at some point in the past and rejected?

If not raised, it's not surprising it's not supported now.

Bruce

Re: should a BIBLIOGRAPHY keyword supercede org-cite-global-bibliography?

[Bruce D'Arcus]

As Emmenuel pointed out, we missed that Nicolas already thought of
this, and you can do this:

#+org-cite-global-bibliography: nil

With that, there's no problem, and lots of flexibility.

On Mon, Jul 19, 2021 at 8:53 PM Thomas S. Dye  wrote:
>
> I used to have a global bibliography that my employees all used.
> Every project also had a local bibliography for citations that
> didn't appear in the global bibliography.  At the end of a
> project, after the editor had cleaned up the local bibliography,
> I'd merge it with the global bibliography using a utility called
> bibtool.
>
> hth,
> Tom
>
> Vikas Rawal  writes:
>
> >> It seems like that should not be the case, i.e. if you define
> >> BIBLIOGRAPHY
> >> keywords it means you do not want to use the ones
> >> in org-cite-global-bibliography. Is there a scenario where the
> >> union of those
> >> makes sense?
> >
> > I second this. The local bibliographies should supercede the
> > global.
> >
> > Vikas
>
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>

Re: should a BIBLIOGRAPHY keyword supercede org-cite-global-bibliography?

[Bruce D'Arcus]

On Mon, Jul 19, 2021 at 1:54 PM John Kitchin  wrote:

> Maybe a reasonable compromise is something like
>
> #+bibliography: :local t
>
> which could indicate not to use the global variable.

I like it!

Bruce

Re: should a BIBLIOGRAPHY keyword supercede org-cite-global-bibliography?

[Bruce D'Arcus]

Yes, you're right Emmanuel.

I guess this goes back to my file type/extension issue then.

I do expect this to be a non-issue in time though, as related packages
update to fully support all three common input formats.

On Mon, Jul 19, 2021 at 1:29 PM CHARPENTIER Emmanuel
 wrote:
>
> > It seems like that should not be the case, i.e. if you define
> > BIBLIOGRAPHY keywords it means you do not want to use the ones in
> > org-cite-global-bibliography. Is there a scenario where the union of
> > those makes sense?
>
> Yes indeed: you may have
>   - A library for background issues (e. g. methodology)
>   - A (or several) subject matter-specific library (e. g. a
> subdiscipline, a method, etc...)
>   - A library specific to the question you are discussing (e. g.
> results of a bibliographic search specific to your question).
>
> The first one is a perfect target for org-cite-global-bibliography. The
> last one is of course a target for #+BIBLIOGRAPHY ; I'd tend to let the
> subject matter library as a file-specific #+BIBLIOGRAPHY (my subject
> matters tend to vary...), but this depends on your field.
>
> You may also think of this typology as books, reviews and research
> papers respectively...
>
> HTH,
>
> --
> Emmanuel Charpentier
>

Re: should a BIBLIOGRAPHY keyword supercede org-cite-global-bibliography?

[Bruce D'Arcus]

I was wondering about this the other day too, and am not sure.

It can actually be a problem, and has been for me, if you're mixing
export processors; like biblatex, and CSL (which is best to use with
json currently).

So I definitely see a downside currently, and can't think of a problem
in changing this.

If someone else can, maybe it should be configurable?

Along these lines, it might be nice if we could choose which global
file(s) or extensions for which processor.

On Mon, Jul 19, 2021 at 12:07 PM John Kitchin  wrote:
>
> The org-cite-list-bibliography-files function in oc.el returns a combination 
> of file-local files and the bibfiles defined in org-cite-global-bibliography.
>
> It seems like that should not be the case, i.e. if you define BIBLIOGRAPHY 
> keywords it means you do not want to use the ones in 
> org-cite-global-bibliography. Is there a scenario where the union of those 
> makes sense?
>
> 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
>

Re: org-cite citation commands

[Bruce D'Arcus]

Unlike John, I don't have a working demo of this particular smaller idea,
but as it relates to the styles/commands question, I thought I'd mention it.

So the idea is to use the style completion UI to show the user what the
options are, by including the export preview; for the tex export
processors, it would be the latex commands, and for CSL, would be the
rendered output.

While I don't have it running, this should definitely be doable.

I put an initial mockup here.

https://github.com/bdarcus/bibtex-actions/issues/168

Probably something like this should be added to oc-basic at some point.

On Sun, Jul 18, 2021, 12:10 AM Vikas Rawal  wrote:

> This is very helpful already. Keenly looking forward to how this develops.
>
> Vikas
>
> On Sat, Jul 17, 2021 at 04:52:33PM -0400, John Kitchin wrote:
> > I made a video of my current org-cite setup at
> https://www.youtube.com/watch?v=
> > 4ta4J20kpmM. You can also find a link to the code to run it in the
> description
> > there.
> >
> > I don't intend this to be a final video (it is still a little rough!),
> it is
> > just to help people see what I am thinking about for the future of
> org-ref, at
> > least as far as the citations go.
> >
> > 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
>

Re: org-cite citation commands

[Bruce D'Arcus]

On Sat, Jul 17, 2021 at 10:20 AM Vikas Rawal  wrote:

> Thanks, Bruce and John. Indeed, I used biblatex with natbib=true
> option, which gives me citet and citep in biblatex. But using
> \autocite and \textcite is perfect.
>
> I am noticing a few other issues at this stage.
>
> I have a large biblatex database, and loading it using C-c C-x @ to
> insert citations seems very slow (have not managed to load it thus
> far). Org-ref used to be much faster in this. org-cite works fine with
> a smaller biblatex database. I don't know if others have had the same
> experience.

Give this a try:

https://github.com/bdarcus/bibtex-actions#org-cite

I hope to see similar "insert processors" for ivy-bibtex and helm-bibtex.

Bottomline, it's trivial to replace that "basic" processor with much
better options.

See discussion on:

https://github.com/jkitchin/org-ref/issues/885

> I understand that oc-biblatex.el loads biblatex in the background,
> produces the citations and the bibliography, and inserts them in the
> exported output. In that case, what are the possibilities of using
> biblatex commands to configure the output?

To be precise, you mean what are the options to configure the
oc-biblatex export processor to use different or additional commands?

ATM, I don't believe there are any, and the alternative is to write
your own export processor, say basing it off the oc-biblatex one.

What, specifically, do you need, that is not currently supported?

The current processors are pretty comprehensive; see the note from Andras.

When designing this sort of thing, you basically have a choice.

You can just have styles that map directly to the output targets.

This has an obvious advantage if you only ever use one target.

But it has a major disadvantage if you want to use others.

So the approach we took here is to design a common set of styles and
substyles, and then map to output formats from there.

The result is the citations are more-or-less export format agnostic.

> I realise that these will
> not work since most of it would be LaTeX specific. Does that mean the
> users will have to work with CSL styles to format the output even if
> they are using oc-biblatex.el? I am still somewhat confused about how
> this is going to work.

CSL styles are analogous to BST files in bibtex; you use those with oc-csl.

When using that, citeproc-el handles the output processing, including for latex.

Basically, if you want consistent output formatting across latex and
other targets like HTML or OpenDocument, you want to use oc-csl.

Give it a try.

Note, though, that citeproc-el does not currently support cite/t or
some others, but that should be coming "soon".

HTH; let me know if anything is unclear.

Bruce

Re: org-cite citation commands

[Bruce D'Arcus]

We were posting at the same time :-)

On Sat, Jul 17, 2021 at 8:39 AM John Kitchin  wrote:

> There is not currently a way to get \citet and \citep with the biblatex 
> backend.

Yes, but \autocite andt \textcite produce the expected output, and
have the advantage they are independent of output format. As in, the
current behavior will work in an author-date style or a note-based
one.

So [cite:@key] and [cite/t:@key] should produce the expected output in
both biblatex and natbib.

Bruce

Re: org-cite citation commands

[Bruce D'Arcus]

On Sat, Jul 17, 2021 at 7:41 AM Vikas Rawal  wrote:

> What is the equivalent here of the various citation commands that something 
> like biblatex or bibtex provide? The two most common citation commands I use 
> are citet and citep (or parencite). These are used to produce the following 
> kind of output using org-ref/biblatex:
>
>
> -
> * citet

cite/t

> * citep

cite (no style; it's default)

> I am a bit lost with the citation styles that are inbuilt in oc-biblatex.el. 
> Is it expected that we will have to write additional citation styles for 
> getting these kinds of output?

No; there is already extensive style support, that works consistently
across the different export processors.

E.g. cite/t will produce the same output in natbib and biblatex (and
very soon, csl).

You can see the draft mapping of style here, though I need to update it.

https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

Bruce

Re: could we support * in a cite style.

[Bruce D'Arcus]

BTW, Nicolas added a helpful function towards the end, which returns
both the full style and variant and names, and also the shortcuts.

(org-cite-supported-styles '(natbib biblatex))

Re: could we support * in a cite style.

[Bruce D'Arcus]

On Fri, Jul 16, 2021 at 2:15 PM John Kitchin  wrote:
>
> Hi all,
> It looks like this is not a supported style for the new cite syntax:
>
> [cite/author*:@swain-2016-chemd]
>
> I think it should be allowed, because it maps cleanly to the natbib cite type 
> of \citeauthor*. There are a bunch of other starred types as well. that would 
> be nicer than something like [cite/author/star:@swain-2016-chemd] or 
> [cite/author-star:@swain-2016-chemd] IMO.

Are you aware can do this now, which will output consistent formatting
across natbib and biblatex export processors, and I expect in the
future too csl:

[cite/a/f:@low2001]

Bruce

Re: Comments break up a paragraph when writing one-setence-per-line

[Bruce D'Arcus]

On Fri, Jul 16, 2021 at 12:07 PM William Denton  wrote:

> However, I was a bit surprised when I found that a commented line starts a new
> paragraph.

I hadn't yet discovered that, but I think it should be considered a
bug. The output of your example should remove the commented line
entirely, and so be:

In this paragraph I introduce an idea.
But I am sure about this. And here is my conclusion.

Perhaps it can be easily fixed?


Bruce

Re: [PATCH] be more cautious when setting csl etc dir location

[Bruce D'Arcus]

FWIW, I ran into this issue.

After installing org, oc-csl looks in the wrong path for the etc files.

On Mon, Jul 12, 2021 at 2:07 PM Timothy  wrote:
>
> Hello,
>
> It's come to my attention that the current value of
> org-cite-ctl--etc-dir is problematic for anyone managing Org with
> package.el or straight. This patch adds a check to see if the initial
> location actually exists, if it doesn't we try the expected location
> when using package.el/straight.
>
> --
> Timothy
>

[oc] use-package config question

[Bruce D'Arcus]

As I'm trying to put together a PR for the doom module for adding
org-cite support [1], I'm realizing I really don't understand
use-package very well.

Could someone with some expertise in this area recommend how I do the following?

Load org-cite and it's associated packages (oc-basic, oc-natbib,
etc.), and set some associated variables, if org-cite is available.

Bruce

[1] https://github.com/hlissner/doom-emacs/pull/5212

Re: [PATCH] Change default latex compiler to latexmk

[Bruce D'Arcus]

Can we merge this patch now?

On Wed, Jun 30, 2021 at 7:14 AM Bruce D'Arcus  wrote:
>
> Looks good, Bastien, and I think reflects the consensus of that thread.
>
> But trying just now, I'm not able to apply the patch on my local repo
> for whatever reason, so haven't tested it.
>
>
>
> On Wed, Jun 30, 2021 at 6:48 AM Bastien  wrote:
> >
> > Hi Bruce,
> >
> > "Bruce D'Arcus"  writes:
> >
> > > What's the status of this patch?
> >
> > Can you quickly review it and say whether it's good?
> >
> > Thanks,
> >
> > --
> >  Bastien

Re: Citations merged!

[Bruce D'Arcus]

Thanks for all your work on this Nicolas: really nice job!

On Fri, Jul 9, 2021, 2:54 AM Nicolas Goaziou  wrote:

> Hello,
>
> It took years, but citations are now full part of Org syntax.
>
> Thanks to everyone involved over the time!
>
> Now, it needs to be documented, but that will come a bit later.
>
> Regards,
> --
> Nicolas Goaziou
>
>

Re: [wip-cite-new] Merging tomorrow?

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 9:43 AM Timothy  wrote:
>
> Hi Nicolas,
>
> > At this point, I don’t have enough understanding of the problem to have
> > an opinion. IIUC, your example does not even mention citations. How
> > should it be used, what should be the output in LaTeX, and in UTF-8
> > export? This is not clear to me.
> >
> > What can I say however is: if this feature implies to change, or extend,
> > syntax, then it is /de facto/ a blocker for the merge, and needs to be
> > sorted out.
>
> This very much depends on how you view references vs citations. I personally
> think of references as in-text citations (i.e. you’re citing other bits of the
> very same document), but I doubt this is a common view (as suggested by other
> replies).

I'm glad you raised the question, even if it is a bit late. But I
indeed don't think your view is common :-)

I decided to take a look at what a canonical guide like Chicago Manual
of Style says about this.

They call these "text references" (though confusingly, they use the
word "references" when discussing citations too).

For example, there are headings like "3.9: Text references to numbered
illustrations". or "2.30: Formatting text references and callouts to
tables and illustrations".

And then descriptions like "A text reference is addressed to the
reader (“see table 5,” or “fig. 3.2”) and will appear in the published
version."

Here's some stuff from APA, though they don't go into references much.

https://apastyle.apa.org/style-grammar-guidelines/tables-figures/figures

And finally, FWIW, MS Word and Open/LibreOffice implement support for
this via "cross-references":

https://guides.lib.umich.edu/c.php?g=283073=1888264

https://wiki.openoffice.org/wiki/Documentation/OOo3_User_Guides/Writer_Guide/Using_automatic_cross-references

So they may be similar, but are not the same.

And the implementation challenges raised by John Kitchin and Joost
Kremers (namely the candidate list is different) make this better to
deal with using a different mechanism.

As a package developer that supports org-cite, I really don't want to
be worrying about internal references and such.

And as a user, I don't see the benefit of doing so.

Effectively, these seem more like org internal links.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 7:46 AM Nicolas Goaziou  wrote:

> In this situation, the function I want to encourage re-using is
> `org-cite-supported-styles'. `org-cite-basic--complete-style' is so
> trivial that I didn't bother exporting it.

Okay, I see now.

So `org-cite-supported-styles' returns what it sounds like; a list of styles.

((("author" "a")
  ("caps" "c"))
 (("noauthor" "na")
  ("bare" "b"))
 (("nocite" "n"))
 (("note" "ft")
  ("caps" "c")
  ("bare-caps" "bc"))
 (("numeric" "nb"))
 (("text" "t")
  ("caps" "c")
  ("bare-caps" "bc"))
 (("nil")
  ("caps" "c")
  ("bare-caps" "bc")
  ("bare" "b")))

 `org-cite-basic--complete-style' is "trivial" just in the sense it
only supports styles (not sub-styles), and one can imagine adding
annotations to make it easier for users to know what a given choice
will result in.

But that's not for you to worry about, or for oc-basic.

I'll think about it; not sure what the best path for a more
feature-full alternative would be ATM.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 8:48 AM Eric S Fraga  wrote:
> ... I have lost track of what is going on in the emacs-sphere
> when it comes to completion frameworks.  I use ivy/counsel.  Is there
> somewhere a good summary of the state of play?  Would I wish to move to
> another framework?

You're not the only one. There's been a ton of activity on this new
generation of completing-read-based completion packages the past
year+.

And what's a bit difficult to grok initially is these are decoupled
packages that work together, which gives users more choice, but can
also be confusing.

Probably the best summary is on the Selectrum repo README. But there's
a lot there, so it might be a bit much.

I have also tried to summarize it on my README in a more focused way.

Note that that selectrum repo has some test scripts where you can kick
the tires with different options, using emacs -Q.

https://github.com/raxod502/selectrum/tree/master/test

I use an adapted version of those in my repo, so in that case you can
just do ./run.sh.

If you want to dive in, my suggestion is install and configure the
following, and experiment.

1. vertico and selectrum (completion UI; I prefer vertico these days,
but they're really similar, and they don't conflict if you have both
installed)
2. orderless (completion-style)
3. consult (counsel-like commands, and now enhanced multi-selection)
4. embark (contextual actions)

That should give you similar experience to what you have now, in a
more modular approach.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 7:46 AM Nicolas Goaziou  wrote:

> In this situation, the function I want to encourage re-using is
> `org-cite-supported-styles'. `org-cite-basic--complete-style' is so
> trivial that I didn't bother exporting it.

OK, I'll take a closer look at that.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Wed, Jul 7, 2021 at 6:59 PM Nicolas Goaziou  wrote:

> For a developer, there are now two ways to create an insert processor.
>
> 1. If you are happy with the global behaviour of "basic", but want to
>improve completion, I added the `org-cite-make-insert-processor'
>tool.

This was very helpful, so I just added a commit making use of it.

https://github.com/bdarcus/bibtex-actions#org-cite

So same org-cite-insert behavior as oc-basic, but using
bibtex-actions-read for the completion.

Bruce

Re: [wip-cite-new] Merging tomorrow?

[Bruce D'Arcus]

On Thu, Jul 8, 2021 at 6:26 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Timothy  writes:
>
> > Bruce D'Arcus  writes:
> >
> >>> wip-cite-new deals with citing from bibliographies, but I don't think it
> >>> deals with within-document referencing --- should it?
> >
> >> 1. Should it?
> >> 1. Maybe.
> >
> > I feel like it would fit. With everything that's been done for
> > citations, this feels like it may be a rather minor addition (or at
> > least this is what I hope).
> >
> >> 2. Can it? Could the design be extended to include internal referencing?
> >> 2. I think so. You'd just need a way to include internal targets in
> >> addition to the citation-references (keys); for illustration,
> >> something like [cite:#some-if].
> >
> > I can't claim to have thought about this that much either, but something
> > like [cite:#some-fig] would seem to fit.
> >
> >> 3. If yes to both, should that hold back merger now?
> >> 3. No.
> >
> > I don't think this should hold up the merge either, but it's relevant in
> > the overall nature of the feature and perhaps could be shoehorned in
> > following the merge? I feel like this is one small quite simple case and
> > most of the thinking required has already been done. I'm not sure
> > though, I'd go with whatever Nic's thought are on this.
>
> At this point, I don't have enough understanding of the problem to have
> an opinion. IIUC, your example does not even mention citations. How
> should it be used, what should be the output in LaTeX, and in UTF-8
> export? This is not clear to me.
>
> What can I say however is: if this feature implies to change, or extend,
> syntax, then it is /de facto/ a blocker for the merge, and needs to be
> sorted out.

As I was hinting, I don't know this area well either.

I think the first question is the "should" one; whether this is
in-scope of this module.

I wasn't sure, so said "maybe".

Joost says "no."

In latex, such internal references are not citations though; they use
a different mechanism.

Does that not suggest, Timothy, that this might be out-of-scope for
this module; that Joost is right?

Bruce

Re: [wip-cite-new] Merging tomorrow?

[Bruce D'Arcus]

On Wed, Jul 7, 2021 at 11:48 PM Timothy  wrote:

> wip-cite-new deals with citing from bibliographies, but I don't think it
> deals with within-document referencing --- should it?

It doesn't now.

I guess to break down the second question further:

1. Should it?
2. Can it? Could the design be extended to include internal referencing?
2. If yes to both, should that hold back merger now?

I've not thought about this a lot, but my tentative view ...

1. Maybe.
2. I think so. You'd just need a way to include internal targets in
addition to the citation-references (keys); for illustration,
something like [cite:#some-if].
3. No.

I say no in part because while it's possible it's fairly
straightforward to add this, it will take some thought, and there's
probably details to sort out.

And the code is ready, I think, based on the requirements that have
been the focus the past year+.

OTOH, perhaps this basic requirements question was raised before I
joined the discussion, and it was already rejected?

Either way, I don't think this should hold back merger now. It can be
added later if it makes sense.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Wed, Jul 7, 2021 at 6:59 PM Nicolas Goaziou  wrote:

> For a developer, there are now two ways to create an insert processor.
>
> 1. If you are happy with the global behaviour of "basic", but want to
>improve completion, I added the `org-cite-make-insert-processor'
>tool.

Just a little thing:

Why is it:

org-cite-basic--complete-style

... rather than:

org-cite-basic-complete-style

I thought you would want to encourage reuse of that one, in particular?

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Sat, Jul 3, 2021 at 3:58 AM Nicolas Goaziou  wrote:

> Anyway, I'll try to provide something a little more useful out of the
> box, based on your comment and Bruce D'Arcus suggestion.

Nicolas - I saw you pushed some changes, per the discussion.

First, my initial thought is the behavior at point is perfect.

Second, what's your intended way one enters a citation with two references?

In selectrum, I:

1. select one reference with RET
2. select another
3. C-j to exit

Is that the expected workflow and behavior?

Just want to confirm, as that doesn't work in Vertico, so I need to
figure out why (maybe a keybinding issue?).

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Sat, Jul 3, 2021 at 10:58 AM Eric S Fraga  wrote:

> > Anyway, I'll try to provide something a little more useful out of the
> > box, based on your comment and Bruce D'Arcus suggestion.
>
> But that's partly why I mentioned ivy-bibtex: solutions already exist
> and there should be no need to re-invent the wheel?

I kind of disagree.

There's a middle ground between super minimal and fully-featured that
I think is appropriate for oc-basic.

Nicolas is doing things with even the basic insert function that are
not possible with the existing tools currently, in part as a
demonstration of the possibilities, and also just to provide a decent
default experience.

But as I said to him off-list, if he simply changes his completion
table from being a list of keys, to a list of cons like I mentioned,
and maybe even makes the table a variable, then third-party tools can
do one of two things:

1. if the variable, simply plug-in their own completion table, and so
get a richer UI (this is the case with bibtex-actions, which has the
same data structure)
2. the code itself can be a demo that can be easily adapted; in my
case, I can pretty much copy-and-paste it and just change the "all"
let variables

Practically speaking, the ivy-bibtex "insert citation" action, which
uses the bibtex-completion-insert-citation function behind-the-scenes,
can then be enhanced such that it is more fully-featured in the
context of org than it is in other modes, and that it is now.

So enhancing this a little bit will have both short-term and long-term
pay-off, both for default citations in org, and for third-party tools.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Sat, Jul 3, 2021 at 5:20 AM Nicolas Goaziou  wrote:

> > First, after adding a style, I can't see how to subsequently remove it
> > using this interface, to just have "[cite:@key]". Is that possible?
>
> Of course. Just select the empty string instead of an entry. It is done
> with C-j on Selectrum and `completing-read-default'. I assume this is
> the same on other completion frameworks.

I thought I tried that to edit an existing style, and it didn't work.

But I see now it does.

Good.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Fri, Jul 2, 2021 at 4:05 PM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:

> > If I select that, "nil" is added to the citation, so that the result
> > is "[cite/nil:@key]".
>
> That's expected. "nil" is the name of the processor's fall-back style,
> ignoring any inheritance. It is different from the empty style (""),
> which takes into account inheritance.

Two things:

First, after adding a style, I can't see how to subsequently remove it
using this interface, to just have "[cite:@key]". Is that possible?

In my formatting function for OC, which is simpler than your's in some
ways, I have a named "default" style, with that as the
ido-completing-read "initial-value", which is then removed if
selected.

In practice, what that means is if the user is prompted for the style
but hits return, they select "default", and hence the result is
"[cite:@key]".

But they can also, of course, select the other named styles instead.

It seems efficient and clear to me, and if the answer to my question
above is "no", it could be a reasonable approach to address this.

Second, the "nil" vs "empty" distinction was obviously not immediately
intuitive to me. I don't have a better name for "nil" ATM though, so
maybe it will be fine. Hopefully people won't have the need to use it
much.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Fri, Jul 2, 2021 at 5:21 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> John Kitchin  writes:
>
> > I would not use a prefix arg here. you should just check what is at the
> > point, and if it is a citation then append it after the citation at point,
> > and if not insert a new one (maybe after moving the point to an appropriate
> > place if needed).
>
> Well, currently, if there's a reference at point, the function updates
> it, which I think is also a valid behaviour.
>
> On other parts of the citation, the function updates its style.

Is it possible to have three options?

1. if on "cite" prefix, edit style
2. if on citation-reference, edit reference
3. else (like where point is after a semi-colon but within the
citation), append reference

So the difference with current behavior is 1 would be more
constrained, and 3 would be a new option.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Fri, Jul 2, 2021 at 6:33 PM Nicolas Goaziou  wrote:

> The completion table, if required, and the completion mechanism belong
> to the insert function. So, you can plug anything you want.

You're right.

It is likely less work, with better results, for me to adapt what you
do with the basic insert function to my package, than vice-versa.

> I encountered this, too. I think this is a Selectrum bug, because when
I disable it, I can successfully use the UI.

Confirmed.

Vertico has no such issue, with a very similar UI/UX to selectrum.

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Fri, Jul 2, 2021, 5:48 PM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:
>
> > BTW, you may already be thinking this, but you may as well add completion
> > from the files registered with OC at this point. :-)
> >
> > Only having the completion table populated with in-document keys won't be
> > very useful, particularly in a new document.
>
> The completion table is populated by all the keys in the bibliography.
> It is not limited to in-document keys.
>

Oh good.

Let me revise then.

Rather than just completing the key, how about something like:

("title author date" . "key")

E.g. look up against the data, and return the key.

It's hard to remember keys if you have hundreds or thousands.

In bibtex-actions, I added some hidden data to the search string, including
the key, to ensure uniqueness.

> If you do, ideally it would be extensible/configurable.
> >
> > Or is the latter already the case?
>
> I am a bit lost. Would you mind explaining what should be
> extensible/configurable?
>

For example, plug in a different completion table or function?

> OTOH, IDK how much you feel the need to get everything done before merger,
> > or whether some pieces can wait?
>
> I'd like to add support for JSON bibliography in Org Cite Basic first.
>

Makes sense.

Bruce

I'm also wondering if some integration with pcomplete (M-/) is
> warranted. It may not be with an efficient enough insertion function.
> Maybe this can wait.
>
> Otherwise, I'm mostly done.
>
> Regards,
>

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

On Fri, Jul 2, 2021, 4:14 PM Nicolas Goaziou  wrote:

> "Bruce D'Arcus"  writes:
>
> > 1. I don't see a way to add a key to an existing citation. Editing an
> > existing key uses completing-read, rather than
> > completing-read-multiple (as for a new citation), and places point
> > after the existing key means the style editing UI will pop up.
>
> Indeed, there's no way to add a reference to an existing citation.
> I admit I didn't think about it. What about appending a reference when
> the function is called with C-u?


Probably that would work.

BTW, you may already be thinking this, but you may as well add completion
from the files registered with OC at this point. :-)

Only having the completion table populated with in-document keys won't be
very useful, particularly in a new document.

If you do, ideally it would be extensible/configurable.

Or is the latter already the case?

OTOH, IDK how much you feel the need to get everything done before merger,
or whether some pieces can wait?

Bruce

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

Also:

1. I don't see a way to add a key to an existing citation. Editing an
existing key uses completing-read, rather than
completing-read-multiple (as for a new citation), and places point
after the existing key means the style editing UI will pop up.
2. If I use CRM to add multiple keys, for reasons I haven't
determined, I get a "match required" error if I complete the second
key. I can only get it to work if I hit enter before fully completing
the key. I don't know if this is just some selectrum oddity/bug or
not.

On Fri, Jul 2, 2021 at 12:11 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> I just added an interface to unify functions responsible for inserting
> citations in a buffer. The default binding is .
>
> I also plugged a rather crude function with that interface. In order to
> use it, you can evaluate:
>
>   (setq org-cite-insert-processor 'basic)
>
> Internally, this will bind  to `org-cite-basic-insert', which
> can insert citations, or edit existing ones, depending on the point.
>
> From a developer point of view, you can specify two new keywords when
> registering a new processor: :insert and :cite-styles. See
> `org-cite-register-processor' for details. See also an application in
> "oc-basic.el", for example.
>
> Regards,
> --
> Nicolas Goaziou
>

Re: [wip-cite-new] Quick note about citation insertion

[Bruce D'Arcus]

Looking good Nicolas.

Just one small thing.

If I run on a citation, I get a list of styles, including "nil".

If I select that, "nil" is added to the citation, so that the result
is "[cite/nil:@key]".


On Fri, Jul 2, 2021 at 12:11 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> I just added an interface to unify functions responsible for inserting
> citations in a buffer. The default binding is .
>
> I also plugged a rather crude function with that interface. In order to
> use it, you can evaluate:
>
>   (setq org-cite-insert-processor 'basic)
>
> Internally, this will bind  to `org-cite-basic-insert', which
> can insert citations, or edit existing ones, depending on the point.
>
> From a developer point of view, you can specify two new keywords when
> registering a new processor: :insert and :cite-styles. See
> `org-cite-register-processor' for details. See also an application in
> "oc-basic.el", for example.
>
> Regards,
> --
> Nicolas Goaziou
>

Re: [PATCH] Change default latex compiler to latexmk

[Bruce D'Arcus]

Looks good, Bastien, and I think reflects the consensus of that thread.

But trying just now, I'm not able to apply the patch on my local repo
for whatever reason, so haven't tested it.



On Wed, Jun 30, 2021 at 6:48 AM Bastien  wrote:
>
> Hi Bruce,
>
> "Bruce D'Arcus"  writes:
>
> > What's the status of this patch?
>
> Can you quickly review it and say whether it's good?
>
> Thanks,
>
> --
>  Bastien

Re: [PATCH] Change default latex compiler to latexmk

[Bruce D'Arcus]

What's the status of this patch?

On Sun, Jun 6, 2021 at 12:55 PM Timothy  wrote:
>
> Hey all,
>
> From the earlier discussion on this, I got feeling a consensus had
> reached that this is a good idea, as long as we check that latexmk is
> available first.
> As such, here is a patch changing the default LaTeX compiler to latexmk
> --- as long as it's available. For what it's worth I've been using this
> exact command in my personal config for months now, and it's worked
> excellently.
>
> --
> Timothy
>

Re: [wip-cite-new] Where is the development branch ?

[Bruce D'Arcus]

On Mon, Jun 28, 2021 at 8:22 AM Eric S Fraga  wrote:
>
> On Monday, 28 Jun 2021 at 08:09, Bruce D'Arcus wrote:
> > FWIW, I added a function to format org-cite here, which you can use
> > with ivy-bibtex also.
>
> Thank you.  Very comprehensive.  Mine is much simpler!  But I have two
> versions, one for the master branch and one for the wip-cite-new branch
> and I have to keep re-evaluating the code when I switch org branches
> which is why I'm keen to have the branches merged. ;-)

Oh, for sure; I agree it'd be good to get this merged for those of us
that need to get academic work done now!

Bruce

Re: [wip-cite-new] Where is the development branch ?

[Bruce D'Arcus]

On Mon, Jun 28, 2021 at 7:07 AM Eric S Fraga  wrote:

> It would be nice to have this merged with master so that I can have the
> rest of my workflow at hand; e.g. I have ivy-bibtex inserting links to
> citations automatically but I have to change the format of what it
> inserts depending on which version of org I am using...

FWIW, I added a function to format org-cite here, which you can use
with ivy-bibtex also.

https://github.com/bdarcus/bibtex-actions/blob/main/bibtex-actions.el#L200

There were a few UI decisions I made that will need real world testing
to see if they were right.

Bruce

Re: Export Org mode files to (gag, barf) MS Office?

[Bruce D'Arcus]

IDK myself, as I don't use Windows. But this looks helpful?

https://emacs.stackexchange.com/questions/53957/how-to-fix-the-error-executable-zip-needed-for-creating-opendocument-files-w

On Sat, Jun 26, 2021 at 10:57 AM Brandon Taylor
 wrote:

> Okay. Well, I’m running Emacs on (boo, hiss) Windows, but I can’t seem to get 
> my Org mode file to export to ODT. Emacs is complaining about a missing “zip” 
> executable. How would I go about working around that little issue on a 
> Windows system?

Re: Export Org mode files to (gag, barf) MS Office?

[Bruce D'Arcus]

Oops; it does.

https://orgmode.org/manual/OpenDocument-Text-Export.html

On Sat, Jun 26, 2021, 10:54 AM Bruce D'Arcus  wrote:

> MS Office supports OpenDocument, so that might be better path for org to
> support.
>
> I've wondered myself why it doesn't already support it.
>
> On Sat, Jun 26, 2021, 10:48 AM Brandon Taylor 
> wrote:
>
>> I know we’re not supposed to really even TALK about proprietary software
>> in FOSS communities like this one, but I can’t help but wonder if someone
>> might consider making (an) Emacs plugin(s) that allow(s) a user to export
>> Org mode files to Microsoft Office file formats such as .docx, .xlsx and
>> the like? Or is/are there already (a) plugin(s) in the MELPA that can do
>> this?
>>
>>
>>
>> Brandon Taylor
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>

Re: Export Org mode files to (gag, barf) MS Office?

[Bruce D'Arcus]

MS Office supports OpenDocument, so that might be better path for org to
support.

I've wondered myself why it doesn't already support it.

On Sat, Jun 26, 2021, 10:48 AM Brandon Taylor 
wrote:

> I know we’re not supposed to really even TALK about proprietary software
> in FOSS communities like this one, but I can’t help but wonder if someone
> might consider making (an) Emacs plugin(s) that allow(s) a user to export
> Org mode files to Microsoft Office file formats such as .docx, .xlsx and
> the like? Or is/are there already (a) plugin(s) in the MELPA that can do
> this?
>
>
>
> Brandon Taylor
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

Re: [wip-cite-new] Exporting to pandoc md (and from there to zotero odt)

[Bruce D'Arcus]

Cool!

We should also get pandoc to support updated org-cite syntax.

https://github.com/jgm/pandoc/issues/7329


On Wed, Jun 23, 2021, 12:57 PM Anders Johansson 
wrote:

> Hi all,
> I appreciate the work done on the cite functionality!
> I use zotero for managing my library and have previously used zotxt
> and org-zotxt (along with some additions in my zotxt-extra library)
> for being able to cite in org-mode and export correctly to various
> formats.
> https://gitlab.com/egh/zotxt
> https://gitlab.com/egh/zotxt-emacs
> https://gitlab.com/andersjohansson/emacs-zotxt-extra
>
> Zotxt has used a custom link format for citations (similar to org-ref)
> which links to zotero but optionally also contains a citekey (defined
> via the zotero-better-bibtex extension to zotero). I actually wrote my
> PhD thesis with this setup, but the connection to Zotero has always
> felt a little wobbly and Zotero is also quite slow for my large
> library.
>
> Now seems to be a great time to convert to a workflow with the new
> cite format. To enable a conversion from org mode to word processors
> with Zotero ”active” citations I created two libraries to manage this
> via pandoc and the pandoc filter created for the zotero-better-bibtex
> extension.
> (see: https://retorque.re/zotero-better-bibtex/exporting/pandoc/)
>
> This allows me a workflow like:
> 1. keep an updated  .bib-file of my library in zotero (with the help
> of zotero-better-bibtex)
> 2. cite in org-mode (for me with completion via helm-bibtex and
> https://github.com/bdarcus/bibtex-actions/pull/113)
> 3. Export to an odt-file with active zotero citations (with oc-pandoc
> and ox-md-pandoc-zotero)
>
> I attach them here in case anyone else finds some part of this workflow
> usable.
> https://gitlab.com/andersjohansson/org-cite-pandoc
> https://gitlab.com/andersjohansson/ox-md-pandoc-zotero
>
> I couldn’t find any previous definitions for exporting to the pandoc
> cite format so I quickly hacked up org-cite-pandoc. I suppose it could
> be be widely useful and included in org. Feel free to use it as
> suitable (I have FSF copyright assignment for emacs).
>
> Best,
> Anders Johansson
>

Re: [org-cite] request for coding help on a capf to insert citation key

[Bruce D'Arcus]

On Sat, Jun 5, 2021 at 12:13 PM Bruce D'Arcus  wrote:
>
> I've been struggling with this for a while, and am a mediocre programmer, so 
> thought I'd ask for help here.

I made progress on this, with one question, for Nicolas:

What's the best way to constrain the capf?

Idea is if a user is within a citation, and types "@a", it activates.

Here's what I have now, but it's too tight; I'm assuming that second
line is the issue.

  (when (and (eq major-mode 'org-mode)
 (eq (car (org-element-context)) 'citation)
 (looking-back "@[a-zA-Z]*" 5))

Bruce

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

On Sun, Jun 20, 2021 at 3:41 AM Nicolas Goaziou  wrote:

...

> > The example you are highlighlighting here was why I was earlier
> > suggesting for a rule that would allow something like this input:
> >
> > "A quotation ending with a period." [cite: @hoel-71-whole].
> >
> > ... where the second would be dropped, hence getting the expected output.
>
> This is interesting, but we might get false positives, as in the
> following (far-fetched) example
>
>   … the so-called "foobar". [cite/text: See @hoel-71-whole p. 42].
>
> which bites us because we need to process even non-note citations to
> remove the spurious punctuation while ignoring the necessity of a given
> punctuation character.

Yeah, I wasn't sure of the details.

> As another, imperfect, workaround, I submit the following idea for
> consideration:
>
>   "A quotation ending without punctuation" [cite: @hoel-71-whole].
>   "A quotation ending with a period"[cite: @hoel-71-whole].
>
> IOW, the presence or absence of a space before the citation determines,
> according to a note rule, if the punctuation should go inside or outside
> the quotation. When processing non-note citations, we just need to
> ensure there is at least a space after the previous element, which is
> less "dangerous" than removing punctuation.
>
> I find it a bit too subtle, and so error-prone, but so is punctuation
> anyway.
>
> WDYT?

Just to confirm, Nicolas, your proposal would basically say the second
example would override the default punctuation-moving behavior for the
locale?

And for an in-text/author-date style, what would the output be with
that example?

I, someone who may have an "en-US" bias you could say, would expect:

 "A quotation ending with a period" (Hoel, 1971).

As in, the in-quote period would be dropped regardless, and therefore
a space would also need to be added.

Is that right Denis? It wouldn't make sense to do any of these; right?

 "A quotation ending with a period." (Hoel, 1971).
 "A quotation ending with a period." (Hoel, 1971)
 "A quotation ending with a period"(Hoel, 1971).
etc.

Bruce

Re: [longlines] (was: example paper written in org completely)

[Bruce D'Arcus]

I recently switched to one-sentence-per-line + visual-line-mode.

On Fri, Jun 18, 2021 at 11:00 AM John Kitchin  wrote:
>
> I use visual-line-mode. It almost always works fine for me.
>
> On Fri, Jun 18, 2021 at 10:38 AM Uwe Brauer  wrote:
>>
>> >>> "ESF" == Eric S Fraga  writes:
>>
>> > On Friday, 18 Jun 2021 at 13:55, Uwe Brauer wrote:
>> >> Right, fair enough. I thought it was MS Office or something like this.[1]
>>
>> > Yeah; I avoid that problem mostly by using ODT export in org.
>>
>> > Sometimes, if I have to work on an actual document that LibreOffice or
>> > gnumeric cannot handle, I access our institution's systems using
>> > rdesktop and/or a web interface.  Luckily, I only have to the latter
>> > once every few months at most.
>>
>> Coming back to your original post. I finally downloaded it and had a
>> quick look at its source org file.
>>
>> You are using longlines (that is now auto-fill after 70 chars).
>>
>> I never found a longline mode I liked and that is why I stick to good
>> old auto-fill with 70 chars.
>>
>> I wounder what you use to display the file (I am using a either a 14
>> inch Thinkpad X1 or 13inch MacBookAir, so maybe that is the issue here).
>>
> --
> 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
>

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

Missing word on the key sentence ...

On Mon, Jun 14, 2021 at 7:37 PM Bruce D'Arcus  wrote:

> The example you are highlighlighting here was why I was earlier
> suggesting for a rule that would allow something like this input:
>
> "A quotation ending with a period." [cite: @hoel-71-whole].
>
> ... where the second would be dropped, hence getting the expected output.

Should be "second period would ..."

Bruce

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

On Mon, Jun 14, 2021 at 7:45 AM Denis Maier  wrote:
>
> Below a few examples of what I mean.
>
> WDYT? Am I missing something?
>
> Denis
> ===
> #+cite_export: csl
> #+cite_export: csl 
> "C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"
> #+bibliography: test.bib
>
> * Original source
>
> "A quotation ending with a period."
>
> "A quotation ending without punctuation"
>
> * Author-date style input (= semantically non-strict input)
>
> "A quotation ending with a period" [cite: @hoel-71-whole].
>
> "A quotation ending without punctuation" [cite: @hoel-71-whole].
>
> ** author-date output with language: en-us
> Expected: "A quotation ending with a period" (Hoel 1971).
> Actual:   "A quotation ending with a period" (Hoel 1971).
>
> Expected: "A quotation ending without punctuation" (Hoel 1971).
> Actual:   "A quotation ending without punctuation" (Hoel 1971).
>
> => ok
>
> ** author-date output with language: de
> Expected: "A quotation ending with a period" (Hoel 1971).
> Actual:   "A quotation ending with a period" (Hoel 1971).
>
> Expected: "A quotation ending without punctuation" (Hoel 1971).
> Actual:   "A quotation ending without punctuation" (Hoel 1971).
>
> => ok
>
> ** note style output with language: en-us
> Expected: "A quotation ending with a period."[1]
> Actual:   "A quotation ending with a period."[1]
>
> Expected: "A quotation ending without punctuation."[1]
> Actual:   "A quotation ending without punctuation."[1]
>
> => ok
>
> ** note style output with language: en-gb or de
> Expected: "A quotation ending with a period."[1]
> Actual:   "A quotation ending with a period".[1]
>
> Expected: "A quotation ending without punctuation".[1]
> Actual:   "A quotation ending without punctuation".[1]
>
> => Here, we cannot distinguish between the two cases as we don't know whether 
> punctuation appears in the original source.
>
> * Note style input (=semantically strict input)
>
> "A quotation ending with a period." [cite: @hoel-71-whole]
>
> "A quotation ending without punctuation". [cite: @hoel-71-whole]
>
> As the input preserves the location of punctuation in the original material, 
> I'd say it should be much easier to deal with this. We don't have to add 
> information which isn't in the input, but rather we'll just have to move any 
> punctuation to after the citation object. Maybe I'm missing something, but to 
> me this looks like a much simpler operation than going in the opposite 
> direction.
>
> Maybe we should stop talking about author date vs note style input, but 
> rather about strict vs. non-strict input.

It's definitely not author-date vs note. I see it as in-text citations
vs note citations. As in, the former applies to other styles beyond
author-date.

The example you are highlighlighting here was why I was earlier
suggesting for a rule that would allow something like this input:

"A quotation ending with a period." [cite: @hoel-71-whole].

... where the second would be dropped, hence getting the expected output.

But IDK what Nicolas thinks of considering that now, or deferring for
later consideration.

Bruce

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

I'll let you two sort it out; I don't have a position.

On Sun, Jun 13, 2021, 3:23 PM Denis Maier  wrote:

>
> Bruce D'Arcus  hat am 14.06.2021 00:04 geschrieben:
>
>
> Nicolas explained the reverse is out of scope,
>
> IIRC, it was out of scope ATM.
>
> and gave a reasonable explanation why (because much harder to reconstruct
> missing information IIRC).
>
> That's where I disagree. I think the opposite is true.
>
> On Sun, Jun 13, 2021, 2:54 PM Denis Maier  wrote:
>
> Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> > Hello,
> >
> > Denis Maier  writes:
> >
> >> Yes, good this is coming.
> >
> > As a step forward, I rebased wip-cite-new branch with more support for
> > note numbers handling.
> >
> > I added three customizable variables:
> >
> > - org-cite-adjust-note-numbers, which simply allows the user to toggle
> >punctuation and note number moving (on by default).
> >
> > - org-cite-note-rules, which defines what rules to apply according to
> >locale, expressed as a language tag, as in RFC 4646.
> >
> > - org-cite-punctuation-marks, which lists strings recognized as
> >punctuation in the process.
> >
> > `csl' and `basic' processors now both make use of this.
> >
> > I'd appreciate some feedback, in particular about the docstrings of the
> > variables above. I focused on the "note numbers" topic instead of
> > "punctuation" since I found the latter too generic.
> >
> > Also, there are some points that may need to be discussed:
> >
> > - I'm not sure about the `org-cite-punctuation-marks' variable being
> >global, i.e., not locale-specific.
> >
> > - There is no support for this in LaTeX-derived back-ends, because
> >I don't know when a citation is going to become a footnote. As
> >a reminder, there is no "\footcite" command in `biblatex' processor.
> >OTOH, users might prefer using a more advanced mechanism, e.g.,
> >csquotes.
> >
> > - It doesn't do anything special in quote blocks, because I'm still not
> >sure there is something to do. AFAIU, special casing there only
> >applies to author-date location, which out of the scope of this code.
> >
> > WDYT?
>
> Ok, I've managed to test this a bit, and I think this looks pretty good
> so far.
>
> The only question I'd still have is if this could somehow also cover the
> reverse situation (going from a note style to author-date). I've noticed
> that simply adding a new language rule doesn't work anymore---as opposed
> to my initial tests with earlier iterations of that mechanism. Seems
> like this mechanism is now only triggered when using a note based style.
>
> Best,
> Denis
>
> >
> > Regards,
> >
>
>

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

Nicolas explained the reverse is out of scope, and gave a reasonable
explanation why (because much harder to reconstruct missing information
IIRC).

On Sun, Jun 13, 2021, 2:54 PM Denis Maier  wrote:

> Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> > Hello,
> >
> > Denis Maier  writes:
> >
> >> Yes, good this is coming.
> >
> > As a step forward, I rebased wip-cite-new branch with more support for
> > note numbers handling.
> >
> > I added three customizable variables:
> >
> > - org-cite-adjust-note-numbers, which simply allows the user to toggle
> >punctuation and note number moving (on by default).
> >
> > - org-cite-note-rules, which defines what rules to apply according to
> >locale, expressed as a language tag, as in RFC 4646.
> >
> > - org-cite-punctuation-marks, which lists strings recognized as
> >punctuation in the process.
> >
> > `csl' and `basic' processors now both make use of this.
> >
> > I'd appreciate some feedback, in particular about the docstrings of the
> > variables above. I focused on the "note numbers" topic instead of
> > "punctuation" since I found the latter too generic.
> >
> > Also, there are some points that may need to be discussed:
> >
> > - I'm not sure about the `org-cite-punctuation-marks' variable being
> >global, i.e., not locale-specific.
> >
> > - There is no support for this in LaTeX-derived back-ends, because
> >I don't know when a citation is going to become a footnote. As
> >a reminder, there is no "\footcite" command in `biblatex' processor.
> >OTOH, users might prefer using a more advanced mechanism, e.g.,
> >csquotes.
> >
> > - It doesn't do anything special in quote blocks, because I'm still not
> >sure there is something to do. AFAIU, special casing there only
> >applies to author-date location, which out of the scope of this code.
> >
> > WDYT?
>
> Ok, I've managed to test this a bit, and I think this looks pretty good
> so far.
>
> The only question I'd still have is if this could somehow also cover the
> reverse situation (going from a note style to author-date). I've noticed
> that simply adding a new language rule doesn't work anymore---as opposed
> to my initial tests with earlier iterations of that mechanism. Seems
> like this mechanism is now only triggered when using a note based style.
>
> Best,
> Denis
>
> >
> > Regards,
> >
>
>

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

On Sat, Jun 12, 2021 at 6:04 PM Nicolas Goaziou  wrote:

> Of course, different punctuation marks exist, so characters are at least
> locale-dependant. But I don't know if the set is entirely determined by
> the locale or if it also depends on the "style" of the document.

It's a good question. I need to think about this one.

> > So the upshot is if users want this functionality for LaTeX/PDF, they
> > should use oc-biblatex for that export target?
>
> Actually, that's the opposite. I don't know if it is possible, or even
> appropriate, to port that feature to `biblatex' and `natbib' processors.
> So, ATM, if you want it, and target LaTeX/PDF, your only option is
> `csl'.

OIC; I misread your post.

To clarify (I realized after sending that message I should have done
so), biblatex, at least, has this sort of punctuation moving included
out-of-box. So there's indeed no need to include it in oc-biblatex.

I thought you were saying you were not including such moving in oc-csl
latex export, hence my question.

So I think we're good on that then.

Bruce

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

I'm not able to test this closely ATM, but a few things ...

On Sat, Jun 12, 2021 at 5:39 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Denis Maier  writes:
>
> > Yes, good this is coming.
>
> As a step forward, I rebased wip-cite-new branch with more support for
> note numbers handling.
>
> I added three customizable variables:
>
> - org-cite-adjust-note-numbers, which simply allows the user to toggle
>   punctuation and note number moving (on by default).
>
> - org-cite-note-rules, which defines what rules to apply according to
>   locale, expressed as a language tag, as in RFC 4646.
>
> - org-cite-punctuation-marks, which lists strings recognized as
>   punctuation in the process.
>
> `csl' and `basic' processors now both make use of this.
>
> I'd appreciate some feedback, in particular about the docstrings of the
> variables above. I focused on the "note numbers" topic instead of
> "punctuation" since I found the latter too generic.
>
> Also, there are some points that may need to be discussed:
>
> - I'm not sure about the `org-cite-punctuation-marks' variable being
>   global, i.e., not locale-specific.

One of the things I've wondered about, but cannot offer any expertise
on (really, I have no clue), is how this might work for languages like
Arabic or Mandarin.

> - There is no support for this in LaTeX-derived back-ends, because
>   I don't know when a citation is going to become a footnote. As
>   a reminder, there is no "\footcite" command in `biblatex' processor.
>   OTOH, users might prefer using a more advanced mechanism, e.g.,
>   csquotes.

So the upshot is if users want this functionality for LaTeX/PDF, they
should use oc-biblatex for that export target?

> - It doesn't do anything special in quote blocks, because I'm still not
>   sure there is something to do. AFAIU, special casing there only
>   applies to author-date location, which out of the scope of this code.

Here's the scenario I believe Denis was concerned about:

#+begin_quote
... block with citation at end. [cite:@doe]
#+end_quote

I think in standard author-year styles, we'd want:

... block with citation at end. (Doe, 2020)

... while in note-based and "US" (space removed):

... block with citation at end.[1]

Not sure if that has any practical import, but just to clarify.

Bruce

Re: [wip-cite-new] experimental citeproc-el based activation processor

[Bruce D'Arcus]

Good; I was wondering about that!

On Sat, Jun 12, 2021, 8:47 AM Timothy  wrote:

>
> Update: I found the thread,
> https://orgmode.org/list/87lf90b5ey@gnu.org/
>
> Timothy  writes:
>
> > Regarding the Emacs 24.3 requirement, I haven't got the thread on hand
> > but IIRC Bastien said that he will bump Org's minimum Emacs to 25 in the
> > 9.5 release. As long as I'm not mis-remembering, the above should be
> > fine.
>
>

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 4:25 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > On Tue, Jun 8, 2021 at 7:36 AM Bruce D'Arcus  wrote:
> >
> >> (org-cite-register-processor 'bibtex
> >> :follow #'bibtex-completion-open-any)
> >
> > Actually, looking at the docstrings, I don't think this will work as
> > is, as the follow processor "accepts two arguments, the citation or
> > citation reference object at point", while the bibtex-completion
> > functions take a list of keys.
> >
> > So I guess for that I'd need a little wrapper to call that function.
>
> Indeed.

Not a big deal, but I'll ask :-)

Given how common existing functions are that take a list of keys, WDYT
about adding something like a `org-cite-get-references-keys` helper
function, to parallel `org-cite-get-references`?

So in this case one could do:

(bibtex-completion-open-any (org-cite-get-references-keys datum)))

Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 4:25 PM Nicolas Goaziou 
wrote:

> > Still, I'm confused why the basic font-locking doesn't work in this
case.
>
> I know it is not terribly useful but… it works here. For example, if no
> bibliography is defined, all cite keys are red (error face).

Actually that is useful; it confirms I basically understand this, but
there's something else wrong with my config or something.

Thanks,
Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 7:36 AM Bruce D'Arcus  wrote:

> (org-cite-register-processor 'bibtex
> :follow #'bibtex-completion-open-any)

Actually, looking at the docstrings, I don't think this will work as
is, as the follow processor "accepts two arguments, the citation or
citation reference object at point", while the bibtex-completion
functions take a list of keys.

So I guess for that I'd need a little wrapper to call that function.

Still, I'm confused why the basic font-locking doesn't work in this case.

Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Tue, Jun 8, 2021 at 5:33 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > So would it be so simple as doing something like this, to use the
> > bibtex-completion-open function instead?
> >
> > (org-cite-register-processor 'basic
> >   :follow #'bibtex-completion-open)
> >
> > As in, that just tells what function to use for at-point?
> >
> > If yes, that definitely works!
>
> It does, but you're overriding `basic' processor. You could as well
> define your own processor
>
>   (org-cite-register-processor 'bibtex
> :follow #'bibtex-completion-open)
>
> and use it with
>
>   (setq org-cite-follow-processor 'bibtex)
>
> > I've been a bit slow wrapping my head around the difference between
> > follow and activate, but I think it's starting to become more clear.
>
> Follow is what happens when you use C-o on a citation. Activate is run
> in the background during font-lock.

That's a very clear explanation!

So I'm trying to get this working now.

Here's what I want:

- "basic" font-locking
- bibtex-completion-open-any for C-o

If I understand correctly, the below minimal config should work, but
does not; as in, no font-locking, and C-o returns a "no link found".

What am I doing wrong?

(require 'oc-basic)
(require 'bibtex-completion)

(org-cite-register-processor 'bibtex
:follow #'bibtex-completion-open-any)

(setq org-cite-follow-processor 'bibtex)
(setq org-cite-activate-processor 'basic)

Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 5:27 PM Bruce D'Arcus  wrote:

> So would it be so simple as doing something like this, to use the
> bibtex-completion-open function instead?
>
> (org-cite-register-processor 'basic
>   :follow #'bibtex-completion-open)
>
> As in, that just tells what function to use for at-point?

... or rather, one would have to write additional code to accompany
that function?

LIke a 'oc-bibtex-completion-follow'?

Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 5:14 PM Nicolas Goaziou  wrote:

> ... would be great do something
> > like:
> >
> > (setq org-cite-basic-open bibtex-completion-open-pdf)
>
> If you want to use a different "follow" capability, you need to provide
> a different processor instead of configuring this one.

OIC.

So would it be so simple as doing something like this, to use the
bibtex-completion-open function instead?

(org-cite-register-processor 'basic
  :follow #'bibtex-completion-open)

As in, that just tells what function to use for at-point?

If yes, that definitely works!

I've been a bit slow wrapping my head around the difference between
follow and activate, but I think it's starting to become more clear.

> > Second, I completely lose font-locking when using json files. I know
> > you have plans, Nicolas, to add json support, but even without that,
> > shouldn't the citation be highlighted?
>
> Could you provide an example?

I'm sorry; you're going to kill me.

In trying to reproduce it just now, I can't.

So I guess you can ignore this too.

Bruce

Re: [org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 12:53 PM Bruce D'Arcus  wrote:

> ... would be great do something
> like:
>
> (setq org-cite-basic-open bibtex-completion-open-pdf)

I guess that raises a question for me about what code goes where.

Maybe instead have it set in oc.el?

(setq org-cite-open 'bibtex-completion-open-pdf)

Bruce


Bruce

[org-cite, oc-basic] configurable open-at-point, font-locking when json?

[Bruce D'Arcus]

I'm kind of losing track of details, but two things:

First, the current oc-basic has a "follow" function that if point is
over a citation-reference (key), and one does "M-x org-open-at-point",
the bibtex entry is opened.

Very cool!

Similar to my idea to have a configurable capf, could that function be
configurable?

A couple of people noted, for example, that the preferred choice would
be that the actual document be opened. I actually got a PR for exactly
this default behavior this past weekend, and bibtex-completion has a
function that takes keys and does this. So would be great do something
like:

(setq org-cite-basic-open bibtex-completion-open-pdf)

Second, I completely lose font-locking when using json files. I know
you have plans, Nicolas, to add json support, but even without that,
shouldn't the citation be highlighted?

Bruce

Re: Could a citation act as a link, or a link to be exported as a citation?

[Bruce D'Arcus]

On Mon, Jun 7, 2021 at 3:02 AM Ypo  wrote:
>
> I've been reading you about cites. Conversation is above my head, but just in 
> case it could be helpful, I would like to address a frequent problem in the 
> workflow of taking notes, that advanced users suffer too.
>
> When taking notes, it's usual to make some bibliographical references in one 
> file and some related notes in a different file. I link both using internal 
> links, but it can't be exported directly as a bibliography, which would be 
> cool indeed.
>
> Could a citation act as a link, or a link to be exported as a citation?

In general, a citation is conceptually a kind of specialized link.

And org-ref and now org-cite is designed around the possibility of
attaching actions to those citations. So, for example:

> An example, could the link "[[id:20210607T083216.726761][...]]" be 
> substituted by a cite, that takes you to the reference?

The oc-basic processor has an at-point function that will do just
this, if by "reference" you mean the bibtex (and maybe ultimately csl
json) source entry.

Have you looked at org-roam and org-roam-bibtex?

If not, that might give you some ideas, as it heavily relies on org
links, but also has support for citations.

Plans there are to support org-cite, BTW.

Bruce

Re: [PATCH] Allow LaTeX reference command (\ref) to be customised

[Bruce D'Arcus]

+1

On Sun, Jun 6, 2021, 2:19 PM Timothy  wrote:

> Hi All,
>
> I've started doing some more cross-referencing in documents exported to
> LaTeX, and a hardcoded use of \ref has begun to stand out to me as a
> rather annoying thing. Hypperef provides \autoref for adding helpful
> prefixes (section, figure, etc.), and there are other packages which one
> may want to use to generate 'clever' references (like cleveref with
> \cref).
>
> As such, I think that the hardcoded \ref should actually be turned into
> a customisable format string, which is what the attached patch does.
>
> --
> Timothy
>
>

Re: [org-cite] request for coding help on a capf to insert citation key

[Bruce D'Arcus]

One other idea, Nicolas:

Is there room to include a org-cite somehow, so that one had a defcustom like:

(setq org-cite-complete-key-candidates my-candidates)
;; here override default with results from my package
(setq my-candidates (bibtex-actions--get-candidates))

... and default could be some simple thing in oc-basic?

If not, totally fine of course, but I thought I'd mention it as I'm
trying to figure this out.

Bruce

On Sat, Jun 5, 2021 at 5:14 PM Bruce D'Arcus  wrote:
>
> Round 2, which should address the "regex" todo.
>
> --8<---cut here---start->8---
> (defun bibtex-actions-complete-key-at-point-oc ()
> "Complete org-cite citation key at point.
>
> When inserting '@' in a buffer the capf UI will present user with
> a list of entries, from which they can narrow against a string
> which includes title, author, etc., and then select one.  This
> function will then return the key 'key', resulting in '@key' at
> point."
> ;; FIX exit-function is wrong; results in "no match"
>   (when (and (eq major-mode 'org-mode)
>  (eq (car (org-element-context)) 'citation))
> (let* ((candidates (bibtex-actions--get-candidates))
>(begin (save-excursion (backward-word) (point)))
>(end (point)))
>   (list begin end candidates :exclusive 'no
> :exit-function
> (lambda (chosen status)
>   (when (eq status 'finished)
> (cdr (assoc chosen candidates
> --8<---cut here---end--->8---

Re: [org-cite, oc-basic] Citation disambiguation

[Bruce D'Arcus]

I believe he rebased it and modified the history? So same branch.

On Sun, Jun 6, 2021, 7:36 AM András Simonyi 
wrote:

> Dear All,
>
> On Fri, 4 Jun 2021 at 23:06, Nicolas Goaziou 
> wrote:
>
> > > I think some kind of disambiguation strategy should be implemented for
> > > the basic citation backend to be really usable with the author-year
> > > style. WDYT?
> >
> > Implemented in latest wip-cite-new branch.
> >
> > Regards,
>
> Thanks, this is amazing! I was trying to look into it, but the latest
> commit I see at
> https://code.orgmode.org/bzg/org-mode/commits/wip-cite-new is from a
> week ago. Is there a different location from which I can pull this
> update?
>
> thanks again,
> András
>
>

Re: [wip-cite-new] Adjust punctuation around citations

[Bruce D'Arcus]

On Sat, Jun 5, 2021 at 5:35 PM Nicolas Goaziou  wrote:

> Getting back to this thread… I'd like to see it moving forward.

Yes. This is the last missing piece I see!

> You lost me here. Punctuation moving was implemented with notes cites in
> mind (much like Pandoc, I think).

Correct. And also biblatex.

> More exactly, punctuation shuffling
> may happen whenever a cite turns into a footnote. For any other case,
> the author is expected to place the cite object manually. So, the
> automation does not apply to blockquotes, in the sense that inline
> quotes or blockquotes use the same location for footnotes.

I guess to bottomline it, see the link that Denis provided, including
to the end with footnotes.

https://writingcenter.uagc.edu/block-quotations

I haven't tested the punctuation moving for this specifically, but it
would suggest a user would place this in a blockquote:

... end of sentence. [cite:@doe]

... and the result should remove the space for a footnote.

... end of sentence.[1]

I don't know how quotes work here, but perhaps there's no difference. Denis?

Bruce

Re: [org-cite] request for coding help on a capf to insert citation key

[Bruce D'Arcus]

Round 2, which should address the "regex" todo.

--8<---cut here---start->8---
(defun bibtex-actions-complete-key-at-point-oc ()
"Complete org-cite citation key at point.

When inserting '@' in a buffer the capf UI will present user with
a list of entries, from which they can narrow against a string
which includes title, author, etc., and then select one.  This
function will then return the key 'key', resulting in '@key' at
point."
;; FIX exit-function is wrong; results in "no match"
  (when (and (eq major-mode 'org-mode)
 (eq (car (org-element-context)) 'citation))
(let* ((candidates (bibtex-actions--get-candidates))
   (begin (save-excursion (backward-word) (point)))
   (end (point)))
  (list begin end candidates :exclusive 'no
:exit-function
(lambda (chosen status)
  (when (eq status 'finished)
(cdr (assoc chosen candidates
--8<---cut here---end--->8---

[org-cite] request for coding help on a capf to insert citation key

[Bruce D'Arcus]

I've been struggling with this for a while, and am a mediocre programmer,
so thought I'd ask for help here.

I started out writing this generate capf to insert citation keys, but have
decided to make it specific to org-cite.

Here's the commented function.

TIA.

Note the "candidates" variable accesses a cached alist, of the form:

("long search string with title, author, etc." . "citekey")

So I want the user to be able to select on the car, but insert the cdr.


--8<---cut here---start->8---
(defun bibtex-actions-complete-key-at-point-oc ()
"Complete org-cite citation key at point.

When inserting '@' in a buffer the capf UI will present user with
a list of entries, from which they can narrow against a string
which includes title, author, etc., and then select one.  This
function will then return the key 'key', resulting in '@key' at
point."
;; FIX exit-function is wrong; results in "no match"
;; TODO tighten this regex for org-cite
  (when (looking-back "@[a-zA-Z]+" 5)
(let* ((candidates (bibtex-actions--get-candidates))
   (begin (save-excursion (backward-word) (point)))
   (end (point)))
  (list begin end candidates :exclusive 'no
:exit-function
(lambda (chosen status)
  (when (eq status 'finished)
(cdr (assoc chosen candidates
--8<---cut here---end--->8---

Re: [oc-csl] citations in footnotes

[Bruce D'Arcus]

On Fri, Jun 4, 2021 at 9:28 AM Nicolas Goaziou  wrote:

> OK. Fixed. Thank you.

Looks good; thanks!

Bruce

Re: [org-cite, oc-csl] setting no-link parameter within document?

[Bruce D'Arcus]

On Fri, Jun 4, 2021 at 8:51 AM Denis Maier  wrote:

> > I still think it would be valuable to have the option to do something
> > like this, so it works across export backends.
> >
> > #+print_bibliography: :links nil
>
> Turns out, such an option already exists, at least for biblatex:
> \usepackage[hyperref=false]{biblatex}
>
> IIRC, it is possible to pass options to the biblatex package, right? As
> this is mostly relevant for biblatex I assume this here does the job.

What is "this"?

In any case, to restate:

Citeproc-el has a "no-links" parameter that can currently be
controlled with 'org-cite-csl-link-cites'.

By default it is set to t, which means one gets linked citations in
all output formats. This is fine and good.

I'm just asking to be able to do that at the document level.

That keyword could also be recognized by oc-biblatex too, though I'm
not specifically suggesting that ATM.

Bruce

Re: [org-cite, oc-csl] setting no-link parameter within document?

[Bruce D'Arcus]

On Fri, Jun 4, 2021 at 8:18 AM Eric S Fraga  wrote:
>
> On Friday,  4 Jun 2021 at 14:01, Denis Maier wrote:
> > Ok, I first thought you can just add the configuration to the
> > LATEX_HEADER keywords, but that won't work since everything in there
> > is loaded before hyperref.
>
> I am not sure what is loaded before but most of my documents have
> something along the lines of
>
> #+latex_header: 
> \hypersetup{colorlinks=true,citecolor=red!80!black,urlcolor=blue!60!black}
>
> adjusted for individual documents; this works just fine for me.

Good to know; thanks!

I still think it would be valuable to have the option to do something
like this, so it works across export backends.

#+print_bibliography: :links nil

Bruce

[org-cite, oc-csl] setting no-link parameter within document?

[Bruce D'Arcus]

I see the processor has a org-cite-csl-link-cites defcustom to set
this globally, but can one set it at the document level?

Further explanation:

The default hyperref settings in latex export in general are too much,
with boxes everywhere and garish colors.

When coupled with a note style with bibliography, like
chicago-note-bibliography-16th-edition.csl, it's overwhelming, Notably
each footnoted text becomes linked. And in that case, the linked data
is redundant. Example and screenshots here:

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

So I can imagine a user generally leaving the defcustom set to true,
but on individual documents (like with the chicago example) wanting to
turn it off.

Note that one can, per the thread I link to above, turn off links, or
modify their colors, using hyperref. But that's specific to the latex
export, and I don't think (?) there's an easy way to set that at the
document level.

Bruce

Re: [org-cite, oc-basic] Citation disambiguation

[Bruce D'Arcus]

On Thu, Jun 3, 2021 at 5:13 PM András Simonyi  wrote:

> I think some kind of disambiguation strategy should be implemented for
> the basic citation backend to be really usable with the author-year
> style. WDYT?

I hadn't tested that, but I agree.

As you know, disambiguation can get complicated, but that approach is
easy low-hanging fruit.

Bruce

[oc-csl] citations in footnotes

[Bruce D'Arcus]

In the approach taken by CSL implementations, and by biblatex
autocite, when dealing with note styles, you have two kinds of
citations in notes:

1. what we might call "automatically footnoted"; citations in the
running text that get converted on export to footnotes (or endnotes)
2. citations within footnotes, that get output as is, without any
footnote wrapping.

With this input:

---
Body text with a citation: [cite:@mcneill2011].

Footnote: [fn:1]

#+print_bibliography:

* Footnotes

[fn:1] A commentary, and then a citation: [cite:@low2001].
-

... the citation within the footnote now generates an additional footnote.


[3] A commentary, and then a citation:[4].

[4] Low, “The Edge and the Center: Gated Communities and the Discourse
of Urban Fear.”
-

It should not; output should be:


[3] A commentary, and then a citation: Low, “The Edge and the Center:
Gated Communities and the Discourse of Urban Fear.”
-

Bruce

Re: suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

On Wed, Jun 2, 2021 at 12:30 PM Colin Baxter  wrote:
>
>
> I'm beginning to think this change of the default should not
> happen. From this thread it seems to be that the chances of it breaking
> existing work flow is high.

I don't see how that follows. Can you clarify?

> I really don't understand why the changed is needed.

I've stated it twice, I believe, but it's now a longer thread, so:

Org is set to get native citation support.

Once that's merged, people who use this feature will be disappointed
to know that when using the natbib or biblatex export processors,
their citations and bibliographies will not render.

As in, from their perspective, it will be broken upfront.

Bruce

Re: suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

On Wed, Jun 2, 2021 at 4:28 AM Tim Cross  wrote:

> The more I think about it, I think the best solution would be to update
> the code which sets the default and have it check for latexmk. If it is
> found, set it as the default and if it is not found, set the existing
> default. This would have minimum impact on users and allow those who
> have installed latexmk to get the benefits while not forcing those who
> don't need it to install it.

If this were possible, I agree it would be the best approach.

Bruce

Re: suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

On Tue, Jun 1, 2021 at 9:09 PM Scott Randby  wrote:

> As a constant user of Org's LaTeX export capability, this change would break 
> my ability to export to PDF, and it would be difficult for me to fix. I don't 
> support this change.

Can you explain this, Scott? Why would anything "break'?

And for those that think this is a bad idea, suggested alternatives?

With the status quo; new org-cite users will run latex/pdf output
process and will be surprised by the results, as there will be no
citations or bibliography.

I suppose the easy solution is a prominent note in the documentation.

Bruce

Re: [oc-basic]

[Bruce D'Arcus]

On Tue, Jun 1, 2021 at 5:25 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > It seems if I have only global bibliographies set, the oc-basic
> > blue/red flagging of citekeys will always be red, even if the keys are
> > correct.
>
> I cannot reproduce it. Would you have a more precise example?

I tried a minimal example, and can't reproduce it either.

It's possible what I was seeing was when I had both a json and a bib
file specified in the global bibliography, though when I tried that
again now, I also can't reproduce it.

If and when I do, I will be sure to include further details.

Bruce

Re: suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

On Tue, Jun 1, 2021 at 1:03 PM Timothy  wrote:
>
>
> Bruce D'Arcus  writes:
>
> > Thanks Timothy.
> >
> > What's your view on modifying current default?
>
> I think latexmk is a pretty reasonable expectation, and your
> justification that it's more important seems sound to me.
>
> Using the value seen in my config, I've found that at the least my
> version of latexmk interprets the arguments such that
> `org-latex-compilers' still works as expected (with xelatex, lualatex,
> etc.). Perhaps this would make sense as a new default if it works well
> for others too (without the -shell-escape bit though).

Here's the current command for the "latexmk" option:

"latexmk -g -pdf -pdflatex=\"%latex\" -outdir=%o %f"

... and here's what you have, minus shell-escape.

"latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f"

Do they not both account for the engine (luatex, xetex, etc.)?

In any case, whatever the command is, clearly it should.

Bruce

Re: suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

Thanks Timothy.

What's your view on modifying current default?

On Tue, Jun 1, 2021, 12:36 PM Timothy  wrote:

>
> Hi Bruce,
>
> In case it's of interest, I've been quite happy with this:
> https://tecosaur.github.io/emacs-config/config.html#compiling
>
> Bruce D'Arcus  writes:
>
> > While testing org-cite a few weeks ago, I noticed by default bibtex
> > won't run with natbib export, or biblatex with biblatex export.
> >
> > Since org has not had native citations, this is not surprising.
> >
> > But with org-cite coming soon, this will change.
> >
> > At the time I suggested changing default to use latexmk, which will
> > handle both bibtex and biblatex runs.
> >
> > https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00486.html
> >
> > So what do LaTeX users think about changing the default for
> > "org-latex-pdf-process" to "latexmk"?
> >
> > Is there any reason not to do this?
> >
> > Bruce
>
> --
> Timoty
>

suggestion to change default org-latex-pdf-process to latexmk

[Bruce D'Arcus]

While testing org-cite a few weeks ago, I noticed by default bibtex
won't run with natbib export, or biblatex with biblatex export.

Since org has not had native citations, this is not surprising.

But with org-cite coming soon, this will change.

At the time I suggested changing default to use latexmk, which will
handle both bibtex and biblatex runs.

https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00486.html

So what do LaTeX users think about changing the default for
"org-latex-pdf-process" to "latexmk"?

Is there any reason not to do this?

Bruce

[oc-basic]

[Bruce D'Arcus]

It seems if I have only global bibliographies set, the oc-basic
blue/red flagging of citekeys will always be red, even if the keys are
correct.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sun, May 30, 2021 at 4:20 PM Nicolas Goaziou  wrote:

> > Would you have this nil by default, or is there a reasonable default
> > you could set?
>
> I wrote "oc-basic" to be a reasonable, albeit very limited, default.
> I just need to make it grow JSON support first.

It might not line up with your timeline for this, , and I'm not sure
if you want to depend on an external library, but you should probably
be aware of the work that Joost is doing on parsebib to integrate CSL
JSON support.

The branch, including documentation:

https://github.com/joostkremers/parsebib/tree/wip/csl

Feedback etc:

https://github.com/joostkremers/parsebib/issues/12

Bruce

Re: [org-cite, oc-csl] print_bibliography options

[Bruce D'Arcus]

On Mon, May 31, 2021 at 2:11 PM András Simonyi  wrote:
>
> Dear All,
>
> I think a useful default/baseline for handling the occurrence of
> multiple #+print_bibliography keywords  would be to implement the
> "chapter use case", which, for each #+print_bibliography, would
> collect only the citations occurring after to previous
> #+print_bibliography (if there is one) and before the current one, and
> print out an independent bibliography corresponding to the citations.
> All citations in this section would refer to this bibliography, and
> would be disambiguated accordingly.

This would have two advantages:

1) add support for the "per section/chapter" use case András notes to oc-csl
2) avoid duplicate bibliographies in the example I raised; what we
might call "multi-section bibliography" use case; then if and when
citeproc-el adds support this, the documents would be gracefully
enhanced

Bruce

Re: [oc-csl] testing status

[Bruce D'Arcus]

On Mon, May 31, 2021 at 10:33 AM András Simonyi
 wrote:
>
> Dear All,
>
> (what follows is  a copy of my reply to the corresponding citeproc-el issue)
> I think I managed to track this down. First of all, the issue doesn't
> affect html and latex Org exports, which use the html and latex output
> of citeproc-el directly; the problematic behavior occurs only when
> citeproc-el produces org output and this gets embedded in the Org
> document before exporting. In the latter case, the Org exporter treats
> the doi links in the bibliography as it would any doi link in the
> document, and, apparently, this means converting them to urls by
> default. (I don't know what is the easiest way of turning this off.)

I'll also copy my reply:

Thanks for looking into this!

I'm glad I was wrong about it also happening with the HTML output; I
got confused as I was switching styles.

If this doesn't happen with HTML and LaTeX, it's much less of an
issue. But still, ideally it would work consistently (across
backends).

Bruce

Re: [oc-csl] testing status

[Bruce D'Arcus]

On Sun, May 30, 2021 at 5:24 PM András Simonyi  wrote:
>
> Dear All,
>
> On Sun, 30 May 2021 at 22:38, Bruce D'Arcus  wrote:
>
> > There is one thing I can't figure out. Here's the output I get:
> > I don't understand why that URL is included, as that entry has no URL.
>
> > It seems citeproc-el may have a parameter that substitutes DOI URL if
> > DOI is present, but URL is absent if t?
>
> > András: Is that correct?
>
> citeproc-el definitely doesn't have this kind of functionality, it
> must come from the used CSL style somehow. Is the result different
> with other citeprocs?

It's maybe a style issue, though I haven't figured it out yet.

This is what pandoc produces with the same style etc.

Low, Setha M. “The Edge and the Center: Gated Communities and the
Discourse of Urban Fear.” American Anthropologist 103, no. 1 (March 1,
2001): 45–58. doi:10.1525/aa.2001.103.1.45.

... which is what I read the style
(chicago-note-bibliography-16th-edition.csl) to specify.

I'll explore more, probably tomorrow.

Bruce

Re: [oc-csl] testing status

[Bruce D'Arcus]

On Sun, May 30, 2021 at 4:23 PM Bruce D'Arcus  wrote:
>
> On Sun, May 30, 2021 at 4:12 PM Nicolas Goaziou  
> wrote:
> >
> > Hello,
> >
> > "Bruce D'Arcus"  writes:
> >
> > > 1. JSON input doesn't work for me:
> > > https://github.com/andras-simonyi/citeproc-el/issues/20
> >
> > I think I fixed this one. I cannot test it properly as I don't have
> > a JSON bibliography file.
>
> Yes, I can confirm you fixed it. Thanks!

There is one thing I can't figure out. Here's the output I get:

Low, Setha M. “The Edge and the Center: Gated Communities and the
Discourse of Urban Fear.” /American Anthropologist/ 103, no. 1 (March 1,
2001): 45–58. <https://doi.org/10.1525/aa.2001.103.1.45>.

I don't understand why that URL is included, as that entry has no URL.

It seems citeproc-el may have a parameter that substitutes DOI URL if
DOI is present, but URL is absent if t?

I can't immediately find it, but if that's the case, I think that
should be turned off.

András: Is that correct?

Bruce

Re: [oc-csl] testing status

[Bruce D'Arcus]

On Sun, May 30, 2021 at 4:12 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > 1. JSON input doesn't work for me:
> > https://github.com/andras-simonyi/citeproc-el/issues/20
>
> I think I fixed this one. I cannot test it properly as I don't have
> a JSON bibliography file.

Yes, I can confirm you fixed it. Thanks!

So I closed the above issue.

Also, I posted a minimal CSL JSON file here, in case anyone needs it.

https://gist.github.com/bdarcus/98e6d3ef9be22e0912670469f04f28da

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 12:22 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > On Fri, May 28, 2021 at 4:31 PM András Simonyi  
> > wrote:
> >
> >> Maybe instead of a full alist mapping backends to citation processors
> >> we could have only options to declare a separate processor for
> >> latex-based backends and another for non-latex ones?
> >
> > This would go a long way, and is probably all that's necessary.
> >
> > Really "latex" is the unique output mode here.
>
> But one may want to use a different processor for, say, beamer and
> regular latex. Both are "latex" based. Worse, all custom back-ends
> derived from "latex" are bound to use the same processor.

I indeed hadn't thought about that.

> Here's another proposal:
>
> `org-cite-export-processor' is now an alist, where keys are export
> back-ends or t, which is the default key.
>
>   '((latex biblatex bibstyle citestyle)
> (beamer natbib nil nil)
> (my-latex natbib bibstyle)
> (t csl nil nil))
>
> The selected processor is the one associated to the back-ends closest to
> the current one used for export, by `org-export-derived-backend-p'
> order. So if `my-other-latex' is derived from beamer, it will use
> (natbib nil nil).
>
> OTOH, I suggest to stick to a single "cite_export" keyword, which
> overrides any selected processor above. IOW
>
>#+cite_export: basic
>
> will use basic whatever the current export back-end is.
>
> In practice, I think it is sufficient. The only case where it may be
> limiting is if you need to export with two different back-ends with two
> processors different from those set in `org-cite-export-processor'. But
> in that situation, I think swapping the cite_export keyword is
> acceptable.
>
> So overall, I think it is a good compromise between simplicity and
> power.
>
> WDYT?

I'm not the best person to weigh in on org details, but in general, it
looks good to me.

Just to confirm, then, this would allow me to specify:

1. oc-csl as default
2. oc-biblatex as default for latex
3. locally override

With 3, if on a particular document I didn't want 2, I'd just do this
in the document, which would suppress 2 in effect?

#+cite_export: csl style

...?

Would you have this nil by default, or is there a reasonable default
you could set?

Bruce

[oc-csl] testing status

[Bruce D'Arcus]

For anyone here testing oc-csl, and to update Nicolas, I've reported
all the issues I've found either here, or on the citeproc-el issue
tracker.

For the latter:

1. JSON input doesn't work for me:
https://github.com/andras-simonyi/citeproc-el/issues/20
2. suppress author improvements:
https://github.com/andras-simonyi/citeproc-el/issues/19
3. multi-bib: https://github.com/andras-simonyi/citeproc-el/issues/17
4. "full" variant support:
https://github.com/andras-simonyi/citeproc-el/issues/16
5. "author" and "text" style support:
https://github.com/andras-simonyi/citeproc-el/issues/15

And there's an existing issue there to add biblatex input support:

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

For anyone testing this, I'm particularly curious if you have any
success with 1 (JSON input).

All of these are minor issues that I don't think should hold up
oc-csl, except maybe the JSON issue if it's confirmed beyond me.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 1:25 PM Bruce D'Arcus  wrote:
>
> On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou  
> wrote:

> > We dropped variant inheritance some time ago already, when the suggested
> > syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> > totally different from Org Cite POV. I'd rather not re-introduce this.
>
> Oh wait, I just realized citeproc-el already has a parameter for
> "caps" (which I hadn't realized).
>
> - "bare" -> "suppress-affixes" parameter
> - "caps" -> "capitalize-first"
>
> Right?
>
> So that would allows support for:
>
> - "bare"
> - "caps"
> - "bare-caps"
>
> So if he adds an equivalent of the "full" parameter, that could extend
> the sub-styles support in oc-csl?

I added an issue for this at the citeproc-el issue tracker:

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

Note that one key difference with oc-csl is the variants are
configured with individual parameters, while LaTeX uses commands.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > Right now, citeproc-el, and hence also oc-csl, only supports the "bare" 
> > variant.
> >
> > Would it be feasible, and make sense, to fall back all "bare" variants
> > to "bare" for now?
> >
> > So this:
> >
> > [cite//bare-caps:@latexcompanion]
> >
> > ... would render as:
> >
> > Doe 2019
>
> We dropped variant inheritance some time ago already, when the suggested
> syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> totally different from Org Cite POV. I'd rather not re-introduce this.

Oh wait, I just realized citeproc-el already has a parameter for
"caps" (which I hadn't realized).

- "bare" -> "suppress-affixes" parameter
- "caps" -> "capitalize-first"

Right?

So that would allows support for:

- "bare"
- "caps"
- "bare-caps"

So if he adds an equivalent of the "full" parameter, that could extend
the sub-styles support in oc-csl?

> Maybe "bare" need to be promoted as a full-fledged style, so "bare/caps"
> could fallback to "bare". I don't know.

I thought of that too, but it won't work, because "bare" applies to
multiple styles.

Bruce

Re: [org-cite, oc-csl] print_bibliography options

[Bruce D'Arcus]

On Sat, May 29, 2021 at 11:15 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> >> Bibliography is printed using "\printbibliography" command.  Additional
> >> options may be passed to it through a property list attached to the
> >> "print_bibliography" keyword.  E.g.,
> >>
> >>#+print_bibliography: :section 2 :heading subbibliography
>
> > I don't believe citeproc-el currently supports any of these features,
> > and it looks like the citeproc-el API doesn't even have an optional
> > parameter to put details like these.
> >
> > As a consequence, if one adds an example like the above, so that one
> > has two print_bibliography lines, one will get two, duplicate
> > bibliography lists outside of oc-biblatex.
>
> I don't understand how you reach that consequence… If the citation
> processor does not understand the properties, it simply ignores them,
> but obeys to "print_bibliography" directive anyhow.
>
> Have you tried it? I'm not sure to understand your concern.

Yes.

I think we're saying the same thing, but maybe I need to clarify the
implications better?

See below.

Let me illustrate with a full example, where the @einstein entry has a
"keyword" field of "primary."

The use case is a user wanting a bibliography with two sections, which
is a common case for this feature.

Note that I am unsure of the exact invocation to achieve this with
biblatex (as in, it's probably wrong), but I don't think that matters
to illustrate the point.

>>>>>
#+language: en
#+bibliography: test.bib
#+cite_export: csl

1. simple: [cite:@latexcompanion]
2. primary source: [cite:@einstein]
3. affixes: [cite/text:see @latexcompanion chapter 2 p.23]
4. quote, punctuation: “my quote” [cite/text/caps:@latexcompanion].

* Bibliography
** Primary Sources
#+print_bibliography: :keyword primary :title "Primary Sources"
** Secondary Sources
#+print_bibliography: :title "Secondary Source"
<<<<<

Here's the output from oc-csl:

>>>>>
1. simple: (Goossens, Mittelbach, and Samarin 1993)
2. primary source: (Einstein 1905)
3. affixes: (see Goossens, Mittelbach, and Samarin 1993, chaps. 2 p.23)
4. quote, punctuation: “my quote” (Goossens, Mittelbach, and Samarin
   1993).


1 Bibliography
══

1.1 Primary Sources
───

  Einstein, Albert. 1905. “Zur Elektrodynamik Bewegter Körper. (German)
  [on the Electrodynamics of Moving Bodies].” /Annalen Der Physik/ 322
  (10):891–921.

  Goossens, Michel, Frank Mittelbach, and Alexander Samarin. 1993. /The
  LaTeX Companion/. Reading, Massachusetts: Addison-Wesley.


1.2 Secondary Sources
─

  Einstein, Albert. 1905. “Zur Elektrodynamik Bewegter Körper. (German)
  [on the Electrodynamics of Moving Bodies].” /Annalen Der Physik/ 322
  (10):891–921.

  Goossens, Michel, Frank Mittelbach, and Alexander Samarin. 1993. /The
  LaTeX Companion/. Reading, Massachusetts: Addison-Wesley.
<<<<<

So two duplicate lists.

Does that clarify?

The other common case I am familiar with is a bibliography per section
of a document.

It may not be practical to do anything other than current behavior,
but I was hoping some biblatex experts might have some thoughts.

And, of course, wanting to flag this for András to think about, since
ideally citeproc-el would support this.

Bruce