Re: [O] Citations, continued

On Wed, Feb 11, 2015 at 11:51 AM, Richard Lawrence < richard.lawre...@berkeley.edu> wrote: > Stefan Nobis writes: > > > Richard Lawrence writes: > > > > But anyway: Some tool is needed to generate the bibliography with all > > its data - this tool has to handle all these details and therefore it

Re: [O] Citations, continued

Stefan Nobis writes: > Richard Lawrence writes: > >> I know these commands are convenient, and that not having them would >> introduce this class of errors, but the question is whether they are >> so important that it's worth providing an equivalent for them in >> non-LaTeX backends. > > Hmmm...

Re: [O] Citations, continued

Aaron Ecay writes: > The uppercase variants are important for correctness with names like > “von Neumann”. When we write a sentence which begins “Von Neumann > (19xx) claimed that...” the “von” must be capitalized, though it > should be lowercase in non-sentence-initial position. Of course, we

Re: [O] Citations, continued

Hi Rasmus, 2015ko otsailak 10an, Rasmus-ek idatzi zuen: [...] > Keys I don't care about, since they are quite biblatex specific: > smartcite, autocide, parentcite*, uppercase variants. *volcites(s) (any > objections?) Smartcite is like footcite in regular text and parencite in footnotes.

Re: [O] Citations, continued

Richard Lawrence writes: > I know these commands are convenient, and that not having them would > introduce this class of errors, but the question is whether they are > so important that it's worth providing an equivalent for them in > non-LaTeX backends. Hmmm... I don't see this as a big proble

Re: [O] Citations, continued

Richard Lawrence writes: > Hi Tom and all, > > t...@tsdye.com (Thomas S. Dye) writes: > >> Richard Lawrence writes: >> >>> Conceptually, something like `@key:year' isn't a citation, but merely >>> indirection, because it doesn't actually provide the reader of the >>> rendered document enough inf

Re: [O] Citations, continued

Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: > Richard Lawrence writes: > >> Conceptually, something like `@key:year' isn't a citation, but merely >> indirection, because it doesn't actually provide the reader of the >> rendered document enough information to look up the reference. I

Re: [O] Citations, continued

Richard Lawrence writes: > Conceptually, something like `@key:year' isn't a citation, but merely > indirection, because it doesn't actually provide the reader of the > rendered document enough information to look up the reference. I think > we can cut down on the number of `citation' types that

Re: [O] Citations, continued

Hi Stefan, Stefan Nobis writes: > Richard Lawrence writes: > >> Rasmus writes: > >>> Citation types for extracting parts: >>> citeauthor, citetitle, citeyear, citedate, citeurl, > >> As I've said in other posts, I think maybe we should not think of >> these as `citation' commands and thus

Re: [O] Citations, continued

Richard Lawrence writes: > Rasmus writes: >> Citation types for extracting parts: >> citeauthor, citetitle, citeyear, citedate, citeurl, > As I've said in other posts, I think maybe we should not think of > these as `citation' commands and thus don't need to represent them > in citation s

Re: [O] Citations, continued

