help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help


From: Matt Proud
Subject: Re: Help
Date: Wed, 20 Jan 2010 08:52:28 -0800 (PST)
User-agent: G2/1.0

This is an especially good idea.  I declared .emacs bankruptcy about
two years ago, refactored for configuration and third-party imports
into separate files, and never turned back.

Another good tip is to put your Emacs configuration directory into
version control---e.g., Git.  If you're dilligent about keeping good
comments in revision logs, you could just roll back to other dates
when things go South.  I declared general dot-file bankruptcy and put
all my major ones in Git a while back.  It makes life so simple
between work, my laptop, and my desktop, too.

Good luck!

On Jan 10, 2:36 pm, Tim X <address@hidden> wrote:
> Cecil Westerhof <address@hidden> writes:
> > "Rhey, David" <address@hidden> writes:
>
> >> There is a list of things that comes before this error, and a small 
> >> suggestion
> >> to run ??debug-init? after it. I?ve been working on this off and on for 
> >> awhile
> >> now, but haven?t made any breakthroughs. Any help or insight would be most
> >> appreciated.
>
> > What I always find useful when debugging -and that is what you need to
> > do- is commenting things out.
> > I just would comment almost everything out and then start Emacs. If it
> > goes alright, there is no problem with that. Then uncomment something,
> > etc. When you know which code gives the problem, it is easier to solve.
> > And if you can not solve it, you can 'exactly' tell what the problem is
> > and it is easier for the people here to solve it.
>
> When you have an error in a .emacs file, especially if its a very large
> one, I find the following useful.
>
> 1. Run with --debug-init. This will provide a backtrace which is often
> enough to find the offending line.
>
> 2. If that doesn't help, a 'binary search' approach is often helpful.
> Rather than commenting out all the lines, put a couple of message lines
> in. Start with a line at around half way in the file i.e.
>
> (Message "Got to checkpoint 1")
>
> The error  will either be in the first half or the second half. So, next
> time you start emacs, check the messages buffer. If your message is in
> there, you know your error is in the second half of the file, otherwise,
> its in the first half.
>
> Once you have narrowed it down to which half, put another message
> halfway in that half i.e.
>
> (message "Got to checkpoint 2)
>
> Keep repeating the process until you narrow down to the command with the
> error.
>
> Another thing I do to make management of my .emacs easier is that I
> break of related functionality into its own file. I put all these files
> into a directory and add that directory to the emacs load-path. Each
> file ends with a 'provides' line. I then just have 'require' lines in my
> .emacs. For example, I have all my org mode stuff in a file called
> tx-org.el. The last line of that file is
>
> (provide 'tx-org)
>
> In my .emacs I have a couple of lines at the top which set my private
> elisp directories and then I have something like
>
> (require 'tx-org)
>
> I find this helps prevent my .emacs from becoming to large and clutterd
> and I can add/remove related config settings just by
> commenting/uncommenting one line in my .emacs. Another nice side effect
> is that when I do have an error and I run debug-init, it usually clearly
> indicates which of my config files the error is in, making it quick to
> track down.
>
> Tim
>
> --
> tcross (at) rapttech dot com dot au



reply via email to

[Prev in Thread] Current Thread [Next in Thread]