BEGIN_LATEX_HEADER [cont]

BEGIN_LATEX_HEADER [cont]

[Ken Mankoff]

Hi,

I'm following up on a thread suggesting a method to easily include 
large
amounts of LaTeX header material. See
https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00480.html 

Please consider this a +1 for that feature request.

One suggestion was:
> You could have a LaTeX block and tangle it to preamble.tex and 
> input
> preamble.tex in a LATEX_HEADER.

Which seems like an OK work-around. 

I have two follow-up questions about this.

1) I can't seem to get

#+BEGIN_LATEX :tangle preamble.tex

to work. It needs to be

#+BEGIN_SRC latex :tangle preamble.tex

Is this correct?

Secondly, is there a way to automatically tangle one just this 
section
each time I export the file? Or automatically all sections (but 
just in
this file)?

Thanks,

  -k.

Re: BEGIN_LATEX_HEADER [cont]

[Aaron Ecay]

Hi Ken,

2014ko ekainak 19an, Ken Mankoff-ek idatzi zuen:
> 
> Hi,
> 
> I'm following up on a thread suggesting a method to easily include 
> large
> amounts of LaTeX header material. See
> https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00480.html 
> 
> Please consider this a +1 for that feature request.
> 
> One suggestion was:
>> You could have a LaTeX block and tangle it to preamble.tex and 
>> input
>> preamble.tex in a LATEX_HEADER.
> 
> Which seems like an OK work-around. 
> 
> I have two follow-up questions about this.
> 
> 1) I can't seem to get
> 
> #+BEGIN_LATEX :tangle preamble.tex
> 
> to work. It needs to be
> 
> #+BEGIN_SRC latex :tangle preamble.tex

Correct.  The former is only for export, and doesn’t work with babel
features (incl. tangling)

> 
> Is this correct?
> 
> Secondly, is there a way to automatically tangle one just this 
> section
> each time I export the file? Or automatically all sections (but 
> just in
> this file)?

Something like (untested):

,----
| #+begin_src emacs-lisp
|   (org-babel-goto-named-src-block "preamble")
|   (org-babel-tangle)
| #+end_src
| 
| #+name: preamble
| #+begin_src latex :tangle preamble.tex
|   % code goes here
| #+end_src
`----

You’ll need to use some combination of “:exports none” or a headline
tagged :noexport: to avoid these src blocks showing up in the exported
output.

HTH,

-- 
Aaron Ecay

Re: BEGIN_LATEX_HEADER [cont]

[Sebastien Vauban]

Aaron Ecay wrote:
> 2014ko ekainak 19an, Ken Mankoff-ek idatzi zuen:
>> I'm following up on a thread suggesting a method to easily include
>> large amounts of LaTeX header material. See
>> https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00480.html
>> 
>> Is there a way to automatically tangle one just this section each
>> time I export the file? Or automatically all sections (but just in
>> this file)?
>
> Something like (untested):
>
> ,----
> | #+begin_src emacs-lisp
> |   (org-babel-goto-named-src-block "preamble")
> |   (org-babel-tangle)
> | #+end_src
> | 
> | #+name: preamble
> | #+begin_src latex :tangle preamble.tex
> |   % code goes here
> | #+end_src
> `----
>
> You’ll need to use some combination of “:exports none” or a headline
> tagged :noexport: to avoid these src blocks showing up in the exported
> output.

Another solution which would be fine would be to have
‘#+BEGIN_LaTeX_HEADER ... #+END_LaTeX_HEADER’ blocks.

Dunno if easy, however; but it'd be more straightforward for most users
(no need to rely on Babel to tangle first).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: BEGIN_LATEX_HEADER [cont]

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Another solution which would be fine would be to have
> ‘#+BEGIN_LaTeX_HEADER ... #+END_LaTeX_HEADER’ blocks.
>
> Dunno if easy, however; but it'd be more straightforward for most users
> (no need to rely on Babel to tangle first).

