Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > I think there are really two paths here: either we only support the > common denominator between all processors, like, e.g., Pandoc, or we > handle every possible command, knowing that most of them will not be > portable anyways.
Yes, I think that is the core issue: which way to do we want to go here? My opinion has always been that it makes more sense to just support the common denominator at the level of Org citation syntax, for two reasons: (1) it makes implementing a good solution that will work for a lot of cases much more feasible, and (2) anyone who really needs more than the common denominator -- that is to say, anyone who needs BibLaTeX -- can already write arbitrary LaTeX snippets directly in an Org document. Thus the latter group doesn't really lose anything if the syntax only supports the common denominator, while everyone else has a lot to gain from an implementation of citation syntax that can be exported on other backends. On the other hand, this opinion is narrowly focused on the issue of how citation syntax can be rendered into citations when exporting a document. When I think about the other uses for the syntax that e.g. John Kitchin has talked about in this thread, and that something like a future org-ref could support, then I see that people who need to export citations as BibLaTeX *would* still be missing out if they couldn't use the citation syntax. So, I think it is good if the syntax can support advanced BibLaTeX users too, and it looks to me like the "cite/xxx" syntax can do that. I have no objections to the syntax you've proposed, Nicolas. I *do* think it's worth marking a clear distinction between citation syntax that can vs. cannot be expected to export correctly on non-LaTeX backends. It looks to me at the moment like that distinction will be expressed as the difference between "cite" and "cite/xxx". For me, that's a reason to make "cite/text" a special case and give it its own syntax, since this is such an important and widespread use case, and CSL supports it. But I don't feel that strongly about this. For me, it would be fine if it's mentioned as a special case in the manual. -- Best, Richard