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

[Emanuel Berg]

T.V Raman wrote:

> 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 -- 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
>
>             And by the way when this was fixed a few  months ago, it
>             ws fixed in the Emacs tree.

Maybe, but the only way to approach it is still "does this
warning make sense or not?" If it does, it should, regardless
of everything else, be left to say what it says.

Especially with native-compile there are tons of warnings,
instalation, vanilla Emacs, ELPA, you name it, but again, the
problem isn't the warnings but the people who write to code
who don't fix them, really.

Maybe native-compile in particular is too new and people will,
when they start to use it more, be more aware of those
warnings and more motivated to fix them.

As for this docstring warning not to have lines over 80 chars
... isn't that a good warning, that makes sense to have?

There is also this you can run, for packages

  (checkdoc-current-buffer t)

And this - related - to improve the Elisp quality:

  
https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html

Hm, that's a lot of stuff to help us improve, maybe someone
can integrate it into a linter or whatever the technical term
is, a static code analyzer?

In *Packages* for ELPA and MELPA, M-x how-many RET lint RET is
88, but that is for all languages represented there, e.g.

  closure-lint-mode 20101118.2124 available melpa minor mode for the Closure 
Linter

for Closure and so on.

-- 
underground experts united
https://dataswamp.org/~incal