How to quit?

How to quit?

[Marcin Borkowski]

OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
I take a deep breath and bisect my 900-line init.el...

In LaTeX, however, when I have some weird problem, I can put \endinput
in a file, and everything past that is ignored.  Is there anything like
that in Elisp?

It just occured to me that (debug) /might/ work, and so might
(keyboard-quit).  Is this a good idea?  Are there any others?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: How to quit?

[Doug Lewan]

Marcin,

No such thing in LISP. That's just not in its nature.

However, you can use C-uC-u M-x comment-region, for example, to create comments that you've added strictly for this debugging exercise.

-- 
,Doug
Douglas Lewan
Shubert Ticketing
(201) 489-8600 ext 224 or ext 4335

The human brain is the most complex thing known to man, according to the human brain.


> -----Original Message-----
> From: help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org
> [mailto:help-gnu-emacs-bounces+dougl=shubertticketing.com@gnu.org] On
> Behalf Of Marcin Borkowski
> Sent: Wednesday, 2015 February 25 10:37
> To: Help Gnu Emacs mailing list
> Subject: How to quit?
> 
> OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
> I take a deep breath and bisect my 900-line init.el...
> 
> In LaTeX, however, when I have some weird problem, I can put \endinput
> in a file, and everything past that is ignored.  Is there anything like
> that in Elisp?
> 
> It just occured to me that (debug) /might/ work, and so might
> (keyboard-quit).  Is this a good idea?  Are there any others?
> 
> Best,
> 
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Faculty of Mathematics and Computer Science
> Adam Mickiewicz University

Re: How to quit?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

() Marcin Borkowski <mbork@wmi.amu.edu.pl>
() Wed, 25 Feb 2015 16:36:39 +0100

   Are there any others?

You can try adding the form:

 (with-current-buffer (get-buffer " *load*")
   (goto-char (point-max)))

prior to the possibly-problematic portion.  This presumes
init-file processing uses the buffer named " *load*" (note
leading space and asterisks), so YMMV.

Anyway, the "skip to end" approach is not as nice as simply
‘(debug)’ IMHO, because w/ ‘(debug)’, you can continue.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: How to quit?

[Marcin Borkowski]

On 2015-02-25, at 17:07, Doug Lewan <dougl@shubertticketing.com> wrote:

> Marcin,
>
> No such thing in LISP. That's just not in its nature.

That I understand.  But this is no just “Lisp”, its “Emacs Lisp”, and
more precisely, it’s a language used to (among others) writing config
files.

BTW, extensive use of global (and buffer-local) variables also is not in
“Lisp nature”, right? ;-)

> However, you can use C-uC-u M-x comment-region, for example, to create comments that you've added strictly for this debugging exercise.

That was precisely what I didn’t want to do.

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to quit?

[Emanuel Berg]

Doug Lewan <dougl@shubertticketing.com> writes:

> However, you can use C-u C-u M-x comment-region, for
> example, to create comments that you've added
> strictly for this debugging exercise.

Or perhaps the OP can do like this:

    (message "Hello")

    (/ 1 0)

    (message "to Poland!")

With `load-file' I only get the first message.

You can also tell the debugger just to note the error
so it won't bother you with the heavy artillery and
just notes the error (tell me if you want this).

For an init file it might be a different story though
in many cases that should be debugable with
`load-file' just as well. It *is* a file, after all!

-- 
underground experts united

Re: How to quit?

[J. David Boyd]

Emanuel Berg <embe8573@student.uu.se> writes:

> Doug Lewan <dougl@shubertticketing.com> writes:
>
>> However, you can use C-u C-u M-x comment-region, for
>> example, to create comments that you've added
>> strictly for this debugging exercise.
>
> Or perhaps the OP can do like this:
>
>     (message "Hello")
>
>     (/ 1 0)
>
>     (message "to Poland!")
>
> With `load-file' I only get the first message.
>
> You can also tell the debugger just to note the error
> so it won't bother you with the heavy artillery and
> just notes the error (tell me if you want this).
>
> For an init file it might be a different story though
> in many cases that should be debugable with
> `load-file' just as well. It *is* a file, after all!


If only elisp had a 'goto'.  Maybe someday!  :-)

Re: How to quit?

[Bob Proulx]

Marcin Borkowski wrote:
> OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
> I take a deep breath and bisect my 900-line init.el...
> 
> In LaTeX, however, when I have some weird problem, I can put \endinput
> in a file, and everything past that is ignored.  Is there anything like
> that in Elisp?
> 
> It just occured to me that (debug) /might/ work, and so might
> (keyboard-quit).  Is this a good idea?  Are there any others?

The way I do this myself is to copy the file off to a safe place as a
backup.  Then use two copies of emacs.  In one copy I chop the file up
into the bisections.  The other copy I start and stop repeatedly
letting it load the init file possibly with or without --debug-init to
debug the file.  By using two emacs processes I can keep one open with
the init file being chopped up.  That one I can easily work through
the process like this following.  Note that I disable transient mark
mode and line-move-visual as evil.

  C-x h mark-whole-buffer
  M-= count-words-region
  ...say the buffer has 120 lines...
  C-u 60 C-n
  C-w kill-region
  C-x C-s save-buffer
  ...test...  problem in remaining or removed section?...

If in the remaining section then cut it in half again.  If in the
removed section then undo the region kill and then kill the other half
save and test again.  Continue until you have converged on the
problem.  Once I get things reduced to a single screen I can usually
see the problem by eye and inspection.

Good luck!
Bob

P.S.  There are many ways to determine the number of lines in the file
to start the bisection.  There is M-x what-line.  The line number has
been added to the mode line in recent versions so simply jump to the
bottom and look in the modeline.  Other ways.

