[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be universall
From: |
Pedro Andres Aranda Gutierrez |
Subject: |
Re: Re: [BUG] #+cite_export: ... bibstyle citestyle cannot be universally used as global defaults (was: Patch for \usepackage[ ... natbib = true ...]{...biblatex} with org-cite) |
Date: |
Thu, 23 Feb 2023 12:43:33 +0100 |
Soory for the re-post... Just setting up a new email client
On Sun, 5 Feb 2023 00:14:59 +0100 (CET) Edgar wrote:
> Dear Ihor,
> On Feb 4, 2023 at 12:31 PM, Ihor Radchenko <yantar92@posteo.net> wrote:Edgar
> Lux <edgarlux@mailfence.com> writes:
>> For example, ... the proposed idea is
>> a bit awkward:
>>
>> ...
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style[...]
>> citation-style[...]
>>
>> I assumed that there is one "major" bibliography-style/citation-style.
>> However, it is not really the case in practice. The styles are combined.
> First of all, I quickly glanced at the other citation processors, and they
> seem to have been implemented with a different design in Org. This *may* have
> to do with biblatex being more advanced (disclaimer: I'm not saying that it
> actually is, it's a possibility only).
> If the idea is that all processors are going to get the same syntax, I think
> that the implementation may not suit one of them. At that point, it may be
> that the filters will have to be adapted to specific processors in contrived
> ways. This of course will be much dependent on the choice of processors
> chosen to be supported by Org. Some other groups may decide to implement, for
> example, the JabRef #+cite_export (this does not imply that JabRef is a
> citation processor, it's just a colourful example).
>> For example, adding links to bibliography to citations is applied
>> regardless of the particular citation command being used.
>>
>> So, I am not leaning closer to only allowing options being passed to
>> "processor", but not to styles. This will at least come closer to
>> certain settings being citation package global config applied to
>> everything. If we have options applied to specific citation commands,
>> they will rather fit into citation-style/sub-style.
>>
>> #+cite_export: processor[opt1=val1,opt2=val2,...] bibliography-style
>> citation-style
> If it were me, I would consider just having the options as =#+cite_export:
> processor :options "anything"=. If the bibliography-style is important for
> the user and processor, may be default values can be provided; and let the
> user read some documentation option which are needed to run her particular
> processor (provided by them, not necessarily Org). Again, being completely
> honest, I don't think that you should put a dummy (like me) making these very
> relevant decisions.
Joining the discussion I seem to have missed before (because I was
using a less org-ish solution).
My scenario: BEAMER and LATEX are my main targets, both with BIBLATEX
and biber as backend. Works nicely, and I can include a bibliography
at the end of my presentations, which is nice for lectures.
I'm more interested in the 'processor' part, because the default
bibliography and citation style fit me. However, I think that
something like:
#+cite_export: processor bibliography-style citation-style :options
opt1=val1,opt2=val2,...
as a generalised form (for the shortened version with default styles):
#+cite_export: processor :options opt1=val1,opt2=val2,...
would be expressive enough.
Best, /PA
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet