Help

[Rhey, David]

Hello,

 

I’m an IT worker with the University of Michigan. I have a professor who has a fairly detailed .emacs file that he’s worked with for years. I recently built him a VM for his laptop. He would like the .emacs file from his desktop imported to his laptop VM. Every time I replace the original .emacs file contents with his original I get the following error (upon opening a terminal and typing: emacs):

 

“An error has occurred while loading ‘/home/david/.emacs’

 

Invalid read syntax: “) or . in a vector”

 

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.

 

Regards,

 

David

UMICH Chemistry IT

[Tassilo Horn]

"Rhey, David" <dr...@umich.edu> writes:

Hi David,

> "An error has occurred while loading '/home/david/.emacs'
>
> Invalid read syntax: ") or . in a vector"
>
> There is a list of things that comes before this error,

Then poste them, and if possible make that .emacs available, if there
are no private things like passwords in them.

> and a small suggestion to run '-debug-init' after it.

Then do exactly that: emacs --debug-init

You'll get a backtrace, which should point you to the offending form.

Bye,
Tassilo

[Cecil Westerhof]

"Rhey, David" <dr...@umich.edu> 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.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Tim X]

Cecil Westerhof <Ce...@decebal.nl> writes:

> "Rhey, David" <dr...@umich.edu> 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

[Matt Proud]

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!