There are many ways to cut the file in half.  If you don't like moving
by lines or have line-move-visual enabled so that next-line doesn't
actually move by lines then there is M-g g goto-line to jump there
directly.  Also the movement commands M-> and M-< leave the mark
behind.  Use C-x C-x to view the extent of the region between mark and
point.

The M-> end-of-buffer and M-< beginning-of-buffer commands have an odd
additional behavior.

  With numeric arg N, put point N/10 of the way from the beginning.
  If the buffer is narrowed, this command uses the beginning of the
  accessible part of the buffer.

Therefore running M-< C-u 5 M-> will take you to the middle of the
buffer.

Re: How to quit?

[Marcin Borkowski]

On 2015-02-25, at 18:57, J. David Boyd <dboyd2@mmm.com> wrote:

> If only elisp had a 'goto'.  Maybe someday!  :-)

Wow, what an idea!  It has one!  I could use catch/throw!

Thanks! ;-)

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to quit?

[unfrostedpoptart]

On Wednesday, February 25, 2015 at 7:36:58 AM UTC-8, Marcin Borkowski wrote:
> OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
> I take a deep breath and bisect my 900-line init.el...
> 
> In LaTeX, however, when I have some weird problem, I can put \endinput
> in a file, and everything past that is ignored.  Is there anything like
> that in Elisp?
> 
> It just occured to me that (debug) /might/ work, and so might
> (keyboard-quit).  Is this a good idea?  Are there any others?
> 

You could comment-out part as people have suggested.  However, the easiest way is just to select the part of the code you want to run and then do M-x eval-region.   Piece of cake!

 David

RE: How to quit?

[Drew Adams]

> OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
> I take a deep breath and bisect my 900-line init.el...
> 
> In LaTeX, however, when I have some weird problem, I can put \endinput
> in a file, and everything past that is ignored.  Is there anything like
> that in Elisp?
>
> It just occured to me that (debug) /might/ work, and so might
> (keyboard-quit).  Is this a good idea?  Are there any others?

Just put `(top-level)' in your init file where you want it to stop.
Command `top-level' returns to, well, Emacs top-level. ;-)

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').

Actually, I bind `C-x C-;' to this command, from `misc-cmds.el'
(http://www.emacswiki.org/emacs/download/misc-cmds.el).

(defun comment-region-lines (beg end &optional arg)
  "Like `comment-region' (which see), but comment/uncomment whole lines."
  (interactive "*r\nP")
  (if (> beg end) (let (mid) (setq mid beg beg end end mid)))
  (let ((bol  (save-excursion (goto-char beg) (line-beginning-position)))
        (eol  (save-excursion (goto-char end)
                              (if (bolp) (point) (line-end-position)))))
    (comment-region bol eol arg)))

Re: How to quit?

[Robert Thorpe]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> OK, so I have a problem, and it doesn't show up when I do emacs -Q.  So
> I take a deep breath and bisect my 900-line init.el...
>
> In LaTeX, however, when I have some weird problem, I can put \endinput
> in a file, and everything past that is ignored.  Is there anything like
> that in Elisp?

Yes, if you quote a lot of code then it becomes data, data in the
top-level of a file is just thrown away.  So, the equivalent of
\endinput is:

'(

Then, at the very end of the file put:

)

It can be useful to use the word "quote" which is equivalent, since this
isn't done in normal programming so it sticks out.  In that case begin
with:

(quote

Of course, parenthesis must balance in the blocks commented out for this
to work.  "(top-level)" can be used in init files but not in other code.

BR,
Robert Thorpe

Re: How to quit?

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

> Just put `(top-level)' in your init file where you
> want it to stop. Command `top-level' returns to,
> well, Emacs top-level. ;-)

Yes, that seems to do exactly what the OP wants.

> 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 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).

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.

-- 
underground experts united

Re: How to quit?

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Of course, parenthesis must balance in the blocks
> commented out for this to work. "(top-level)" can be
> used in init files but not in other code.

Are you sure? I don't get the second message here,
either as is or in a `progn':

    (message "hello")

    (top-level)

    (message "UK")

-- 
underground experts united

Re: How to quit?

[Robert Thorpe]

Emanuel Berg <embe8573@student.uu.se> writes:

> Robert Thorpe <rt@robertthorpeconsulting.com> writes:
>
>> Of course, parenthesis must balance in the blocks
>> commented out for this to work. "(top-level)" can be
>> used in init files but not in other code.
>
> Are you sure? I don't get the second message here,
> either as is or in a `progn':

I'm sure you don't.  But, putting (top-level) in library code that's
loaded, required and/or byte-compiled can cause chaos.

BR,
Rob

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.

Re: How to quit?

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

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

The original, "real" comments give structure to the
code file - they are labels, often. When you comment
out a big block of code those labels aren't by far as
distinguishable because the code block "comment" gets
the same font color. So when those labels in part
disappear, your overall orientation of the document is
reduced. This makes it more difficult to navigate even
in the part that isn't commented out.

>> 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"?

Well, yes! The more organized you are, the better you
get at "guessing" and the more likely is it that your
shamanism works when you need it. Getting the files
organized isn't equal to getting an organized mind but
it is a good start...

On the other hand, having several files and loading
them don't rule out the "binary search" method. First
attempt, comment out the last half of the lines (those
that load files). Later, if you want to apply "binary
search" to the failing file as well, there will be a
lot less code to deal with compared to the proposed
several thousand line spaghetti bowl inti file.

There are also purely technical advantages like much
smaller compile time for a single error in a short
file.

-- 
underground experts united