Re: improving debug output of get-buffer

[Rahguzar]

Hi Eli,
I was the other participant in the original discussion that led to this
thread.

Eli Zaretskii <eliz@gnu.org> writes:

>> That makes sense. But basically, we were using with-current-buffer, which 
>> uses
>> set-buffer and it took time to realize the “(wrong-type-argument stringp 
>> nil)”
>> error was from that with-current-buffer.
>
> And the backtrace didn't tell you the error was from set-buffer?

No backtrace stopped before `set-buffer`.

The backtrace was

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  eshell-syntax-highlighting--highlight-elisp(113 120)
  eshell-syntax-highlighting--parse-and-highlight(command 120)
  #<subr eshell-syntax-highlighting--enable-highlighting>()
  apply(#<subr eshell-syntax-highlighting--enable-highlighting> nil)
  (condition-case err (apply func args) ((debug error) (signal (car err) (cdr 
err))))
  cae-debug-reraise-error(#<subr 
eshell-syntax-highlighting--enable-highlighting>)
  apply(cae-debug-reraise-error #<subr 
eshell-syntax-highlighting--enable-highlighting> nil)
  eshell-syntax-highlighting--enable-highlighting()

where the function `eshell-syntax-highlighting--highlight-elisp` uses
the `with-current-buffer`.

I have been flummoxed by similar problems a few times before. Usually it
is `(with-current-buffer var body)` where `var` is a variable whose value
is I expect to be a buffer but which actually in nil. The
`(wrong-type-argument stringp nil)` makes me go looking for nil strings
in the body rather than realizing that the problem is with var
especially since `set-buffer` tends not to popup in the backtrace.

> In any case, your original question was about get-buffer, not about
> set-buffer.  Are you actually asking about set-buffer?

`set-buffer` is more relevant yes.

Thanks,
Rahguzar