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

[T.V Raman]

Agreed on everything except the last: Yes, we  cant do anything about
third party macros, but we  == Emacs is the one displaying the
docstring, so we can surely break ourselves free from the docstring
not  being wider than 80 chars; and for instance, in your example, the
function name passed is  a 128-char hyphenated string, then how to
handle that is still better handled in the display algorithm, 

Stefan Kangas writes:
 > "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?

--