From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: help-gnu-emacs-mXXj517/zsQ@public.gmane.org
Subject: Re: Interesting problem: eval-after-load and local variables
Date: Fri, 19 Oct 2012 11:40:14 +0200 [thread overview]
Message-ID: <80ehkuu7ep.fsf@somewhere.org> (raw)
In-Reply-To: mailman.11221.1350564945.855.help-gnu-emacs@gnu.org
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
prev parent reply other threads:[~2012-10-19 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 8:02 Interesting problem: eval-after-load and local variables Sebastien Vauban
2012-10-16 9:18 ` Peter Dyballa
2012-10-16 17:54 ` Michael Heerdegen
2012-10-17 3:23 ` Kevin Rodgers
[not found] ` <mailman.11151.1350444234.855.help-gnu-emacs@gnu.org>
2012-10-17 8:32 ` Sebastien Vauban
2012-10-18 4:09 ` Michael Heerdegen
2012-10-18 12:55 ` Kevin Rodgers
2012-10-18 17:46 ` Bob Proulx
[not found] ` <mailman.11221.1350564945.855.help-gnu-emacs@gnu.org>
2012-10-19 9:40 ` Sebastien Vauban [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80ehkuu7ep.fsf@somewhere.org \
--to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
--cc=help-gnu-emacs-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.