Re: Abbreviations support
Thanks for the hint! Denis Am 04.06.2022 um 18:11 schrieb John Kitchin: Org-ref supports this for glossaries and acronyms. See https://youtu.be/sebs2vSIEk4 For an overview. On Sat, Jun 4, 2022 at 6:13 AM Timothy wrote: Hi Denis, > Is there support for abbreviations in org-mode? Something like what the acro > package provides for latex, i.e., assemble a list of all used abbreviations, use > a full form when an abbreviation is used for the first time, the abbreviated > form afterwards. If that does not exist: What would be a good way to approach > that? Not directly, but I think you could do something like this as a halfway-house: ┌ │ Blah blah text ABBR │ │ * Abbreviations │ │ - <<>> :: Some abbreviation │ ... └ I’d think there’s scope for a package say “org-abbreviations” which provides acro-like support. Perhaps even support for a central abbreviations file. Hmm, I may think of trying a small MVP for that this weekend. All the best, Timothy -- John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Include LaTeX source and compiled result
Am 09.06.2022 um 09:47 schrieb Fraga, Eric: On Wednesday, 8 Jun 2022 at 21:01, Denis Maier wrote: :exports code works. But the problem with the other options is that the compilation fails. But I cannot tell why. It just tells me "Code block produced no output". This is not surprising as the LaTeX src blocks are expected to be LaTeX body only, not preamble etc. I.e. in your case, just the line that says "This is a test". You may wish to look at org-format-latex-header, org-babel-latex-preamble, org-babel-latex-end-env, ... Exactly, I've found that out by looking at the file in temp. Testing with body only failed as well! I can however manually compile the temporary file. Anyway: This means you cannot switch to using complete files? I was hoping for something like :fragment nil or :complete-doc t How can you diagnose such an issue? You can sometimes find the org babel files created in /tmp. Anything else? I've found those files, but I was wondering whether Emacs could give me some more useful debug infos? (Especially since compiling the temporary files works...) Denis
Abbreviations support
Hi everyone, is there support for abbreviations in org-mode? Something like what the acro package provides for latex, i.e., assemble a list of all used abbreviations, use a full form when an abbreviation is used for the first time, the abbreviated form afterwards. If that does not exist: What would be a good way to approach that? Best, Denis
Re: Org-cite (oc-csl) tip: Filtering bibliography for language
Am 19.12.2022 um 23:20 schrieb András Simonyi: ... I've forgotten to add that another (probably more user friendly) option would be to design and implement some kind of filtering DSL. András On Mon, 19 Dec 2022 at 23:05, András Simonyi wrote: Dear All, On Mon, 19 Dec 2022 at 15:49, Christian Moe wrote: Refinements welcome. I'm especially wondering what would be an elegant way to generalize this for more languages without defining a predicate for each language (given that we cannot pass the language as an additional argument in the print_bibliography line). Thanks for describing this usage! As for the problem of generalizing to more languages, one relatively simple solution would be to allow arbitrary sexps as filters. Then one could write something like #+print_bibliography: :filter (lambda (item) (bibitem-has-language item "en"))) Would this type of extension be helpful? One (not necessarily important) consequence would be that filters of this type would be obviously unusable with the biblatex exporter. best wishes, András I'd say both options are certainly useful. A filtering DSL is surely the more user friendly option, but allowing lambda expressions would probably be quicker to implement, and it would also allow for predicates not anticipated by DSL designers. Best, Denis
Re: wip-cite status question and feedback
Hi,
very good to see these things are getting discussed again. (Back then, I have
been following the citation syntax discussion from a distance rather then
participating actively, so that's my first post here.)
It would be great if Org had a closer integration with a Citeproc. This would
be a huge improvement for those who use Emacs and Org for academic writing.
Anyway, concerning this:
> Speaking of which, I read about the "citation modes", which may be preferred
> over "suppress author". What are these citation modes? How do you combine
> them if "suppress author" is one of the "citation modes".
Bruce has already sent a link to Pandoc's org-mode Reader where you can find
the citation modes. The standard (markdown) implementation can be found here:
https://github.com/jgm/pandoc/blob/f2b337768e95c8903f65e597f7d8cd81938dacc3/src/Text/Pandoc/Readers/Markdown.hs
Anyway, currently there are basically three modes:
- NormalCitation
- SuppressAuthor
- AuthorInText
At the moment, there is no way to combine modes.
A simple markdown sample:
#+BEGIN_SRC
[@doe]
[-@doe]
@doe argues ...
-@doe [23]
#+END_SRC
Gives:
#+BEGIN_EXAMPLE
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix
= [], citationMode = NormalCitation, citationNoteNum = 0, citationHash = 0}]
[Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix
= [], citationMode = SuppressAuthor, citationNoteNum = 0, citationHash = 0}]
[Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix
= [], citationMode = AuthorInText, citationNoteNum = 0, citationHash = 0}] [Str
"@doe"],Space,Str "argues",Space,Str "\8230"]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], citationSuffix
= [Str "23"], citationMode = SuppressAuthor, citationNoteNum = 0, citationHash
= 0}] [Str "@doe",Space,Str "[23]"]]
#+END_EXAMPLE
So:
[@doe] => NormalCitation
[-@doe] => SuppressAuthor
@doe argues ... => AuthorInText
-@doe [23] => SuppressAuthor
I do admit that this last example is a bit pointless, but it shows a point. =>
SuppressAuthor takes precedence over the other modes in both cases.
Depending on CSL's future development there might well be other citations
modes. I personally think there's much to learn from biblatex, but that's a
different debate...
Best,
Denis
Re: wip-cite status question and feedback
Hi, > Let's assume Org implements SuppressAuthor as "-@doe", so far it has: > > | Syntax| Mode| Sample output > | > |---+-+---| > | @doe or [cite:@doe] | AuthorInText| Doe (2020) > | > | -@doe or [cite:-@doe] | AuthorInText + SuppressAuthor | (2020) > | > | [@doe] or [(cite):@doe] | NormalCitation | (Doe, 2020) > | > | [-@doe] or [(cite):-@doe] | NormalCitation + SuppressAuthor | (2020) > | > > So, we could mix suppress author with some other style, although this > seems useless for the time being. > > Current syntax is not great because it is ad-hoc, and not very > future-proof, if new modes appear. Also, the "(cite)" key is a bit > mouthful, "citep" might have been prettier. Anyway, is it complete > enough? Well, that depends on your target. If you aim for CSL than that's already fairly complete. (Even it's more than complete since the current CSL specification only knows normal citations. Suppressing authors is done by calling applications, and AuthorInText is a pandoc-specific addition.) If you aim for biblatex than there's still a long way to go. Concerning "cite", "(cite)", and "citep" 1. In CSL the basic citation depends on the class of the citation style. Citations appear either as parenthetical citations or in notes. It's not a huge deal, but nevertheless... 2. "citep" is much better than "(cite)", but it is also inaccurate as long as CSL is concerned. So, I'd rather suggest something along these lines: cite: => note citation or parenthetical citation => (Doe 2020) citet => narrative cite => Doe (2020) Of course, you might argue that this is too closely tied to CSL. You could also adopt natbib's cite, citet, citep commands, or biblatex's many cite commands... > Also, there is some ambiguity between modes applying reference-wise, > i.e., "suppress author", and modes applying to the whole reference, > i.e., NormalCitation and AuthorInText. > > Therefore, I'm wondering: has the following any meaning? > > [cite: -@doe; @foo] > [(cite): -@doe; @foo] Good question: I think "[(cite): -@doe; @foo]" is absolutely possible. That would be "(2019; Foo 2020)". But what about "[cite: -@doe; @foo]"? That is certainly more complicated. How do you render multiple narrative citations? Best, Denis
Re: wip-cite status question and feedback
> 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. "Doe blah blah {2017}"/"Doe blah blah {[3]}" ->
> > author-in-text+suppress-author command
>
> ... notwithstanding that, I think Nicolas' latest proposed syntax
> would support this anyway.
>
> [citet:-@doe17]
Perhaps that can be used as author-only?
That would be:
[cite: @doe17] => (Doe 2017) [or a footnote, of course.)
[cite: -@doe17] => (2017)
[citet: @doe17] => Doe (2017)
[citet: -@doe17] => Doe
So we have like two basic citation types: One that is part of the narrative,
one where the citation is set off from the main text. Both citations can be
modified with a minus prefix. In one case this leads to "suppress author", in
the other case this means "author only". (Using the same prefix for two
different things can be considered problematic.)
Best,
Denis
Re: wip-cite status question and feedback
Nicolas Goaziou hat am 12. April 2020 17:32 geschrieben: > > > "Bruce D'Arcus" writes: > > > On Sun, Apr 12, 2020 at 10:02 AM Nicolas Goaziou > > wrote: > > >> Yes, and a "t-styled" citation would be: > >> > >> [citet:see;@doe2020;@doe2019] > >> > >> Barring the prefix, the syntax of the citation does not change wrt to > >> "wip-cite" branch. However, this is enough to be slightly incompatible, > >> hence the "wip". > > > > Good; no issues that I see with this at all. > > Great! > > I'll wait a bit for others to comment. If there is no objection, I'll > implement this in "wip-cite" and rebase that branch on top of "master" > for easier testing and feedback. Your proposal looks good to me. Just one question concerning typed citations. citeX is good and concise, but why limit this to only one character? What about allowing something more verbose? Perhaps "cite-intext:" or "cite:intext:"? The simple syntax is great for most cases, but if you want to support some of those not so common biblatex commands, this might be better. What do you think? (I think there's been a discussion about that, but I don't remember the exact details.) Anyway, I think your proposal is a good start, and it can be extended afterwards. Concerning some other open questions, I suggest sticking to what citeproc-org uses: 1. For the bibliography: #+bibliography: something.bib (Could this be a list containing multiple files?) 2. Placing the bibliography with: #+bibliography: here (Ideally, it would be possible to have this multiple times, perhaps with some filters, like printing only the works of a certain author, or with certain keywords, or so. But that's, of course something for later...) 3. Setting the style: #+CSL_STYLE: "some-style.csl" Of course, if you're using biblatex or natbib you'll need another option for that. Best, Denis
Re: wip-cite status question and feedback
> Nicolas Goaziou hat am 13. April 2020 00:19 > geschrieben: > > > Hello, > > denis.maier.li...@mailbox.org writes: > > > Just one question concerning typed citations. citeX is good and > > concise, but why limit this to only one character? > > Because… it is good and concise? ;) > > > What about allowing something more verbose? Perhaps > > "cite-intext:" or "cite:intext:"? > > Note the latter introduces an ambiguity: [cite:see: @doe was right!]. > Fixing it requires two colons in default cite prefix: [cite::@doe]. > I don't think we want this. > > The former doesn't have this bias. Ok, ambiguity is not good. So we need something else. (As in the other message: cite/note or cite-intext?) > > > The simple syntax is great for most cases, but if you want to support > > some of those not so common biblatex commands, this might be better. > > 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 out. > > > What do you think? > > This is a conciseness versus readability problem, not a technical one, > as long as we do not allow too much, from a parser point of view. > > I have no strong opinion on the topic. It would be more valuable to hear > from actual citations users. What would they prefer? What about allowing both, just like most command line tools have short and long options (e.g., -o and --open)? Best, Denis
Re: wip-cite status question and feedback
> > 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 out. > > > > I second that. Some of the many BibLaTeX commands are due to > > compatibility with other (older) packages and to ease transitions. > > > > Another aspect: Maybe it would be a good idea to reserve some chars > > (e.g. the numeric ones) for user defined citation commands (a > > minimalistic reserved namespace). > > My main concern is not so much the sheer number of available commands. I am > just not sure if something like [cite6: @doe] will increase readability. > (Will you remember what that is supposed to mean?) Also: With biblatex you > have \nocite and \notecite, which one will be [citen: @doe]? I guess here I'd > use citen for the more common option (nocite), but there still could be the > need for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. > Again, a set of simple commands cite, citet, and perhaps a few others might a > good starting point, but I am not sure if that is enough in the long run. (I > currently use mainly CSL so I don't have much need for them myself, but I > think extensability might become an issue at some point.) Also, some might > prefer to have more verbose commands. > > By the way, I think you should add a nocite version to your proposal. (citen, > citeno or something similar.) > > Concerning the fallback idea (citep being equal to cite if citep is not > defined by a backend.) That's really good, but perhaps there should be a way > to customize the fallback rules? Like a certain citex should be treated as > cite, while citey is equal to citet... > WDYT? > > > > [Placing bibliography with "#+bibliography: here"] > > > It is smart, but I'm not sure I like using the same keyword for two > > > different things. OTOH, I don't have a better idea. > > > > I personally also dislike one keyword for completely different > > purposes. Therefore I suggest to take the idea from BibLaTeX and use a > > keyword like "printbibliography" the mark the place where the > > bibliography should be output. > > Ok, fair enough. > So: > #+BIBLIOGRAPHY: file1.bib > #+BIBLIOGRAPHY: file2.bib > [Rest of file] > > #+PRINTBIBLIOGRAPHY > > Or perhaps: > > #+BIBLIOGRAPHYFILE: file1.bib > #+BIBLIOGRAPHYFILE: file2.bib > [Rest of file] > > #+BIBLIOGRAPHY > > But ultimately, each will be fine. I don't think that matters much... > > > This command may also have parameters like filtering options (maybe > > depending on the backend processor; I only know BibLaTeX so I can't > > say if it would be easy to abstract away differences between different > > engines). In the case of BiBLaTeX the printbibliography command > > optionally accepts multiple key-value parameters. Some examples for > > the keys are "heading" for the chapter/section heading, "type" to > > output/print only entries of a certain type (like "book"; or type > > "online" and with the additional key "nottype" separate non-online and > > online sources), "keyword" to filter entries with the associated > > keyword etc. > > Yes, biblatex is very powerful here, and much ahead of other solutions. > Pandoc has some support for multiple bibliographies, but it's nowhere as > advanced. So offering something here would be great, but the question is how > this can be done in a output agnostic way. > > > [Style selection] > > > I think this part is out of Org's scope. Since values between > > > various citation back-ends are probably not compatible, e.g., some > > > may require a file, others a style name, normalization is not useful > > > here. They can use whatever keyword they fancy. > > > > Yes, I second that. But it may be worth thinking a second about using > > one Org document to generate output with different backends (e.g. PDF > > via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have > > some way to configure each citation engine form the same document. > > Either use different keywords like "#+CSL_STYLE" and > > "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style" > > parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to > > translate its value individually for each engine - e.g. an alist or > > some function provided by the user. And if no translation is provided, > > just give the value verbatim to the engine, thus if a user only > > targets a single backend, he does not need to provide any > > extra configuration. > > These are very good questions. Looking again at pandoc: There you have two > options: > a) use pandoc-citeproc to produce the citations for each target format > b) use a native bibliographic tool (e.g. biblatex or natbib in latex output). > > Option b) is clearly more powerful as you can use > But option a) can be
Re: wip-cite status question and feedback
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 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 out. > > I second that. Some of the many BibLaTeX commands are due to > compatibility with other (older) packages and to ease transitions. > > Another aspect: Maybe it would be a good idea to reserve some chars > (e.g. the numeric ones) for user defined citation commands (a > minimalistic reserved namespace). My main concern is not so much the sheer number of available commands. I am just not sure if something like [cite6: @doe] will increase readability. (Will you remember what that is supposed to mean?) Also: With biblatex you have \nocite and \notecite, which one will be [citen: @doe]? I guess here I'd use citen for the more common option (nocite), but there still could be the need for a notecite version. Perhaps [cite-note: @doe] or [cite/note: @doe]. Again, a set of simple commands cite, citet, and perhaps a few others might a good starting point, but I am not sure if that is enough in the long run. (I currently use mainly CSL so I don't have much need for them myself, but I think extensability might become an issue at some point.) Also, some might prefer to have more verbose commands. By the way, I think you should add a nocite version to your proposal. (citen, citeno or something similar.) Concerning the fallback idea (citep being equal to cite if citep is not defined by a backend.) That's really good, but perhaps there should be a way to customize the fallback rules? Like a certain citex should be treated as cite, while citey is equal to citet... WDYT? > [Placing bibliography with "#+bibliography: here"] > > It is smart, but I'm not sure I like using the same keyword for two > > different things. OTOH, I don't have a better idea. > > I personally also dislike one keyword for completely different > purposes. Therefore I suggest to take the idea from BibLaTeX and use a > keyword like "printbibliography" the mark the place where the > bibliography should be output. Ok, fair enough. So: #+BIBLIOGRAPHY: file1.bib #+BIBLIOGRAPHY: file2.bib [Rest of file] #+PRINTBIBLIOGRAPHY Or perhaps: #+BIBLIOGRAPHYFILE: file1.bib #+BIBLIOGRAPHYFILE: file2.bib [Rest of file] #+BIBLIOGRAPHY But ultimately, each will be fine. I don't think that matters much... > This command may also have parameters like filtering options (maybe > depending on the backend processor; I only know BibLaTeX so I can't > say if it would be easy to abstract away differences between different > engines). In the case of BiBLaTeX the printbibliography command > optionally accepts multiple key-value parameters. Some examples for > the keys are "heading" for the chapter/section heading, "type" to > output/print only entries of a certain type (like "book"; or type > "online" and with the additional key "nottype" separate non-online and > online sources), "keyword" to filter entries with the associated > keyword etc. Yes, biblatex is very powerful here, and much ahead of other solutions. Pandoc has some support for multiple bibliographies, but it's nowhere as advanced. So offering something here would be great, but the question is how this can be done in a output agnostic way. > [Style selection] > > I think this part is out of Org's scope. Since values between > > various citation back-ends are probably not compatible, e.g., some > > may require a file, others a style name, normalization is not useful > > here. They can use whatever keyword they fancy. > > Yes, I second that. But it may be worth thinking a second about using > one Org document to generate output with different backends (e.g. PDF > via LaTeX and BibLaTeX, HTML, and ASCII). It would be nice, to have > some way to configure each citation engine form the same document. > Either use different keywords like "#+CSL_STYLE" and > "#+BIBLATEX_STYLE" or we use your original suggestion of a ":style" > parameter to the "#+BIBLIOGRAPHY" keyword and provide some means to > translate its value individually for each engine - e.g. an alist or > some function provided by the user. And if no translation is provided, > just give the value verbatim to the engine, thus if a user only > targets a single backend, he does not need to provide any > extra configuration. These are very good questions. Looking again at pandoc: There you have two options: a) use pandoc-citeproc to produce the citations for each target format b) use a native bibliographic tool (e.g. biblatex or natbib in latex output). Option b) is clearly more powerful as you can use But option a) can be used if you need the same output in DOCX, HTML and PDF. (Say you have an
