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

[Nix]

On 5 Jun 2011, Alan Mackenzie said:

> Hi, Nix.
>
> On Thu, Jun 02, 2011 at 10:43:06PM +0100, Nix wrote:
>> On 2 Jun 2011, Alan Mackenzie stated:
>
>> > On Thu, Jun 02, 2011 at 05:47:16PM +0100, Nix wrote:
>> >> On 2 Jun 2011, Alan Mackenzie told this:
>
>> >> 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!
>
> OK.  Would you please try this patch and let me know how it works.  It's
> a bit less ugly than your one (-:

Sorry for the insane delay, a big system update meant that restarting
Emacs was inadvisable for a few weeks until I'd crushed some (non-Emacs)
bugs. Thankfully there were no power cuts in this period :)

Your fix (in the form you committed it, since I delayed so long) seems
to work, though despite a lot of looking at it I'm not quite sure how!
God knows it's less grotesque than the 'pile things in then filter them
out again' approach I was employing.

>> 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!)
>
> It was an attempt to prevent .dir-local variables from overriding more
> specifically set variables (e.g. set in a hook function).  It didn't work
> very well.  :-(

Yeah. There are arguments on both sides for whether hook functions
should override dir-local (and for that matter file-local) variables.
I'm not sure which way the priorities should run, but I'm fairly sure it
should be consistent for all of Emacs, not just cc-mode, which implies
that we need some sort of helper that everyone can call to disambiguate
these cases.

> 2. Be VERY wary about sending "streams of consciousness"; they can
> sometimes be difficult to make sense of.  Reading them the morning after
> can be helpful.

Yeah, sorry about that. It wasn't actually a stream of consciousness:
it was a victim of repeated over-editing for 'clarity' (for which read
incomprehensibility).

> 3. Don't assume the grizzled senile maintainer can simply follow a patch;
> explain it!  Often the bug submitter, having just spent several hours on
> it, knows the piece of code better than the maintainer.

OK. I've been castigated for over-explaining patches on other lists, and
even for commenting code: nice to know this list is a 'please explain
yourself' list, I much prefer that.

> 4. In Emacs, the standard diff format is contextual (-c), but unified
> (-u) is OK too.

I still don't understand how anyone can read context diffs. :) but then
other poeple find unified diffs impossible to read as well. Obviously
we should use the UK government standard format and send things around
as PDF files with the old text blacked out by inserting a black box
above it. ;}

> So, let me know if the patch works, then we can close this bug.

It works!

-- 
NULL && (void)