Hi,
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Richard Lawrence <richard.lawre...@berkeley.edu> writes:
>> We have already seen a couple of examples in this thread of properties
>> that one might want to specify in a backend-agnostic way:
>> - special-case capitalization
>> - user-defined type/command/label/etc.
>>
>> Other things one might want to do include:
>> - indicating when a citation should be placed in a footnote
>> - extracting arbitrary bibliographic field(s)
>
> I disagree. These properties should be associated to the subtype.
> Having two places to set them is asking for trouble.
>
> IMO, there is little incentive to define a set of options for a single
> use. Creating a dedicated subtype /once/ makes more sense.
>
> Also the syntax stays clean.
+1. A subtype is ∞ customizable. With a highlevel API, e.g. based on
org-bibtex plist is enough for any relevant task.
>> - providing an overlay string for displaying complicated/ugly
>> citations
>
> I don't think Org should provide this. Overlays are slow. Also, there is
> no good default for displaying citations. However, an external library
> could do that.
I think overlays would be nice, e.g. for multiple authors, but [cite: pre
@key post] it's almost effortless to read, so I don't care much.
Someone mentioned that e.g. Zotero has poor keys by default. Of course
one way to get around this is inserting a zotero entry as a org-bibtex
entry and give it nice key. Problem solved.
>> And I think there is no reason, at the moment, to expect that these are
>> the only possible uses for arbitrary backend-agnostic properties that a
>> user can interpret, either via export filters or via in-buffer
>> customizations.
>
> Export filters are orthogonal to the problem at hand. They are applied
> after handlers. We are discussing about handlers here (e.g., there are
> custom link types and export filters for links).
+1. Handling subtypes in a filter is a bad idea. It's already hard doing
stuff without extracting the element from the text-properties.
Customization should be done over a list of plist of entries imo, e.g.
((:common-pre "pre" :common-post "post" :type "cite" :subtype "subtype")
(:type "article" :title "t" :author "a" :pre "pre" :post "post")
(:type "article" :title "t" :author "a" :pre "pre" :post "post"))
Utility functions like citeauthor should be available so that you can
generate e.g. genetive cite as
(cite-mapconcat
(lambda (cite) (concat (citeauthor cite) "'s (" (citeyeat cite) ")" ))
citations)
> I think we should postpone the idea of attributes for object, as it gets
> in the way of the discussion. IMO,
>
> [cite/subtype: ...]
>
> is all we need, syntax-wise.
+1
Though [cite:subtype:whatever] has a higher RK metric. . .
—Rasmus
--
Me gusta la noche, me gustas tú
