Re: improving debug output of get-buffer

[Eli Zaretskii]

> From: Rahguzar <rahguzar@zohomail.eu>
> Cc: StrawberryTea <look@strawberrytea.xyz>,  emacs-devel@gnu.org
> Date: Thu, 02 Nov 2023 16:11:48 +0100
> 
> I was the other participant in the original discussion that led to this
> thread.

Once again: too bad that the whole discussion, with all its details,
does not happen on our bug tracker, but on some GitHub site.  The
details should be posted here, all of them, to help us understand and
investigate the issues.

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

Even if you set debug-on-error non-nil?  If so, I'd love to see a
reproduction recipe to understand why this happens.

> The backtrace was
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   eshell-syntax-highlighting--highlight-elisp(113 120)

So you are saying that if instead we'd see

  Debugger entered--Lisp error: (wrong-type-argument string-or-buffer-p nil)
    eshell-syntax-highlighting--highlight-elisp(113 120)

it would have been much better?  Would you mind explaining to me how
would that be much more helpful?  Because I don't see it.

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

And knowing that eshell-syntax-highlighting--highlight-elisp calls
with-current-buffer, the error message still made no sense?  How so?

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

We could improve the diagnostics of set-buffer.  But I'm still at a
loss how that would have helped you here when "stringp nil" did not.