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

[Sebastien Vauban]

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
cause...

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

-- 
Sebastien Vauban