I suggest to use existing solutions instead: configure
`org-latex-classes'.


Regards,

-- 
Nicolas Goaziou

Re: BEGIN_LATEX_HEADER [cont]

[Ken Mankoff]

On 2014-06-20 at 04:50, Nicolas Goaziou wrote:
> I suggest to use existing solutions instead: configure
> `org-latex-classes'.

I'm all for using existing solutions, but cannot see how I might use
this to easily customize export differently for different documents when
large amounts of LaTeX preamble code is being used.

The tangle to preamble.tex and then include works but I cannot automate
it as per the example from Aaron. It still works pretty well even if I
do it manually.

  -k.

Re: BEGIN_LATEX_HEADER [cont]

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

2014-06-20 13:17 GMT+02:00 Ken Mankoff <mankoff@gmail.com>:

> On 2014-06-20 at 04:50, Nicolas Goaziou wrote:
> > I suggest to use existing solutions instead: configure
> > `org-latex-classes'.
>
> I'm all for using existing solutions, but cannot see how I might use
> this to easily customize export differently for different documents when
> large amounts of LaTeX preamble code is being used.
>

I for long have defined my own LaTeX class (fp.cls file). It is quite easy
to handle options in there.
Now I use it in place of article or beamer etc.

\documentclass[slides]{fp}

for a beamer org document

\documentclass[exam]{fp}

for a pdf exam document


and so on.

I don't think that it is very effective to store a huge amount of TeX code
in org documents.
You end up in cuting/pasting these headers lines in each line.


My $0.02

Fabrice

[-- Attachment #2: Type: text/html, Size: 1480 bytes --]

Re: BEGIN_LATEX_HEADER [cont]

[Nicolas Goaziou]

Hello,

Ken Mankoff <mankoff@gmail.com> writes:

> On 2014-06-20 at 04:50, Nicolas Goaziou wrote:
>> I suggest to use existing solutions instead: configure
>> `org-latex-classes'.
>
> I'm all for using existing solutions, but cannot see how I might use
> this to easily customize export differently for different documents when
> large amounts of LaTeX preamble code is being used.

It's quite simple. You add your large amount of LaTeX preamble code in
a new class, e.g., "my-class", in `org-latex-classes'. Then, in all
documents needing this preamble code, you just add:

 #+latex_class: my-class

Rinse and repeat for each document type.


Regards,

-- 
Nicolas Goaziou

Re: BEGIN_LATEX_HEADER [cont]

[Aaron Ecay]

Hi Nicolas,

2014ko ekainak 20an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Ken Mankoff <mankoff@gmail.com> writes:
> 
>> On 2014-06-20 at 04:50, Nicolas Goaziou wrote:
>>> I suggest to use existing solutions instead: configure
>>> `org-latex-classes'.
>> 
>> I'm all for using existing solutions, but cannot see how I might use
>> this to easily customize export differently for different documents when
>> large amounts of LaTeX preamble code is being used.
> 
> It's quite simple. You add your large amount of LaTeX preamble code in
> a new class, e.g., "my-class", in `org-latex-classes'. Then, in all
> documents needing this preamble code, you just add:
> 
>  #+latex_class: my-class
> 
> Rinse and repeat for each document type.

There are two issues with this solution.

The first is that editing non-trivial latex code embedded in an elisp
string quickly becomes tedious, whereas it’s much pleasanter in org
using org-edit-special, syntax highlighting of src blocks, etc.

The second is that it’s impossible to share without distributing elisp
code.  From the twin standpoints of reproducible research and security,
I think org ought to maximize the degree to which export use cases are
sharable without resorting to executing elisp code.  There’s a threshold
beyond which it’s impossible to keep these goals, of course.  But it’s
worth considering how org-latex-classes and friends might adapt to
increase the territory that falls within rather than outside the
Turing-complete boundary.

Just my 2 cents,

-- 
Aaron Ecay

Re: BEGIN_LATEX_HEADER [cont]

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> The first is that editing non-trivial latex code embedded in an elisp
> string quickly becomes tedious, whereas it’s much pleasanter in org
> using org-edit-special, syntax highlighting of src blocks, etc.

This is a no-op since you only do it a limited number of times, i.e.
once for each document type.

> The second is that it’s impossible to share without distributing elisp
> code.  From the twin standpoints of reproducible research and security,
> I think org ought to maximize the degree to which export use cases are
> sharable without resorting to executing elisp code.

This is also a no-op. You cannot be serious about reproducible research
if you don't share `org-export-async-init-file' anyway.

