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