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 <yanta...@posteo.net> wrote:Edgar > Lux <edgar...@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
