RE: How to quit?

[Drew Adams]

> > But really you will find, I think, that
> > commenting-out blocks of the file is the handiest.
> > I bind `C-x C-;' to `comment-region', which comments
> > or (with `C-u') uncomments the region, and which
> > nests and unnests such commented blocks (unlike
> > `comment-dwim').
> 
> I don't like the idea of commenting out code blocks.
> The code will be hard to read as code (as a comment!?)
> with no font lock (or worse: the same color as the
> "real" comments which are now drowned). It'll just be
> bulky and in the way.

I think you are perhaps missing the point of debugging
an init file this way (binary search).  You should not
be trying to read the code that is commented out.

Binary search is essentially blind, except for noticing
the result of each test to inform the next division.
You don't read any code.

(And that is why many of us have learned its value the
hard way, over and over.  We feel that we are too clever
for that.)

Commenting and uncommenting is just a way of making the
code invisible to evaluation.

If you want to also make it invisible to yourself for
some reason - e.g., if you are bothered by it being
"bulky and in the way", or if you are tempted to "read
[it] as code (as a comment!?)" - you can do that too
(see, e.g., library `hide-comnts.el',
http://www.emacswiki.org/emacs/download/hide-comnt.el).

As for confusion with "real" comments - no such problem.
That's the point of `comment-region', which nests and
unnests correctly.

This nesting behavior is similar to the behavior of
Common Lisp block-commenting (envelopes of `#|' + `|#').

> I have a better idea, and that is for the OP to split
> his init file into several files all dedicated a
> specific area of configuration and/or extention. The
> OP mentioned 900 lines of Elisp - myself, I use
> several files and very few are longer than 100 lines
> (those which are often has ambitious documentation
> inline which makes for a huge bulk of lines).

Meme combat, I'm afraid.  My init file is so split.
So what?  I still use a binary search on it - and then,
if necessary, on whichever library I discover is the
culprit.

No matter how finely you split your mass of code, or
conversely how much you clump it together in a giant
sack of spaghetti, a dumb, blind binary search can
often be your friend.  More often than you might think.

> Besides many other advantages, in this specific
> situation, one could load all the files from .emacs
> (with `load-file') and then just comment out a single
> line to not have a specific file loaded.

Which single line?  That's the point.

Are you going to try each one in turn?  Are you going
to try to guess, based on your intelligent division of
subject matter into sacks that are each "dedicated [to]
a specific area of configuration and/or extention"?

If so, then you are being clever.  For this kind of
search, you will (eventually) find that you are often
being too clever.  Dumb binary search will beat you to
the punch much of the time, I'm afraid.

If the answer were so obvious as to lead you to the
culprit library & line right off the bat then there would
be no question of how to proceed.  No one would bother to
ask how to debug their init file in such an obvious case.

But when things are not so obvious (and when things you
thought were obvious turn out not to be what you thought),
binary search can be your friend.

That's the point of using a binary search - in whatever
file, however big or small it might be.  *You don't know
which line is the culprit*, whether that line loads another
library or calculates the high tides at full moon at your
location.