From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/59138 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.gnus.general Subject: Re: Change in bytecomp.el breaks Gnus Date: Sun, 14 Nov 2004 14:17:08 -0500 Message-ID: <877joo45bz.fsf-monnier+emacs@gnu.org> References: <877jouepy8.fsf@telia.com> <200411111745.iABHji207636@raven.dms.auburn.edu> <871xezbtyh.fsf-monnier+emacs@gnu.org> <200411141729.iAEHTSQ24178@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1100459871 14318 80.91.229.6 (14 Nov 2004 19:17:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 Nov 2004 19:17:51 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, yamaoka@jpl.org, ding@gnus.org Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Sun Nov 14 20:17:38 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 1CTPsX-0001H6-00 for ; Sun, 14 Nov 2004 20:17:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTQ1C-0005py-N1 for gebp-emacs-pretest-bug@gmane.org; Sun, 14 Nov 2004 14:26:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CTQ19-0005pe-OR for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 14:26:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CTQ19-0005pK-3N for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 14:26:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTQ19-0005pA-0J for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 14:26:31 -0500 Original-Received: from [209.226.175.184] (helo=tomts22-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CTPs6-0001nu-Id for emacs-pretest-bug@gnu.org; Sun, 14 Nov 2004 14:17:10 -0500 Original-Received: from alfajor ([70.48.82.245]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041114191709.DOMX1919.tomts22-srv.bellnexxia.net@alfajor>; Sun, 14 Nov 2004 14:17:09 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 9F1B8D7396; Sun, 14 Nov 2004 14:17:08 -0500 (EST) Original-To: Luc Teirlinck In-Reply-To: <200411141729.iAEHTSQ24178@raven.dms.auburn.edu> (Luc Teirlinck's message of "Sun, 14 Nov 2004 11:29:28 -0600 (CST)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:4663 gmane.emacs.gnus.general:59138 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:59138 > 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 compilation warnings are basically useless to anyone else than the author. To fix this part is currently hopeless. To the elisp author, OTOH they can be very handy if she chooses to pay attention to them. > `(elisp)Coding Conventions' says to avoid compiler warnings, but many > authors ignore this. I think there's a whole range of cases: 1 - the author never byte compiles her files. 2 - she byte-compiles occasionally but just ignores all the warnings. 3 - she'd like to pay attention to the warnings, but there's so many that she's discouraged before even starting (anybody who's taken a look at Calc knows what I'm talking about). 4 - she'd pays attention to the warnings but several of them can't be fixed without ugly workarounds. For vars the (defvar foo) form is a godsent, but for functions, there's nothing equivalent (yet). The recently proposed (defun foo) form would be extremely helpful. 5 - ... > 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. Many of those warnings are bogus. One of the most common case of "bogus" is when a CL function is used in a macro and this macro is only used inside the file, so it's only used during byte-compilation and never at runtime. The warning is "bogus" is the sense that it's harmless but it is real in the sense that loading the resulting .elc file will define a macro which will burp if you try to use it without first loading CL. Stefan