emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Citation syntax: a revised proposal


From: Rasmus
Subject: Re: [O] Citation syntax: a revised proposal
Date: Wed, 18 Feb 2015 23:35:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Hi,

Nicolas Goaziou <address@hidden> writes:

> Richard Lawrence <address@hidden> 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ú




reply via email to

[Prev in Thread] Current Thread [Next in Thread]