[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting problem: eval-after-load and local variables

From: Sebastien Vauban
Subject: Re: Interesting problem: eval-after-load and local variables
Date: Wed, 17 Oct 2012 10:32:55 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (windows-nt)

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 alone,
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 (à 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

>> - It does it (via the predefined autoloads), but the eval-after-load 
>> overrides
>>    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 already
> 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 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?*

> 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 expect 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,

Sebastien Vauban

reply via email to

[Prev in Thread] Current Thread [Next in Thread]