emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Config best practices?
@ 2015-03-20  0:14 Marcin Borkowski
  2015-03-20  9:07 ` Sebastien Vauban
  0 siblings, 1 reply; 10+ messages in thread
From: Marcin Borkowski @ 2015-03-20  0:14 UTC (permalink / raw)
  To: Org-Mode mailing list

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-20  0:14 Config best practices? Marcin Borkowski
@ 2015-03-20  9:07 ` Sebastien Vauban
  2015-03-20 23:18   ` Marcin Borkowski
  0 siblings, 1 reply; 10+ messages in thread
From: Sebastien Vauban @ 2015-03-20  9:07 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-20  9:07 ` Sebastien Vauban
@ 2015-03-20 23:18   ` Marcin Borkowski
  2015-03-20 23:27     ` Rasmus
  2015-03-21  3:05     ` Nick Dokos
  0 siblings, 2 replies; 10+ messages in thread
From: Marcin Borkowski @ 2015-03-20 23:18 UTC (permalink / raw)
  To: emacs-orgmode


On 2015-03-20, at 10:07, Sebastien Vauban <sva-news@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-20 23:18   ` Marcin Borkowski
@ 2015-03-20 23:27     ` Rasmus
  2015-03-21  3:05     ` Nick Dokos
  1 sibling, 0 replies; 10+ messages in thread
From: Rasmus @ 2015-03-20 23:27 UTC (permalink / raw)
  To: emacs-orgmode

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> On 2015-03-20, at 10:07, Sebastien Vauban <sva-news@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. . .

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-20 23:18   ` Marcin Borkowski
  2015-03-20 23:27     ` Rasmus
@ 2015-03-21  3:05     ` Nick Dokos
  2015-03-21  8:09       ` Sebastien Vauban
  2015-03-21  9:15       ` Marcin Borkowski
  1 sibling, 2 replies; 10+ messages in thread
From: Nick Dokos @ 2015-03-21  3:05 UTC (permalink / raw)
  To: emacs-orgmode

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> On 2015-03-20, at 10:07, Sebastien Vauban <sva-news@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-21  3:05     ` Nick Dokos
@ 2015-03-21  8:09       ` Sebastien Vauban
  2015-03-21 12:56         ` Nick Dokos
  2015-03-21  9:15       ` Marcin Borkowski
  1 sibling, 1 reply; 10+ messages in thread
From: Sebastien Vauban @ 2015-03-21  8:09 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Nick Dokos wrote:
> Marcin Borkowski <mbork-12VZH/wba7B4rM3dGMyr8Q@public.gmane.org> writes:
>> On 2015-03-20, at 10:07, Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-21  3:05     ` Nick Dokos
  2015-03-21  8:09       ` Sebastien Vauban
@ 2015-03-21  9:15       ` Marcin Borkowski
  2015-03-21  9:42         ` Sebastien Vauban
  1 sibling, 1 reply; 10+ messages in thread
From: Marcin Borkowski @ 2015-03-21  9:15 UTC (permalink / raw)
  To: emacs-orgmode


On 2015-03-21, at 04:05, Nick Dokos <ndokos@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-21  9:15       ` Marcin Borkowski
@ 2015-03-21  9:42         ` Sebastien Vauban
  2015-03-21 13:01           ` Nick Dokos
  0 siblings, 1 reply; 10+ messages in thread
From: Sebastien Vauban @ 2015-03-21  9:42 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Marcin Borkowski wrote:
> On 2015-03-21, at 04:05, Nick Dokos <ndokos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-21  8:09       ` Sebastien Vauban
@ 2015-03-21 12:56         ` Nick Dokos
  0 siblings, 0 replies; 10+ messages in thread
From: Nick Dokos @ 2015-03-21 12:56 UTC (permalink / raw)
  To: emacs-orgmode

Sebastien Vauban <sva-news@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Config best practices?
  2015-03-21  9:42         ` Sebastien Vauban
@ 2015-03-21 13:01           ` Nick Dokos
  0 siblings, 0 replies; 10+ messages in thread
From: Nick Dokos @ 2015-03-21 13:01 UTC (permalink / raw)
  To: emacs-orgmode

Sebastien Vauban <sva-news@mygooglest.com>
writes:

> Marcin Borkowski wrote:
>> On 2015-03-21, at 04:05, Nick Dokos <ndokos@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-03-21 13:02 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-20  0:14 Config best practices? Marcin Borkowski
2015-03-20  9:07 ` Sebastien Vauban
2015-03-20 23:18   ` Marcin Borkowski
2015-03-20 23:27     ` Rasmus
2015-03-21  3:05     ` Nick Dokos
2015-03-21  8:09       ` Sebastien Vauban
2015-03-21 12:56         ` Nick Dokos
2015-03-21  9:15       ` Marcin Borkowski
2015-03-21  9:42         ` Sebastien Vauban
2015-03-21 13:01           ` Nick Dokos

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).