Re: [O] Feature request: Maintaining multiple init files with one org file

[Tim Cross]

I suspect part of the reason org doesn't have specific support for this
is because for many, solving the multiple machine/multiple
platform/multiple environment issue pre-dates org and so wasn't an itch
needing to be scratched. I've been using pretty much the same approach
since emacs 21.

As your emacs init file is really just a lisp program, it is relatively
easy to implement multiple environment support within the file itself,
which is what I do. At the start of my init file, I just have some elisp
which sets variables representing the platform (linux or mac), the
hostname (I have both a linux and mac box at home and work) and the
profile (home/work). Then it is just if/cond/when conditionals where
needed. I use org to store the file mainly for documentation purposes
and will have the same file on all platforms. The advantage is that it
is the same file on all platforms, the disadvantage is that it is larger
and probably more complex than it would be if you tangled different
files per system.

For me this is just 6 of one and half a dozen of the other. YMMV. I do
find there are some things best set/managed via Emacs' custom facility,
so the most useful bit in my init file is the bit which loads different
custom files based on the platform. I don't bother keeping the custom
files in git, so they stay local to each system. I find using custom to
manage face and font settings particularly convenient over managing them
by hand in my init file.

Tim

Sven Bretfeld <address@hidden> writes:

> Hi
>
> I don't know how you guys maintain init files for different hosts. I
> have one org-file with the header:
>
> #+PROPERTY: header-args :tangle ~/.emacs
>
> The file is synced to all my machines and produces the local init files
> on each. Most configurations are shared, but some are host-specific
> (e.g. font size).
>
> Sadly export filtering does not work with the tangle function. It would
> be nice to be able to do something like:
>
> ,----
> | * Default Frame
> | ** Office Computer                            :OFFICE:
> | #+begin_src emacs-lisp
> | (setq default-frame-alist '(
> |       (font . "-PfEd-DejaVu Sans 
> Mono-normal-normal-normal-*-26-*-*-*-m-0-iso10646-1")
> |       (width . 102)
> |       (height . 41))
> | #+end_src
> |
> | ** Computer at home                           :HOME:
> | #+begin_src emacs-lisp
> | (setq default-frame-alist '(
> |       (font . "-PfEd-DejaVu Sans 
> Mono-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
> |       (width . 150)
> |       (height . 50))
> | #+end_src
> |
> | ** Laptop                                     :LAPTOP:
> | #+begin_src emacs-lisp
> | (setq default-frame-alist '(
> |       (font . "-PfEd-DejaVu Sans 
> Mono-normal-normal-normal-*-12-*-*-*-m-0-iso10646-1")
> |       (width . 80)
> |       (height . 30))
> | #+end_src
> `----
>
> It should be clear what this is about. On the office computer you would
> prepare the file headers to exclude the tags HOME and LAPTOP from being
> tangled and, after saving/tangling the file, you would have a nice init
> file suiting this computer. At home the same by excluding the other tags
> etc.
>
> This would save a lot of work and you would have a tidy way to maintain
> all your init files without (if (string-equal (system-name) clauses.
>
> If the noexport tag worked, it would also save a lot of time and mess
> when debugging your init file in case of an error.
>
> I don't actually understand why the developers decided not to implement
> export filtering in the tangling operations. I know about the COMMENT
> keyword, but the above example should make clear that this solution is
> far from handy.
>
> Maybe there is another way that escaped me so far?
>
> All best,
>
> Sven


--
Tim Cross