Re: Abbreviations support

2022-06-06 Thread Denis Maier

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

2022-06-09 Thread Denis Maier




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

2022-06-03 Thread Denis Maier

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

2022-12-20 Thread Denis Maier

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

2020-04-10 Thread denis . maier . lists
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

2020-04-11 Thread denis . maier . lists
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

2020-04-18 Thread denis . maier . lists
> 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

2020-04-12 Thread denis . maier . lists
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

2020-04-13 Thread denis . maier . lists
> 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

2020-04-13 Thread denis . maier . lists
> > 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

2020-04-13 Thread denis . maier . lists
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 

<    1   2