2

I am having a fairly big .emacs file with lots of stuff inside, parts of which I have copied from somewhere else. At some point in the file I am setting the font size to some value but this setting later on gets overwritten by some other function that I am unable to find unfortunately.

Is there a possibility to evaluate an elisp file function by function (so I could see at which point the font-size changes) or is there some other method to debug such a case (e.g. specify a variable and have a debugger tell me which functions are changing it)?

1

You want to find out which part of your init file (or some other Lisp file) is causing some change.

You probably do not want to just evaluate the file sequentially, one sexp (e.g. function definition) at a time, checking the resulting behavior.

Instead, consider bisecting the file recursively. That is, evaluate 1/2 of it (sequentially), to determine which half causes the problem. Then do the same with 1/2 of that half, etc. This way you narrow down the problem from 1/2 to 1/4, 1/8/, 1/16,..., which is a binary search.

This is very quick, even though it might not seem that way in the beginning.

To evaluate only part of a file, you can select that part and use M-x eval-region.

But for recursively bisecting a file that you load (e.g. your init file), the easiest way to proceed is to comment out the part that you do not want to evaluate, then load the file.

You can use command comment-region to comment out the region. You can use it with plain C-u to uncomment the region.

For your init file, you will typically need to restart Emacs after each such edit (commenting out part of the file). Even so, this is quick.

Not only is this a quick way to find the culprit; it is also sure. When you instead think that you can guess this or that, you can easily miss something. This blind and dumb approach doesn't have that weakness.

(And of course if you do have some good guesses then you can combine this blind method with a bit of guessing.)

  • Thank you! I thought about doing that, but a.) it seemed to me that there must be a better (maybe automated solution) for doing that (is there an elisp debugger that can track changes of a variable?) and b.) restarting emacs every time is a rather tedious thing, especially since it takes a while to startup when evaluating the entire init file. – Simon Fromme Jan 17 '17 at 19:02
  • @Simon "automated solution" - see github.com/Malabarba/elisp-bug-hunter – npostavs Jan 17 '17 at 19:10
  • @npostavs: Thank you, I will try this out. – Simon Fromme Jan 17 '17 at 19:27
  • The very weird thing I encountered now is that emacs must be evaluating some things after the init file is loaded which causes the font size to change. When manually evaluating the init file again, I get the behavior I want. Any ideas what that could be? – Simon Fromme Jan 17 '17 at 19:27
  • Keep track of what you do after loading the init file, if loading it does cause the problem. Something that you are doing (perhaps something that you are loading later?) is introducing the problem. We cannot guess that here, at least not without more info. – Drew Jan 17 '17 at 21:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.