[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Feature request: Maintaining multiple init files with one org fi
Re: [O] Feature request: Maintaining multiple init files with one org file
Sun, 29 Jul 2018 12:42:27 +0200
mu4e 0.9.19; emacs 26.1
Thanks for the answer.
Tim Cross writes:
> 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.
This is pretty much how I do it at the moment. Complexity is indeed the
problem here. I have Emacs also running on an Android tablet under
Termux. This one needs quite a lot of adjustments to the init
file. Already the paths to the org files and to some non-elpa/melpa
packages are different. Other packages are not available on Termux
(e.g. aspell) or not meaningful at all (X-related stuff, mu4e
etc.). Having the same init file here as on the other computers, would
easily end up in a mess of IFs and WHENs (and probably slow down the
start process on Android).
At the moment I have a separate .emacs for the tablet and have to
remember changing this file, for ex. whenever I include a new file in
the org-agenda-files list. This could be much more tidy with an org
> 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.
I'm trying to use customize as little as possible, since AFAIK there is
no way to let customize use an org file instead of a "real" init file.