Rasmus writes: > So, the (opinionated) useful defaults in biblatex are: > cite(s), parencite(s), footcite(s), texcite(s), fullcite, > footfullcite, nocite So that is to say we need to be able to express the following distinctions (did I miss anything?): - in-text vs. parenthetical (par

Re: [O] Citations, continued

> > Ok, sorry I didn't check the natbib manual carefully. AFAIK you get > numbers with biblatex without any author-year options so: > > \cite{k}, \parencite{k} → [Num] > \textcite{k} → A [Num] > > Is this similar to \numcite? From natbib is seems to be intended for > people who use author-year,

Re: [O] Citations, continued

Hi Nicolas and all, Nicolas Goaziou writes: > If year, or author, are needed, I suggested to append some optional > parameter to the key, e.g., > > [cite: pre @key:year post] I proposed exactly this earlier in the thread, but then I came to the conclusion that we shouldn't do it. Conceptuall

Re: [O] Citations, continued

John Kitchin writes: > Rasmus writes: > >> Nicolas Goaziou writes: >> >>> Another option is to mimic custom links, if that's what you're thinking >>> of, which means to store every user-defined keyword in a variable and >>> build a regexp out of it. I dislike it even more because the document is

Re: [O] Citations, continued

Nicolas Goaziou writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> Yes, I typically use what I call a multicite to get multiple citations >> with biblatex. It just inserts {key}. I precede two or more of these >> with a placeholder--π for parencites, † for textcites, or ƒ for >> footcites--a

Re: [O] Citations, continued

Rasmus writes: > Nicolas Goaziou writes: > >> Another option is to mimic custom links, if that's what you're thinking >> of, which means to store every user-defined keyword in a variable and >> build a regexp out of it. I dislike it even more because the document is >> not portable anymore, as i

Re: [O] Citations, continued

Hi, Nicolas Goaziou writes: > Rasmus writes: > >> So, the (opinionated) useful defaults in biblatex are: >> cite(s), parencite(s), footcite(s), texcite(s), fullcite, >> footfullcite, nocite > > Isn't footcite/footfullcite a choice made at the document's level > instead of per citation? I

Re: [O] Citations, continued

Nicolas Goaziou writes: >> So, the (opinionated) useful defaults in biblatex are: >> cite(s), parencite(s), footcite(s), texcite(s), fullcite, >> footfullcite, nocite > > Isn't footcite/footfullcite a choice made at the document's level > instead of per citation? If that's the case, it co

Re: [O] Citations, continued

Rasmus writes: > So, the (opinionated) useful defaults in biblatex are: > cite(s), parencite(s), footcite(s), texcite(s), fullcite, > footfullcite, nocite Isn't footcite/footfullcite a choice made at the document's level instead of per citation? If that's the case, it could go in a keywo

Re: [O] Citations, continued

Nicolas Goaziou writes: > I think > > [cite: common pre; pre1 @k1 post1; pre2 @k2 post2; common post] > > is regular and readable enough. So, there's no need to add special > support for multicite. Definitely. In latex you'd just use multicite whenever more than two keys within one cite-group

Re: [O] Citations, continued

Rasmus writes: > Nicolas Goaziou writes: > >> If you write something like >> >> [cite: pre1 @k1 post1; pre2 @k2 post2] >> >> wouldn't it possible to guess you want to use multicite? IOW, does using >> "multicite" really implies a change in the syntax? > > To fully support multicite you need ke

Re: [O] Citations, continued

Nicolas Goaziou writes: > If you write something like > > [cite: pre1 @k1 post1; pre2 @k2 post2] > > wouldn't it possible to guess you want to use multicite? IOW, does using > "multicite" really implies a change in the syntax? To fully support multicite you need keyless citations in the beginn

Re: [O] Citations, continued

Nicolas Goaziou writes: > Another option is to mimic custom links, if that's what you're thinking > of, which means to store every user-defined keyword in a variable and > build a regexp out of it. I dislike it even more because the document is > not portable anymore, as it requires you to share

Re: [O] Citations, continued

Rasmus writes: > Not necessarily. I could do: > >(defun rasmus/gentive-citation (citation-element backend) > (case backend ...) ...) > >(add-to-list 'org-cite-types 'rasmus/gentive-citation ) > > E.g. for genitive citations such as "Smith's (1984) model", which can be > mostly

Re: [O] Citations, continued

t...@tsdye.com (Thomas S. Dye) writes: > Yes, I typically use what I call a multicite to get multiple citations > with biblatex. It just inserts {key}. I precede two or more of these > with a placeholder--π for parencites, † for textcites, or ƒ for > footcites--and then use a filter to insert \p

Re: [O] Citations, continued

John Kitchin writes: > Why cannot there be a list of acceptable keywords eg > > [citenum: > [citeyear: > [citeauthor: > > which a backend would be responsible for handling, including a default > handler for unknown keywords? It has the same problem as [pre @key post] syntax: it is slower to pars

Re: [O] Citations, continued

John Kitchin writes: >> Can you (or Tom, or someone else) make the case that it is important >> enough to have multicites that non-LaTeX backends should support them >> out of the box? (I'm not doubting it, I just don't have any idea why >> since I don't use them myself.) > > My case is that if

Re: [O] Citations, continued

Richard Lawrence writes: > > My concern is just that we clearly distinguish the `main' or `proper' > citation syntax from the user-extensible part, as I said here: > > Rasmus has also expressed support for something like this, and I can see > that it is important for a user to be able to define

Re: [O] Citations, continued

Hi John and all, John Kitchin writes: > I think the critical point is that the syntax must be user > extendable. It should be possible to add these different types, even if > most people do not use them. Otherwise, links will continue to be used > anyway. I completely agree. Some form of user

Re: [O] Citations, continued

Nicolas Goaziou writes: > Rasmus writes: > >> PS: Here's a quick link "proof-of-concept" (not really) with biblatex >> only, and cite it textcitation. Documents with this type of syntax are >> indeed pleasant to the eye. >> >> [[cite: pre1 @bohringer14 post1; pre2 @davis14 post2]] > > As pointe

Re: [O] Citations, continued

Rasmus writes: > The question: > > In any given document, do you typically need more than two types of > citations, i.e. {citet, citep} OR {textcite, parentcite}? > > I do use other citation types, in particular a genitive version of > textcite, but not very often. That was why I initia

Re: [O] Citations, continued

Richard Lawrence writes: > Hi Tom and all, > > t...@tsdye.com (Thomas S. Dye) writes: > >> IIUC, Org mode citation syntax needs to capture four pieces of >> information for an *individual* citation: a =key= into one or more >> stores of bibliographic information; a =citation-command= that is >> u

Re: [O] Citations, continued

Richard Lawrence writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> IIUC, Org mode citation syntax needs to capture four pieces of >> information for an *individual* citation: a =key= into one or more >> stores of bibliographic information; a =citation-command= that is >> understood by the =ci

Re: [O] Citations, continued

Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: > IIUC, Org mode citation syntax needs to capture four pieces of > information for an *individual* citation: a =key= into one or more > stores of bibliographic information; a =citation-command= that is > understood by the =citation-style= spe

Re: [O] Citations, continued

Aloha Rasmus, Rasmus writes: > In any given document, do you typically need more than two types of > citations, i.e. {citet, citep} OR {textcite, parentcite}? Yes, I typically use what I call a multicite to get multiple citations with biblatex. It just inserts {key}. I precede two o

Re: [O] Citations, continued

Nicolas Goaziou writes: > Rasmus writes: > >> The question: >> >> In any given document, do you typically need more than two types of >> citations, i.e. {citet, citep} OR {textcite, parentcite}? >> >> I do use other citation types, in particular a genitive version of >> textcite, but

Re: [O] Citations, continued

Rasmus writes: > The question: > > In any given document, do you typically need more than two types of > citations, i.e. {citet, citep} OR {textcite, parentcite}? > > I do use other citation types, in particular a genitive version of > textcite, but not very often. That was why I init

Re: [O] Citations, continued

Aloha Tom, Were obviously have similar requirements. However, there's one point where I'm entirely on the same page as you. I want to figure out if that's 'cause I haven't thought carefully enough about it, or because I have simpler requirements. t...@tsdye.com (Thomas S. Dye) writes: > I don'

Re: [O] Citations, continued

Nicolas Goaziou writes: > 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. If [-@k1] has non-obvious

Re: [O] Citations, continued

Tom, thanks for this contribution. From my point of view, you have summarised the requirements very well. I agree with them completely, especially the need to expose and to hide the right information when perusing the org file. -- Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

Re: [O] Citations, continued

Aloha all, I'm having a hard time relating the various syntax proposals to a common, shared goal for Org mode users. This might just be me--I often struggle to understand conversations on the Org mode list. However, I'm also convinced that lack of clearly shared goals really gets in the way of p

Re: [O] Citations, continued

Richard Lawrence writes: > But doesn't the first case pose the same performance problems as the > Pandoc syntax, since it does away with the tag? Or are you thinking > it's easier to parse because the key occurs immediately after the > bracket, without a prefix...? Correct. It is easier to dism

Re: [O] Citations, continued

Nicolas Goaziou writes: > Rasmus writes: > >> PS: Here's a quick link "proof-of-concept" (not really) with biblatex >> only, and cite it textcitation. Documents with this type of syntax are >> indeed pleasant to the eye. >> >> [[cite: pre1 @bohringer14 post1; pre2 @davis14 post2]] > > As pointe

Re: [O] Citations, continued

Hi Nicolas and all, On Sun, Feb 8, 2015 at 1:58 AM, Nicolas Goaziou wrote: > > - in-text citation > > [KEY] or [KEY suffix] > > [@item1] or [@item1 p. 30] or [@item1 p. 30, with suffix] > > - out-text citation > > [cite: prefix? key suffix?; prefix2? key2 suffix2? ...] > >

Re: [O] Citations, continued

Hi John and all, On Sun, Feb 8, 2015 at 1:46 AM, John Kitchin wrote: > My only concern is that it remains possible to support this relatively > full set of citation options on export: > ... > which we are currently able to do. I never type any of those in, org-ref > does it automatically from a k

Re: [O] Citations, continued

Rasmus writes: > PS: Here's a quick link "proof-of-concept" (not really) with biblatex > only, and cite it textcitation. Documents with this type of syntax are > indeed pleasant to the eye. > > [[cite: pre1 @bohringer14 post1; pre2 @davis14 post2]] As pointed out already, the double square brac

Re: [O] Citations, continued

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 ⋯"). Probably I don't understand pandoc well > enough... In the initial suggestion @k:journal or

Re: [O] Citations, continued

Nicolas Goaziou writes: >> Another issue is that it's not transpose-words safe. E.g. this output >> seems bad: [-@k1 @k2 30] => Y1 A2 (Y2, 30). > > This citation is invalid. The point of [@k1] is that the author is > mandatory, since it is in-text, so [-@k1] doesn't make sense. In that case I

Re: [O] Citations, continued

Rasmus writes: 2. [cite:@item1: p. 30] says blah. ... 2. Doe (2005, 30) says blah. ^^^ According to Erik, this is just a possible output. It belongs to export configuration. 3. [cite:@item1: p. 30, with suffix] says blah. 4.

Re: [O] Citations, continued

Hi, Thanks for the quick reply. A very colorful (in Gnus at least) reply follows. >>> 1. [cite:@item1] says blah. >>> 2. [cite:@item1: p. 30] says blah. >> >> Why is "p." stripped here? > > I don't understand. Anyway, I now suggest This is what I'm talking about: >>> 2. [cite:@item1: p. 3

Re: [O] Citations, continued

Rasmus writes: > Nicolas Goaziou writes: > >> Using the example from Erik Hetzner in the same thread, what about: >> >> 1. [cite:@item1] says blah. >> 2. [cite:@item1: p. 30] says blah. > > Why is "p." stripped here? I don't understand. Anyway, I now suggest [@item1] and [@item1 p. 30]

Re: [O] Citations, continued

Richard Lawrence writes: > On Sat, Feb 7, 2015 at 2:43 PM, Nicolas Goaziou > wrote: > >> What about the following set? >> >> bold code entity italic latex-fragment line-break strike-through >> subscript superscript underline superscript > > That would work fine for me in prefixes and suffixes

Re: [O] Citations, continued

My only concern is that it remains possible to support this relatively full set of citation options on export: (defcustom org-ref-cite-types '("cite" "nocite" ;; the default latex cite commands ;; natbib cite commands, http://ctan.unixbrain.com/macros/latex/contrib/natbib/natnotes.pdf "

Re: [O] Citations, continued

Nicolas Goaziou writes: > Using the example from Erik Hetzner in the same thread, what about: > > 1. [cite:@item1] says blah. > 2. [cite:@item1: p. 30] says blah. Why is "p." stripped here? > 3. [cite:@item1: p. 30, with suffix] says blah. > 4. [cite:@item1: -@item2 p. 30; see also @ite

Re: [O] Citations, continued

Hi Nicolas, I just want to say thanks for continuing the conversation, by the way: I know this thread has gotten long, but I'm glad people are still paying attention, and Nicolas, your opinion counts for a lot. On Sat, Feb 7, 2015 at 2:43 PM, Nicolas Goaziou wrote: > What about the following se

Re: [O] Citations, continued

Richard Lawrence writes: >> Since full citations can only exist in a bracketed citation, there is no >> reason to create a third object type for the latter. It acts as a mere >> container only useful for lexer. > > I think this is not quite right: in my original terminology, `individual > citatio

Re: [O] Citations, continued

Hi, Nicolas Goaziou writes: > - full-citation (aka individual citation), with, in addition to the > properties above, :prefix and :suffix, both being parsed string. Full-citation is confusing. A full citation is (to me) what you have in the bibliography. > Since full citations can only

Re: [O] Citations, continued

Hi, I realize you list Pandoc features, but I will still point out some issues with this syntax. Richard Lawrence writes: > Specifically I think we need the following categories, all of which > would be objects: > - key > - prefix / pre-text > - suffix / post-text > - locator What is t

Re: [O] Citations, continued

Hi Nicolas and all, Nicolas Goaziou writes: > Richard Lawrence writes: > > Thanks for this reverse engineering. > >> Specifically I think we need the following categories, all of which >> would be objects: >> - key >> - prefix / pre-text >> - suffix / post-text >> - locator >> - indiv

Re: [O] Citations, continued

Richard Lawrence writes: Thanks for this reverse engineering. > Specifically I think we need the following categories, all of which > would be objects: > - key > - prefix / pre-text > - suffix / post-text > - locator > - individual citation > - bracketed citation > - unbracketed ci

Re: [O] Citations, continued

Erik Hetzner writes: > On Wed, 4 Feb 2015 at 07:59:46 PST, > Richard Lawrence wrote: >> The idea is, a citation like "As Doe says in @Doe99:title, ..." should >> render like "As Doe says in /The Title/, ...", not like "As Doe says in >> Doe (1999), ...", even if "@Doe99" citations in the docu

Re: [O] Citations, continued

On Wed, 4 Feb 2015 at 07:59:46 PST, Richard Lawrence wrote: > > Erik Hetzner writes: > > >> The ideal would be if citeproc would take care of proper formatting > >> of all such citation types, given just an ordered list of the fields > >> that should appear. I don't know if CSL supports this,

Re: [O] Citations, continued

On Wed, 4 Feb 2015 at 04:06:36 PST, Nicolas Goaziou wrote: > > Hello, > > Erik Hetzner writes: > > > I concentrated on getting the parser to recognize valid citations > > first. I have now finished this part (excepting any bugs, of course :) > > and will need to add code to generate a proper

Re: [O] Citations, continued

Hi Nicolas, Nicolas Goaziou writes: > Also, AFAIU, the syntax for valid citations is not defined explicitly so > far. For example, I don't think it was discussed if any subset of Org > objects (e.g., macros or bold text) is allowed in a citation. This is a good question that, as you say, deserv

Re: [O] Citations, continued

None of those features need to change, don't worry! Julian M. Burgos writes: > Thanks everyone for thinking about citations. I wish I knew enough lisp > to make a contribution to this work... for now I can only sit on the > side and clap. > > I am also a big fan of org-ref. Although my needs ar

Re: [O] Citations, continued

Erik Hetzner writes: >> The ideal would be if citeproc would take care of proper formatting >> of all such citation types, given just an ordered list of the fields >> that should appear. I don't know if CSL supports this, though; do >> you? > > I’m not entirely sure what you mean. The authors of

Re: [O] Citations, continued

Hello, Erik Hetzner writes: > I concentrated on getting the parser to recognize valid citations > first. I have now finished this part (excepting any bugs, of course :) > and will need to add code to generate a proper parse tree. Then it can > be integrated into org-element.el. The point of "or

Re: [O] Citations, continued

Thanks everyone for thinking about citations. I wish I knew enough lisp to make a contribution to this work... for now I can only sit on the side and clap. I am also a big fan of org-ref. Although my needs are not complex (basically citing from a BibLatex file and exporting to LaTex), I found th

Re: [O] Citations, continued

Hi Richard, On Tue, 3 Feb 2015 at 08:11:19 PST, Richard Lawrence wrote: > […] > Yes. I'll have to take a look at the Pandoc citeproc code and see how > easy it would be to add support for something like this. If there are > Org people that need citation types that select specific fields, I

Re: [O] Citations, continued

On Tuesday, 3 Feb 2015 at 08:27, Richard Lawrence wrote: [...] >> For me, any solution will likely do just fine as my use of citations is >> quite straightforward. I seldom, if ever, have pre or post text but I >> do use a couple of alternative citation types (author, year; year only). > > Just

Re: [O] Citations, continued

Hi Eric and all, Eric S Fraga writes: > On Tuesday, 3 Feb 2015 at 11:35, Rasmus wrote: > I'm enjoying following this thread. I look forward to the community > converging on some solution. Me too! > For me, any solution will likely do just fine as my use of citations is > quite straightforwa

Re: [O] Citations, continued

Hi Erik and all, Erik Hetzner writes: > On Mon, 2 Feb 2015 at 20:41:06 PST, > Richard Lawrence wrote: >> The only reason I proposed anything else was that it seemed like other >> people already know that they need more than the Pandoc syntax provides. >> I think the main realistic cases are t

Re: [O] Citations, continued

On Tuesday, 3 Feb 2015 at 11:35, Rasmus wrote: [...] I'm enjoying following this thread. I look forward to the community converging on some solution. For me, any solution will likely do just fine as my use of citations is quite straightforward. I seldom, if ever, have pre or post text but I d

Re: [O] Citations, continued

Vikas Rawal writes: > Org-ref is very functional and has so far been able to deal with much > of my needs. So, I just hope we are not trying to fix something that > is not broken. IMO for the same reason it is attractive to limit *bold* to imply bold. [At one point it was possible to alter the (

Re: [O] Citations, continued

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

Re: [O] Citations, continued

Hi Richard, On Mon, 2 Feb 2015 at 20:41:06 PST, Richard Lawrence wrote: > > Hi Erik and all, > > Actually, I totally agree. For my own use, I would be completely happy > with just using the Pandoc syntax for citations in Org, without any > modifications. Great! > The only reason I proposed

Re: [O] Citations, continued

Hi Erik and all, Erik Hetzner writes: > I am really, really glad to see people discussing citations in > org-mode. But I have some concerns about this proposal. > > Before extensions are proposed to the pandoc format, I think it is > important to understand how flexible the combination of pandoc

Re: [O] Citations, continued

On Mon, 2 Feb 2015 at 10:02:41 PST, Richard Lawrence wrote: > > Hi all, > > Here is the citation syntax proposal I have mentioned in a couple of > posts now. I have attached it as an Org document for better > readability, and also reproduced the text below. Let me know what you > think! Hi R

Re: [O] Citations, continued

Org-ref is very functional and has so far been able to deal with much of my needs. So, I just hope we are not trying to fix something that is not broken. The real need in the context of citations is to somehow extend the bibtex/biblatex integration to other export formats (odt/html, most impor

Re: [O] Citations, continued

Hi Rasmus and all, Thanks for your comments! Rasmus writes: >> ** Backend-agnostic formatting properties >> *** Selecting specific fields >> Selecting specific fields to display could be done by appending field >> names to cite keys after colons, much like Org tags: >> #+BEGIN_QUOTE >> [See @Do

Re: [O] Citations, continued

Thanks! I had been thinking about how to do that for a while, and seeing Samuel's idea crytallized it for me. Thanks Samuel, and Tom for remembering it from long ago. yes that should also be possible. once you open the rabbit hole of embedded lisp, many things are possible ;) even beyond citations

Re: [O] Citations, continued

Hi John, Wow. It's inspiring to see Samuel's idea in action. Presumably, something like this would also be possible? ;; follow function (lambda (path) (let* ((data (read (concat "(" path ")"))) (head (car data)) (plist (cadr data))) (funcall (plist-get plist :follow) he

Re: [O] Citations, continued

John Kitchin writes: > #+BEGIN_SRC emacs-lisp :results silent > (org-add-link-type > "slink" ...) > #+END_SRC Thanks John, this is great! I managed to chop down my citation setup to the following: [[cite:key :pre pre :post post :type type]] with reasonable support for other backends. I only

Re: [O] Citations, continued

Hi, Richard Lawrence writes: > Here is the citation syntax proposal I have mentioned in a couple of > posts now. Thanks. I think it's a good start, but I find it too far away from Org in some respects. Hence comments follow. > ** Backend-agnostic formatting properties > *** Selecting specifi

Re: [O] Citations, continued

> I'm glad you like Samuel's idea about extensible syntax for links. I > don't know if it is practical or not, but it was one of those ideas that > seemed right on when I first read it. I am glad you mentioned, it was an inspiration! Although this is sure to move away from a standard new syntax,

Re: [O] Citations, continued

You can color your own links like this: (highlight-regexp "cite:\\([a-zA-Z0-9]*[-_:]*\\)*" 'dired-warning) (highlight-regexp "citenum:\\([a-zA-Z0-9]*[-_:]*\\)*" 'dired-marked) The regexps are not as robust as what org uses, the plain link on my system looks like: "\\<\\(Autocite[*s]?\\|Cite\

Re: [O] Citations, continued

Hi John, John Kitchin writes: >> Now, I agree with you that Org mode links are not ideal for citations. >> Parsing the description is humbug and error-prone, and the descriptions >> look ungainly in the Org mode document. I never remember to click >> citation links in the "right" place! There

Re: [O] Citations, continued

Hi, Richard Lawrence writes: > Hi Rasmus and all, > > Rasmus writes: > >> Richard Lawrence writes: > >>> Within a citation, each reference to an individual work needs to be >>> capable of containing: >>> 1) a database key that references the cited work >>> 2) prefix / pre-text >>> 3) suf

Re: [O] Citations, continued

Hi all, Here is the citation syntax proposal I have mentioned in a couple of posts now. I have attached it as an Org document for better readability, and also reproduced the text below. Let me know what you think! Best, Richard #+TITLE: A Proposal for Org citation syntax #+AUTHOR: Richard Law

Re: [O] Citations, continued

Hi Rasmus and all, Rasmus writes: > Richard Lawrence writes: >> Within a citation, each reference to an individual work needs to be >> capable of containing: >> 1) a database key that references the cited work >> 2) prefix / pre-text >> 3) suffix / post-text >> 4) references to page/ch

Re: [O] Citations, continued

t...@tsdye.com (Thomas S. Dye) writes: > You and others are advocating a separate syntax for links and citations, > which might indeed be the way to go. I can see it being much nicer than > the current state of affairs with Org mode links. The downside is that > it will mean learning another set

Re: [O] Citations, continued

On Sat, 31 Jan 2015 at 10:26:05 PST, Richard Lawrence wrote: > > Hi all, > > […] > > As I mentioned in the earlier thread, I think the Pandoc syntax is a > good place to start, and I think it would be valuable to have the two > syntaxes be compatible. But even Pandoc's citation syntax might not

Re: [O] Citations, continued

I have very little of substance to say, but many thanks to Richard for raising the level of discourse to a much more sophisticated one than I was able to achieve in my initial post. I don't feel qualified to comment on whether links or a new citation syntax is appropriate. But I do think that Ric

Re: [O] Citations, continued

t...@tsdye.com (Thomas S. Dye) writes: > You and others are advocating a separate syntax for links and citations, > which might indeed be the way to go. I can see it being much nicer than > the current state of affairs with Org mode links. The downside is that > it will mean learning another set

Re: [O] Citations, continued

John Kitchin writes: > See cite:Doe1999 for an overview; a more extensive discussion is in > cite:Foobar2000 This is ok and supported by ox-bibtex.el. > if the pre/post text is really critical somehow, you can do this. > > [[cite:Doe1999][See::for an overview]]; a more extensive discussion is i

Re: [O] Citations, continued

Richard Lawrence writes: > Nicolas Goaziou writes: > >> Richard Lawrence writes: >> >>> ...so the first step for introducing citation syntax to Org should be >>> compiling a list of all the things such a syntax should represent. >> >> See also >> >>

Re: [O] Citations, continued

Thomas S. Dye writes: > Aloha Richard, > > Richard Lawrence writes: > >> My point is not that the link syntax *can't* do enough. Rather, my >> point is that citations are conceptually distinct from links, and if we >> are going to adopt an official syntax for them, that syntax should >> reflect

Re: [O] Citations, continued

Richard Lawrence writes: > 2) There are at least several different backend reference database > formats (BibTeX, Zotero, etc.) used by Orgsters. Not all such databases > use human-readable keys. Org also has a nice internal format for > storing reference information: org-bibtex. Human readable

Re: [O] Citations, continued

Aloha Richard, Richard Lawrence writes: > My point is not that the link syntax *can't* do enough. Rather, my > point is that citations are conceptually distinct from links, and if we > are going to adopt an official syntax for them, that syntax should > reflect this conceptual distinction. Thi

Re: [O] Citations, continued

Hi John and all, John Kitchin writes: >> As for the first problem, I think a good case can be made for adding new >> syntax to Org to represent citations, instead of repurposing/extending >> existing syntax (most notably, the link syntax). >> > > I think links are remarkable flexible, and solve

  1   2   >