emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bytecomp: doc string wider than 80 spurious warnings are back


From: Stefan Kangas
Subject: Re: bytecomp: doc string wider than 80 spurious warnings are back
Date: Thu, 28 Sep 2023 00:38:54 -0700

"T.V Raman" <raman@google.com> writes:

> Hope  it gets fixed upstream in Hydra. But stepping back a level:
>
> 1. Byte Compiler warnings are really useful when developing in Emacs
>    Lisp.
>    2. But they lose their value if the byte compiler gets noisy

No disagreement there.

>                                                                 -- in
>       this case I think this warning qualifies as noise because:
>
>       A. The developer who is hit with this warning can do nothing
>          about it
>          B. It obscures more useful warnings
>

A typical case looks like this:

  (defmacro foo (name)
    `(defun bar ()
       ,(format "foo %s." name)))

If someone passes in a string NAME longer than 80 characters, that will
generate a warning.  It is the responsibility of whoever writes a macro
to ensure it doesn't generate long docstrings by properly wrapping it.
The same is true for any byte-compiler warning.

In core we use `internal--format-docstring-line' for this, which means
that fixed code for the above would look like this:

    (defmacro foo (name)
      `(defun bar ()
         ,(internal--format-docstring-line
           (format "foo %s." name))))

I don't think there's anything we can do about macros in third-party
packages, unfortunately.  Perhaps `internal--format-docstring-line' is
useful enough not to be marked internal, though?  I'm not sure.

>             And by the way when this was fixed a few  months ago, it
>             ws fixed in the Emacs tree.

But that warning was due to a macro in our tree, right?



reply via email to

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