From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: sea-level rise of byte-compilation warnings [was: Fixing...byte-compilation warnings...] Date: Sun, 15 Nov 2015 08:07:01 -0800 (PST) Message-ID: References: <5645F670.9040601@online.de> <56460E2B.10603@cs.ucla.edu> <87io54c0es.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447708900 25876 80.91.229.3 (16 Nov 2015 21:21:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2015 21:21:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: daniel sutton , Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 16 22:21:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZyRDE-0005cd-Gg for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 22:21:20 +0100 Original-Received: from localhost ([::1]:49688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyRDE-0005BW-06 for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 16:21:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zxzpi-0001bJ-Cm for emacs-devel@gnu.org; Sun, 15 Nov 2015 11:07:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zxzpe-0005Nu-Aj for emacs-devel@gnu.org; Sun, 15 Nov 2015 11:07:14 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zxzpe-0005Nq-4m for emacs-devel@gnu.org; Sun, 15 Nov 2015 11:07:10 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAFG72a7021432 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Nov 2015 16:07:03 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAFG72JS028391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Nov 2015 16:07:02 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAFG71V0026692; Sun, 15 Nov 2015 16:07:02 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194558 Archived-At: > It seems like this warning needs to go to new consumers > but not in the core. You mean don't bother developers of the core, but just bother everyone else? Why is that TRT? Or by "consumers" perhaps you meant new core code as opposed to old core code? Old code is still hacked on, so warnings should be as appropriate for it as for new code that consumes it. > Perhaps there could be a list of ignorable warnings > that could be suppressed when in the core?=20 Perhaps we should just remove one or two of the shiploads of warnings that have been piled on in the last few years? Or at least provide clear guidelines for 3rd-party libraries, as to how to make the code itself warningless when byte-compiled by its users. The degree of warning is now overkill in many contexts (even for novices, it could be argued). But it is particularly annoying for package authors to have to reassure users that warnings they see are "normal", because of code that adapts to multiple Emacs versions. This kind of warning is far more ubiquitous for 3rd-party packages than it is for "core" code, which has less (little) concern/need for such adaptation. The current case is an exception that proves the rule. And I'm glad that the "core" occasionally gets a taste of its own medicine in this regard. Maybe that will help lead to a saner approach to such warnings in general. I don't see why the question of drowning in a sea of typically worthless warnings is relevant only to "when in the core"? What is so special about "the core" in this regard? Please find a solution for all Emacs developers and users, not just those hacking on the "core". And yes, it is useful to have (most) such warnings. What is needed is to: * be able to notice the important ones, while also showing ones that are less important * be able to have the code itself easily (and conditionally) inhibit them - as a whole or by type --- FWIW, my crystal ball whispers that just analyzing the code for sexps that are protected by `fboundp' might go a long way toward eliminating many spurious warnings. I'm not saying that such analysis is easy or that it would be super-accurate, but any such might be an optional aid that users could take advantage of. Another possibility might be to come up with a macro or two that somehow encapsulates the use of things like `fboundp' and perhaps even `featurep' or Emacs version tests for accommodating different Emacs versions. (There were (are?) such macros for handling code that is conditional for XEmacs vs GNU Emacs, for instance.) Code that uses such macros could easily be optionally (conditionally) made immune to the corresponding irrelevant warnings. But misuse would of course mean missing some relevant ones. And then there is the need to explicitly include the macro definitions when using older Emacs versions that did not define them.