Re: [RFC PATCH] setting indentation styles via `c-file-style' fails to actually change indentation

[Nix]

On 2 Jun 2011, Alan Mackenzie stated:

> Hi, Nix.
>
> On Thu, Jun 02, 2011 at 05:47:16PM +0100, Nix wrote:
>> On 2 Jun 2011, Alan Mackenzie told this:
>> > At a guess, the bug is caused by calling c-file-style with a setting of
>> > `dont-override' which causes it to choke on the above hacks.
>
>> Er, yes. Did you miss my original post? 'cos I came to that conclusion,
>
> Sorry, I got a bit confused by the length of your post.

That's fine, I had trouble understanding it myself :)

>> and have a patch, which works for me, at least... but it's rather ugly,
>> so if there is a better way which would still allow setting of styles on
>> file-by-file and directory-(class)-by-directory-(class) basis, then I'm
>> glad to try that instead!
>
> I'm concerned that adding the extra value 'default to dont-override, and
> also the two extra variables, might be an unwarranted increase in
> complexity.

Yes :( but every other solution seemed to be even *more* complex.

> But first, I'd like to understand exactly what the bug is.  For a start,
> _please_ tell me which version of Emacs you're testing with.  Anyhow,
> ...

This happens with trunk Emacs (24.1-to-be).

>> Now. Add that same c-file-style as a file-local or directory-local
>> variable to that other style. Reopen it. 'c-basic-offset' hasn't
>> changed from the 'gnu' default, but 'c-indentation-style' proclaims
>> that the style has in fact been set. In fact, 'c-basic-offset' is
>> permanently stuck at the value specified for 'gnu', no matter what
>> style you asked for. And this is true for every single variable that
>> is set by the 'gnu' style, and for the pieces of 'c-offsets-alist' as
>> well.
>
> I think what you're saying is that in a file like this,
>
>     int main (int argc, char *argv[])
>     {
>         printf ("Hello, world!\n") ;
>     }
>     /* Local Variables: */
>     /* c-file-style : "linux" */
>     /* End:             */
>
> , c-basic-offset remains 4, when it ought to become 8.  Is this in fact
> the bug you have found?

Not quite. In a file like this:

int main (int argc, char *argv[])
{
    printf ("Hello, world!\n") ;
}

with this style in effect:

(c-add-style "otbs" '("bsd" (c-offsets-alist . ((statement-cont . 4)
                                                (inextern-lang . 0)
                                                (label . 0)
                                                (arglist-cont-nonempty . 4))))))

and with directory local variables set (in my case) via

(dir-locals-set-class-variables 'unix '((c-mode . ((c-file-style . "otbs")
                                                   (fill-column . 80)
                                                   (indent-tabs-mode . t)))))

and the file assigned to the 'unix directory class, not a single one of
the 'otbs style elements take effect. Neither do the inherited 'bsd
elements. This differs from your case firstly because it tests style
inheritance, which is all tangled up with this, and secondly because it
tests dir local variables, which are where the breakage is visible.

> Just one thing: are you absolutely sure you got the syntax of your Local
> Variables: section correct?  If not, I think Emacs just fails to
> recognise it without giving an error message.

I can never actually remember the syntax of that section, because I
hardly ever use it: it's rather unfriendly when working in projects
where most members don't use Emacs, and apt to be inconsistent as files
you do not create don't have any of the variables set. Directory local
variables solve both these problems :)

> [ ... ]
>> DONT-OVERRIDE is clearly doing what it is specified to do. However,
>> since 'c-set-style' may be called more than once when initializing a
>> buffer, .....
>
> Critical here is what value of `dont-override' is used in each of these
> calls.

Well, it's called once at initialization time with the c-default-style
with dont-override set to 't' iff, oh, gods, you can read that code as
well as I can and I'm too smashed on antihistamines to parse it right
now. Then it gets called again in `c-before-hack-hook' with
dont-override set to 't' iff the only c-file-style was in the directory
local variable. (The rationale for this remains opaque to me, but since
the underlying bug in my case was in the first part I didn't investigate
that bit too closely. The style doesn't end up set to the directory-
local style: it ends up set to the default!)

Plus, each of these calls the underlying style-addition function
repeatedly for inherited styles.

>> ... the net effect of these semantics is to set variables which are
>> defined in the 'c-default-style' as well as in the 'c-file-style' to
>> their values in the 'c-default-style', which is surely wrong: the
>> 'c-default-style' is a global fallback, and should not take precedence
>> over per-file or per-directory indentation styles.
>
> That is true.  The question is why is the c-set-style for the
> `c-file-style' not doing its job?.  Normally it would override the
> default style just set up.

It doesn't :( again, the email describes it more clearly than I can in
my current hayfever-wrecked state.

> Anyhow, first I need to be able to reproduce the bug.  Any help you can
> give me with this will be most appreciated.

Maybe the pollen count will go down soon and I can think about this
more clearly...

-- 
NULL && (void)