Re: [O] Config best practices?
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?
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?
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?
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?
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?
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?
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?
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?
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
[O] Config best practices?
Hello all, I'm wondering what people do to keep the configuration of their Org files in order. 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? 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. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
