Is there a way to get a pretty-printed backtrace buffer?
There is, but you'll have to wait for Emacs 27 to be released or get a build of it in the meantime. Quoth its etc/NEWS file:
* Changes in Specialized Modes and Packages in Emacs 27.1
*** The Lisp Debugger is now based on 'backtrace-mode'.
Backtrace mode adds fontification and commands ...
Use M-x set-variable RET debug-on-error RET t RET.
(Or M-: (setq debug-on-error t).)
That will open the debugger when the error is raised. You can see who called that recentf-mode, what arguments it was passed, etc.
The problem you see is that recentf-mode was expecting a string argument and it received a nil argument (or possibly no argument).
To debug ...
Load the source file (*.el, not *.elc) that defines the function you're interested in. E.g., M-x load-file or M-x load-library (but be sure to specify .el).
Then use M-x debug-on-entry, to enter the debugger when that function is called. Step through the debugger with d (or c to skip through a step you're not interested in). Use e to evaluate any sexp (e.g. ...
Nope. There is no simple solution ready-to-hand. As far as I know, users just manually remove the bytecode from backtraces they report. That's what I do, at least.
This has been requested more than once, including with Emacs bug #6991.
The bug was summarily closed immediately -- no reason given. Eventually it was reopened and relegated to the "wishlist".
I'm not sure just what you're asking, but does using function backtrace in your code, at the place where you want to see a backtrace, help? C-h f says:
backtrace is a compiled Lisp function in subr.el.
Print a trace of Lisp function calls currently active.
Output stream used is value of standard-output.
Looks perfectly "normal" to me: the \NNN you see are bytes in the bytecode of the functions that have been used to run your code.
It's somewhat annoying to see them in the backtrace, indeed, so after a few decades of living with it, Emacs-26 finally changed to provide a prettier representation.
Do you see the same problem when you start Emacs using emacs -Q (no init file)? If not then recursively bisect your init file to find out what is causing the problem (e.g. *Backtrace* seeming to disappear and Emacs becoming dysfunctional).
If you still see the problem with emacs -Q then consider reporting an Emacs bug.
If buffer *Backtrace* has not been ...
Let's look at the documentation for yank. From C-h f yank RET:
Reinsert ("paste") the last stretch of killed text.
Oh, so yank doesn't just return the last killed text; it inserts it too. So you can simply run (yank) to put that text into your buffer.
So why are we seeing the wrong-type-argument error? Let's run (yank) in IELM, so we can see ...
Emacs 27: C-hig (elisp)Backtraces
Debugger mode is derived from Backtrace mode, which is also used to show
backtraces by Edebug and ERT. (*note Edebug::, and *note the ERT manual:
The backtrace buffer shows you the functions that are executing and
their argument values. When a backtrace buffer is created, it ...
It's possible to format backtraces differently using mapbacktrace with a custom function. One such example is always printing the items as list, I've contributed a patch introducing the debugger-stack-frame-as-list customizable that does that. Check out the implementation of backtrace in Emacs 26.1 or newer.
The advice framework is good for this sort of thing. You could advise low-level functions like write-region and insert-file-contents (those probably offer good coverage). One way would be to use a function that logs both the filename and a stack trace. Something like the following:
(lambda (&rest args)
@npostavs was able to track the problem down in the Emacs bug report 27571: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27571
In a nutshell, the error is caused because the ulimit stack size is too low to handle this particular situation. ulimit -S -s unlimited resolves this issue.
In the event the Emacs team implements a fix, or if another solution is ...
The easiest thing to do is to create your own debugger in the environment in which the error occurs. That goes something like this:
(defun my-debugger (&rest debugger-args)
(message "BACKTRACE: %s"
(let ((standard-output (current-buffer)))
Setting edebug options doesn't actually help here. Errors that are listed in debug-ignored-errors are ignored even while executing under Edebug. This isn't mentioned in the manual (as of Emacs 24.5) but it is mentioned in the docstring of debug-on-error (for which edebug-on-error is just a proxy). (I don't understand why debug-ignored-errors has any ...