--- Begin Message ---
|
Subject: |
29.1; "docstring wider than 80 characters" when there is no docstring |
|
Date: |
Wed, 06 Sep 2023 21:08:29 +0200 |
I have this piece of code:
(cl-defstruct (json-process-client-application
(:constructor json-process-client--application-create)
(:conc-name json-process-client--application-))
message-callbacks)
In GNU Emacs 29.1, "Warning: docstring wider than 80 characters" even
though I wrote no docstring here. I understand the problem lies in the
generated code and I agree the lisp names in my code are long. But, I
don't think the byte compiler should annoy me about docstrings I didn't
write.
What do you think?
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#65790: 29.1; "docstring wider than 80 characters" when there is no docstring |
|
Date: |
Wed, 13 Sep 2023 07:38:31 -0700 |
Version: 30.1
Damien Cassou <damien@cassou.me> writes:
> I've added tests to bytecomp-tests.el as suggested. (why not
> cl-macs-tests.el instead?)
Good question. Perhaps we should move all of those tests to more
relevant locations. OTOH, the macro for this is in bytecomp-tests.el
currently, so I guess we'd have to move that. Maybe it would fit in
ert-x.el. It seems outside the scope of this bug report though.
>> Could we keep the old format when possible, and use the new one only
>> when needed?
>
> I tried to do that, is that what you want? I feel the added complexity
> isn't worth it so I'm fine changing it back to the simpler version if
> you change your mind.
The code is less nice obviously, but I think not changing the
autogenerated docstrings in the typical cases is also important.
Therefore, I think the complexity is ultimately worth it. Perhaps
someone should do a round over all of this to see if it can be cleaned
up a bit, though...
I've now installed your patches on master. Feel free to post followups
if you want to fix any of the above, or if you spot anything else that
could be improved in relation to this.
Thanks again for your efforts.
--- End Message ---