From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: sea-level rise of byte-compilation warnings [was: Fixing...byte-compilation warnings...] Date: Mon, 16 Nov 2015 23:48:05 +0000 Message-ID: <87y4dxy096.fsf@gmail.com> 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 1447721979 28370 80.91.229.3 (17 Nov 2015 00:59:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 00:59:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 01:59:24 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 1ZyUbx-0000tt-Vb for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 01:59:06 +0100 Original-Received: from localhost ([::1]:53782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyUbx-0004fk-Ir for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2015 19:59:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZySa4-0006We-7O for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:49:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZySZz-0002G0-8e for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:49:00 -0500 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZySZz-0002Fw-3N for emacs-devel@gnu.org; Mon, 16 Nov 2015 17:48:55 -0500 Original-Received: by wmec201 with SMTP id c201so937441wme.1 for ; Mon, 16 Nov 2015 14:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=USPvQFNmKP8vjK1cbgLVIfbJVOoEbjontWCvrzEYbqg=; b=XVF30EBhfswNY1BFndldSYAJFMiaTnVYEn3GvFDOWQHminQPd8AyDcpFU5/YT/UME/ QSyMY0TMR/pmoYpfrkkIF5ylAPOsNYE+DW3js4Uj2mY2TMXkH6n1FGiyjiaGKZlBGf7s QVEdw54MT5vfGWKctCL6ezGIlp6ciVHgzxyWBcwMbkaxPuuxQ8NdNKi5loyZEf0N/CMq 5VqGxG4sV/2JiUTEMYNkQUo4JjEUjxcDYHad/W+kQP+Hvvo0n2gkZejJ/yTmhU+/27yL wJKkL8vckcrS/L2/5KCgeYm1/XGD5HLNz5l4TXWl33fv9678KdGFO3ix+MGJ6ttJM0Ba MOWA== X-Received: by 10.194.185.42 with SMTP id ez10mr30739062wjc.82.1447714134437; Mon, 16 Nov 2015 14:48:54 -0800 (PST) Original-Received: from Gandalf-Linux.gmail.com (host-92-12-87-116.as43234.net. [92.12.87.116]) by smtp.gmail.com with ESMTPSA id h189sm20748029wme.1.2015.11.16.14.48.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 14:48:52 -0800 (PST) In-Reply-To: (Drew Adams's message of "Sun, 15 Nov 2015 08:07:01 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22f 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:194606 Archived-At: Drew Adams writes: > 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. In my experience, 90% of the superfluous warnings are silenced by a `defvar' or a `declare-function'. Finally, with-no-warnings should cover the last 10. If this isn't well documented it really should be. The reason we can't just remove one or two shiploads of these warnings is that they could be pointing to actual problems (in my experience, about 1/3 of the time they are), such as functions/variables that weren't required. > The degree of warning is now overkill in many contexts > (even for novices, it could be argued). I don't usually feel overwhelmed by the warnings. Most of my elisp files have 0 to 3 of these warning-suppressing forms. Only the really large projects with 10+ files end up having a lot. I'm curious what are your contexts. I guess you're supporting Emacs versions < 24.1? > What is needed is to: > > * be able to notice the important ones, while also > showing ones that are less important Different warning levels might be nice, but (looking at `byte-compile-warnings') the only warnings that don't immediately mean =E2=80=9Cthis code might break=E2=80=9D are the `cl-functions', `obsolete',= and `mapcar'. So I don't know how much it would help your warning flood. > * be able to have the code itself easily (and > conditionally) inhibit them - as a whole or by type Like I said, with-no-warnings inhibits them locally, but I perfectly agree there should be a way to suppress warnings on a file-local (and maybe dir-local) basis. > 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. My psychic senses agree.