From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: bytecomp: doc string wider than 80 spurious warnings are back Date: Wed, 27 Sep 2023 18:16:44 +0200 Message-ID: <87msx7iob7.fsf@dataswamp.org> References: <25876.19565.180274.795481@retriever.mtv.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6700"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:hcrfX2ERqiQn9uK8CSQtyVk6eMs= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 27 21:47:31 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qlaVO-0001UT-T5 for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Sep 2023 21:47:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qlaUr-0007qN-GL; Wed, 27 Sep 2023 15:46:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qlXDn-0008Th-0W for emacs-devel@gnu.org; Wed, 27 Sep 2023 12:17:07 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qlXDj-0007bj-3Z for emacs-devel@gnu.org; Wed, 27 Sep 2023 12:17:05 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qlXDf-0002Lf-QO for emacs-devel@gnu.org; Wed, 27 Sep 2023 18:16:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 27 Sep 2023 15:46:47 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311118 Archived-At: 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