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: Wed, 17 Oct 2012 10:32:55 +0200 Organization: Sebastien Vauban Message-ID: <808vb58pmw.fsf@somewhere.org> References: <80y5j6etfl.fsf@somewhere.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1350462914 29215 80.91.229.3 (17 Oct 2012 08:35:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 08:35:14 +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 Wed Oct 17 10:35:20 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 1TOP60-0001QX-FN for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2012 10:35:20 +0200 Original-Received: from localhost ([::1]:45485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOP5t-0005x9-GY for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Oct 2012 04:35:13 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-2.dfn.de!news.dfn.de!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 121 Injection-Info: mx04.eternal-september.org; posting-host="368fa3c7dc5c1bbe516391bd65bd1ab2"; logging-data="4714"; mail-complaints-to="abuse-VVbKFVtnif8H+i2N2EyTrmui9UKz+5OX@public.gmane.org"; posting-account="U2FsdGVkX1+HZFI1YB1vYwzmvJrmM0FR" User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (windows-nt) X-Archive: encrypt Cancel-Lock: sha1:mF+tOROg8CngOu3ys0LYc3+edsg= sha1:QgN+r0B7iRDUSSSMsikIo/ThgY0= X-Url: Under construction... Original-Xref: usenet.stanford.edu gnu.emacs.help:194969 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:87299 Archived-At: Hi Kevin, Kevin Rodgers wrote: > On 10/16/12 2:02 AM, Sebastien Vauban wrote: >> In order to speed up my Emacs startup, I've put many customizations in >> eval-after-load's, such as: >> >> --8<---------------cut here---------------start------------->8--- >> (eval-after-load "time-stamp" >> '(progn >> ;; format of the string inserted by `M-x time-stamp' >> (setq time-stamp-format "%:y-%02m-%02d %3a %02H:%02M %u"))) >> --8<---------------cut here---------------end--------------->8--- >> >> in order to avoid the require itself in the .emacs file. > > In general, it is not necessary to load a library before customizing its = global > options. You should get the desired effect with just: > > (setq time-stamp-format "%:y-%02m-%02d %3a %02H:%02M %u") 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 alo= ne, but I've applied the same principal to many other blocks of customs. >> Now, this causes a problem, as my local variable customizations aren't >> respected anymore. >> >> For example, I have the following local vars in my file `common.sty' to = set up >> the format of the time-stamp (=C3=A0 la LaTeX): >> >> --8<---------------cut here---------------start------------->8--- >> %% common.sty -- LaTeX common commands and environments >> >> \NeedsTeXFormat{LaTeX2e} >> \ProvidesPackage{common}[2012/10/15 v1.0 Common stuff between documents = and presentations] >> >> % ... >> >> %% End of package >> \endinput % very last line >> >> % Local Variables: >> % time-stamp-format: "%:y/%02m/%02d" >> % time-stamp-start: "Provides\\(Class\\|Package\\){[a-zA-Z-]+}\\[" >> % time-stamp-end: " " >> % End: >> --8<---------------cut here---------------end--------------->8--- >> >> The problem is the following: >> >> - Upon opening the file, Emacs sees it needs to load time-stamp. > > 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... >> - It does it (via the predefined autoloads), but the eval-after-load ove= rrides >> the local variables' value. > > Yes, because the eval-after-load form is apparently evaluated while the > common.sty buffer is current, and the file local variable section has alr= eady > made each variable local to that buffer. > >> - When saving the file, the time-stamp format provided in local vars is = NOT >> applied. > > Actually, I think the file local variables are applied and then overridde= n 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?* > 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. >> In a way, that's perfectly normal. In another, not at all: I would expec= t the >> local vars to win over the wide values, in any configuration (even if my= setq >> were in an eval-after-load construct). >> >> What do you think? > > 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? Best regards, Seb --=20 Sebastien Vauban