emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]