bug#12068: 24.1; customizing debug-on-error to nil disables --debug-init

[Dave Abrahams <dave@boostpro.com>]

on Thu Aug 02 2012, Glenn Morris <rgm-AT-gnu.org> wrote:

> Maybe you mean, put the error after the customization section.

Yes.

> The custom block does get put at the end of .emacs when first created.

Yes, but once you get into more sophisticated configurations, it's
common to want to do things at init time after the customizations are
known.

> An equivalent scenario would be:
>
> cat ~/.emacs
>
> (setq debug-on-error nil)
> (error "foo")
>
> There's no good solution to that other than "don't do that then". 

Of course there's a good solution to that...

> Except maybe have a really-debug-on-error variable that overrides
> debug-on-error and is only settable by --debug-init. 

There you go.  Another possibility is for whatever deals with errors to
check whether we're in initialization, and if so, consult argv for the
presence of "--debug-init" and let that override debug-on-error.  Being
able to reliably debug initialization is really crucial, because if your
init gets messed up, you really can't do anything else.

> But it seems like pointless complexity to me. I assume debug-on-error
> is customizable for people who want to set it non-nil. I can't imagine
> many will customize it to nil.

What do you think people will do when they've set it to non-nil and then
they get annoyed that they're always dropping into the debugger and
really want to turn it back off so it sticks?  That's right, they'll do
what I did: customize it to nil.  I'm not even all that naïve a user;
I've done some pretty heavy elisp hacking in my time, and this still
really baffled me for a long time.  

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost