emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>,
	Org Mode List <emacs-orgmode@gnu.org>
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	[thread overview]
Message-ID: <CAO48Bk8ybq9Qkzyj-PyCNKFEWNLoWVuFpyNJc9GxBO3eL5UPSA@mail.gmail.com> (raw)

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

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

                 reply	other threads:[~2023-02-23 11:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAO48Bk8ybq9Qkzyj-PyCNKFEWNLoWVuFpyNJc9GxBO3eL5UPSA@mail.gmail.com \
    --to=paaguti@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).