From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: Citation syntax: a revised proposal Date: Wed, 18 Feb 2015 23:35:46 +0100 Message-ID: <87egpmu9tp.fsf@gmx.us> References: <87k2zjnc0e.fsf@berkeley.edu> <87bnkvm8la.fsf@berkeley.edu> <87zj8co3se.fsf@berkeley.edu> <87ioezooi2.fsf@berkeley.edu> <87mw4bpaiu.fsf@nicolasgoaziou.fr> <8761aznpiq.fsf@berkeley.edu> <87twyjnh0r.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YODDo-0002Bv-PU for emacs-orgmode@gnu.org; Wed, 18 Feb 2015 17:35:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YODDl-0005WG-Dt for emacs-orgmode@gnu.org; Wed, 18 Feb 2015 17:35:56 -0500 Received: from plane.gmane.org ([80.91.229.3]:37258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YODDl-0005Vw-47 for emacs-orgmode@gnu.org; Wed, 18 Feb 2015 17:35:53 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YODDj-0008Bp-Qr for emacs-orgmode@gnu.org; Wed, 18 Feb 2015 23:35:51 +0100 Received: from tsn109-201-152-15.dyn.nltelcom.net ([109.201.152.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Feb 2015 23:35:51 +0100 Received: from rasmus by tsn109-201-152-15.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Feb 2015 23:35:51 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi, Nicolas Goaziou writes: > Richard Lawrence 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ú