From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: Citations, continued Date: Tue, 03 Feb 2015 11:35:23 +0100 Message-ID: <87iofjffkk.fsf@gmx.us> References: <87vbjmn6wy.fsf@berkeley.edu> <87sieokx8e.fsf@berkeley.edu> <87iofkdr6o.fsf@pank.eu> <87oapblpvc.fsf@berkeley.edu> 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]:35002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIape-000774-Oy for emacs-orgmode@gnu.org; Tue, 03 Feb 2015 05:35:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIapc-00057T-1J for emacs-orgmode@gnu.org; Tue, 03 Feb 2015 05:35:46 -0500 Received: from plane.gmane.org ([80.91.229.3]:57538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIapb-00056w-Lz for emacs-orgmode@gnu.org; Tue, 03 Feb 2015 05:35:43 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YIapT-0003cO-F9 for emacs-orgmode@gnu.org; Tue, 03 Feb 2015 11:35:35 +0100 Received: from tsn109-201-154-193.dyn.nltelcom.net ([109.201.154.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2015 11:35:35 +0100 Received: from rasmus by tsn109-201-154-193.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 03 Feb 2015 11:35:35 +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 Richard Lawrence writes: > Hi Rasmus and all, > > Thanks for your comments! > > Rasmus writes: >>> #+BEGIN_QUOTE >>> [See @Doe99, pp. 34--45; also @Doe00:year, section 6] >>> >>> [See their article in @Doe99:journal:year.] >>> #+END_QUOTE >> >> First, I think we should use @key for inline and (@key) for parenthesis >> expressions. This give us two short keys. [@Key ⋯] can be reserved for >> complicated references. > > That sounds fine to me. I think you may be using `inline' differently > than me, though: do you mean `author's name appears in the text (not in > parentheses)'? (I was using it to talk about where the citation > definition appears in the document, not where the author's name appears > relative to parentheses.) I applied my usecase which is \textcite and \parentcite. The point it that you have got two types of citations at hand: could be \textcite and \footcite if you care more for that. >> I don't like "@Doe99:journal:year". It's too unlike existing syntax. > > I agree it's a little clunky, but I think most of the time there would > just be one selector. I was thinking of this on analogy with heading > properties and tags...is there a better existing syntax to refer to a > property value? Perhaps it's similar to properties and tags. I have key values in mind which are either key:value or :key value as in OPTIONS lines and MY_KEYWORD lines... Perhaps it is not the correct reference. >> Rather, I'd just introduce types as hinted previously, [@Doe99 :type >> my-journal-year-type]. Org can provide as many predefined :type as we >> care for, and let the user define the rest as necessary. > > I don't like this, because it seems like a lot more work for me as a > user to achieve something that should be simple, and it trades > specifying /what/ data I want for describing it more indirectly. > > Suppose I'm writing a document, and I know I just want to reference the > journal and year of a particular publication, in that order. Being a > studious keeper of my org-bibtex database, I already know that these > fields are called "journal" and "year". But if, in addition to > reference database field names, I have to remember names for /types/ of > /combinations/ of field names, that's too much. Reftex will do this for you. > I'll end up taking endless trips to the manual to figure out which type > I need in this case. Do I need :type journal-before-year? :type > journal-and-year? etc. This feels a bit too much like having to > remember (or look up) all the different LaTeX citation commands. Might be true. I don't expect that problem much. > What about just separating the field names off, as keys? Like: > > [See Doe's review @Doe99 :journal :year] That looks much better ("Org-ish"), though it implies [See Doe's review @Doe99 :journal nil :year nil] Which is kind of the opposite of the desired... Or perhaps I'm just misreading it. >>> When specific fields are requested, ONLY data from those fields should >>> appear in the exported document. Backends would choose how to export >>> these citations based on the selected fields. >> >> What happens when a field is undefined? > > I guess I would suggest the same thing as happens in LaTeX: you get a > nice, bold "??" in the output where the missing data should be. Or better, throw an error. >> I think R-markdown uses something like [-@Smith79]. Again, I don't like >> the [@key:nocite]. > > Doesn't [-@Smith79] mean something different, namely, "cite @Smith79 > without the author name"? It produces output like: "(1979)". Thanks for the clarification. >>> #+BEGIN_QUOTE >>> * Citations >>> >>> #+ATTR_LATEX: :command citet >>> #+ATTR_HTML: :class my-citation >>> [cite:1] See @Doe99, pp. 34--45; @Foobar2000, ch.1. >>> #+END_QUOTE >> >> Why not. Since footnote-definition is a greater element it /does/ take >> affiliated keywords, but I have never seen this used. > > Right, that's the point here...(were you disagreeing?) No. >> For inline maybe something like this: >> [@Key :type_html my-citation :type_latex citet] > > Actually, this is a lot like the syntax I was thinking about for the > inline case, but in the end I thought it was too complicated and new to > be worth it, when the #+ATTR_BACKEND syntax will already work for the > out-of-line case. I'm not opposed to something like this in principle, > but I really think we should try to keep the inline case very simple and > obvious to use, even if that means restricting its expressiveness a bit. The thing is it makes it very readable and obvious. You can fix display issues separately if you want. >> From experience, the biblatex model of separating the loading of files, >> styles and printing into different commands is a great advantage. > > OK. I'd even be happy with > > #+BIBLIOGRAPHY: > #+BIBLIGRAPHY_STYLE: > #+PRINT_BIBLIOGRAPHY: > > where the first could be specified as many times as desired, to indicate > external reference databases. Yeah, I had those in an earlier draft. My only issue is that #+PRINT_BIBLIOGRAPHY: is awkward if nothing comes after the ':'. >>> The point of specifying the style and locale as part of >>> the #+BIBLIOGRAPHY definition is for compatibility with both LaTeX and >>> Citation Style Language bibliography and citation formatting. >> >> Local is defined by #+LANGUAGE. AFAIK, Org doesn't support many >> languages. E.g. here's the definition of LANGUAGE in ox.el: >> >> (:language "LANGUAGE" nil org-export-default-language t) > > Ah, OK, I didn't know about #+LANGUAGE. Is there any reason why the > locale of the bibliography might be different than the locale of the > document? (I'm monolingual, I'm afraid, so I doubt I could think of one > if there were...) AFAIK, #+LANGUAGE is a single element, e.g. 'en' or 'de'. With ox-latex you can load several languages via babel and org-latex-packages-alist. Loading locals via other mechanism seems like a bug. —Rasmus -- With monopolies the cake is a lie!