Eventually, if you insist on writing your full preamble within the
document, you can start to write it in a LaTeX-mode buffer, copy it in
your Org document and add "#+LATEX_HEADER: " in front of each line.
This last step is done easily with `string-rectangle' (C-x r t).


Regards,

-- 
Nicolas Goaziou

Re: BEGIN_LATEX_HEADER [cont]

[Aaron Ecay]

Hi Nicolas,

2014ko ekainak 21an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> The first is that editing non-trivial latex code embedded in an elisp
>> string quickly becomes tedious, whereas it’s much pleasanter in org
>> using org-edit-special, syntax highlighting of src blocks, etc.
> 
> This is a no-op since you only do it a limited number of times, i.e.
> once for each document type.

If you do it once, then it’s not a no-op, by definition.  I think you
mean that you disagree in the amount which you weight this as a concern,
which is a reasonable opinion to have.  But phrasing it in the way you
did is inaccurate and rather curt.

FWIW, in my experience latex (or any) code rarely flows from mind to
keyboard perfectly in the first attempt; there is some period of
revision, during which convenient editing matters.

> 
>> The second is that it’s impossible to share without distributing elisp
>> code.  From the twin standpoints of reproducible research and security,
>> I think org ought to maximize the degree to which export use cases are
>> sharable without resorting to executing elisp code.
> 
> This is also a no-op. You cannot be serious about reproducible research
> if you don't share `org-export-async-init-file' anyway.

This is also not true (or it’s some kind of value judgment).  Org’s
default settings + #+bind + local variables can do quite a bit.

> 
> Eventually, if you insist on writing your full preamble within the
> document, you can start to write it in a LaTeX-mode buffer, copy it in
> your Org document and add "#+LATEX_HEADER: " in front of each line.
> This last step is done easily with `string-rectangle' (C-x r t).

This is basically making the user do (something like) org-edit-special
manually.  It can probably be automated somewhat – I’ll work on a patch.

Thanks,

-- 
Aaron Ecay

[ANN] ox-extras (was: BEGIN_LATEX_HEADER [cont])

[Aaron Ecay]

2014ko ekainak 21an, Aaron Ecay-ek idatzi zuen:

[...]

>> Eventually, if you insist on writing your full preamble within the
>> document, you can start to write it in a LaTeX-mode buffer, copy it in
>> your Org document and add "#+LATEX_HEADER: " in front of each line.
>> This last step is done easily with `string-rectangle' (C-x r t).
> 
> This is basically making the user do (something like) org-edit-special
> manually.  It can probably be automated somewhat – I’ll work on a
> patch.

This is now implemented in a new library in contrib, ox-extras.  This is
intended as a semi-official, semi-curated repository for helpful pieces of
org export hooks and customizations.  Differently than worg, the aim is to
make it easy for users to load the snippets through the ox-extras-activate
function.  Even so, I hope this will be an “executable wiki” where anyone
(who has commit access to the org repo) is free to contribute new hook
functions and improve existing ones.

In the present case, if you execute

