[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: improving debug output of get-buffer
From: |
Rahguzar |
Subject: |
Re: improving debug output of get-buffer |
Date: |
Thu, 02 Nov 2023 17:57:03 +0100 |
User-agent: |
mu4e 1.10.7; emacs 29.1 |
Thanks Eli,
Eli Zaretskii <eliz@gnu.org> writes:
> 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.
I agree with this but this was me trying to provide a fix for a package
maintained by someone else so it was somewhat out of our control. I did
try to provide some context.
> Even if you set debug-on-error non-nil? If so, I'd love to see a
> reproduction recipe to understand why this happens.
I will try to come up with a `emacs -Q` recipe.
> 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.
For me at least, I don't always remember than it is possible to pass a
buffer name to `with-current-buffer` and in this particular case I had
expected that argument to be a buffer object but it turned out to
be nil. So when I saw `(wrong-type-argument stringp nil)` I just went
looking for a string in the body of `with-current-buffer` without
realizing that the string, this error is referring to might be buffer
name. With `(wrong-type-argument string-or-buffer-p nil)` I think I
would have looked for a `BUFFER-OR-NAME` argument and found 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?
See above, I mistakenly thought I was passing a buffer object.
> 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.
As a clumsy programmer I cause quite a lot of errors, a sizable of them
of `stringp nil` variety and mostly they are caused by wrong
manipulation of strings. So when I see it I tend to hunt for strings I
in the code. I think `buffer-or-string-p` will narrow down the places
where I need to look quite substantially.
Thanks,
Rahguzar