From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59137 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.gnus.general Subject: Re: Change in bytecomp.el breaks Gnus Date: Sun, 14 Nov 2004 11:29:28 -0600 (CST) Message-ID: <200411141729.iAEHTSQ24178@raven.dms.auburn.edu> References: <877jouepy8.fsf@telia.com> <200411111745.iABHji207636@raven.dms.auburn.edu> <871xezbtyh.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1100453449 21153 80.91.229.6 (14 Nov 2004 17:30:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 Nov 2004 17:30:49 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, monnier@iro.umontreal.ca, ding@gnus.org Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Sun Nov 14 18:30:37 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CTOCz-0004LC-00 for ; Sun, 14 Nov 2004 18:30:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTOLe-0006v8-4f for gebp-emacs-pretest-bug@gmane.org; Sun, 14 Nov 2004 12:39:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CTOLb-0006ur-Hk for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 12:39:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CTOLb-0006uf-4Y for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 12:39:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTOLb-0006ub-1R for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 12:39:31 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CTOCf-0000iN-7t for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 12:30:17 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id iAEHUGFu010068; Sun, 14 Nov 2004 11:30:16 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id iAEHTSQ24178; Sun, 14 Nov 2004 11:29:28 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: yamaoka@jpl.org In-reply-to: (message from Katsumi Yamaoka on Sun, 14 Nov 2004 15:10:44 +0900) X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: emacs-pretest-bug.gnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.pretest.bugs:4661 gmane.emacs.gnus.general:59137 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59137 Katsumi Yamaoka wrote: Because it will grow up to be not a few numbers of warnings if we don't take any countermeasure. It makes it hard to find important messages from such chaos. In Emacs, the situation is already hopeless. I redirected make bootstrap's error messages to a file. That file is 8155 lines long. Not all these lines are compiler warnings but a lot of them are. `(elisp)Coding Conventions' says to avoid compiler warnings, but many authors ignore this. In fact, it seems obvious that many authors not only do not worry about silencing compiler warnings, they do not even look at them. Many authors seem to believe that _all_ compiler warnings are bogus anyway and act accordingly. In fact, I have seen people silence compiler warnings them without even checking whether they are bogus or not. Most warnings are of the "function may not be defined at runtime" or "assignment to free variable" type. There are such an enormous amount of them that we have, practically speaking, no choice but to assume that they are bogus until proven non-bogus. Most "function from cl package called at runtime" seem to involve situations where loading the .el file loads cl, but loading the .elc does not. I believe that this is acceptable, in which case most of these warnings are bogus. Most "obsolete variable" warnings are not bogus, but fixing them does not seem urgent. Most of the new "designed for interactive use" warnings are probably not bogus, but they have to be looked at individually. Every single "assigning to a constant" warning seemed to be non-bogus. These are actually real non-trivial bugs, because reloading the file will erase all changes made in the Emacs session. I will discuss these separately. Sincerely, Luc.