Re: (Not so) Short note about citations in Org

[Denis Maier <denismaier@mailbox.org>]

Oh, and what do you think regarding the multiple bibliographies question?

Denis

Am 26.04.2021 um 22:02 schrieb Nicolas Goaziou:
> Hello,
> 
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
> 
>> On this, on the other (big) wip-cite thread, Nicolas said the following:
>>
>> "A drawback with allowing emphasis there is that prefix and suffix become
>> parsed data and not plain string anymore. As a consequence, searching
>> through them, e.g., when looking for locator names, requires an
>> additional level of indirection, since you need to first transform
>> parsed data back into plain text."
>>
>> Nicolas: I get that you need more code to do this, but are there other
>> practical consequences of allowing more than plain-text?
> 
> The code I need to write does not count, really. It is 10 locs at most,
> without the tests.
> 
> My concern is the additional burden for processor developers. They will
> need to shift from one representation to the other, this is not
> convenient. Also some tasks then become an order of magnitude harder.
> 
> For example, let's consider the suffix: " p.32 and following" If it is
> plain text, I can recognize p.32 as a locator, and replace it with "page
> 32" using something like `replace-regexp-in-string'.
> 
> Now, if it is a somewhat opaque parsed string, I need to first expand
> it, for example with `org-element-interpret-data', modify the output as
> above, and then parse it again to get a new parsed string.
> 
> I can no longer (concat "(" prefix author "," year suffix ")") either,
> because prefix and suffix are not strings anymore. I need to
> 
>    (format "(%s%s, %s%s)"
>            (org-export-data prefix info)
>            (org-export-data author info)
>            year    ;I assume year cannot contain problematic characters
>            (org-export-data suffix info))
> 
> So, nothing impossible, but still slightly inconvenient.
> 
> Regards,
>