From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: defvars at compile time Date: Tue, 28 Mar 2006 14:20:43 -0500 Message-ID: <87lkuugz78.fsf-monnier+emacs@gnu.org> References: <20403.1141690692@olgas.newt.com> <3861.1142268982@olgas.newt.com> <22907.1142318606@olgas.newt.com> <3669.1142364565@olgas.newt.com> <7035.1142372131@olgas.newt.com> <28215.1142437339@olgas.newt.com> <87fyldk4tx.fsf-monnier+emacs@gnu.org> <873bhbcjfj.fsf-monnier+emacs@gnu.org> <87hd5jny5h.fsf@olgas.newt.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1143573674 30089 80.91.229.2 (28 Mar 2006 19:21:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2006 19:21:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 28 21:21:12 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FOJkW-00058U-8F for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2006 21:21:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOJkV-0004Vj-Nq for ged-emacs-devel@m.gmane.org; Tue, 28 Mar 2006 14:21:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FOJkG-0004Ro-QQ for emacs-devel@gnu.org; Tue, 28 Mar 2006 14:20:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FOJkE-0004PC-Oc for emacs-devel@gnu.org; Tue, 28 Mar 2006 14:20:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FOJkE-0004P5-Ls for emacs-devel@gnu.org; Tue, 28 Mar 2006 14:20:46 -0500 Original-Received: from [209.226.175.74] (helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FOJm1-00031u-Ga for emacs-devel@gnu.org; Tue, 28 Mar 2006 14:22:37 -0500 Original-Received: from alfajor ([70.55.143.15]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060328192044.MOEF16051.tomts20-srv.bellnexxia.net@alfajor>; Tue, 28 Mar 2006 14:20:44 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 511D7D7393; Tue, 28 Mar 2006 14:20:43 -0500 (EST) Original-To: Bill Wohler In-Reply-To: <87hd5jny5h.fsf@olgas.newt.com> (Bill Wohler's message of "Mon, 27 Mar 2006 17:41:46 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:52159 Archived-At: >> Well, I'd have to strongly disagree with "have to". Nothing forces you to >> remove all compilation warnings for all supported emacsen. > Not in Emacs perhaps, but MH-E conventions require it. Well, that's your choice, of course. > And I'd argue that it should be required in Emacs as well. I'd strongly oppose it. I could OTOH accept a policy that Emacs packages should not output any warning when compiled with the Emacs version that they come with. Because then we have a lot more freedom to fix the problematic warning either in the package, or in byte-compiler, or ... >> It's much worse than that. It's fundamentally wrong to make code less >> readable for the sake of compiler warnings. Compiler warnings are there to >> help you find bad code and improve it. > Assuming you find the warning. The problem with a forest of compiler > warnings is that warnings you might want to see are hidden. Because > MH-E code compiles clean, if an error or warning appears, it stands > out loud and clear. That doesn't contradict what I said. > Asking how to write code that doesn't generate compiler warnings is a > legitimate question. If you can suggest a clean way to do this, we'll > do it. As mentioned, for your original problem, the byte-compiler was fixed so it doesn't generate a warning for this code any more. For that particular problem, it is *the* clean way to fix the warning. If you want to eliminate the warning without allowing yourself this clean fix (e.g. by insisting dogmatically that all warnings must go, even when compiling with some older byte-compiler), you'll end up with uglier and less maintainable code. Stefan