(ox-extras-activate '(latex-header-blocks))

you will be able to use blocks of the following form:

#+header: :header yes
#+begin_latex
  \foo{}
  \bar{}
#+end_latex

These will be transformed so that the begin/end wrapper is removed and
each line is prepended with #+latex_header: on export.  They can be
edited as latex code with the usual org-edit-special function (C-c ').

The #+header: :header yes line is a bit confusing.  The first #+header:
is part of org syntax that allows us to tag blocks (and other elements)
with plists.  The :header yes in the plist indicates that this block
should be treated as a latex_header, and not a normal type of latex
block.

Thanks,

-- 
Aaron Ecay

Re: BEGIN_LATEX_HEADER [cont]

[Ken Mankoff]

On 2014-06-21 at 20:42, Aaron Ecay wrote:
> 2014ko ekainak 21an, Nicolas Goaziou-ek idatzi zuen:
>> 
>> Aaron Ecay <aaronecay@gmail.com> writes:
>> 
>>> The first is that editing non-trivial latex code embedded in an
>>> elisp string quickly becomes tedious, whereas it’s much pleasanter
>>> in org using org-edit-special, syntax highlighting of src blocks,
>>> etc.
>> 
>> This is a no-op since you only do it a limited number of times, i.e.
>> once for each document type.
>
> If you do it once, then it’s not a no-op, by definition.  I think you
> mean that you disagree in the amount which you weight this as a
> concern, which is a reasonable opinion to have.  But phrasing it in
> the way you did is inaccurate and rather curt.
>
> FWIW, in my experience latex (or any) code rarely flows from mind to
> keyboard perfectly in the first attempt; there is some period of
> revision, during which convenient editing matters.

It is not a 1x operation, it is a per-document operation. For example,
in my use-case that started this whole discussion, each publication
requires tweaking a dozen or more lines of biblatex config.

  -k.

Re: BEGIN_LATEX_HEADER [cont]

[Nicolas Goaziou]

Aaron Ecay <aaronecay@gmail.com> writes:

> This is basically making the user do (something like) org-edit-special
> manually.

That is an interesting idea. `org-edit-special' could be improved to
edit clusters of export keywords (e.g. #+LATEX) in a dedicated buffer.

Recognizing a keyword as an export keyword is doable (i.e. iterate over
registered back-ends and check export keywords they define), but finding
the appropriate major-mode for the alternate buffer seems cumbersome. It
could be hard-coded, but that is not very practical. It could also be
decided in the export back-end definition.


Regards,

-- 
Nicolas Goaziou

Re: BEGIN_LATEX_HEADER [cont]

[Nicolas Goaziou]

Ken Mankoff <mankoff@gmail.com> writes:

> It is not a 1x operation, it is a per-document operation. For example,
> in my use-case that started this whole discussion, each publication
> requires tweaking a dozen or more lines of biblatex config.

Of course there are an amount of lines that depends on the document.
This is where #+LATEX keywords comes handy.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] ox-extras

[Rasmus]

Aaron Ecay <aaronecay@gmail.com> writes:

> 2014ko ekainak 21an, Aaron Ecay-ek idatzi zuen:
>
> [...]
>
>>> Eventually, if you insist on writing your full preamble within the
>>> document, you can start to write it in a LaTeX-mode buffer, copy it in
>>> your Org document and add "#+LATEX_HEADER: " in front of each line.
>>> This last step is done easily with `string-rectangle' (C-x r t).
>> 
>> This is basically making the user do (something like) org-edit-special
>> manually.  It can probably be automated somewhat – I’ll work on a
>> patch.
>
> This is now implemented in a new library in contrib, ox-extras.  This is
> intended as a semi-official, semi-curated repository for helpful pieces of
> org export hooks and customizations.  Differently than worg, the aim is to
> make it easy for users to load the snippets through the ox-extras-activate
> function.  Even so, I hope this will be an “executable wiki” where anyone
> (who has commit access to the org repo) is free to contribute new hook
> functions and improve existing ones.
>
> In the present case, if you execute
>
> (ox-extras-activate '(latex-header-blocks))
>
> you will be able to use blocks of the following form:
>
> #+header: :header yes
> #+begin_latex
>
>   \foo{}
>   \bar{}
> #+end_latex
>
> These will be transformed so that the begin/end wrapper is removed and
> each line is prepended with #+latex_header: on export.  They can be
> edited as latex code with the usual org-edit-special function (C-c ').
>
> The #+header: :header yes line is a bit confusing.  The first #+header:
> is part of org syntax that allows us to tag blocks (and other elements)
> with plists.  The :header yes in the plist indicates that this block
> should be treated as a latex_header, and not a normal type of latex
> block.

You did not attach a file and you probably want to make it as s new
message without the ref to the previous thread.

In any case, I don't like the spirit of the exercise:

   This is intended as a semi-official, semi-curated repository for
   helpful pieces of org export hooks and customizations.

If it's helpful (enough) it should be ox.el, I guess, or
ox-ENGINGE.el. . .  Parallel, semi-official extension to ox itself
doesn't sound nice.

But with high probability I'm just lacking the right insights!

—Rasmus

-- 
To err is human. To screw up a 10⁶ times per second, you need a computer

Re: [ANN] ox-extras

[Rasmus]

Rasmus <rasmus@gmx.us> writes:

> Aaron Ecay <aaronecay@gmail.com> writes:
>
>> 2014ko ekainak 21an, Aaron Ecay-ek idatzi zuen:
>>
>> [...]
>>
>>>> Eventually, if you insist on writing your full preamble within the
>>>> document, you can start to write it in a LaTeX-mode buffer, copy it in
>>>> your Org document and add "#+LATEX_HEADER: " in front of each line.
>>>> This last step is done easily with `string-rectangle' (C-x r t).
>>> 
>>> This is basically making the user do (something like) org-edit-special
>>> manually.  It can probably be automated somewhat – I’ll work on a
>>> patch.
>>
>> This is now implemented in a new library in contrib, ox-extras.  This is
>> intended as a semi-official, semi-curated repository for helpful pieces of
>> org export hooks and customizations.  Differently than worg, the aim is to
>> make it easy for users to load the snippets through the ox-extras-activate
>> function.  Even so, I hope this will be an “executable wiki” where anyone
>> (who has commit access to the org repo) is free to contribute new hook
>> functions and improve existing ones.
>>
>> In the present case, if you execute
>>
>> (ox-extras-activate '(latex-header-blocks))
>>
>> you will be able to use blocks of the following form:
>>
>> #+header: :header yes
>> #+begin_latex
>>
>>   \foo{}
>>   \bar{}
>> #+end_latex
>>
>> These will be transformed so that the begin/end wrapper is removed and
>> each line is prepended with #+latex_header: on export.  They can be
>> edited as latex code with the usual org-edit-special function (C-c ').
>>
>> The #+header: :header yes line is a bit confusing.  The first #+header:
>> is part of org syntax that allows us to tag blocks (and other elements)
>> with plists.  The :header yes in the plist indicates that this block
>> should be treated as a latex_header, and not a normal type of latex
>> block.
>
> You did not attach a file and you probably want to make it as s new
> message without the ref to the previous thread.

Sorry, it's in contrib as you said :) My mistake.

-- 
Bang bang

Re: [ANN] ox-extras

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> you will be able to use blocks of the following form:
>
> #+header: :header yes
> #+begin_latex
>   \foo{}
>   \bar{}
> #+end_latex
>
> These will be transformed so that the begin/end wrapper is removed and
> each line is prepended with #+latex_header: on export.  They can be
> edited as latex code with the usual org-edit-special function (C-c ').

Actually that's rather different than the suggestion in this thread,
which was to introduce a new type of block.

This could be implemented in core, but it should use #+attr_latex
instead of #+header since this is latex related.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] ox-extras

[Thomas S. Dye]

Aloha all,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Aaron Ecay <aaronecay@gmail.com> writes:
>
>> you will be able to use blocks of the following form:
>>
>> #+header: :header yes
>> #+begin_latex
>>   \foo{}
>>   \bar{}
>> #+end_latex
>>
>> These will be transformed so that the begin/end wrapper is removed and
>> each line is prepended with #+latex_header: on export.  They can be
>> edited as latex code with the usual org-edit-special function (C-c ').
>
> Actually that's rather different than the suggestion in this thread,
> which was to introduce a new type of block.
>
> This could be implemented in core, but it should use #+attr_latex
> instead of #+header since this is latex related.

+1.  

My use case is the one Ken mentioned earlier--customizing biblatex with
Org mode header lines.  I do this by googling and then experimenting
with the code chunks I discover (I don't want to be a biblatex
programmer).  I format the code chunks now with a keyboard macro, which
works but is more complex than I like.  A construct like the one Aaron
has implemented is handy in this situation.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com