Nicolas Goaziou writes:
> 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))
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
Dear All,
On Sat, 29 May 2021 at 18:22, Nicolas Goaziou wrote:
> 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
Hello,
"Bruce D'Arcus" writes:
> 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
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
"Bruce D'Arcus" writes:
> 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"
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
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:
>
"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
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?
>
>
On Sat, May 29, 2021 at 3:51 AM Stefan Nobis wrote:
>
> Nicolas Goaziou writes:
>
> > By default, no export processor is selected. All citations are
> > removed from output, and print_bibliography keywords, ignored.
>
> As I'm coming from LaTeX and have been bitten more than once by
> missing
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
Nicolas Goaziou writes:
> By default, no export processor is selected. All citations are
> removed from output, and print_bibliography keywords, ignored.
As I'm coming from LaTeX and have been bitten more than once by
missing citations in the output (which is solved far better today by
On Fri, May 28, 2021 at 9:52 AM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Pandoc has an option to surround more complex locators, that might
> > confuse the parser, in braces.
> >
> > More:
> >
> > https://pandoc.org/MANUAL.html#extension-citations
> >
> > Is that
Dear All,
I'm trying to catch up with the new developments, it isn't easy :-).
I think it would be really helpful to be able to map different
backends to different processors, because latex based solutions like
natbib can handle only latex-based backends, so anybody who wanted to
export both to
"Bruce D'Arcus" writes:
> On Fri, May 28, 2021 at 1:54 PM Timothy wrote:
>>
>>
>> Nicolas Goaziou writes:
>>
>> > I wouldn't hold my breath.
>> >
>> > First, IIUC, there's no reason to force biblatex over natbib OOTB as
>> > both are widely in use. But, more importantly, "oc-csl" require the
On Fri, May 28, 2021 at 1:54 PM Timothy wrote:
>
>
> Nicolas Goaziou writes:
>
> > I wouldn't hold my breath.
> >
> > First, IIUC, there's no reason to force biblatex over natbib OOTB as
> > both are widely in use. But, more importantly, "oc-csl" require the
> > external Citeproc library, so it
Nicolas Goaziou writes:
> I wouldn't hold my breath.
>
> First, IIUC, there's no reason to force biblatex over natbib OOTB as
> both are widely in use. But, more importantly, "oc-csl" require the
> external Citeproc library, so it cannot be loaded by default. As
> a consequence, no default
Timothy writes:
> Nicolas Goaziou writes:
>> You can, for example, select the appropriate citation processor
>> according to `org-export-current-backend' in an export hook.
>
> I see, this sounds like not too much trouble, but I think ideally this
> would be OOTB behaviour.
I wouldn't hold my
Nicolas Goaziou writes:
>> Forgive me if I'm jumping in without a good understanding of the
>> context, but does this mean that I can't easily have biblatex be used
>> when exporting to .tex and citeproc used when exporting to HTML?
>
> It depends on what you mean by "easily".
Well, what I'm
Hello,
Timothy writes:
> Nicolas Goaziou writes:
>
>>> Also, is it possible for me to set things up so that export to latex
>>> runs through the oc-biblatex processor, but otherwise it uses oc-csl,
>>> where I have (obviously) different styles for each?
>>
>> It is not possible to set export
Nicolas Goaziou writes:
>> Also, is it possible for me to set things up so that export to latex
>> runs through the oc-biblatex processor, but otherwise it uses oc-csl,
>> where I have (obviously) different styles for each?
>
> It is not possible to set export processor per export back-end,
On Fri, May 28, 2021 at 11:54 AM Nicolas Goaziou wrote:
> > Related, could we also have a `org-cite-csl-styles-dir' defcustom, to
> > avoid having to specify the full path?
>
> Good idea. Also implemented.
Thank you!
> > And/or alternately just `org-cite-csl-dir' for both locales and
> >
Hello,
"Bruce D'Arcus" writes:
> On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou
> wrote:
>
>> The processor uses the "en-US" CSL locale file shipped with Org for rendering
>> localized dates and terms in the references, independently of the language
>> settings of the Org document.
Hello,
"Bruce D'Arcus" writes:
> Pandoc has an option to surround more complex locators, that might
> confuse the parser, in braces.
>
> More:
>
> https://pandoc.org/MANUAL.html#extension-citations
>
> Is that feasible here too?
I'd like to avoid this if possible. We'll see what we can do when
On Thu, May 27, 2021 at 12:13 PM Bruce D'Arcus wrote:
>
> On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus wrote:
>
> > One other thing I tested just now not yet accounted for: a locator
> > whose values is a list; for example, that renders as (Doe 2019, pp.
> > 23, 25).
> >
> > Is there an easy
I'm trying to run this on a fairly recent emacs-master w/ native-comp
enable, using ~emacs -Q ~/test-cites.org~, where test-cites.org is this:
#+cite_export: csl
"/home/matt/Zotero/styles/chicago-manual-of-style-16th-edition-inline-notes-for-syllabi.csl"
#+bibliography:
On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus wrote:
> One other thing I tested just now not yet accounted for: a locator
> whose values is a list; for example, that renders as (Doe 2019, pp.
> 23, 25).
>
> Is there an easy way to handle that?
Nevermind; this works as expected.
On Thu, May 27, 2021 at 10:34 AM Bruce D'Arcus wrote:
>
> On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus wrote:
>
> > I was expecting (not to say I should have necessarily) in this case:
> >
> > [cite:@doe p23]
> >
> > ... that either "p23" is recognized as a locator, or as a suffix
> > string
On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus wrote:
> I was expecting (not to say I should have necessarily) in this case:
>
> [cite:@doe p23]
>
> ... that either "p23" is recognized as a locator, or as a suffix
> string for the citation reference.
To be clear, Nicolas, your change to the
On Thu, May 27, 2021 at 9:12 AM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > On Thu, May 27, 2021 at 4:01 AM Denis Maier wrote:
>
> >> I think a plain "p" in front of a number is not recognized as a locator
> >> prefix.
> >> Nicolas's post mentions "page", "p.", "pp." as
Hello,
"Bruce D'Arcus" writes:
> On Thu, May 27, 2021 at 4:01 AM Denis Maier wrote:
>> I think a plain "p" in front of a number is not recognized as a locator
>> prefix.
>> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
>> page. So in your case this here seems to
Hello,
Denis Maier writes:
> I think a plain "p" in front of a number is not recognized as
> a locator prefix.
> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> page. So in your case this here seems to apply: "The part of the
> suffix before the locator is appended to
On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou wrote:
> The processor uses the "en-US" CSL locale file shipped with Org for rendering
> localized dates and terms in the references, independently of the language
> settings of the Org document. Additional CSL locales can be made available
> by
On Thu, May 27, 2021 at 4:01 AM Denis Maier wrote:
>
> Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:
> > On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus wrote:
> >
> >> BTW, I did get it all setup, and do seem to have run into a bug.
> >>
> >> Input:
> >>
> >> [cite/noauthor:@latexcompanion p23]
>
Hello,
Denis Maier writes:
> I've just tried to test this, but I can't get it to work.
>
> I've done
> git pull
> make
>
> And I'm getting:
> In toplevel form:
> oc-csl.el:93:1:Error: Cannot open load file: No such file or
> directory, citeproc
>
> Do you have an idea what's going wrong here?
Hi,
Am 26.05.2021 um 22:33 schrieb Nicolas Goaziou:
thanks for this!
I've just tried to test this, but I can't get it to work.
I've done
git pull
make
And I'm getting:
In toplevel form:
oc-csl.el:93:1:Error: Cannot open load file: No such file or directory,
citeproc
Do you have an idea
Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:
On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus wrote:
BTW, I did get it all setup, and do seem to have run into a bug.
Input:
[cite/noauthor:@latexcompanion p23]
Output (not position of the locator label):
(p 1993, 23)
Hmm ... experimenting
On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus wrote:
> BTW, I did get it all setup, and do seem to have run into a bug.
>
> Input:
>
> [cite/noauthor:@latexcompanion p23]
>
> Output (not position of the locator label):
>
> (p 1993, 23)
Hmm ... experimenting some more, these work correctly.
On Wed, May 26, 2021 at 6:07 PM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > What if a developer has the idea to hook up one of the new, very fast,
> > csl libraries: either the haskell version associated with pandoc, or
> > the rust-based version associated with Zotero?
>
Hello,
"Bruce D'Arcus" writes:
> What if a developer has the idea to hook up one of the new, very fast,
> csl libraries: either the haskell version associated with pandoc, or
> the rust-based version associated with Zotero?
>
> Possible reasons they might want to do that: performance and/or
>
Hi Nicolas,
I'll take a close look at this and test it over the coming days, but
in the meantime, on two more general points:
On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou wrote:
First, names:
> I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
> is shorter, and
42 matches
Mail list logo
