Am 05. Mai 2021 um 14:27 Uhr -0400 schrieb Bruce D'Arcus:
> Hope that explains.
Sure, thank you! I just wanted to provide some possibly useful input.
I am not to critise these exciting efforts.
-quintus
--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security:
Passau, Germany |
Am 05.05.2021 um 20:14 schrieb M. ‘quintus’ Gülker:
Am 05. Mai 2021 um 09:46 Uhr -0400 schrieb Bruce D'Arcus:
We found three rules:
1. what Chicago calls "American"
2. what it calls "British"
3. French (though Denis is still confirming how these work in actual books)
The output in each, when f
On Wed, May 5, 2021 at 2:15 PM M. ‘quintus’ Gülker
wrote:
> I wonder, can the placement of the footnote not just be left to the
> author...? I have the impression that something is being
> over-engineered here with the attempt to automate this, but maybe this
> is just me.
The use case is for us
Am 05. Mai 2021 um 09:46 Uhr -0400 schrieb Bruce D'Arcus:
> We found three rules:
>
> 1. what Chicago calls "American"
> 2. what it calls "British"
> 3. French (though Denis is still confirming how these work in actual books)
>
> The output in each, when formatting as a note:
>
> 1. A sentence e
On Sun, May 2, 2021 at 6:18 PM Bruce D'Arcus wrote:
> On Sun, May 2, 2021 at 5:59 PM Denis Maier wrote:
>
> > I'm thinking whether this could make the system more flexible and
> > adaptable.
>
> We'd still need to discuss details of course (like including sensible
> defaults, etc.) if this were
On the substance of these rules, my conclusion (and Denis knows this
are better than I, so can amend this) is the primary difference
between what Chicago calls "American" punctuation rules and "British"
is that the former puts trailing punctuation within the closing quote,
and the latter does not,
On Sun, May 2, 2021 at 5:59 PM Denis Maier wrote:
> I'm thinking whether this could make the system more flexible and
> adaptable.
We'd still need to discuss details of course (like including sensible
defaults, etc.) if this were possible, but Denis and I agree that
having a second optional para
While evaluating different aspects of punctuation moving I had another
look at the csquotes package. p. 21 f. and p. 27 ff. in the manual
(http://mirrors.ctan.org/macros/latex/contrib/csquotes/csquotes.pdf) are
quite instructive.[1] This package a structured representation of a
quotation, final
On Fri, Apr 30, 2021 at 5:48 PM Denis Maier wrote:
> Yes, this should be equivalent to the behaviour in pandoc.
>
> However, as I've said before, this behaviour is only correct in American
> English.
Denis and I are working on sorting out the details of how to address
this off-list ATM.
But I'm
Hello,
Denis Maier writes:
> However, as I've said before, this behaviour is only correct in
> American English. TO quuote the Chicago Manual of Style 6.9: "In an
> alternative system, sometimes called British Style (as described in
> the /New Oxford Style Manual ...) ... only those punctuation
Hi Nicolas,
thanks for all you work on this one. I don't have a setup where I can
test this, but from what I can tell this looks quite good already.
Am 30.04.2021 um 15:28 schrieb Nicolas Goaziou:
[...]
OK. I wrote a POC, and I would appreciate some feedback about it.
In order to test it,
Hello,
"Bruce D'Arcus" writes:
> But an example from American English for illustration, derived from
> Denis' examples.
>
> "A simple quote" [cite:@doe].
>
> When rendered, that should be this in an author-date style:
>
> "A simple quote" (Doe 2021).
>
> ... and this in a note style:
>
> "A simp
Am 27.04.2021 um 16:07 schrieb Bruce D'Arcus:
On Tue, Apr 27, 2021 at 9:58 AM Denis Maier wrote:
Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.
Only if you mentally parse it as a parenthetical author-date citation.
I don't think so. A
On Tue, Apr 27, 2021 at 9:58 AM Denis Maier wrote:
> > Your example fails on 1 because it suggests the citation attaches to
> > (starts) the following sentence.
>
> Only if you mentally parse it as a parenthetical author-date citation.
I don't think so. A period is a way we delimit sentences; is
Am 27.04.2021 um 14:32 schrieb Bruce D'Arcus:
On Tue, Apr 27, 2021 at 7:44 AM Denis Maier wrote:
Regarding simpler ways, why not just:
"A simple quote." [cite: @doe p. 45]
No, that's worse ;-)
Let's review basic requirements:
1. a plain text document really should be readable and its sema
On Tue, Apr 27, 2021 at 7:44 AM Denis Maier wrote:
> Regarding simpler ways, why not just:
>
> "A simple quote." [cite: @doe p. 45]
No, that's worse ;-)
Let's review basic requirements:
1. a plain text document really should be readable and its semantics clear
2. a user should be able to write
Am 27.04.2021 um 12:12 schrieb Bruce D'Arcus:
On Mon, Apr 26, 2021 at 4:35 PM Denis Maier wrote:
Regarding the proposal: I think that could go in the right direction,
but in the current form it has the downside that you can't use the
prefix anymore, right?
Not sure why you would need a prefi
Bruce D'Arcus writes:
> Hmm .. org doesn't have an inline quote, I guess?
I don't think so, unless @@quote:@@ is recognised.
--
Timothy
On Mon, Apr 26, 2021 at 4:35 PM Denis Maier wrote:
> Regarding the proposal: I think that could go in the right direction,
> but in the current form it has the downside that you can't use the
> prefix anymore, right?
Not sure why you would need a prefix for this case, but org-cite has
two levels
Am 26.04.2021 um 16:54 schrieb Bruce D'Arcus:
I had an idea on this, though it may not be a good one ...
On Sat, Apr 24, 2021 at 2:39 PM Bruce D'Arcus wrote:
On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou wrote:
Hello,
"Bruce D'Arcus" writes:
Some sentence with a concluding citation [
I had an idea on this, though it may not be a good one ...
On Sat, Apr 24, 2021 at 2:39 PM Bruce D'Arcus wrote:
>
> On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou
> wrote:
> >
> > Hello,
> >
> > "Bruce D'Arcus" writes:
> >
> > > Some sentence with a concluding citation [cite:@key].
> > >
> >
On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Some sentence with a concluding citation [cite:@key].
> >
> > ... that should end up like this:
> >
> > Some sentence with a concluding citation.[1]
> >
> > Aside: looking through the CSL spec, it
Hello,
"Bruce D'Arcus" writes:
> Some sentence with a concluding citation [cite:@key].
>
> ... that should end up like this:
>
> Some sentence with a concluding citation.[1]
>
> Aside: looking through the CSL spec, it doesn't seem this is
> documented. It obviously should be.
>
> And I don't rem
Am 23. April 2021 um 09:24 Uhr -0400 schrieb Bruce D'Arcus:
> It can be that not only does the space get removed, but the note mark
> is moved outside the period.
>
> So if you have ...
>
> Some sentence with a concluding citation [cite:@key].
>
> ... that should end up like this:
>
> Some sent
Hello,
András Simonyi writes:
> Thank you, this is very promising! I've checked the behaviour of
> citeproc-org with and without a note style now and there is only one
> additional minor difference which I forgot to mention, I don't know
> how difficult would it be to implement it: When a citat
On Fri, Apr 23, 2021 at 9:24 AM Bruce D'Arcus wrote:
> Aside: looking through the CSL spec, it doesn't seem this is
> documented. It obviously should be.
>
> And I don't remember if that convention is locale-specific; e.g. if
> while that's the standard in English, it could be different in France
On Fri, 23 Apr 2021 at 15:24, Bruce D'Arcus wrote:
> It can be that not only does the space get removed, but the note mark
> is moved outside the period.
>
> So if you have ...
>
> Some sentence with a concluding citation [cite:@key].
>
> ... that should end up like this:
>
> Some sentence with a
Dear All,
On Fri, 23 Apr 2021 at 14:03, Nicolas Goaziou wrote:
>> well, I think there might be some legitimate use cases, e.g.,
>> (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103)
> This use-case is not convincing, because it ought to be the task of the
> citation processor t
On Fri, Apr 23, 2021 at 9:10 AM Bruce D'Arcus wrote:
> I also forgot to mention this detail, and agree it's important to be
> able to do: to modify punctuation around such "footnoted-citations".
While I'm on it, one other related detail:
It can be that not only does the space get removed, but t
On Fri, Apr 23, 2021 at 8:56 AM András Simonyi wrote:
> Thank you, this is very promising! I've checked the behaviour of
> citeproc-org with and without a note style now and there is only one
> additional minor difference which I forgot to mention, I don't know
> how difficult would it be to imp
Dear All,
On Fri, 23 Apr 2021 at 13:49, Nicolas Goaziou wrote:
> I went ahead and implemented `org-cite-wrap-citation' function in
> "oc.el" (from wip-cite-new branch). Here's a quick demo.
> --8<---cut here---start->8---
> (defun ngz-cite-demo-export-citatio
Hello,
András Simonyi writes:
> well, I think there might be some legitimate use cases, e.g.,
> (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103)
This use-case is not convincing, because it ought to be the task of the
citation processor to italicize "cf." (perhaps through an o
Nicolas Goaziou writes:
> "Bruce D'Arcus" writes:
>
>> In general (conceptually), if you have one footnote in text, and one
>> in a footnote, with a note style, both will be rendered as footnotes.
>>
>> So in an adapted version from earlier:
>>
>>
>> Text 1 [@cite:@a].
>> Text 2[fn:1].
>>
>
Bruce D'Arcus writes:
> If point is within the citation brackets, you see the raw syntax, so
> you can edit it.
>
> Once you are outside the brackets, having already inserted the
> citation, you see a preview of the output.
This sounds quite sensible to me. I'd be happy with some sensible
auth
On Wed, Apr 21, 2021 at 10:47 PM Timothy wrote:
> I think what would be ideal, would be if common citation styles could
> define a method which produces a display string, like "Goaziou et al.
> (2021)". If nothing is defined, then no overlay should be produced.
Make sense, but with a caveat: not
John Kitchin writes:
> 5. I mostly think the citations should be displayed as plain text, i.e.
> not replaced by a numbered overlay, or equivalent. I could see hiding
> the [], but also guess that would be more confusing than beneficial.
As someone who works author-year inline citations into t
Hello,
"Bruce D'Arcus" writes:
> In general (conceptually), if you have one footnote in text, and one
> in a footnote, with a note style, both will be rendered as footnotes.
>
> So in an adapted version from earlier:
>
>
> Text 1 [@cite:@a].
> Text 2[fn:1].
>
> [fn:1] This is [cite:@b].
> -
On Wed, Apr 21, 2021 at 7:51 PM Nicolas Goaziou wrote:
>
> Hello,
>
> András Simonyi writes:
>
> > This is a crucial point: when a note CSL style is used, the export has
> > to generate footnotes "around" those citations which are not already
> > in a footnote.
> > Since citeproc-org generates
Hello,
András Simonyi writes:
> This is a crucial point: when a note CSL style is used, the export has
> to generate footnotes "around" those citations which are not already
> in a footnote.
> Since citeproc-org generates only Org fragments, this is very simple
> to do (with anonymous footnote
Dear All,
On Sun, 18 Apr 2021 at 15:11, Nicolas Goaziou wrote:
> I am also leaning towards removing the possibility to include Org syntax
> (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly
> useful (you can move the bold part outside of the citation object), and
> yet, adds
and for completeness from the org-ref point of view, probably all of
them call something like (org-ref-find-bibliography) inside those
functions to get a list of bib sources from a hierarchy of local
definitions in the buffer to env vars, to a default source variable
defined in elisp. I think somet
A big +1 to everything John said. On this:
On Wed, Apr 21, 2021 at 4:26 PM John Kitchin wrote:
> 4. I tend to have my follow function launch a hydra menu, which provides
> many action choices. I think this is easier than trying to remember a lot of
> different commands that also work at the cita
>>> - "fontification" is meant to give full access to face selection, what
>>> is really displayed, additional keymaps, all using a single
>>> function.
>>
>>> At the moment, I have no idea about what arguments would be useful.
>>> I think John Kitchin gave ideas about this alre
On Wed, Apr 21, 2021 at 3:57 PM John Kitchin wrote:
> I guess that the actions I use most often when "opening" a citation are,
> opening the pdf, going to the webpage for it, and then opening the
> bibtex entry (usually to fix capitalization or something). In org-ref
> though, there are a whole b
I guess that the actions I use most often when "opening" a citation are,
opening the pdf, going to the webpage for it, and then opening the
bibtex entry (usually to fix capitalization or something). In org-ref
though, there are a whole bunch of other potential actions, like
searching for related ci
On Wed, Apr 21, 2021 at 1:08 PM Nicolas Goaziou wrote:
> I will take care about the default back-end (hopefully before the end of
> the week but don't hold your breath), but can only provide guidance for
> the conversion part. I hope there is enough motivated people to give it
> a try.
My lisp s
Hello,
Matt Price writes:
> As a user, is there any way I can participate at this point? I'm not in a
> position to contribute code tight now but really do want to have this
> feature as soon as possible. It's going to improve my students' lives quite
> a bit.
Thank you for your interest.
I ha
As a user, is there any way I can participate at this point? I'm not in a
position to contribute code tight now but really do want to have this
feature as soon as possible. It's going to improve my students' lives quite
a bit.
>
>
>
Hello,
M. ‘quintus’ Gülker writes:
> The citation object will provide access to all elements of the new
> cite syntax I assume, including things like key, prefix and suffix?
Indeed. Also global prefix and suffix.
> Several styles I am normally confronted with require crossreferencing
> in cita
On Sun, Apr 18, 2021 at 9:31 AM Ihor Radchenko wrote:
>
> Nicolas Goaziou writes:
>
> > In my mind, "opening" leads to the bibliography reference, not to the
> > original document. IIUC, in this situation, the location does not matter
> > much, does it?
> >
> > In any case, Org has no clue about
Nicolas Goaziou writes:
> In my mind, "opening" leads to the bibliography reference, not to the
> original document. IIUC, in this situation, the location does not matter
> much, does it?
>
> In any case, Org has no clue about the "location" of the citation. It
> can provide the suffix associated
Hello,
András Simonyi writes:
> are short-form citations like @doe2018 or [@doe2018] also supported?
No, I removed them in last year's iteration, because they are prone to
false positives. I didn't want to repeat the footnote syntax mistake,
when "[1]" was equivalent to "[fn:1]".
I am also le
Hi,
Am 12. April 2021 um 15:19 Uhr +0200 schrieb Nicolas Goaziou:
> The syntax is complete in "wip-cite-new" branch. For the record, in its
> full glory, it can look like this:
>
> [cite/style: global prefix; prefix -@key suffix ; ... ; global suffix]
>
> [...]
> - "exporting" action is tric
On Fri, Apr 16, 2021 at 1:06 PM András Simonyi wrote:
> The Emacs world is currently rather BibTeX
> centered, but biblatex is an important (and rather different)
> alternative, and there is CSL as well which I expect to become more
> and more relevant (it's citeproc-el's native format). Moreover
Dear All,
apologies for being this late with my reaction -- here are some
comments/questions on Nicolas's summary:
On Mon, 12 Apr 2021 at 15:19, Nicolas Goaziou wrote:
> suffix" are all optional. So, in its minimal form, it can be as simple
> as:
>
> [cite:@Doe:1995a]
are short-form citati
Dear All,
thank you very much for bringing this forward and thanks to Nicholas
for his work and detailed write-up on the API! Unfortunately, I'm
extremely busy right now, but will try to comment in detail on the
coming days, most probably on Thursday. I'm very excited by the new
developments!
bes
Hello,
"Bruce D'Arcus" writes:
> Maybe since Nicolas has been around lately, he can weigh in?
I guess I can make a summary about the current state of the citations
branch, i.e., what is done, what is missing.
There are three major steps to complete in order to add citations in
Org: defining the
Maybe since Nicolas has been around lately, he can weigh in?
On Wed, Mar 24, 2021 at 2:28 PM M. ‘quintus’ Gülker
wrote:
>
> Am 24. März 2021 um 09:22 Uhr -0400 schrieb Bruce D'Arcus:
> > Anyone know anything else?
>
> Not really. I would just like to say that I am eagerly watching this
> thread a
Am 24. März 2021 um 09:22 Uhr -0400 schrieb Bruce D'Arcus:
> Anyone know anything else?
Not really. I would just like to say that I am eagerly watching this
thread and am earnestly curious about what will happen to wip-cite. A
proper cite system for org would be such a useful feature.
-quintus
I know Bastien and Nicolas are less active on the list these days, but does
anyone know what the plan is with the wip-cite branch?
My understanding is the syntax work that Nicolas did was done enough that
it was ready for testing, and that the remaining questions were really what
more needed to be
Could Nicholas or Bastien please update on where this stands at this point?
On Wed, Jun 3, 2020 at 10:53 AM Bruce D'Arcus wrote:
>
> On Wed, Jun 3, 2020 at 10:40 AM Bastien wrote:
>
> > Hi all,
> >
> > just a quick word in this thread to say that we are in feature freeze
> > for Org core feature
On Wed, Jun 3, 2020 at 10:40 AM Bastien wrote:
> Hi all,
>
> just a quick word in this thread to say that we are in feature freeze
> for Org core features (ie. everything in org*.el files, + ob.el/ol.el).
>
> So let's take the time to discuss this in details for 9.5 (or later,
> when it's ready.)
Hi all,
just a quick word in this thread to say that we are in feature freeze
for Org core features (ie. everything in org*.el files, + ob.el/ol.el).
So let's take the time to discuss this in details for 9.5 (or later,
when it's ready.)
Thanks!
--
Bastien
One thing on a detail:
On Fri, May 29, 2020 at 6:00 PM András Simonyi wrote:
...
> From the citeproc-el (and CSL) perspective, the list of bibliography database
> files, the place where the bibliography should be placed (if it's specified)
> ...
Particularly if citeproc.el gets incorporated i
On Fri, May 29, 2020 at 6:00 PM András Simonyi wrote:
>
> Hi,
>
> apologies for reacting that late (it seems that I messed up my email filtering
> royally) ...
I wondered what happened to you; glad you sorted it out though!
...
> (i) Default ("built in") citation processor in Org
>
> I think ci
Hi,
apologies for reacting that late (it seems that I messed up my email filtering
royally) -- it is very nice to see progress in this area. Thanks to all of you
for trying to bring this forward, and, of course, to Bruce for initiating the
thread.
I think that the syntax that has crystallized is
Hi Bastian,
On Sun, May 24, 2020 at 8:12 AM Bastien wrote:
>
> Hi Bruce,
>
> "Bruce D'Arcus" writes:
>
> > I'm not sure of the value of this sort of question thrown in the
> > middle of a long-running, many year, conversation. You seem to assume
> > nobody considered this.
>
> Well, this sounde
Hi Bruce,
"Bruce D'Arcus" writes:
> I'm not sure of the value of this sort of question thrown in the
> middle of a long-running, many year, conversation. You seem to assume
> nobody considered this.
Well, this sounded a bit harsh, problably more than what was intended.
> But to answer anyway .
Nicolas Goaziou writes:
> I think there are really two paths here: either we only support the
> common denominator between all processors, like, e.g., Pandoc, or we
> handle every possible command, knowing that most of them will not be
> portable anyways.
Yes, I think that is the core issue: whi
Am 02.05.2020 um 18:34 schrieb Nicolas Goaziou:
It seems you didn't copy the list. I add it again.
No, I think that should be fine. (Perhaps also a fourth one for
author-only. And what about nocite?)
Sorry. I wasn't clear.
There is still full support for styles behind the suggested syntax,
e
It seems you didn't copy the list. I add it again.
> No, I think that should be fine. (Perhaps also a fourth one for
> author-only. And what about nocite?)
Sorry. I wasn't clear.
There is still full support for styles behind the suggested syntax,
e.g., [cite/author: ...], [cite/nocite: ...] (thi
Hello,
"Bruce D'Arcus" writes:
> So to sum up, I expect we will explicitly define three commands:
> default (the one defined in the citation template of the style),
> suppress-author (which need not be explicitly defined in the style,
> since the processor knows how to achieve this), and cite-te
On Sat, May 2, 2020 at 9:13 AM Nicolas Goaziou wrote:
> I suggested to support at least "cite", "cite/text" and "cite/paren",
> but it sounds like "cite/paren" is not possible with Citeproc. This
> doesn't matter much, we can limit the supported set to "cite" and
> "cite/text" in Citeproc.
Just
Hello,
Richard Lawrence writes:
> If so, then I think Nicolas' proposal to have "cite" mean default and
> make non-default citations available as "cite/xxx" makes sense
> (especially with the other syntax supporting suppress-author, etc.).
>
> If not, then the "cite/xxx" syntax makes less sense
On Sat, May 2, 2020 at 5:51 AM Nicolas Goaziou wrote:
...
> > Does that mean you'll be able to have the same or different processors
> > for different backends? (Like biblatex for latex and citeproc-el for
> > ODT/HTML/etc.; or when you need identical output you can use
> > citeproc-el even for
Hello,
Thank you for the feedback.
Denis Maier writes:
> What about using quotes if someone needs this, like so [cite: "common
> prefix; still common prefix"; pre @key post; pre @key2 post; common
> suffix] ?
Then we would have to find a way to escape the quote…
> Does that mean you'll be abl
On Fri, May 1, 2020 at 1:38 PM Richard Lawrence
wrote:
>
> "Bruce D'Arcus" writes:
>
> >> > My understanding, though, is that org "cite" would default to your
> >> > last example I quote above (in natibib, citep); that there's no need
> >> > for a dedicated "cite/paren" command, either reserved o
"Bruce D'Arcus" writes:
>> > My understanding, though, is that org "cite" would default to your
>> > last example I quote above (in natibib, citep); that there's no need
>> > for a dedicated "cite/paren" command, either reserved or not.
>>
>> Not necessarily. "cite" means default value, whatever
Hello,
Am 25.04.2020 um 18:19 schrieb Nicolas Goaziou:
Hello,
I cannot answer all open questions as the thread would spread too thin.
So, I'll try to subsume where Org is at the moment, and what need to be
decided.
Thanks for the suggestion. Looks like a pretty solid approach.
There is a li
On Sat, Apr 25, 2020 at 4:03 PM Nicolas Goaziou wrote:
...
> > My understanding, though, is that org "cite" would default to your
> > last example I quote above (in natibib, citep); that there's no need
> > for a dedicated "cite/paren" command, either reserved or not.
>
> Not necessarily. "cite"
Hello,
"Bruce D'Arcus" writes:
> On Sat, Apr 25, 2020 at 12:20 PM Nicolas Goaziou
> wrote:
>
[...]
>>
>> [cite/text: ...]
>> [cite/paren: ...]
>>
> So in this approach, we have a single core "cite" command, and
> everything else is a namespaced extension?
Indeed.
> My understanding, t
First, thanks for your work on this Nicolas; really awesome to see the progress!
I'm just going to address your syntax/cite command question.
I don't have concerns about the other details, and I think others are
better positioned to comment on those ...
On Sat, Apr 25, 2020 at 12:20 PM Nicolas G
Hello,
I cannot answer all open questions as the thread would spread too thin.
So, I'll try to subsume where Org is at the moment, and what need to be
decided.
First things first, I pushed a new branch, "wip-cite-new" in the
repository, with an modified implementation of citation syntax,
hopefull
"Bruce D'Arcus" writes:
> I can't see that it's necessary to have a fourth, because I think the
> result of that would be this, which doesn't make any sense.
>
> 4. "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> author-in-text+suppress-author command
>
> Let us know what you think?
I think t
On Sat, Apr 18 2020, Bruce D'Arcus wrote:
The question, then: Is that what you're saying; we don't need
suppress-author?
I think I actually agree, though will add a topic that came up
in the
CSL implementation discussion for the author-in-text styles in
the
past few days.
Here's a common
> Bruce D'Arcus hat am 18. April 2020 15:22 geschrieben:
>
>
> But ...
>
> On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus wrote:
>
> ...
>
> > I can't see that it's necessary to have a fourth, because I think the
> > result of that would be this, which doesn't make any sense.
> >
> > 4. "Do
> Bruce D'Arcus hat am 18. April 2020 15:22 geschrieben:
>
>
> But ...
>
> On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus wrote:
>
> ...
>
> > I can't see that it's necessary to have a fourth, because I think the
> > result of that would be this, which doesn't make any sense.
> >
> > 4. "
But ...
On Sat, Apr 18, 2020 at 9:17 AM Bruce D'Arcus wrote:
...
> I can't see that it's necessary to have a fourth, because I think the
> result of that would be this, which doesn't make any sense.
>
> 4. "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> author-in-text+suppress-author command
On Sat, Apr 18, 2020 at 8:48 AM Richard Lawrence
wrote:
>
> Hi Bruce and all,
>
> "Bruce D'Arcus" writes:
>
> > Just to align what you're saying and what I'm saying:
> >
> > I see three commands in the pandoc syntax: standard/parenthetical,
> > author-in-text, and suppress-author; that look like
Hi Bruce and all,
"Bruce D'Arcus" writes:
> Just to align what you're saying and what I'm saying:
>
> I see three commands in the pandoc syntax: standard/parenthetical,
> author-in-text, and suppress-author; that look like so:
>
> [@doe17]
> @doe17
> -@doe17
>
> Implicit in what you wrote is the
Just one question, Richard ...
On Sat, Apr 18, 2020 at 5:50 AM Richard Lawrence
wrote:
[...]
> I think it is worth pointing out to Bib(La)TeX users that it is useful
> to avoid a proliferation of citation commands in Org syntax. The syntax
> discussed so far achieves this by "factoring out" for
Joost Kremers writes:
> Good points. I guess what this boils down to is whether Org wants
> to be like LaTeX, where simple things are doable and complicated
> things possible, or Pandoc, where simple things are simple indeed
> and complicated things essentially impossible.
>
> To clarify: in L
Hi all,
Nice to see this issue being discussed again!
I don't have a lot to add and at the moment I don't have a lot of time
to contribute, but I wanted to make one point about this issue:
Joost Kremers writes:
> On Mon, Apr 13 2020, Nicolas Goaziou wrote:
>> denis.maier.li...@mailbox.org writ
On Wed, Apr 15 2020, Richard Lawrence wrote:
62 combinations might sound like a lot, but if you want your
cite
commands to be mnemonic, you'll run out of options much more
quickly.
[...]
So, I think the relevant question
is: how many different basic citation types are needed *within a
singl
> Stefan Nobis hat am 13. April 2020 10:33 geschrieben:
>
>
> Nicolas Goaziou writes:
>
> > Alphanumeric suffix provides 62 combinations, which should hopefully
> > be enough for any citation back-end out there (I'm looking at you
> > biblatex). It's not terribly readable, tho, as you point o
On Mon, Apr 13, 2020 at 8:05 AM Gustav Wikström wrote:
> I'm curious. So take this for what it is; I.e. curiosity. What /exactly/ is
> meant with a citation here? Is it a new general concept in Org mode, or is it
> something more narrow, as an extension for some specific third party
> software
Joost Kremers ; emacs-orgmode@gnu.org;
> András Simonyi ; John Kitchin
>
> Subject: Re: wip-cite status question and feedback
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Note that in CSL processors, the locators are meaningful key-values,
> > bas
Joost Kremers writes:
> I don't think it's necessary to use a dash (or any other character)
> in longer cite commands, though. =citeintext= isn't that much more
> difficult to read than =cite-intext=. (Biblatex does just fine
> without dashes, and there's always camelCase if you're so inclined.)
Sorry, my last message was unreadable. (and possibly sent twice, once from a
wrong account... don't know if this will come through)
> Stefan Nobis hat am 13. April 2020 10:33 geschrieben:
>
>
> Nicolas Goaziou writes:
>
> > Alphanumeric suffix provides 62 combinations, which should hopeful
> > Stefan Nobis hat am 13. April 2020 10:33 geschrieben:
> >
> >
> > Nicolas Goaziou writes:
> >
> > > Alphanumeric suffix provides 62 combinations, which should hopefully
> > > be enough for any citation back-end out there (I'm looking at you
> > > biblatex). It's not terribly readable, tho
1 - 100 of 138 matches
Mail list logo