[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-cite status question and feedback
From: |
Nicolas Goaziou |
Subject: |
Re: wip-cite status question and feedback |
Date: |
Wed, 08 Apr 2020 11:32:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello,
"Bruce D'Arcus" <address@hidden> writes:
> Note that in CSL processors, the locators are meaningful key-values,
> basically; not plain text strings.
OK, but it is enough for Org to feed a CSL processor with, e.g.,
key -> "@doe99"
prefix -> "see "
suffix -> ", pp. 33-35"
Then CSL processor does its job to extract whatever information it
needs. Am I right?
> While I of course can't speak for John, I would hope and expect org
> ref to support the new syntax.
>
> I would hope and expect the same of other packages (like ebib) that
> use their own custom syntax.
I hope so, too. But it would help if developers could chime in and tell
what API Org should provide. This is particularly important since Org
will only provide the API, without any specialized implementation. More
on this at the end of the message.
> 1. just have a super simple citation export formatter, with (per
> above) room to configure an external one
Sure. Org should provide default export for citations in LaTeX, ASCII,
HTML, Texinfo and ODT. Suggestions are more than welcome.
> 2. while I don't know its status, include citeproc-org in org and
> emacs
I think citeproc-el should ship with Emacs, but I cannot speak for
Emacs; it would be nice to ask Emacs developers about it.
> I'd say if citeproc-org is far along and free of substantial bugs, 2
> might make sense. I am, of course, biased, but CSL's been widely
> deployed in the wild for more than a decade, and there are thousands
> of available styles.
>
> Otherwise, and more likely, 1 would be the best path; users get basic
> output formatting for citations, but then can plug in more elaborate
> tools (citeproc-org, citeproc-hs*, etc.) if they need them.
Option 2 makes a lot of sense if citeproc-el is integrated with Emacs.
Until them, I agree that option 1 is the way to go at the moment.
> WDY about that?
Sounds like a plan. Let me summarize it a bit :
1. [ ] Finalize Org citation syntax. It is mostly good, but we need to
decide about the following points:
- [ ] Should it include both "(cite):" and "cite:", i.e., does it
make sense to provide a (very limited) style specification piece
wise?
- [ ] Should it include /global/ prefix and suffix?
- [ ] Should we keep the short specification, i.e., "[@key]"?
- [ ] What kind of markup do we allow in a citation? At the moment
the exhaustive list is: bold, code, entity, italic, latex-fragment,
strike-through, subscript, superscript, underline, verbatim and
line breaks.
2. [ ] Decide about API Org should provide for it to be useful. Here are
some low hanging fruits:
- [ ] List all ".bib" files associated to the document,
- [ ] List all citations,
- [ ] Return citation key at point, if any.
- Anything else?
Moreover, we need to decide about how external processors could plug
into the export framework.
- [ ] For example, it could be a simple variable bound to a list of
functions. Each function accepts three arguments: the export
back-end, as a symbol, the full citation, as a list of triplets
(key, prefix, suffix) along with global prefix/suffix, and the
usual INFO communication channel. Does it need more?
- [ ] Also, the prefix/suffix may contain some Org markup, so this
needs to be also processed. Should it happen before, or after the
external processor does its job? I.e., should the function
translate into Org or target format?
3. [ ] Specify the kind of basic translation that be done out of the
box? Ideally, every non-derived back-end should do something, even
basic. Therefore, we need to propose some translation pattern for
each of the following:
- [ ] ASCII
- [ ] HTML
- [ ] LaTeX
- [ ] ODT
- [ ] Texinfo
4. Anything else?
We need help, or at least opinion, from actual implementors to go
further. I'm CC'ing some of them.
I can take care of the implementation (with some time, my plate is full
at the moment), but I'm mostly incompetent about design issues.
So, what about ticking off some items?
Regards,
--
Nicolas Goaziou
- wip-cite status question and feedback, Bruce D'Arcus, 2020/04/07
- Re: wip-cite status question and feedback, Albert Krewinkel, 2020/04/09
- Re: wip-cite status question and feedback, Bruce D'Arcus, 2020/04/09
- Re: wip-cite status question and feedback, Bruce D'Arcus, 2020/04/09
- Re: wip-cite status question and feedback, Bruce D'Arcus, 2020/04/09
- Re: wip-cite status question and feedback, Nicolas Goaziou, 2020/04/09
- Re: wip-cite status question and feedback, Bruce D'Arcus, 2020/04/09
- Re: wip-cite status question and feedback, Albert Krewinkel, 2020/04/10