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