From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#16573: 24.3; Auctex (11.87.2) in Elpa issues hundreds of warnings on compile Date: Fri, 31 Jan 2014 09:49:50 -0500 Message-ID: References: <87a9ee8u1y.fsf@thinkpad-t61.fritz.box> <87ppn9nbn4.fsf@gnu.org> <87lhxxn4rn.fsf@gnu.org> <87a9edmwzb.fsf@gnu.org> <87eh3obhv5.fsf@thinkpad-t61.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391180830 23241 80.91.229.3 (31 Jan 2014 15:07:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 15:07:10 +0000 (UTC) Cc: David Kastrup , Neil Jackson , 16573@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 31 16:07:16 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1W9FgY-00072K-4q for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 16:07:14 +0100 Original-Received: from localhost ([::1]:56243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9FgX-0007Un-Mk for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 10:07:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9FQG-0004G3-Kd for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:50:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9FQ9-0007ym-Af for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:50:24 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9FPu-0007iS-CF; Fri, 31 Jan 2014 09:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W9FPt-0007Y4-Lk; Fri, 31 Jan 2014 09:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-auctex@gnu.org Resent-Date: Fri, 31 Jan 2014 14:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16573 X-GNU-PR-Package: emacs,auctex X-GNU-PR-Keywords: Original-Received: via spool by 16573-submit@debbugs.gnu.org id=B16573.139117979429000 (code B ref 16573); Fri, 31 Jan 2014 14:50:01 +0000 Original-Received: (at 16573) by debbugs.gnu.org; 31 Jan 2014 14:49:54 +0000 Original-Received: from localhost ([127.0.0.1]:42481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9FPl-0007Xf-S9 for submit@debbugs.gnu.org; Fri, 31 Jan 2014 09:49:54 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:20918) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9FPj-0007XV-Ni for 16573@debbugs.gnu.org; Fri, 31 Jan 2014 09:49:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+J67/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJC6HcAbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFHO+J67/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJC6HcAbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46492302" Original-Received: from 206-248-158-187.dsl.teksavvy.com (HELO pastel.home) ([206.248.158.187]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 31 Jan 2014 09:49:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C34036035F; Fri, 31 Jan 2014 09:49:50 -0500 (EST) In-Reply-To: <87eh3obhv5.fsf@thinkpad-t61.fritz.box> (Tassilo Horn's message of "Fri, 31 Jan 2014 10:50:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84359 Archived-At: >>> I guess I should wrap those TeX-auto-add-type calls with a >>> `eval-when-compile', right? >> You could. > No, I get a compile error in tex.el when compiling Of course, eval-when-compile and eval-and-compile come with their own set of problems. My "you could" wasn't really meant as an encouragement. >> Or you could turn them into macros. > Indeed, that looks like a typical use-case for macros, but I'm rather > sure that there's a good reason that the auto parser stuff is like it > is. David? Whatever the reason, looking at the code of TeX-auto-add-type, I think it *really* should be turned into a macro, and use defvar/defalias instead of set/fset. > While we are at it: David, is there any reason why somebody would want > to set TeX-install-font-lock to 'ignore nowadays so that font-latex is > not loaded? Would that make AUCTeX use tex-mode.el's font-lock rules? >> Good question. We usually use `declare-function' for these, but >> admittedly, it's not a great solution. > I see. The reason for the code above is that foo is only callable in > very special conditions. That's what I expected. We also have such code in various parts of Emacs. But we don't have a really good solution w.r.t to silencing those warnings. One potential solution I haven't investigated is to create a new `require-autoload' which behaves somewhat like `require' (when interpreted) but which the compiler would replace by a bunch of autoloads (auto-generated by the compiler by taking the intersection of the functions provided by the `require' and the functions called in the file). So you'd replace that code with (require-autoload 'url-util) (defun foo () (url-util-* ...)) and url-util would only be loaded once you call `foo'. Maybe `require-lazy' would be a better name for it, but in any case as long as it's not implemented, its name doesn't matter much. Stefan