Interesting problem: eval-after-load and local variables

Interesting problem: eval-after-load and local variables

[Sebastien Vauban]

Hello,

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.

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.

- It does it (via the predefined autoloads), but the eval-after-load overrides
  the local variables' value.

- When saving the file, the time-stamp format provided in local vars is NOT
  applied.

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?

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Peter Dyballa]

Am 16.10.2012 um 10:02 schrieb Sebastien Vauban:

>  (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")))

With only one statement in the FORM you don't need progn.

--
Mit friedvollen Grüßen

  Pete

When Richard Stallman goes to the loo, he core dumps.

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

[Michael Heerdegen]

Hello,

I think you need to use `setq-default' instead of `setq' - see the
manual for details.  So, that should work:

(eval-after-load "time-stamp"
  ;; format of the string inserted by `M-x time-stamp'
  '(setq-default time-stamp-format "%:y-%02m-%02d %3a %02H:%02M %u"))


Michael.


"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hello,
>
> In order to speed up my Emacs startup, I've put many customizations in
> eval-after-load's, such as:
>
>   (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")))
>
> in order to avoid the require itself in the .emacs file.
>
> 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):
>
> %% 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:
>
> The problem is the following:
>
> - Upon opening the file, Emacs sees it needs to load time-stamp.
>
> - It does it (via the predefined autoloads), but the eval-after-load
> overrides
>   the local variables' value.
>
> - When saving the file, the time-stamp format provided in local vars is NOT
>   applied.
>
> 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?
>
> Best regards,
>   Seb

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

[Kevin Rodgers]

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")

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

> - 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).  Do other
files with time stamp templates work as intended?

> 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, or use
setq-default in the eval-after-load form as suggested by Michael.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

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

[Michael Heerdegen]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> > 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?*

This is absolutely what one would expect.  Whenever a variable x has a
buffer local binding in a buffer b, and you eval (setq x foo) while b is
current, this _always_ sets the local binding of x in b.
`eval-after-load' isn't special here in any regard.  It's just the fact
that you let it eval a setq form with a current buffer that has already
local bindings.

So, setq is the wrong function for you to use in such a context.  If you
want to set the default value of a variable, _always_ use setq-default
when the variable may already have local bindings in effect.

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

Of course you can.  `setq' and `setq-default' both accept any symbol.
The difference is just that

  - setq sets the default value if no buffer local binding is currently
    in effect, else, it sets the local binding

  - setq-default always sets the default binding

In addition, there is a special case of variables that are automatically
buffer-local when they are set in any fashion.

You should really read the chapters Variables > Buffer-Local Variables
and > File Local Variables in the Elisp manual.  It describes it much
better.


Michael.

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

[Kevin Rodgers]

On 10/17/12 2:32 AM, Sebastien Vauban wrote:
> Kevin Rodgers wrote:
...
>> 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.

I don't see how the eval-after-load boilerplate provides any speed or clarity.

...

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

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

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Bob Proulx]

Kevin Rodgers wrote:
> Sebastien Vauban 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 don't know about clarity, although it is nice to know where things
are used, but it can save a very large amount of time when you are
loading up a lot of various bits of emacs functionality.  Things start
up fairly quickly when doing nothing.

  $ time emacs -Q -f kill-emacs
  real    0m0.820s
  user    0m0.088s
  sys     0m0.040s

But on a system where I have many things being loaded with require
this and require that and all of those are required to be loaded
before I have a working emacs and can see and type in anything:

  $ time emacs -f kill-emacs
  real    0m8.362s
  user    0m0.580s
  sys     0m0.168s

That is a *HUGE* difference.  By making use of eval-after-load I have
reduced that startup time to this.  It isn't on the same system and
not directly comparable to the above so I will show both times for
comparison.  And it is on these slower systems where the full load
times were very long and motivated me to optimize the startup.

  $ time emacs -Q -f kill-emacs
  real    0m1.940s
  user    0m0.156s
  sys     0m0.060s

  $ time emacs -f kill-emacs
  real    0m2.423s
  user    0m0.260s
  sys     0m0.132s

And I still have a ways to go.  (Just noting that in the above I
dropped caches between runs making those cold disk accesses for all.)
It was more than 2x slower and the original startup time of the fully
loaded emacs with lots of requires was around 18 seconds.  Getting
that down to less than 2.5 seconds was a huge win.  Now I need to go
back and hit my original machine and get that 8 second load time now.

Using eval-after-load and lazy-loading libraries on demand as they are
needed can be a huge startup speed improvement over simply requiring
libraries and loading every possible thing at every startup.  You
probably aren't going to ise it.  And if you do then you can load it
then.

Bob

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

[Sebastien Vauban]

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