Hi Matt,
Matt Price writes:
> Just a note about Zotero: I think for most of us, the reason to export
> into ODT and/or DOC is to circulate a paper either for review or
> collaboration. Either case will likely involve some revision to citations,
> which would ideally be handled through Zotero.
On Tue, Mar 17, 2015 at 12:26 PM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:
> Hi Andreas,
>
> Andreas Leha writes:
>
> > I have been following this thread from (quite) some distance as I am
> > very interested in more general citation support from orgmode. Please
> > allow some ba
Hi Andreas,
Andreas Leha writes:
>>> 2. The non-LaTeX exports
>>> These are all treated the same and will contain just text, that is
>>> produced to mimic LaTeX's output to some extent?
>>
>> Well, that depends on what you mean by `just' text. Citations can still
>> contain or be wrapped in mar
Hi Richard,
Thank you very much for your detailed answer.
Richard Lawrence writes:
> Hi Andreas,
>
> Andreas Leha writes:
>
>> I have been following this thread from (quite) some distance as I am
>> very interested in more general citation support from orgmode. Please
>> allow some basic quest
Hi Andreas,
Andreas Leha writes:
> I have been following this thread from (quite) some distance as I am
> very interested in more general citation support from orgmode. Please
> allow some basic questions:
>
> 1. For the LaTeX user
> This change means that the LaTeX user can use org syntax for
Hi all,
Richard Lawrence writes:
> Hi Aaron and all,
>
> Richard Lawrence writes:
>
>> I'll take some time this weekend to see if I can wire this together with
>> the Elisp Aaron wrote for the Org exporter side.
>
> I've had some success with this. I would not say that my efforts are
> complet
Hi Aaron and all,
Richard Lawrence writes:
> I'll take some time this weekend to see if I can wire this together with
> the Elisp Aaron wrote for the Org exporter side.
I've had some success with this. I would not say that my efforts are
complete yet, but I thought I should send an update to l
Hi Aaron and all,
Richard Lawrence writes:
>> What version of citeproc-hs are you using? The version under that
>> name is no longer maintained, and I had some trouble getting it to
>> build.
>
> I am in fact using the version under that name (I have not had trouble
> installing/building it via
Hi Aaron and all,
I cleaned up my efforts a bit and posted them here:
https://github.com/wyleyr/org-citeproc
(This program is just a modified version of John MacFarlane's citeproc
program:
https://github.com/jgm/citeproc/
which reads JSON in a slightly different format, and produces JSON
inste
Aloha Aaron,
Aaron Ecay writes:
> I have made citeproc-java give output like:
>
> Smith2014
> Doe1999
> Smith et al.2005
>
> I parse that into lists of (author, year) pairs by splitting on the
> . Then I expose a template to elisp: “%p%a (%y%s)” (for prefix,
> author, year, and
Hi Richard,
Thanks for your comments, and for your work on an implementation.
2015ko martxoak 10an, Richard Lawrence-ek idatzi zuen:
> I have actually been working on the same problem, using citeproc-hs as
> the CSL processor instead of citeproc-java.
This is an interesting approach. What versi
Hi Rasmus,
Thanks for your comments. Some replies:
2015ko martxoak 10an, Rasmus-ek idatzi zuen:
>> These are then slurped by org, and used to fill in printf-style
>> templates. Some people mentioned using citations as generated by
>> citeproc-java directly. However, I don’t believe this is rel
Hi Aaron and all,
Aaron Ecay writes:
> I’ve pushed an update to my branch. The major change is to use
> citeproc-java for the generation of the bibliography and the parsing of
> names.
That is awesome! Thank you for your work.
> The former is straightforward. For the latter, I have created
Hi,
Aaron Ecay writes:
> I’ve pushed an update to my branch.
Thank you Aaron! I appreciate the work. While the below may sound
bitter, it's not!
> These are then slurped by org, and used to fill in printf-style
> templates. Some people mentioned using citations as generated by
> citeproc-ja
Hello all,
I’ve pushed an update to my branch. The major change is to use
citeproc-java for the generation of the bibliography and the parsing of
names. The former is straightforward. For the latter, I have created a
CSL file which outputs author-year citations in an easy-to-parse format.
These
On Monday 09 March 2015 04:10 PM, Sebastien Vauban wrote:
> What is <<<...>>>?
(info "(org) Radio targets")
Hello Nicolas,
Nicolas Goaziou wrote:
> Honestly, Org is already full of cryptic symbols, e.g., {{{...}}}
> @@...@@, <<<>>>, <<...>>, and so on. This is not worse than the
> rest of Org.
What is <<<...>>>?
PS- Not easy to search for that in the Org manual in Emacs: neither <<
nor <<< are
Richard Lawrence writes:
> I was thinking that this should yield a citation object with a structure like:
>
> ('citation ...
> :common-prefix pre
> :common-suffix post
> :references ((:prefix pre1
> :key "k1"
> :suffix post1 ...)
>(:prefix pre
Avram Lyon writes:
> I know that citeproc-js has tried to be engine-agnostic, so perhaps it can
> work with Guile.
It looks like I was too quick. Although the homepage makes it seem like
Guile supports JS, the manual says:
"ECMAScript was not the first non-Schemey language implemented by Guil
On Mar 3, 2015 3:43 AM, "Nicolas Goaziou" wrote:
>
> Richard Lawrence writes:
>
> >> To support multi cites, we must first decide how the parsed will
present
> >> information, i.e., what are the properties in the following case
> >>
> >> [cite:pre; pre1 @k1 post1; pre2 @k2 post2; post]
> >
> >
On Tue, Mar 3, 2015 at 9:28 AM Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:
>
> That sounds right. And I agree with Aaron that we probably don't want a
> hard dependency on Zotero on the output side, so maybe citeproc-js is
> the way to go. On the other hand, as Aaron points out, cite
Hi Aaron,
Aaron Ecay writes:
> Another tangentially related issue is what does (org-element-context)
> return when point is in a multi-citation. It would be nice if it
> returned the citation daughter, rather than the wrapping citations
> element. This would make implementing goto-citation-at-
Hi Avram,
Avram Lyon writes:
> On Mon, Mar 2, 2015 at 7:16 PM Richard Lawrence <
> richard.lawre...@berkeley.edu> wrote:
>>
>> Is there any reason to go with citeproc-java over a different CSL
>> implementation, like citeproc-js or pandoc-citeproc? I am a little
>> nervous about shelling out to
Hi Nicolas,
Nicolas Goaziou writes:
>> Oh, I did not realize there were outstanding issues with this. I
>> remember Rasmus not liking `&'. I'm fine with changing it, though I
>> cannot think of a better symbol. Does someone think we should not have
>> a way of indicating that a reference shou
Hi,
Ken Mankoff writes:
> On 2015-03-03 at 10:41, Rasmus wrote:
>> ;; type is e.g. textcite, and citations look like
>> ;; [[cite: common pre; pre0 @key0 post0; pre1 @key1 post1; common post ]]
>
> My Biblatex keys are currently Author:Four-words-from-title. I
> don't think I'll ever have a
Rasmus writes:
> Nicolas Goaziou writes:
>
>> Richard Lawrence writes:
>>
>>> Sorry, I may not have emphasized this enough, but in the grammar, I wrote:
>>>
>>> - A KEY optionally begins with `-', and obligatorily contains `@' or
>>> `&' followed by a string of characters which begins wit
On 2015-03-03 at 10:41, Rasmus wrote:
> ;; type is e.g. textcite, and citations look like
> ;; [[cite: common pre; pre0 @key0 post0; pre1 @key1 post1; common post ]]
My Biblatex keys are currently Author:Four-words-from-title. I don't think
I'll ever have an author with "[" or "]" character
Hi,
> I’m not sure I’m happy about the citations/citation proposal (under any
> assignment of different names to the pieces). A citations containing
> only one citation is degenerate: it can never have a :prefix or :suffix
> (these will rather be attached to the lone daughter citation).
This is
Hi Rasmus,
2015ko martxoak 2an, Rasmus-ek idatzi zuen:
>
> Looks cool Aaron. Thanks!
>
> Aaron Ecay writes:
>
>> The first issue is that the parser includes trailing punctuation in
>> “bare” @key citations. So the following does not work as expected (the
>> :key includes the period): “This w
Hi Richard (again),
2015ko martxoak 2an, Richard Lawrence-ek idatzi zuen:
>
> Could we guess the backend from the file extension on the BIBLIOGRAPHY,
> to keep things simple here? I don't use a citation manager, so I don't
> know if this is possible for anything other than Bib(La)TeX.
>
> Also,
Hi Nicolas,
2015ko martxoak 2an, Nicolas Goaziou-ek idatzi zuen:
>
> Hello,
>
> Aaron Ecay writes:
>
>> I decided to go ahead and see what I could make of it. The result has
>> been pushed to the org mode repo to the branch wip-cite-awe. (I didn’t
>> want to push to your branch without asking,
Hi Richard,
2015ko martxoak 3an, Richard Lawrence-ek idatzi zuen:
>
> Aaron Ecay writes:
>
>> It would also be possible to just use an external program like
>> citeproc-java. WDYT?
>
> I agree with Rasmus that using an external tool is the preferred way to
> go here. I don't think introducin
Rasmus writes:
> Richard Lawrence writes:
>
>> Is there any reason to go with citeproc-java over a different CSL
>> implementation, like citeproc-js or pandoc-citeproc? I am a little
>> nervous about shelling out to something that sounds it like it requires
>> loading the JVM...
>
> For the lon
Richard Lawrence writes:
> Is there any reason to go with citeproc-java over a different CSL
> implementation, like citeproc-js or pandoc-citeproc? I am a little
> nervous about shelling out to something that sounds it like it requires
> loading the JVM...
For the longest of time, mathtoweb.jar
Nicolas Goaziou writes:
> Richard Lawrence writes:
>
>> Sorry, I may not have emphasized this enough, but in the grammar, I wrote:
>>
>> - A KEY optionally begins with `-', and obligatorily contains `@' or
>> `&' followed by a string of characters which begins with a letter
>> or `_',
Richard Lawrence writes:
>> To support multi cites, we must first decide how the parsed will present
>> information, i.e., what are the properties in the following case
>>
>> [cite:pre; pre1 @k1 post1; pre2 @k2 post2; post]
>
> I was thinking that this should yield a citation object with a stru
Richard Lawrence writes:
> Sorry, I may not have emphasized this enough, but in the grammar, I wrote:
>
> - A KEY optionally begins with `-', and obligatorily contains `@' or
> `&' followed by a string of characters which begins with a letter
> or `_', and may contain alphanumeric chara
On Mon, Mar 2, 2015 at 7:16 PM Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:
>
> Is there any reason to go with citeproc-java over a different CSL
> implementation, like citeproc-js or pandoc-citeproc? I am a little
> nervous about shelling out to something that sounds it like it requir
Aaron Ecay writes:
> It would also be possible to just use an external program like
> citeproc-java. WDYT?
I agree with Rasmus that using an external tool is the preferred way to
go here. I don't think introducing a dependency is really a problem, so
long as we choose the right dependency -- L
Nicolas Goaziou writes:
>> The first issue is that the parser includes trailing punctuation in
>> “bare” @key citations. So the following does not work as expected (the
>> :key includes the period): “This was demonstrated most recently by
>> @Smith2015.” I’m not sure what the right approach is
Hi Nicolas,
Nicolas Goaziou writes:
> To support multi cites, we must first decide how the parsed will present
> information, i.e., what are the properties in the following case
>
> [cite:pre; pre1 @k1 post1; pre2 @k2 post2; post]
I was thinking that this should yield a citation object with a
Nicolas Goaziou writes:
>> It would enable "complicated argument [@k1;@k2;@k3]", which is pretty
>> nice. There's still no pre and post notes etc, only keys.
>
> Shortcuts are simple citations that ought to be available in most
> back-ends. I don't see your example as a particularly straightforw
Rasmus writes:
> So (citation ⋯ :parts ((part ⋯) (part ⋯))). Fine with me. Other
> possibilities are citation/entry and :entries. Or less nice:
> citation/cite and :cites.
I don't mind using :entries and `entry' either. I'll update "wip-cite"
in a few days.
> It would enable "complicated arg
Nicolas Goaziou writes:
>> Perhaps the difference is too subtle. Note that you would never deal with
>> a `citation' other than through a mapping.
>
> Hmm. I still find `citations/citation' pair confusing. What about
> `citation/part'?
So (citation ⋯ :parts ((part ⋯) (part ⋯))). Fine with me.
Rasmus writes:
> Perhaps the difference is too subtle. Note that you would never deal with
> a `citation' other than through a mapping.
Hmm. I still find `citations/citation' pair confusing. What about
`citation/part'?
> Right, I was trying *to add* support for [@k1; ⋯;@kN].
Please don't. Let
Nicolas Goaziou writes:
> However mixing `citations' and `citation' is confusing. I'd rather keep
> the outer one as `citation'. What could go inside? Maybe `cite'?
Perhaps the difference is too subtle. Note that you would never deal with
a `citation' other than through a mapping.
> Moreover,
Rasmus writes:
> I was actually looking at this today and wondering why this was not
> supported.
Not enough specifications.
> I think a citation object should always member of a citations object. So
> the above would be
>
>(citations (:begin n :end N :prefix pre :suffix post
>
Looks cool Aaron. Thanks!
Aaron Ecay writes:
> The first issue is that the parser includes trailing punctuation in
> “bare” @key citations. So the following does not work as expected (the
> :key includes the period): “This was demonstrated most recently by
> @Smith2015.” I’m not sure what the
Nicolas Goaziou writes:
> Richard Lawrence writes:
>
>> What's the next step here? Adding support for multiple references?
>> multi-cites? `&'-keys?
>
> To support multi cites, we must first decide how the parsed will present
> information, i.e., what are the properties in the following case
>
Hello,
Aaron Ecay writes:
> I decided to go ahead and see what I could make of it. The result has
> been pushed to the org mode repo to the branch wip-cite-awe. (I didn’t
> want to push to your branch without asking, but if you prefer I’ll do
> that and delete my own.)
This is not *my* branch.
Aaron Ecay writes:
> Hi Rasmus,
>
> 2015ko martxoak 1an, Rasmus-ek idatzi zuen:
>>
>>> At this point, we probably need to implement a BIBLIOGRAPHY keyword
>>> (files) and BIBLIOGRAPHY_BACKEND (bibtex, zotero, jabref...) and provide
>>> basic tools to handle citations in an Org document.
>>
>> P
Richard Lawrence writes:
> What's the next step here? Adding support for multiple references?
> multi-cites? `&'-keys?
To support multi cites, we must first decide how the parsed will present
information, i.e., what are the properties in the following case
[cite:pre; pre1 @k1 post1; pre2 @k2
Hi Rasmus,
2015ko martxoak 1an, Rasmus-ek idatzi zuen:
>
>> At this point, we probably need to implement a BIBLIOGRAPHY keyword
>> (files) and BIBLIOGRAPHY_BACKEND (bibtex, zotero, jabref...) and provide
>> basic tools to handle citations in an Org document.
>
> Probably a CITATION_STYLE as well
Hi Tom,
2015ko martxoak 2an, "Thomas S. Dye"-ek idatzi zuen:
>
> I'm not able to understand the full implications of subtypes
> vs. plists, so don't have a preferred solution along those lines.
>
> I brought this up in reaction to "This doesn't really work in org."
>
> I'm hoping for an Org mod
Nicolas Goaziou writes:
> Richard Lawrence writes:
>
>> That would be wonderful! Will you publish a patch or, better, a branch
>> somewhere, even if it's not ready for master?
>
> I created a new branch: "wip-cite". It introduces support for @key
> [@key] [cite:pre @key post] and [(cite):pre @k
Aloha Aaron,
Aaron Ecay writes:
> Hi Tom,
>
> 2015ko martxoak 2an, "Thomas S. Dye"-ek idatzi zuen:
>>
>> Aloha Aaron,
>>
>> Aaron Ecay writes:
>>
>>> By way of illustration, Biblatex (AFAICT) doesn’t provide a possessive
>>> citation command, which was mentioned by someone in this thread (or
Hi Tom,
2015ko martxoak 2an, "Thomas S. Dye"-ek idatzi zuen:
>
> Aloha Aaron,
>
> Aaron Ecay writes:
>
>> By way of illustration, Biblatex (AFAICT) doesn’t provide a possessive
>> citation command, which was mentioned by someone in this thread (or its
>> predecessor) as a desideratum. I’d exp
On Sunday, 1 Mar 2015 at 14:24, Thomas S. Dye wrote:
> Rasmus writes:
>
>> Probably a CITATION_STYLE as well, e.g. "numeric", "author-year", etc.
>
> I suggest we keep Patrick Daly's distinction between "citation style"
> and "citation mode". Hence, #+CITATION_MODE instead
> of #+CITATION_STYLE.
t...@tsdye.com (Thomas S. Dye) writes:
> Rasmus writes:
>
>> I have noticed tex4ht manages to do "proper" citations in odt. Perhaps we
>> can study the resulting xml and how it adds a entries. Formatting is
>> tricky... Perhaps only zotero is useful here.
>
> IIUC, tex4ht uses the dvi (device
Aloha Aaron,
Aaron Ecay writes:
> By way of illustration, Biblatex (AFAICT) doesn’t provide a possessive
> citation command, which was mentioned by someone in this thread (or its
> predecessor) as a desideratum. I’d expect a savvy latex user to put in
> their preamble:
>
> \newcommand{\citeposs
Rasmus writes:
> I have noticed tex4ht manages to do "proper" citations in odt. Perhaps we
> can study the resulting xml and how it adds a entries. Formatting is
> tricky... Perhaps only zotero is useful here.
IIUC, tex4ht uses the dvi (device independent format of Knuth) file
produced by LaT
Rasmus writes:
> Probably a CITATION_STYLE as well, e.g. "numeric", "author-year", etc.
I suggest we keep Patrick Daly's distinction between "citation style"
and "citation mode". Hence, #+CITATION_MODE instead
of #+CITATION_STYLE.
IIUC, there are three citation modes:
1. Harvard, author-dat
Hi,
Nicolas Goaziou writes:
>> That would be wonderful! Will you publish a patch or, better, a branch
>> somewhere, even if it's not ready for master?
>
> I created a new branch: "wip-cite". It introduces support for @key
> [@key] [cite:pre @key post] and [(cite):pre @key post] constructs.
Coo
Richard Lawrence writes:
> That would be wonderful! Will you publish a patch or, better, a branch
> somewhere, even if it's not ready for master?
I created a new branch: "wip-cite". It introduces support for @key
[@key] [cite:pre @key post] and [(cite):pre @key post] constructs.
As a reminder,
Hi Stefan,
Stefan Nobis writes:
> Aaron Ecay writes:
>
>> I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
>> biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
>> are quite esoteric, of course, but they are all provided.
>
> There are many commands (and even more pr
Aaron Ecay writes:
>> In this design, the potential explosion in subtypes has been pretty well
>> kept in check. Does that make the design of BibLaTeX a good model for
>> Org mode?
>
> I don’t know, but I suspect not. Latex allows users to create powerful
> macros, but has relatively few built-
Samuel Wales writes:
>> If you don't allow a generalized link to follow a
>> user-specified λs then you don't have a flexible syntax
>> that you expressed desire for above. You'd still have to
>> wait for somebody "upstream" to develop [color-start:⋯].
>
> not sure why you are talking about link
Aaron Ecay writes:
> I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
> biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
> are quite esoteric, of course, but they are all provided.
There are many commands (and even more private commands are possible)
in order to hel
Hi Aaron,
Aaron Ecay writes:
> Hi Thomas,
>
> 2015ko otsailak 25an, "Thomas S. Dye"-ek idatzi zuen:
>>
>> BibLaTeX has 6 standard "subtypes", which it calls "standard commands".
>>
>> A citation style can provide any number of specialized commands in
>> addition to the 6 standard commands.
>>
Hi Thomas,
2015ko otsailak 25an, "Thomas S. Dye"-ek idatzi zuen:
>
> BibLaTeX has 6 standard "subtypes", which it calls "standard commands".
>
> A citation style can provide any number of specialized commands in
> addition to the 6 standard commands.
>
> The various citation styles that ship wi
Richard Lawrence writes:
> Agreed. I'd like to see an implementation of a parser for the
> [cite:...] part of the syntax as a first step. If we can get that far,
> I'd guess that extending the parser to include either a subtype label or
> {:key val ...} syntax will not be too difficult to do.
Hi Richard,
2015ko otsailak 20an, Richard Lawrence-ek idatzi zuen:
> OK. I don't anticipate needing {:key val} myself anytime soon; I was
> just trying to future-proof the syntax, and I don't want to lobby for it
> if you feel strongly that this is problematic.
>
> If there are others (John? Aar
On Wednesday 25 February 2015 09:59 AM, Richard Lawrence wrote:
Vaidheeswaran C writes:
If you need help with ODT/JabRef integration, I am willing to lend a
hand. (Only thing is) I would expect that someone hand-hold me wrt
what one wants in the final exporter on a case-by-case basis. I woul
Vaidheeswaran C writes:
> If you need help with ODT/JabRef integration, I am willing to lend a
> hand. (Only thing is) I would expect that someone hand-hold me wrt
> what one wants in the final exporter on a case-by-case basis. I would
> rather build bottom-up, rather than top-down.
That's gre
On Tuesday 17 February 2015 10:48 PM, Richard Lawrence wrote:
Another, more serious reason is that I work in a field where some
journals do not accept LaTeX submissions, or disprefer them; so
having some citation support in ODT export is important.)
You are lobbying for two things:
1. An impr
On Monday 16 February 2015 09:49 PM, Nicolas Goaziou wrote:
[cite:subtype: whatever]
Nicolas, if you could circulate a one-off patch that handles the above
syntax I will bump it against the ODT backend and JabRef engine.
I am waiting for the FSF representative to counter-sign my assignment
hi richard,
indeed i am not proposing changing any existing syntax.
samuel
hi rasmus!
thanks for your comments.
we are definitely not communicating about the same things.
i do not even understand what you think i am proposing. :)
if you get a chance to re-read my old posts on the subject,
i think it might help?
samuel
Rasmus writes:
> What Org desperately needs in terms of
> reproducible, scientific writing is a rigorous, standard syntax.
IMHO, the citation syntax discussion is more about making citations work
correctly in the various backends and less about reproducible documents.
Babel was a key developmen
Richard Lawrence writes:
> You're right that consistency in that syntax would be a good thing.
> Moreover, Org already has syntax that looks a lot like plists in
> #+ATTR_BACKEND lines and in Babel source block headers, so it seems
> natural to adopt something like it for other sorts of objects.
Hi Samuel,
Samuel Wales writes:
> On 2/20/15, Rasmus wrote:
>> I think everybody is thinking along the lines, but some people want to not
>> have another link-morass :) In particular, I think we are trying hard to
>> avoid this situation:
>>
>> i just think the syntax we design should, if p
Hi Samuel,
Samuel Wales writes:
> basically, i am concerned about syntax creep in the big picture and
> its downstream consequences. for example, it's more efficient to
> support, and for the user to remember, a single general syntax than a
> whole bunch of special syntaxes.
In general, I shar
hi rasmus,
On 2/20/15, Rasmus wrote:
> I think everybody is thinking along the lines, but some people want to not
> have another link-morass :) In particular, I think we are trying hard to
> avoid this situation:
>
> i just think the syntax we design should, if possible, be so general
> t
Samuel Wales writes:
> if everybody is already thinking along the same lines, great.
I think everybody is thinking along the lines, but some people want to not
have another link-morass :) In particular, I think we are trying hard to
avoid this situation:
i just think the syntax we design sh
On 2/20/15, Richard Lawrence wrote:
> If there are others (John? Aaron? Samuel?) who think they really need
> the {:key val} syntax *over and above* a subtype designation, please
> speak up!
i have no comments on citations per se. i just think the syntax we
design should, if possible, be so gene
Hi Melanie,
Melanie Bacou writes:
> Just want to point out RMarkdown/Pandoc implementation of
> bibliographies and citations here
> http://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html
Thanks for joining the discussion! Actually, the Pandoc/RMarkdown
syntax was sort of the
Hi Nicolas,
Nicolas Goaziou writes:
> AFAICT, the most advanced use of citations is Thomas', and he is
> basically only using "subtype". So I'm pretty confident that 99.9% of
> users will be fine with only these subtypes.
> ...
> Again, I don't think we need {:key val} at the moment. Also, it wo
Just want to point out RMarkdown/Pandoc implementation of bibliographies
and citations here
http://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html
One useful option is a `csl: biomed-central.csl` option in the preamble.
--Mel.
On 2/19/2015 12:06 PM, Richard Lawrence wrote:
Richard Lawrence writes:
> Ah, OK, I think I see...so this is basically the second option, with
> users interpreting subtypes via a separate protocol, instead of via
> filters. Right?
Correct.
> What about this concern, then?
>
>>> But that kind of situation is exactly what the extra-info part
Nicolas Goaziou writes:
> I wasn't clear. Subtype should be interpreted by back-ends means it has
> no impact on syntax. However a user should be able to dictate what the
> back-end should do with it, much like `org-add-link-type'.
>
> A new library, e.g. "org-cite.el" would provide all the tool
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 mig
Aaron Ecay writes:
> Hi Nicolas,
>
> 2015ko otsailak 18an, Nicolas Goaziou-ek idatzi zuen:
>>
>> 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.
>
> The question of attrib
I was thinking the same thing as Aaron ;) What could one do with a
"link-like" object with arbitrary attributes/properties... Hmm... maybe
this idea:
http://kitchingroup.cheme.cmu.edu/blog/2015/02/05/Extending-the-org-mode-link-syntax-with-attributes/
without the kludgy parsing? It will be so confu
hi aaron,
On 2/18/15, Aaron Ecay wrote:
> Do you mean how the syntax and implementation of links was used to
> support a new org feature completely unrelated to web URLs, namely
> citations? ;)
heh heh. :] that applies to the outer syntax only. i mean, for
example, plists vs. something less
Hi Samuel,
2015ko otsailak 18an, Samuel Wales-ek idatzi zuen:
>
> i have a silly question: whatever syntax we choose, will it be able to
> be used, in the future, for new org features nobody has thought of
> yet, that are unrelated to citations?
Do you mean how the syntax and implementation of li
Hi Nicolas,
2015ko otsailak 18an, Nicolas Goaziou-ek idatzi zuen:
>
> 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.
The question of attributes for objects arose out of the de
Richard Lawrence writes:
> I know that this is technically easy to handle from the backend's
> perspective. But I have a concern related to Stefan's:
>
> Stefan Nobis writes:
>
>> The drawback is that now subtype is hard or even impossible to vary
>> for different backends. Therefore I would s
[disclaimer: i do not currently use citations, so i have no stake in
citation syntax per se, just a tendency to ask highly generic silly
questions.]
i have a silly question: whatever syntax we choose, will it be able to
be used, in the future, for new org features nobody has thought of
yet, that are unrelated to citations?
my preference is to forestall future syntax creep, enhance
consistency, and amortize the effort in supporting a syntax [in
Hi Nicolas and all,
Nicolas Goaziou writes:
> Richard Lawrence writes:
>
>> Actually, your post has convinced me that it may be worth allowing some
>> explicit name for a type in the [cite: ...] part of the syntax, although
>> I am still leery about what this would mean for non-LaTeX backends.
1 - 100 of 156 matches
Mail list logo
