bug#17051: Order of evaluation in .dir-locals.el

bug#17051: Order of evaluation in .dir-locals.el

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

I have the following .dir-locals.el for a project:

((nil . ((show-trailing-whitespace . nil)
         (eval . (c-add-style "fontforge"
                              '("stroustrup"
                                (indent-tabs-mode . t)
                                (tab-width . 8)
                                (c-offsets-alist
                                 (case-label . *)))))))
 (c-mode . ((c-file-style . "fontforge"))))

The idea is to define a new c-style and apply it to all files in that
project.

When I first visit a file under that project, I get the error: "Undefined
style: fontforge"

When I examine c-style-alist, "fontforge" is the first entry, and when I
look at c-file-style for that buffer, its value is "fontforge". However, as
the error implies, the style has not been applied to that buffer: if I
check the value of indent-tabs-mode, which I have configured globally to
"nil", it is still nil.

If I then run M-x c-set-style RET fontforge RET, the style is applied as
expected.

Hence, it appears my error has to do with the order of evaluation. I tried
putting the "eval" sexp under the "c-mode" section of the .dir-locals.el,
but that still gives the same error, even when I put it before the
c-file-style sexp.

I can't find anything about this in the manual, or online (i.e. examples
where the result of an "eval" entry are relied on by another entry). In
hack-local-variables-apply files.el I found this bit of code:

    ;; Any 'evals must run in the Right sequence.
    (setq file-local-variables-alist
      (nreverse file-local-variables-alist))

so I tried putting the "eval" part at the end of c-mode's list, but that
didn't help either. (I checked file-local-variables-alist in each case to
make sure that in one the eval was before c-file-style, and in the other,
after).

Can someone please set me straight?

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

bug#17051: Order of evaluation in .dir-locals.el

[Noam Postavsky]

reassign 17051 emacs,cc-mode
severity 17051 minor
tag 17051 + confirmed
quit

The reason this doesn't work is revealed in the docstring of c-before-hook:

c-before-hack-hook is a compiled Lisp function in ‘cc-mode.el’.

(c-before-hack-hook)

Set the CC Mode style and "offsets" when in the buffer’s local variables.
They are set only when, respectively, the pseudo variables
‘c-file-style’ and ‘c-file-offsets’ are present in the list.

This function is called from the hook ‘before-hack-local-variables-hook’.

Of course `before-hack-local-variables-hook' runs before any local
variables are set, so there is no "correct" order that a user can use
in .dir-locals.el to define a new style: `c-file-style' always applies
before any other variables.

bug#17051: Order of evaluation in .dir-locals.el

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On 4 June 2016 at 23:02, Noam Postavsky <npostavs@users.sourceforge.net>
wrote:

>
> Of course `before-hack-local-variables-hook' runs before any local
> variables are set, so there is no "correct" order that a user can use
> in .dir-locals.el to define a new style: `c-file-style' always applies
> before any other variables.
>

​Thanks very much; to check I understand, you're saying that at present
it's not possible to do this all in .dir-locals.el; I'd have presumably to
define the style in my Emacs init sequence (or anyway, load it before
visiting the directory)?

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1192 bytes --]

bug#17051: Order of evaluation in .dir-locals.el

[Noam Postavsky]

On Sun, Jun 5, 2016 at 3:38 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> Thanks very much; to check I understand, you're saying that at present it's
> not possible to do this all in .dir-locals.el; I'd have presumably to define
> the style in my Emacs init sequence (or anyway, load it before visiting the
> directory)?

Yes (though I suppose you might be able to make it work by removing
`c-before-hack-hook' and performing `c-set-style' yourself).

bug#17051: Order of evaluation in .dir-locals.el

[Alan Mackenzie]

Hello, Reuben.

On Thu, Mar 20, 2014 at 03:01:12PM +0000, Reuben Thomas wrote:
> I have the following .dir-locals.el for a project:

> ((nil . ((show-trailing-whitespace . nil)
>          (eval . (c-add-style "fontforge"
>                               '("stroustrup"
>                                 (indent-tabs-mode . t)
>                                 (tab-width . 8)
>                                 (c-offsets-alist
>                                  (case-label . *)))))))
>  (c-mode . ((c-file-style . "fontforge"))))

> The idea is to define a new c-style and apply it to all files in that
> project.

Why are you defining the new style "fontforge" every time a file gets
visited?  Couldn't you simply define it once, directly in your .emacs,
before any C files are loaded (e.g., via desktop-save-mode)?

> When I first visit a file under that project, I get the error: "Undefined
> style: fontforge"

I don't think the order of evaluation of variables in .dir-locals.el is
defined.  The code (in .../lisp/files.el) is not easy to understand.  It
could well be that, for that first file, the c-file-style is being
applied before it has been defined.

> When I examine c-style-alist, "fontforge" is the first entry, and when I
> look at c-file-style for that buffer, its value is "fontforge". However, as
> the error implies, the style has not been applied to that buffer: if I
> check the value of indent-tabs-mode, which I have configured globally to
> "nil", it is still nil.

> If I then run M-x c-set-style RET fontforge RET, the style is applied as
> expected.

> Hence, it appears my error has to do with the order of evaluation. I tried
> putting the "eval" sexp under the "c-mode" section of the .dir-locals.el,
> but that still gives the same error, even when I put it before the
> c-file-style sexp.

Again, I'm not aware of any definition of the order of evaluation.

> I can't find anything about this in the manual, or online (i.e. examples
> where the result of an "eval" entry are relied on by another entry). In
> hack-local-variables-apply files.el I found this bit of code:

>     ;; Any 'evals must run in the Right sequence.
>     (setq file-local-variables-alist
>       (nreverse file-local-variables-alist))

> so I tried putting the "eval" part at the end of c-mode's list, but that
> didn't help either. (I checked file-local-variables-alist in each case to
> make sure that in one the eval was before c-file-style, and in the other,
> after).

> Can someone please set me straight?

Would you please try defining your CC Mode style outside of
.dir-locals.el, as suggested above.

It could well be that we need to polish the documentation of this topic a
little.

> -- 
> http://rrt.sc3d.org

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#17051: Order of evaluation in .dir-locals.el

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On 7 June 2016 at 12:23, Alan Mackenzie <acm@muc.de> wrote:

>
> Why are you defining the new style "fontforge" every time a file gets
> visited?


​The idea was to define a per-project style every time that project's
directory was visited.​

  Couldn't you simply define it once, directly in your .emacs,
> before any C files are loaded (e.g., via desktop-save-mode)?
>

I would prefer to keep the per-project style with the project code.​


> ​​
> Would you please try defining your CC Mode style outside of
> .dir-locals.el, as suggested above.
>

​That works fine (I do it for other styles that are more widely
applicable).​

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1735 bytes --]

bug#17051: Order of evaluation in .dir-locals.el

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

>> When I first visit a file under that project, I get the error: "Undefined
>> style: fontforge"
>
> I don't think the order of evaluation of variables in .dir-locals.el is
> defined.  The code (in .../lisp/files.el) is not easy to understand.  It
> could well be that, for that first file, the c-file-style is being
> applied before it has been defined.

Yes, I don't think the order is well-defined -- the manual talks about
priorities:

---
If the @file{.dir-locals.el} file contains multiple different values
for a variable using different mode names or directories, the values
will be applied in an order such that the values for more specific
modes take priority over more generic modes.  Values specified under a
directory have even more priority. 
---

but I don't see anything about the order.

However, there's the .dir-locals-2.el file -- it'll be run after the
first file, so using that would solve the original use case, I think?

But I don't think there's anything here to fix here, so I'm closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no