When I attempt to kill Emacs (with save-buffers-kill-terminal) I get the error
End of file during parsing
Looking at the *Messages* buffer, I see:
progn: End of file during parsing
No *Backtrace* buffer shows up, even with debug-on-error set to t.
How do I figure out what is going on?
Recursively bisect your init file to find which part of it leads to the problem.
Yes, this means restarting and quitting Emacs multiple times, but this is a binary search, so it is in fact very fast, even if it is essentially thoughtless. Importantly, it is systematic, which guessing is typically not.
Likewise, if you find that the problem comes from some library that you load: recursively bisect it to find the problem in it.
And as #phils said, check-parens is also your friend.
Related
as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.
When running emacs calc, typing a prefix key, say 'm', followed by '?' is supposed to show all mode-related commands in the minibuffer as a kind of quick help facility.
For several years I have noticed that this quit working for me. When I hit the '?' the minibuffer flashes the help for a small fraction of a second, then goes blank. I can sometimes see parts of the help text rendered but ususally it blanks too fast to see it.
This does not happen when I run emacs -Q to skip my init file, so it is something in the init file that is the cuplprit.
My init file is quite large. I would like to put something like '(exit)' in different places in my init file to stop processing the init file and see if I can pin down what is causing the problem.
(1) What is the right way to do this?
(2) Anybody else see this problem with the minibuffer in calc?
Good question. The answer is simple: recursively bisect your init file.
Do that by commenting out 1/2 of it, then 3/4, then 7/8,... This is a binary search, and it is very quick, even though it might not seem that way at first. It is systematic, and essentially blind (thoughtless).
To comment out a block of text, use command comment-region. To uncomment a block of text, use C-u with the same command.
Trust me - in no time at all, you will have identified the culprit code, no matter how big your init file is. And if you load other libraries from your init file, and doing the exercise above shows that the culprit code is in one of those libraries, then do the same thing with (a copy of) that library code: recursively bisect it.
After several hours of trying to narrow down the problem, I found the culprit.
When key-chord-mode is set on in calc, the key help facility displays the symptoms I mentioned above.
Would like to keep key-chord enabled globally and disable it in calc-mode, but turning it off in the calc-mode-hook turns it off for all modes. Any ideas?
Anyway, I am closer to figuring out this long-term irritant.
Ever since I installed emacs24 some tiny insignificant piece of my configuration files stopped working. Since I don't really care about this error and It does not affect me I just want Emacs to shut up about initialization warnings and just open the scratch buffer (as it is it opens a second buffer with some error stuff).
Is there a way to do this without having to sit hours to debug lisp code I don't understand?
I really can't post the configuration file because it's really really big and messy, but this is the warning I get:
Warning (initialization): An error occurred while loading `/home/sofia/.emacs':
Symbol's function definition is void: plist-to-alist
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with the
`--debug-init' option to view a complete error backtrace.
In a nutshell, I don't want to ensure normal operation, I just want one buffer when opening emacs
I'm not saying that it's a good idea to do this (in fact I very much agree with #Carl Groner and #rashimoto that masking errors instead of fixing them is usually a Bad Idea™), but at your own risk try adding the following to the top of your .emacs file:
(setq warning-minimum-level :emergency)
This tells Emacs not to warn you about anything except problems
that will seriously impair Emacs operation soon if you do not attend to [them] promptly.
By contrast, the default value of warning-minimum-level is :warning, which causes Emacs to warn you about
data or circumstances that are not inherently wrong, but raise suspicion of a possible problem.
More info about warnings and options for dealing with them here and here.
I've been seeing this a lot lately and am not sure if it is an SBCL issue, an Emacs problem, a SLIME problem, or my own understanding of what it means to "compile" a lisp file.
I will have a function, say this:
(defun some-function (x) (call-this-funcshun))
I will compile and run this, and I'll get an error that my function call-this-funcshun is not defined. Then I realize that is because there is a typo. So change it:
(defun some-function (x) (call-this-function))
In Emacs, I recompile the entire file with Control-C Control-K (Emacs saves automatically before the compile as well). Emacs then reports Compilation finished. I move to the REPL. I try it again, type (some-function whatever) and I get the same error. I search through the small lisp file and see that call-this-funcshun is clearly nowhere in it. Yet I have an error that this function is not defined.
Is there some sort of caching that Emacs or SBCL is doing that causes this to hang around? It's driving me nuts. Worth noting that if I quit SLIME and then launch it again, the issue is resolved. Also worth noting that this does not affect all my code edits, just occasionally.
Maybe the file is not loaded for some reason.
I would set *load-verbose* to T and watch that LOAD actually gets called.
Setting *load-print* to T would then also cause the printing of information about definitions loaded.
I've seen two conditions that can lead to behavior that looks like what you saw:
When the symbol in the file is not the same as the symbol at the REPL. The symbol's name is only a shorthand for identifying the symbol, and the same shorthand can identify different symbols based on which package you use it in. There are some ways to be surprised about which symbol you are referring to, so it can be worth checking with SYMBOL-PACKAGE even when you are pretty sure that they are the same.
When the buffer isn't saved. I'm not sure how C-c C-k deals with this now (because I edited it to auto-save for me), but in general compiling and loading tools tend to work from the file not the buffer.
I was reading this question and the answers are a convoluted mess (timer function REALLY?)
In any case, I don't care about recreating these buffers, as that is trivial. But these buffers contain information which should never be deleted, and because they don't have associated filenames, they are usually killed without confirmation.
I do have a solution in mind, but I want to see if someone has a more "canonical" one.
jtahlborn provided the most canonical solution, except the "keep-buffers" package is showing its age has some issues:
You had to specify whether all protected buffers are to be buried and erased (erased buffers can be recovered with `undo') when killed, or just buried when killed.
member is reimplemented as find-in-list less efficiently.
Helper functions that didn't really help.
I made the the protected-list an alist that associates regexp to erase-action, and deleted the useless (IMO) code. By default, "scratch" is erased when killed, "Messages" is never erased or killed.
See github
You can try adding a function to the kill-buffer-query-functions variable that checks the current buffer, if it is scratch or Messages then return nil. I've never tried this before but it should prevent them from getting killed.
Edit: Here's an example of using kill-buffer-query-functions that allows you to protect specific buffers: http://www.emacswiki.org/emacs/protbuf-by-name.el
i use the keep-buffers utility.
In addition to what has been said by others --
*scratch* is in no way a "vital" buffer. And by default nothing and no one automatically writes anything to *scratch* or modifies anything there.
(FWIW, I tend to use an ordinary Emacs-Lisp mode file buffer instead of *scratch*. One reason is that I do typically want to save it at some point. (Another reason: I prefer that C-j do what it does in Emacs-Lisp mode. Yes, I could change just that key binding, but instead I keep *scratch* for some kinds of interaction, but typically not for a coding sandbox.)
*Messages* is a different story.
But how are you accidentally deleting *Messages*? In decades of using Emacs I don't think I've ever accidentally killed *Messages*. What's the scenario to produce the problem you are looking for a solution to?