Re: next bugfix release?

[Alan Mackenzie]

Hi, Nick,

On Thu, Aug 20, 2009 at 11:16:18AM +1200, Nick Roberts wrote:
>  > Yes.  It's one of these @dfn{wallpaper paste} bugs, where when you
>  > press an area of wallpaper firmly to the wall, the paste under it
>  > pops up another bit of wallpaper somewhere else.  It's going to be
>  > a horrible bug to fix.  Indeed, it may not be fixable, in the sense
>  > of doing the Right Thing under every reasonable circumstance.

> Such 'bubbles', usually called regressions, ....

No, that's not what I meant (although it is also a regression).  I was
talking about the high complexity caused by the number of things that
all have to work right at the same time.  The "fix" I made to cc-mode.el
in July fixed one problem but created another.  Getting them all working
simultaneously is going to be hard.

This complexity has increased recently due to the new feature "directory
locals".  I didn't become aware of this when it was introduced (my bad),
and the person who wrote it wasn't aware of the trouble it would cause
CC Mode (why should he be?).

The trouble is, there are too many ways of setting a CC Mode "style
variable" (such as c-basic-offset), @xref{Config Basics,,, ccmode}.  It
is not always the last setting which should prevail over previous ones.
It is a complexity which nobody would design; it has emerged as such
over CC Mode's lifetime, and is now a mess.  the .dir-locals feature may
have pushed the complexity over the edge of what is manageable.

> ...., might be less likely to appear if, as Cyd suggested, there was a
> CC mode equivalent of compilation.txt.

Er, what's .../etc/compilation.txt about?  It has an alleged explanation
at the top, but that only makes sense if you already have some context.
For example, you need to know why you'd "need matchers", and what sort
of "matchers" they are.

> I can't find this post now, so apologies if it reached a logical
> conclusion.  It might also be harder to implement than
> compilation.txt, as expressions are probably not as self contained,
> but some kind of testuite seems essential to prevent these issues from
> recurring.

CC Mode has an extensive test suite for (static) indentation and
fontification.  It doesn't have any such tests for things like
initialisation of the mode, execution of CC Mode commands, or for
indentation/fontification after buffer changes.  I would very much
welcome anybody stepping forward who had the time and energy to write
these tests.

> Nick

-- 
Alan Mackenzie (Nuremberg, Germany).