[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
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