Re: [O] Config best practices?

2015-03-21 Thread Marcin Borkowski

On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote:

 Yes, but why do you do that? What are you trying to accomplish? What
 does keeping the configuration in order mean?

I have that org-one-to-many utility, which splits the Org file at
(selected) headings, effectively making them separate Org files.  If
I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords
in that file, it makes sense to put the same configs in the files split
from the main one.  Putting them into their own headline may be the
simplest way to tell org-one-to-many what to copy to each generated
file.

I don't like putting them at the top; while #+TITLE or #+AUTHOR do make
sense there (and don't in the split files!), cluttering the first few
screens with e.g. LaTeX definitions is not my favorite way of using
Org-mode.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Re: [O] Config best practices?

2015-03-21 Thread Sebastien Vauban
Nick Dokos wrote:
 Marcin Borkowski mb...@wmi.amu.edu.pl writes:
 On 2015-03-20, at 10:07, Sebastien Vauban sva-n...@mygooglest.com wrote:
 Marcin Borkowski wrote:
 I'm wondering what people do to keep the configuration of their Org
 files in order.

 I'm not sure to correctly grasp your objective.  Could you restate it?

 Sure.

 Where do you put things like

 #+OPTIONS: toc:nil

 or

 #+SEQ_TODO: TODO | DONE

 or

 #+LATEX_HEADER: \newcommand{\eps}{\varepsilon}

 ?

 I use a dedicated top-level headline, with a COMMENT keyword, but
 I started to think that a :noexport: tag might be a better idea.

 Are there any advantages of one over the other, or other approaches
 altogether?

 I can tell you they aren't isomorphic...  The noexport tag simply says
 don't export this subtree.  The COMMENT keyword adds don't run any
 Babel code block in there.

 COMMENT also says that the whole subtree is not to be exported according
 to the doc:

(info (org) Comment lines)

 Has that changed?

Nope, it hasn't: I wrote that COMMENT *adds* don't run any code to
don't export this subtree either. So, we're both on the same
frequency.

 So I guess that – since the lines with options etc. are not exported
 anyway – that using a :noexport: tag might be a better idea.  Am I right?

 The reason I'm asking is that I'm tweaking my org-one-to-many utility
 so that it propagates the config to all the generated files.

 Still not that clear to me.  Maybe an ECM would clarify your request?

 As you wish.  This is what I usually do.

 * Headline
 * Another one
 ** Subheadline
 * COMMENT Config
 #+LATEX_HEADER: \newcommand{\eps}{\varepsilon}
 #+SEQ_TODO: TODO | DONE CANCEL
 #+OPTIONS: toc:nil

 Yes, but why do you do that? What are you trying to accomplish? What
 does keeping the configuration in order mean?

+1

 I sometimes use a Setup heading marked with COMMENT, so it does not get
 exported.  I never put babel stuff in there so I haven't worried about
 that, but if Seb is correct that it prevents babel from evaluating
 things in the subtree, that's a bonus. If you are just trying to
 (mostly) hide it from view, add an :ARCHIVE: tag to the heading.
 But most of the time I have them at the top of the file in plain view.

+1.

Sometimes, I also have a Setup section at the top, with a :ARCHIVE:
tag so that it does not expand when cycling view states (via S-TAB).

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Config best practices?

2015-03-21 Thread Sebastien Vauban
Marcin Borkowski wrote:
 On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote:

 Yes, but why do you do that? What are you trying to accomplish? What
 does keeping the configuration in order mean?

 I have that org-one-to-many utility, which splits the Org file at
 (selected) headings, effectively making them separate Org files.  If
 I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords
 in that file, it makes sense to put the same configs in the files split
 from the main one.  Putting them into their own headline may be the
 simplest way to tell org-one-to-many what to copy to each generated
 file.

 I don't like putting them at the top; while #+TITLE or #+AUTHOR do make
 sense there (and don't in the split files!), cluttering the first few
 screens with e.g. LaTeX definitions is not my favorite way of using
 Org-mode.

As I wrote, you could choose for an ARCHIVE'd heading (one that's
always collapsed) or for a SETUPFILE?

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Config best practices?

2015-03-21 Thread Nick Dokos
Sebastien Vauban sva-n...@mygooglest.com
writes:

 I can tell you they aren't isomorphic...  The noexport tag simply says
 don't export this subtree.  The COMMENT keyword adds don't run any
 Babel code block in there.

 COMMENT also says that the whole subtree is not to be exported according
 to the doc:

(info (org) Comment lines)

 Has that changed?

 Nope, it hasn't: I wrote that COMMENT *adds* don't run any code to
 don't export this subtree either. So, we're both on the same
 frequency.


Ah, sorry: I misunderstood.

-- 
Nick




Re: [O] Config best practices?

2015-03-21 Thread Nick Dokos
Sebastien Vauban sva-n...@mygooglest.com
writes:

 Marcin Borkowski wrote:
 On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote:

 Yes, but why do you do that? What are you trying to accomplish? What
 does keeping the configuration in order mean?

 I have that org-one-to-many utility, which splits the Org file at
 (selected) headings, effectively making them separate Org files.  If
 I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords
 in that file, it makes sense to put the same configs in the files split
 from the main one.  Putting them into their own headline may be the
 simplest way to tell org-one-to-many what to copy to each generated
 file.

 I don't like putting them at the top; while #+TITLE or #+AUTHOR do make
 sense there (and don't in the split files!), cluttering the first few
 screens with e.g. LaTeX definitions is not my favorite way of using
 Org-mode.

 As I wrote, you could choose for an ARCHIVE'd heading (one that's
 always collapsed) or for a SETUPFILE?


The SETUPFILE sounds to me like the best solution, assuming that the
different files are sharing configuration.

-- 
Nick




Re: [O] Config best practices?

2015-03-20 Thread Sebastien Vauban
Hello Marcin,

Marcin Borkowski wrote:
 I'm wondering what people do to keep the configuration of their Org
 files in order.

I'm not sure to correctly grasp your objective.  Could you restate it?

 I use a dedicated top-level headline, with a COMMENT keyword, but
 I started to think that a :noexport: tag might be a better idea.

 Are there any advantages of one over the other, or other approaches
 altogether?

I can tell you they aren't isomorphic...  The noexport tag simply says
don't export this subtree.  The COMMENT keyword adds don't run any
Babel code block in there.

 The reason I'm asking is that I'm tweaking my org-one-to-many utility
 so that it propagates the config to all the generated files.

Still not that clear to me.  Maybe an ECM would clarify your request?

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Config best practices?

2015-03-20 Thread Rasmus
Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 On 2015-03-20, at 10:07, Sebastien Vauban sva-n...@mygooglest.com wrote:

 Hello Marcin,

 Marcin Borkowski wrote:
 I'm wondering what people do to keep the configuration of their Org
 files in order.

I usually have something like

* export options :noexport:
# whatever.

But in e.g. ox-koma-letter I'd just have

* attachments and export options :after-letter:
#+begin_latex
% Enclosure commands
#+end_latex
# whatever

Generally, I try to minimize the number of (i) hacks outside of org-core
(e.g. :ignoreheading:); (ii) number of headings without exported content.

—Rasmus

-- 
And I faced endless streams of vendor-approved Ikea furniture. . .




Re: [O] Config best practices?

2015-03-20 Thread Marcin Borkowski

On 2015-03-20, at 10:07, Sebastien Vauban sva-n...@mygooglest.com wrote:

 Hello Marcin,

 Marcin Borkowski wrote:
 I'm wondering what people do to keep the configuration of their Org
 files in order.

 I'm not sure to correctly grasp your objective.  Could you restate it?

Sure.

Where do you put things like

#+OPTIONS: toc:nil

or

#+SEQ_TODO: TODO | DONE

or

#+LATEX_HEADER: \newcommand{\eps}{\varepsilon}

?

 I use a dedicated top-level headline, with a COMMENT keyword, but
 I started to think that a :noexport: tag might be a better idea.

 Are there any advantages of one over the other, or other approaches
 altogether?

 I can tell you they aren't isomorphic...  The noexport tag simply says
 don't export this subtree.  The COMMENT keyword adds don't run any
 Babel code block in there.

So I guess that – since the lines with options etc. are not exported
anyway – that using a :noexport: tag might be a better idea.  Am I right?

 The reason I'm asking is that I'm tweaking my org-one-to-many utility
 so that it propagates the config to all the generated files.

 Still not that clear to me.  Maybe an ECM would clarify your request?

As you wish.  This is what I usually do.

--8---cut here---start-8---
* Headline
* Another one
** Subheadline
* COMMENT Config
#+LATEX_HEADER: \newcommand{\eps}{\varepsilon}
#+SEQ_TODO: TODO | DONE CANCEL
#+OPTIONS: toc:nil
--8---cut here---end---8---

 Best regards,
   Seb

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



Re: [O] Config best practices?

2015-03-20 Thread Nick Dokos
Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 On 2015-03-20, at 10:07, Sebastien Vauban sva-n...@mygooglest.com wrote:

 Hello Marcin,

 Marcin Borkowski wrote:
 I'm wondering what people do to keep the configuration of their Org
 files in order.

 I'm not sure to correctly grasp your objective.  Could you restate it?

 Sure.

 Where do you put things like

 #+OPTIONS: toc:nil

 or

 #+SEQ_TODO: TODO | DONE

 or

 #+LATEX_HEADER: \newcommand{\eps}{\varepsilon}

 ?

 I use a dedicated top-level headline, with a COMMENT keyword, but
 I started to think that a :noexport: tag might be a better idea.

 Are there any advantages of one over the other, or other approaches
 altogether?

 I can tell you they aren't isomorphic...  The noexport tag simply says
 don't export this subtree.  The COMMENT keyword adds don't run any
 Babel code block in there.


COMMENT also says that the whole subtree is not to be exported according
to the doc:

   (info (org) Comment lines)

Has that changed?

 So I guess that – since the lines with options etc. are not exported
 anyway – that using a :noexport: tag might be a better idea.  Am I right?

 The reason I'm asking is that I'm tweaking my org-one-to-many utility
 so that it propagates the config to all the generated files.

 Still not that clear to me.  Maybe an ECM would clarify your request?

 As you wish.  This is what I usually do.

 * Headline
 * Another one
 ** Subheadline
 * COMMENT Config
 #+LATEX_HEADER: \newcommand{\eps}{\varepsilon}
 #+SEQ_TODO: TODO | DONE CANCEL
 #+OPTIONS: toc:nil


Yes, but why do you do that? What are you trying to accomplish? What
does keeping the configuration in order mean?

I sometimes use a Setup heading marked with COMMENT, so it does not get
exported.  I never put babel stuff in there so I haven't worried about
that, but if Seb is correct that it prevents babel from evaluating
things in the subtree, that's a bonus. If you are just trying to
(mostly) hide it from view, add an :ARCHIVE: tag to the heading.
But most of the time I have them at the top of the file in plain view.

-- 
Nick