From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Sebastien Vauban" Newsgroups: gmane.emacs.help Subject: Re: Interesting problem: eval-after-load and local variables Date: Fri, 19 Oct 2012 11:40:14 +0200 Organization: Sebastien Vauban Message-ID: <80ehkuu7ep.fsf@somewhere.org> References: <80y5j6etfl.fsf@somewhere.org> <808vb58pmw.fsf@somewhere.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1350639917 4975 80.91.229.3 (19 Oct 2012 09:45:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2012 09:45:17 +0000 (UTC) To: help-gnu-emacs-mXXj517/zsQ@public.gmane.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Fri Oct 19 11:45:25 2012 Return-path: Envelope-to: geh-help-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 1TP98t-0002Wr-Hn for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Oct 2012 11:45:23 +0200 Original-Received: from localhost ([::1]:45872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP98l-0003tD-0x for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Oct 2012 05:45:15 -0400 Original-Path: usenet.stanford.edu!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 72 Injection-Info: mx04.eternal-september.org; posting-host="368fa3c7dc5c1bbe516391bd65bd1ab2"; logging-data="8039"; mail-complaints-to="abuse-VVbKFVtnif8H+i2N2EyTrmui9UKz+5OX@public.gmane.org"; posting-account="U2FsdGVkX198SZCH6L9rH/LUMWsaTUs+" User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (windows-nt) X-Archive: encrypt Cancel-Lock: sha1:3/o8+JWan8XISQ96Squ9oDbpdME= sha1:bJ+hxVgg3ZxpWrou431TZ9p25ik= X-Url: Under construction... Original-Xref: usenet.stanford.edu gnu.emacs.help:194996 X-BeenThere: help-gnu-emacs-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.emacs.help:87326 Archived-At: Hi all, Kevin Rodgers wrote: >> I know. And this is a very somewhat ridiculous example. But, for speed and >> clarity of my .emacs, I've generally put all customs inside an >> eval-after-load. A setq is certainly not time-taker, certainly not when alone, >> but I've applied the same principal to many other blocks of customs. > > I don't see how the eval-after-load boilerplate provides any speed or clarity. I guess you should be convinced for speed. For clarity, using an eval-after-load at least forces one to put all customs of a package at the same place, in a big progn. It also allows to drop all private customs of a package, by simply adding (for example) XXX after the name of the package, in the eval-after-load form. So, I can say it renders the .emacs file better organized if all customs were always in eval-after-load. But, OK, it sometimes so trivial or stupid, that I don't pretend (and don't want) to do it for all packages, especially not for the ones which are part of Emacs. >>> I don't see how, since those variables aren't autoloaded. (Their autoload >>> cookies only result in the safe-local-variable property being dumped into the >>> emacs executable for each symbol.) I suspect you have enabled time stamp as >>> documented in the Emacs manual: >>> >>> Then add the hook function `time-stamp' to the hook >>> `before-save-hook'; that hook function will automatically update the >>> time stamp, inserting the current date and time when you save the file. >>> >>> (The function time-stamp is autoloaded.) >> >> You're absolutely right! I described the correct effect, but not the right >> cause... > ... >>> Actually, I think the file local variables are applied and then overridden by >>> the eval-after-load form (but only for the first file that you save). >> >> Your explanation must be right. But my question was more general, in the >> sense: is this the behavior one would expect? Or *should local vars triumph >> over the setq done in the eval-after-load?* > > We should expect file local variables and eval-after-load to work as documented > -- and they do. It is our responsibility to use them correctly -- but you used > eval-after-load unnecessarily, without considering the context. OK. Fully agreeing, now. >>> Do other files with time stamp templates work as intended? >> >> I'll check (but I've already applied the fix suggested by Michael). I guess >> the answer is yes. > ... >>> I think you should either skip the eval-after-load boilerplate >> >> As said, for this example: you're definitively right. It's kind of useless. >> >>> or use setq-default in the eval-after-load form as suggested by Michael. >> >> Can I use setq-default with whichever var? I guess not. But am I right? > > You _can_ use setq-default on any variable, to ensure that you are setting its > global binding and not the current buffer-local binding (if any). OK, clear. Thanks to all, Seb -- Sebastien Vauban