On Wed, Feb 11, 2015 at 11:51 AM, Richard Lawrence
richard.lawre...@berkeley.edu wrote:
Stefan Nobis stefan...@snobis.de writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
But anyway: Some tool is needed to generate the bibliography with all
its data - this tool has to
Stefan Nobis stefan...@snobis.de writes:
Richard Lawrence richard.lawre...@berkeley.edu 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
Richard Lawrence richard.lawre...@berkeley.edu 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
Aaron Ecay aarone...@gmail.com 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.
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.
I
John Kitchin jkitc...@andrew.cmu.edu writes:
Rasmus writes:
Nicolas Goaziou m...@nicolasgoaziou.fr 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
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, but
Rasmus writes:
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Hi Nicolas and all,
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Hi Stefan,
Stefan Nobis stefan...@snobis.de writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
Rasmus ras...@gmx.us writes:
Citation types for extracting parts:
citeauthor, citetitle, citeyear, citedate, citeurl,
As I've said in other posts, I think maybe we should not
Hi Tom and all,
t...@tsdye.com (Thomas S. Dye) writes:
Richard Lawrence richard.lawre...@berkeley.edu 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
Richard Lawrence richard.lawre...@berkeley.edu 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
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Tom and all,
t...@tsdye.com (Thomas S. Dye) writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
Conceptually, something like `@key:year' isn't a citation, but merely
indirection, because it doesn't actually provide the
Richard Lawrence richard.lawre...@berkeley.edu writes:
Rasmus ras...@gmx.us 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
Rasmus ras...@gmx.us 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.
John Kitchin jkitc...@andrew.cmu.edu 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
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
Rasmus ras...@gmx.us 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Rasmus ras...@gmx.us 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Rasmus ras...@gmx.us writes:
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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
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)
Nicolas Goaziou m...@nicolasgoaziou.fr 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
John Kitchin jkitc...@andrew.cmu.edu 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
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
understood
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 initially
Hi John and all,
John Kitchin jkitc...@andrew.cmu.edu 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.
Aloha Rasmus,
Rasmus ras...@gmx.us 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
Richard Lawrence richard.lawre...@berkeley.edu 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
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=
Nicolas Goaziou writes:
Rasmus ras...@gmx.us 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
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
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us 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
Rasmus ras...@gmx.us 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
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 types
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
Richard Lawrence richard.lawre...@berkeley.edu writes:
On Sat, Feb 7, 2015 at 2:43 PM, Nicolas Goaziou m...@nicolasgoaziou.fr
wrote:
What about the following set?
bold code entity italic latex-fragment line-break strike-through
subscript superscript underline superscript
That would
Rasmus ras...@gmx.us writes:
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Nicolas Goaziou m...@nicolasgoaziou.fr 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.
Rasmus ras...@gmx.us 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.
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. 30] says blah.
Nicolas Goaziou m...@nicolasgoaziou.fr 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.
Rasmus ras...@gmx.us 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
Rasmus ras...@gmx.us 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
Hi John and all,
On Sun, Feb 8, 2015 at 1:46 AM, John Kitchin jkitc...@andrew.cmu.edu 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
Hi Nicolas and all,
On Sun, Feb 8, 2015 at 1:58 AM, Nicolas Goaziou m...@nicolasgoaziou.fr 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?
Richard Lawrence richard.lawre...@berkeley.edu 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...?
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us 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
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
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 m...@nicolasgoaziou.fr wrote:
What
Richard Lawrence richard.lawre...@berkeley.edu 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,
Hi,
Nicolas Goaziou m...@nicolasgoaziou.fr 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
Hi,
I realize you list Pandoc features, but I will still point out some issues
with this syntax.
Richard Lawrence richard.lawre...@berkeley.edu writes:
Specifically I think we need the following categories, all of which
would be objects:
- key
- prefix / pre-text
- suffix / post-text
Hi Nicolas and all,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Richard Lawrence richard.lawre...@berkeley.edu 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 /
Richard Lawrence richard.lawre...@berkeley.edu 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
On Wed, 4 Feb 2015 at 07:59:46 PST,
Richard Lawrence richard.lawre...@berkeley.edu wrote:
Erik Hetzner e...@e6h.org 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
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 are
Hi Nicolas,
Nicolas Goaziou m...@nicolasgoaziou.fr 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
On Wed, 4 Feb 2015 at 04:06:36 PST,
Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
Hello,
Erik Hetzner e...@e6h.org 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
Erik Hetzner e...@e6h.org writes:
On Wed, 4 Feb 2015 at 07:59:46 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
Erik Hetzner e...@e6h.org 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
Hello,
Erik Hetzner e...@e6h.org 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
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
Hi Richard,
On Tue, 3 Feb 2015 at 08:11:19 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
Hi Eric and all,
Eric S Fraga e.fr...@ucl.ac.uk 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
Hi Erik and all,
Erik Hetzner e...@e6h.org writes:
On Mon, 2 Feb 2015 at 20:41:06 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
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
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 to
Vikas Rawal vikasli...@agrarianresearch.org 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
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Rasmus and all,
Thanks for your comments!
Rasmus ras...@gmx.us 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
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:
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, it
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)
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
John Kitchin jkitc...@andrew.cmu.edu 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
Hi Rasmus and all,
Thanks for your comments!
Rasmus ras...@gmx.us 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
John Kitchin jkitc...@andrew.cmu.edu 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
Thomas S. Dye writes:
Aloha Richard,
Richard Lawrence richard.lawre...@berkeley.edu 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
Richard Lawrence richard.lawre...@berkeley.edu 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:
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 of
Richard Lawrence richard.lawre...@berkeley.edu writes:
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
...so the first step for introducing citation syntax to Org should be
compiling a list of all the things such a syntax should
On Mon, 2 Feb 2015 at 10:02:41 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
Hi Erik and all,
Erik Hetzner e...@e6h.org 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
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
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
On Sat, 31 Jan 2015 at 10:26:05 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
Hi Richard,
On Mon, 2 Feb 2015 at 20:41:06 PST,
Richard Lawrence richard.lawre...@berkeley.edu 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
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 of
Hi John,
John Kitchin jkitc...@andrew.cmu.edu 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
Hi,
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Rasmus and all,
Rasmus ras...@gmx.us writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
Within a citation, each reference to an individual work needs to be
capable of containing:
1) a database key that
Hi,
Richard Lawrence richard.lawre...@berkeley.edu 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
Hi Rasmus and all,
Rasmus ras...@gmx.us writes:
Richard Lawrence richard.lawre...@berkeley.edu 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 /
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
Here's my personal opinion about how we might solve them.
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,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Richard Lawrence richard.lawre...@berkeley.edu 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
1 - 100 of 103 matches
Mail list logo
