Re: (gnus-icalendar-org-setup) not evaluated in .emacs?

[Tim Cross <theophilusx@gmail.com>]

Management of an emacs init file is a challenge for anyone who has been
using Emacs for a long time. I did this after being a user for over 20
years and like you, was a little daunted by the task. However, I now
realise it was the single best thing I ever did to improve my emacs. I
also had let my config grow organically and what I found out when I
decided to clean it up was that a lot of what I had in there was
unnecessary, was slowing down my Emacs (both startup and runtime) and
that many of my long-term emacs 'annoyances' were actually due to
incorrect or outdated settings in my init file.

A few things I learned which may be of help

1. Put your init in git (or your favourite source control system ) and
do your changes incrementally. You will need to revert to previous
versions, so be methodical with checking in changes and do it
incrementally.

2. Have a look at the use-package macro. This really cleaned up my init
file, helped me make it more modular and really improved both the
structure and maintenance as well as startup times etc.

3. I now use org to manage my init file. In fact, I have a few init
files. I have a bare bones minimal init file which I use when I need to
debug a specific feature/package or generate bug reports, I have an
experimental one where I play with new things and I have my stable
one. Using org, I can just 'tangle' a new init based on one of those
files whenever I need it. I started by just putting all my existing
setup into a block in an org file and exporting that as elisp. As time
permitted, I broke bits off into their own blocks with explanatory
comments/text so that I can remember why/what of the block.

4. Finally, there are some really good 'canned' configurations out
there. I personally quite like purcell's setup (on github). While I
don't use any of these per se, I did 'borrow' some of the ideas.

My setup is now healthier and more stable than it ever has been. The
effort is definitely worth it.

Tim

Loris Bennett writes:

> Eric S Fraga <esflists@gmail.com> writes:
>
>> On Thursday, 14 Sep 2017 at 16:02, Loris Bennett wrote:
>>> But should this kind of ordering dependency happen?  Or should my
>>> Customize block just be at the beginning of my .emacs rather than at the
>>> end?
>>
>> I make sure my customizations are loaded before anything else.  I have
>> my customizations in a separate file and "(load custom-file)" as one of
>> the first things in my Emacs init.  Not the first as such as I set the
>> load-path to point to the versions of packages I am using that may
>> conflict with built-in ones in Emacs.
>
> For someone like me, who fails to spot the related variables even
> within a single file, I think hiving customisation off into a separate
> file might set up a few new tripwires for future me.
>
> Having said that, having let my .emacs grow organically (think "rampant
> weeds") for 30 years, maybe I should take the shears to it.  I'm just
> worried that, if I started today, I might not be productive again until
> the New Year :-(
>
> Cheers,
>
> Loris


-- 
Tim Cross