M-x set-variable RET debug-on-error RET t RET.
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 problems in the execution of a function (e.g.
recentf-mode) you can use
M-x debug-on-entry RET recentf-mode RET. (That's not the problem here, presumably, but it's good to know.) That will open the debugger when function
recentf-mode is invoked. You can step through the function using
Update after your comment:
Ah yes, my bad. I didn't notice that the message is a warning message and not an error message.
Looking at the code in
recentf.el, I see this, which is apparently what produces that message:
(defun recentf-save-list ()
"Save the recent list.
Write data into the file specified by `recentf-save-file'."
(insert (format recentf-save-file-header (current-time-string)))
(recentf-dump-variable 'recentf-list recentf-max-saved-items)
(insert "\n\n;; Local Variables:\n"
(format ";; coding: %s\n" recentf-save-file-coding-system)
(write-file (expand-file-name recentf-save-file))
(set-file-modes recentf-save-file recentf-save-file-modes))
(warn "recentf mode: %s" (error-message-string error)))))
So it apparently means that one of those actions led to an error (which was handled by displaying the warning message). Which of the actions led to the message is unclear. You'd have to check each of the functions, to see whether (a) it expects a string argument and (b) whether it was instead passed
I'd suggest that you start with each of the variables
recentf-save-* - see if one of them has value
nil instead of a string.
You could also copy that function definition, change
error, and try again. Then the
debug-on-error should kick in OK, so you can see better what the problem is.
Alternatively, you can do
M-x debug-on-entry RET recentf-save-list RET, and walk through the debugger (using
d) when that function is invoked, to see exactly what's going on. If you do that, evaluate the function definition again, from Lisp, so you get a better debugging session than if you just use the byte-compiled definition. To evaluate it, put your cursor inside it and use
C-M-x (in Emacs-Lisp mode).
It's too bad that the warning message is not more helpful. The code be written better, to handle the error more appropriately. You might consider filing an Emacs bug report (aka enhancement request):