Re: wip-cite status question and feedback

[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

[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 

Re: wip-cite status question and feedback

[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

[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

[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

[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

[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

[O] Problem With org-collector.el

[lists]

Just recently I have been getting an error with Eric Schulte's very 
useful org-collector.el. The problem happens with (require 'org-table)


The error is

Symbols value as variable is void: org-enable-table-editor

I presume that this symbol has been removed, or renamed. Can anyone give 
me an idea of how I might fix it?


I am running the latest master.

Ian.

Re: [O] Orgmode repeater intervals with end date

[lists]

On 2018-01-10 18:24, ed...@openmail.cc wrote:

Message: 8
Date: Tue, 09 Jan 2018 22:16:56 -0700
From: torys.ander...@gmail.com (Tory S. Anderson)
To: orgmode list 
Subject: [O] Orgmode repeater intervals with end date
Message-ID: <87incamgxj@byu.edu>
Content-Type: text/plain; format=flowed

Hi all,

When repeater intervals are set on on org dates (eg =<2018-01-10
Wed 16:00 +2w>=) 
the output is exported nicely to ical and appears

nicely in agenda. Is there anyway to put an end-date on org dates
so that the +2w will not just continue forever?

I could use org-class, but then it wouldn't be exported to ical
nicely. I was hopefully with <2018-01-10 Wed 16:00
+2w>--<2018-04-10 Wed 16:00 +2w> but this just put the range as
counting every day in the interim. Is there an existing way to
have an end-date on a repeating cycle?

- Tory


Have you tried with DEADLINE:? I seem to remember to have read
something like that somewhere. Don't trust me. If it helps, I am glad,
but I am not sure.



Have a look at 
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sexp-Diary-Entries.html 
However, I am not sure if you can use an Emacs sexp to specify an end 
date.


Ian.

Re: [O] Git repository error

[lists]

On 2017-12-20 17:14, swfl...@flintfam.org wrote:


I'm still having this problem

CB> -- Colin Baxter m43...@yandex.com
CB> 
-

CB> GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5
CB> 41C8
CB> 
-
CB> The sole cause of all human misery is the inability of people 
to

CB> sit quietly in their rooms.  Blaise Pascal, 1670


Same here:

dell src/org-mode ‹master› » git pull -v 
 
1 ↵

Looking up orgmode.org ... done.
Connecting to orgmode.org (port 9418) ... 104.239.132.130 done.
fatal: read error: Connection reset by peer


Ian.

Re: [O] Using Book class without 'parts' for Org-mode Export

[lists]

On 2017-08-16 18:02, R Jain wrote:

Hi Ian,

Thanks for the reply. The part which I'm tripping over is:

#+latex: \chapterauthor{by Mike Anderson}

(add-to-list 'org-latex-classes
  '("koma-book"
 "\\documentclass{scrbook}"
 ("\\chapter{%s}" . "\\chapter{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 )
 )

Where should I add this definition?



I have it in my init file in ~/.emacs.d. I use babel to tangle the file.

Ian.

Re: [O] Using Book class without 'parts' for Org-mode Export

[lists]

On 2017-08-16 14:44, R Jain wrote:

Hi Everyone,

My question is about using Org-mode Export to Latex, but starting with
Chapter, then Section, and so on.

I found a solution on Stackexchange [1] but when I add that code to my
init file, restart emacs, and add "#+LaTeX_CLASS: book_noparts" to my
org file,  it apparently doesn't get read. The exported .tex is an
itemized list.

Any help with what I'm doing wrong would be great help. Also, if
there's a better way to make custom class files within the org-file
I'm working on, please do let me know.

Thanks,
RJ

Links:
--
[1]
https://n1.nylas.com/link/7e7b7fc5c641bf88e42b688f208d6c1b7782ff4f8c6d4b77bb3d2eacf574a234/0?redirect=https%3A%2F%2Femacs.stackexchange.com%2Fquestions%2F33318%2Fexport-org-mode-subtrees-at-chapter-level-for-latex


Here is my setup using the koma-book class. This uses H1 as the chapter 
title. A typical chapter starts with:


** The Clubroom Project
#+latex: \chapterauthor{by Mike Anderson}


(add-to-list 'org-latex-classes
  '("koma-book"
 "\\documentclass{scrbook}"
 ("\\chapter{%s}" . "\\chapter{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\subsection{%s}" . "\\subsection*{%s}")
 ("\\paragraph{%s}" . "\\paragraph*{%s}")
 )
)


In the file to be exported:

#+latex_class: koma-book
#+LATEX_CLASS_OPTIONS: [a5paper,openany,font 10pt]
#+latex_header: \makeatletter
#+latex_header: \newcommand{\chapterauthor}[1]{%
#+latex_header:   {\parindent0pt\vspace*{-5pt}%
#+latex_header:   \linespread{1.1}\large\scshape#1%
#+latex_header:   \par\nobreak\vspace*{35pt}}
#+latex_header:   \@afterheading%
#+latex_header: }
#+latex_header: \makeatother
#+latex_header: \graphicspath{{../../images/}}
#+latex_header: \usepackage{hyperref}
#+latex_header: \usepackage{pdfpages}
#+latex_header: \hypersetup{
#+latex_header: colorlinks,
#+latex_header: citecolor=black,
#+latex_header: filecolor=black,
#+latex_header: linkcolor=blue,
#+latex_header: urlcolor=black
#+latex_header: }
#+latex_header: \KOMAoptions{twoside=false}
#+latex_header: \usepackage{adjustbox}

The first chapter has:

#+latex: 
\includepdf{/home/ian/Documents/emacs/thecastle/images/frontcover.pdf}

#+latex: \setcounter{tocdepth}{2}
#+latex: \tableofcontents

This sets the TOC depthand adds the TOC at the start of the first 
chapter.


Hope that helps.

Ian.

[O] Bug? Setting #+OPTIONS: title:nil Seems to Be Ignored in HTML Export.

[lists]

I don't know if this is intended behaviour or not.

Save the following as setuop.org

#+BEGIN_SRC

:SETUP:
#+LANGUAGE:  en
#+DRAWERS: SETUP NOTES PROPERTIES
#+OPTIONS: author:nil date:nil d:nil title:nil ':t tex:t
#+STARTUP: content indent

:END:

#+END_SRC

Now include setup.org in test.org

#+BEGIN_SRC

#+SETUPFILE: ./setup.org
#+TITLE: A Three Second Route.
* A Three Second Route.
Some text.


#+END_SRC

Exporting as html result in:

#+BEGIN_SRC html


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="en" xml:lang="en">




A Three Second Route.

#+END_SRC

Note that TITLE is exported.

Using org-master bb6e40b08655cc2f33bdf6f9

Ian.

Re: [O] org to static site?

[lists]

On 2017-05-31 16:00, Matt Price wrote:

I'm trying to wean myself off of Wordpress for next year's teaching
websites, and am wondering what solutions other people are using for
turning a collection of org pages and/or subtrees into a static html
site. I am leaning towards Hugo but honestly not for any sensible
reason; I've seen other people use Jekyll, though the fact that Github
doesn't support direct conversion from org-mode removes some of
Jekyll's appeal; and I know there are a number of other solutions too.




I have been using Pelican https://pelican.readthedocs.io/en/3.0/ for a 
while. It's written in Python and has a plugin which supports org-mode, 
or you can use markdown by exporting your content from org-mode. I have 
used it to publish a web version of a book, which is also available in 
pdf. All done from org-mode.


The html version is at: http://thecastle.github.io/thecastle/

The github repo is at: https://github.com/thecastle/thecastle

Ian.

[O] Possible Bug in Capture.

[lists]

I have just switched from maint to master and now get the following 
error capturing to a date tree:


#+begin_src emacs-lisp
Debugger entered--Lisp error: (error "Invalid capture target 
specification: (file+datetree 
\"~/Documents/emacs/org/org_files/tasks/notes.org\" \"Notes.\")")
  signal(error ("Invalid capture target specification: (file+datetree 
\"~/Documents/emacs/org/org_files/tasks/notes.org\" \"Notes.\")"))
  error("Invalid capture target specification: %S" (file+datetree 
"~/Documents/emacs/org/org_files/tasks/notes.org" "Notes."))

  org-capture-set-target-location()
  org-capture(nil)
  call-interactively(org-capture nil nil)
  command-execute(org-capture)

#+end_src

This is my capture template:

("n" "Notes" entry (file+datetree
 "~/Documents/emacs/org/org_files/tasks/notes.org" "Notes.") "* %U %? 
:note:refile:" :prepend t)


This appears to have been introduced in:

commit 958eacdf2294b4edd6aa797d57d4c36ada682089
Author: Nicolas Goaziou 
Date:   Sun Nov 6 09:29:09 2016 +0100

org-capture: Small refactoring

* lisp/org-capture.el (org-capture-set-target-location): Refactor 
using

  pattern-matching for clarity.

Ian.

Re: [O] Capture template to capture in current buffer

[lists]

On 2016-11-10 11:35, Rainer M Krug wrote:

Hi

I am trying to get an in-buffer logging to work. I want to log some
changes in the file and I am using the following template, which was
working some (longer?) time ago:

--8<---cut here---start->8---
(setq org-capture-templates
  `(
;; ::
;; In File Logging ::
;; ::
("c"   "Changes to be logged in buffer"
 entry   (file+headline (buffer-file-name) "CHANGES Log")
 "* %^{Header of CHANGES item}\nLOGGED: %T \n- link :: %a
\n- author   :: Rainer M Krug, email: rai...@krugs.de\n %?")
))
--8<---cut here---end--->8---

But now I get the following error message when using the capture
template:

,
| if: Target buffer ".notes" for file+headline should be in Org mode
`

I had a similar problem. Have a look at: 
https://www.reddit.com/r/emacs/comments/5b3mtr/orgmode_capture_template_issue_after_updating_to/


I fixed my problem by:

("c"
   "New blog post (cycling.ianbarton.net)"
   plain
   (file (lambda() (capture-pelican-draft-file  
"~/Documents/emacs/web_sites/cycling.ianbarton.net/org/_posts")))
   "#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED: 
\n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY 
\n")


capture-pelican-draft-file is a function that gets the file name.

So

  entry   (file+headline (lambda() buffer-file-name)) "CHANGES 
Log")

  "* %^{Header of CHANGES item}\nLOGGED: %T \n- link :: %a
 \n- author   :: Rainer M Krug, email: rai...@krugs.de\n %?")

may fix your problem (not tested).

Ian.

Re: [O] Capture Bug?

[lists]

On 2016-09-21 12:54, Adam Porter wrote:

li...@wilkesley.net writes:


I have a capture template which prompts for a file name and uses this
to create a filename with a datestamp:

(defun capture-pelican-draft-file (path)
  (let ((name (read-string "Name: ")))
(expand-file-name (format "%s-%s.org"
  (format-time-string "%Y-%m-%d")
  name) path)))


("g"
   "New blog post (ianbarton.net)"
   plain
   (file (capture-pelican-draft-file
"~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
   "#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED:
\n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY
\n#+SETUPFILE: ../setup.org\n\n")


Are you using custom-set-variables to set org-capture-templates?  If
not, I think you need to unquote capture-pelican-draft-file.


On the current git master the function capture-pelican-draft-file

doesn't seem to be evaluated, resulting in a "File name doesn't exist"
error. Doing git bisect seems to point at the commit below:

8860c92f62dac87267416708e81bc8aec026fcc7 is the first bad commit
commit 8860c92f62dac87267416708e81bc8aec026fcc7
Author: Nicolas Goaziou 
Date:   Fri Jun 24 00:55:03 2016 +0200


That commit is about org-babel, which I don't think should have 
anything

to do with org-capture.  But you said you bisected it, so you mean that
before that commit, your code works as-is?


Thanks, I'll redo my bisect. I was being harassed by the dog, so might 
have made a mistake! However, the previous commit looks as though it 
might have been the one responsible:


commit 5485170263a46fa17db67b0324c4c4e48bcdfe49
Author: Nicolas Goaziou 
Date:   Fri Jun 24 01:11:49 2016 +0200

org-capture: Remove forbidden value type from "file" templates

I'll try unquoting capture-pelican-draft-file.

Ian.

[O] Capture Bug?

[lists]

I have a capture template which prompts for a file name and uses this to 
create a filename with a datestamp:


(defun capture-pelican-draft-file (path)
  (let ((name (read-string "Name: ")))
(expand-file-name (format "%s-%s.org"
  (format-time-string "%Y-%m-%d")
  name) path)))


("g"
   "New blog post (ianbarton.net)"
   plain
   (file (capture-pelican-draft-file  
"~/Documents/emacs/web_sites/ianbarton.net/org/_posts"))
   "#+AUTHOR: Ian Barton\n#+DATE: %u\n#+PROPERTY: MODIFIED: 
\n#+TITLE\n#+CATEGORY: Blog \n#+PROPERTY: TAGS \n#+PROPERTY: SUMMARY 
\n#+SETUPFILE: ../setup.org\n\n")



On the current git master the function capture-pelican-draft-file 
doesn't seem to be evaluated, resulting in a "File name doesn't exist" 
error. Doing git bisect seems to point at the commit below:


8860c92f62dac87267416708e81bc8aec026fcc7 is the first bad commit
commit 8860c92f62dac87267416708e81bc8aec026fcc7
Author: Nicolas Goaziou 
Date:   Fri Jun 24 00:55:03 2016 +0200

ob-exp: Small fix

* lisp/ob-exp.el (org-babel-exp-src-block): Use `symbol-name' 
instead of

  `eval' since the argument is a dynamically scoped variable anyhow.

Ian.

[O] Exporting to LaTeX Ignores Title Option in #+Options:.

[lists]

I have a bunch of org-files that I want to export. They  all have a 
#+TITLE: but I don't want the Title to appear in the exported code.


If I export the following minimal file:

#+TITLE: My Title.
#+AUTHOR: Ian Barton.
#+STARTUP: content indent
#+DATE: [2016-06-18 Sat 07:43]
#+OPTIONS:  title:nil

I get the following output:

\author{Ian Barton.}
\date{\textit{[2016-06-18 Sat 07:43]}}
\title{My Title.}


I thought that setting title:nil in #+Options: suppressed export of the 
title. Is this expected behaviour with LaTeX?


Ian.

Re: [O] State of the art in citations

[Vikas Rawal Lists]

On 26-Apr-2014, at 6:56 pm, Clément B. clem...@inventati.org wrote:

 Hi all,
 
 - Should I use biblatex instead of bibtex?  
 
 You should. It is very powerful and straightforward. The manual
 is great.
 

Is the choice so clearcut?

A lot of bibliographic databases  provide bibtex-compatible citation 
information. How do you deal with that, when you shift to biblatex?

Of course, this is not an org-mode specific limitation at all. But still 
relevant, I think, when we are discussing what should be the recommended way of 
dealing with citations in org-mode.

Vikas

Re: [O] State of the art in citations

[Vikas Rawal Lists]

 Hi all,
 
 - Should I use biblatex instead of bibtex?  
 
 You should. It is very powerful and straightforward. The manual
 is great.
 


ox-bibtex provides a usable implementation of including bibtex citations in 
html export. Can this be done if using biblatex?

Vikas