I have used "Customize" to set a value for semantic-lex-c-preprocessor-symbol-file. However, after loading up .emacs, this isn't the value I see. On opening up the "Customize" menu for this variable, I see that its state is "Changed outside customize". How do I find it where this was changed? Also, what is the right way of customizing variables to avoid such issues?

  • You can grep for that variable in your emacs setup. If it's changed outside customize, it should be somewhere in your emacs setup. I would also grep in the elpa folder to ensure that none of the packages changed that variable. Nov 17, 2014 at 3:04
  • @kaushalmodi I did exactly that - grepped for it in my .emacs.d folder. That contains the .el files I create + the elpa files. No hits. Hence the question.
    – Pradhan
    Nov 17, 2014 at 3:17
  • I am curious to know why the grep didn't return any results. Do you use .dir-locals.el to do project or directory specific configuration? Or do you have a site-lisp directory that holds some global config? Those files could set this variable. In summary whatever is modifying this variable HAS to be greppable. I would also review the regex used to grep and make sure the recursive flag is added. Unrelated but I use ag instead of grep for faster results. Nov 17, 2014 at 12:15
  • This variable also looks like something that one could set as a File Variable. Doing a project wide recursive ag/grep might give you the answer. Nov 17, 2014 at 12:27
  • @kaushalmodi Yes, I do use a .dir-locals.el file, but I created it to override this behaviour :) So, that wasn't the root cause. I ran a find over my project and found nothing. Also, as a confirmation of my regexp being accurate, the command ended up showing the .dir-locals.el file. So, I am reasonably certain that there's nothing in the project causing this. Could a lazy-load of one of the semantic libraries be resetting it erroneously? I will let you know if I manage to find the issue.
    – Pradhan
    Nov 18, 2014 at 8:33

2 Answers 2


It is not easy to find where such a change was made. The easiest way to find it is to recursively bisect your init file, to find out which part of it causes this.

To do that you can use command comment-region. With C-u it uncomments the region. Comment out 1/2, then 3/4, then 7/8, then 15/16,... of your init file.

Beyond that, code such as this will detect which variables have been changed outside Customize (but I think you already know which variables are concerned):

(let ((vars  ()))
   (lambda (symbol)
     (let ((cval  (or (get symbol 'customized-value)
                      (get symbol 'saved-value)
                      (get symbol 'standard-value))))
       (when (and cval                  ; It is declared with defcustom.
                  (default-boundp symbol) ; It has a value.
                  (not (equal (eval (car cval)) ; Value does not match customize's.
                              (default-value symbol))))
         (push symbol vars)))))
  (message "Variables changed outside: %s" vars))

If you want to let something change a value outside Customize, but you want Customize to consider that it was changed inside Customize, you can do it using library cus-edit+.el. See also Customizing and Saving on Emacs Wiki.

As for the right way to avoid such issues: use Customize to change and save the value. But you already did that. As you say, some other code seems to be changing the value after your saved value is loaded.

(Wrt where to let Customize save changes, I recommend that you use a separate custom-file, instead of letting Customize write stuff to your init file.)

  • That's sad. Was hoping for some way of loading an empty config and having edebug(or something similar) watch the variable. Thanks!
    – Pradhan
    Nov 17, 2014 at 1:30

Emacs version 26.1 and higher allows you to trigger the debugger when a variable changes. Place the following code near the beginning of your init.el:

(debug-on-variable-change 'semantic-lex-c-preprocessor-symbol-file)

Restart your emacs. Each time the variable is changed, you'll enter the debugger with the corresponding backtrace. After each occurence you can press c to continue the execution.

For more information see the elisp manual.

The second part of your question was answered accurately by Drew. Personally, I would recommend keeping the custom-set-variables block at the end of your init file.

  • 1
    This should probably be the answer nowadays Sep 3, 2023 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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