bug#23407: .dir-local settings get obliterated on running a major mode function.

[Alan Mackenzie]

Hello, Stefan.

On Tue, May 03, 2016 at 02:10:45PM -0400, Stefan Monnier wrote:
> >> > +    ;; delay-mode-hooks is set when `byte-compile-file' is the caller.
> >> > +    ;; It is essential that we call `hack-local-variables' in order to
> >> > +    ;; set up `lexical-binding', since `run-mode-hooks' is prevented
> >> > +    ;; from doing its job.
> >> > +    (when delay-mode-hooks
> >> > +      (with-demoted-errors "File local-variables error: %s"
> >> > +        (hack-local-variables 'no-mode))))

> >> But this seems terribly brittle.  Do we care about delay-mode-hooks (as
> >> the code says) or about byte-compile-file (as the comment says)?

[ .... ]

> Hmm... so you're working around someone else's hack!

Yes, so is life.

> > if hack-local-variables isn't run, lexical-binding (for example) doesn't
> > get set up, and make bootstrap fails.

> Of course: hack-local-variables should be run unconditionally.

> >> If it's the former, then the comment needs to be fixed, if it's the
> >> latter, than we need to find some other way to tell this code what's
> >> going on.
> > I don't really understand the question.  Sure, that bit of code is ugly.
> > But the comment both motivates ("it's `byte-compile-file''s fault") and
> > explains the problem (which is that `delay-mode-hooks' being set would
> > prevent `run-mode-hook', and thus `hack-local-variable' from running).
> > It is possible that other stuff might call `normal-mode' like this.
> > What sort of changes do you advocate for the comment (or for the code)?

> How 'bout doing

>     (setq-local hack-local-variables--done t)

> in hack-local-variables, and then testing that instead of testing
> delay-mode-hooks?

That's even more horrible.  What I've done is tidy up the comment (which
now makes no reference to byte-compile-file) and committed the change.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).