From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Citations, continued Date: Sun, 08 Feb 2015 17:11:34 +0100 Message-ID: <874mqws7rd.fsf@nicolasgoaziou.fr> References: <87vbjmn6wy.fsf@berkeley.edu> <87sieokx8e.fsf@berkeley.edu> <54d04780.cb58460a.5243.2603@mx.google.com> <87h9v3li8t.fsf@berkeley.edu> <54d078ff.b044440a.06ec.3cf6@mx.google.com> <87d25rkmag.fsf@berkeley.edu> <54d1bc7b.c57d440a.3c5d.2dca@mx.google.com> <87vbjh284z.fsf@nicolasgoaziou.fr> <87mw4tk4m7.fsf@berkeley.edu> <87oap7z664.fsf@nicolasgoaziou.fr> <87fvaibr3k.fsf@berkeley.edu> <87y4o9s5qc.fsf@nicolasgoaziou.fr> <87d25kpxap.fsf@pank.eu> <87k2zsso3w.fsf@nicolasgoaziou.fr> <87vbjcoewx.fsf@gmx.us> <87bnl4shqg.fsf@nicolasgoaziou.fr> <87h9uwwmgt.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKURM-0007xV-Kg for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 11:10:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKURJ-0005ew-7r for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 11:10:32 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:42399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKURI-0005eg-W6 for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 11:10:29 -0500 In-Reply-To: <87h9uwwmgt.fsf@gmx.us> (rasmus@gmx.us's message of "Sun, 08 Feb 2015 14:40:18 +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: Rasmus Cc: emacs-orgmode@gnu.org Rasmus writes: > In that case I prefer the explicit extraction of keys below, since I don't > understand why [-@k1] is invalid ("in her seminal -@k @k:journal article, > @k:author demonstrated that =E2=8B=AF"). Probably I don't understand pan= doc well > enough... In the initial suggestion @k:journal or @k:author was not possible. In pandoc, AFAIU, in-text means author is outside parenthesis. Nothing fancier. So [-@k1] would mean: "author" is outside parenthesis, but should not be displayed anyway. > It seemed to be the main characteristics of this "locator" that you all > were talking about... See, you are talking again about locator... > Of course not. That would be idiotic. But I would rather try to imitate > the state-of-the-art, which in my book is biblatex, not pandocs. I'm sure biblatex is powerful, but it's clearly not the state-of-the-art in readability, and I guess only `latex' would support its features. Really my concerns are about parsing speed and readability within the document. Heavy biblatex users will eventually have to fall-back to LaTeX-specific syntax at some point anyway. >> If extracting data from an entry is required, then I suggest to extend >> key syntax, e.g.: >> >> @K1:year > > Extracting from a plist-like thingy is easy. I don't understand. > What is hard is proper formatting of things like author, e.g. how many > author to include, adding "and" etc. It would be amazing to let TOOL > handle this! Unfortunately, good TOOL is scare outside of the > latex-world (maybe Zotero? I don't know how commandline friend it is). In any case, this is not the job of Org. At the moment, the goal is to find a readable syntax that allows to present citation information to external processors (biblatex, zotero...). >> I understand, but would it be needed to have both A (Y, C) and A (B, Y) >> in the same document? > > Sure, why not? I don't know. Pandoc doesn't allow it, and, apparently, nobody complained enough to add this feature to Pandoc citations. So, either it is not that useful, or Pandoc citations are hardly used. >> [pre @k1 post] is slower to parse.=20 > > Is that because you'd have to check all occurrences or [=E2=8B=AF]? Correct.=20 Also, it is ambiguous with link syntax (e.g., if pre begin with "[") and footnotes syntax. >> I haven't much against @k1, but it introduces more false positives than >> [@k1]. > > It could check if k1 is a known key and interpret "@k1" accordingly. No it couldn't. Org doesn't know about keys. Or, more precisely, syntax mustn't depend on known keys. I don't want to make the same mistake as export blocks (i.e., #+begin_html doesn't mean the same thing if "ox-html" is loaded or not). @k1, for some subset of chars within k1, would always be parsed a key, valid or not. Again, this is not particularly wrong, but it may introduce false positive from time to time. However, in these cases, we could use entities to escape "@" from the key. Regards,