c-buffer-is-cc-mode? I couldn't remember why it could possibly be important to set it in init, especially since it was buffer local. Well, after restarting, I find I cannot paste anymore, and I'm getting an error involving
c-buffer-is-cc-mode. In these situations, it's best to do
Reproducing the problem, I see from the backtrace that my error comes from my advice I define for pasting:
(defadvice yank (after c-indent-after-yank activate) "Do an indent after a yank" (if c-buffer-is-cc-mode (let ((transient-mark-mode nil)) (indent-region (region-beginning) (region-end) nil))))
The error is now easy to spot. Not every buffer has
c-buffer-is-cc-modedefined, so when elisp tries to evaluate the undefined variable, it throws a
void-variableerror. The fix is pretty simple, which is to use
boundp, which checks to see if a symbol is void or not.
(defadvice yank (after c-indent-after-yank activate) "Do an indent after a yank" (if (and (boundp 'c-buffer-is-cc-mode) c-buffer-is-cc-mode) (let ((transient-mark-mode nil)) (indent-region (region-beginning) (region-end) nil))))
After evaluating this, everything works well once again. The hacky
c-buffer-is-cc-modeis removed, and the
yankadvice now stands on its own.
Let's fix one more problem before calling it a day. I use an awesome package called
key-chord. This enables me to set the press of two keys simultaneously (such as "j" and "k") to a command. I noticed that when I start up, though, it doesn't work until I toggle the to disabled, and then back to enabled.
First, I noticed that
(key-chord-mode 1)is called before any of the
key-chord-define-globalis called. Maybe it should be last? I try it out, but it doesn't help the problem. Maybe the problem is that the feature isn't actually loaded yet. I looked at my config, and saw that I only do operations on
eval-after-loadcalls (which I'll be writing about later). But nothing ever loads it!
When I invoke
M-x key-chord-mode, what must be happening is that the autoload for
key-chordkicks in, loads it, then evaluates everything in all the
eval-after-loadcalls, one of which calls
(key-chord-mode 1). Then the
M-xinvocation executes, which turns the mode off. To fix this, we just need to add a
(require 'key-chord nil t)statement. And that does fix the problem.
I'll go into the
requirestatement in another post, and why I use the additional arguments to the function.
I looked in my init file for other locations in which I'm making the same mistake. I see that I have setup for
bc(a breadcrumb system), but no actual library backing that up right now. I checked, and it isn't available on any of my ELPA servers I use. To me, this is a bad sign. ELPA makes things so much easier that I think it's better if I use some other bookmarking solution and retrain myself. So I'm deleting my config for this, and I'll investigate other bookmarking systems later.
The lessons I've gotten from today's debugging session are this:
- Strange things in init files are a sign that there may be a bug. Don't patch around it. Find the problem and fix it!
- After modifying your init file, load it up and try a few things. Fixing things while working on your init file is much better than discovering some problem at a more inconvenient time. That's when bad fixes and hacks start to creep in.
- If you want a global mode to be on as soon as you start up emacs,
don't forget to
requirethe package. Most other things don't need the
require, since they have elisp
autoloadsthat will load up the code when you execute one of the package's commands.