bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 16, 2015 at 09:49:49PM -0400, Stefan Monnier wrote:
> > It may appear to, but c-after-change does important things like
> > invalidating caches, and preparing the buffer for font locking.  Sooner
> > or later, something will go wrong.  (Unless you've put in an
> > sm-c-after-change, or something like that.)  But you probably know this.

> That's right.

> > This is one of these "please don't report any bugs whilst this is
> > active".

> I still have no idea why you think it's right for c-after-font-lock-init
> to add c-after-change to after-change-functions if it's not there in the
> first place.
> I understand why you might not consider it as a bug, but why do you
> consider it as a feature?

We're bikeshedding.

I suppose it doesn't really matter if we check for the presence of
c-after-change first.  It's more code, that's all.  But it doesn't
really matter.  Hopefully _nobody_ (except someone like yourself who
knows what they're doing) is going to try running without
c-after-change.

> > Again, why do you want to take it out of your Awk Mode?

> Because I'm trying to make my awk-mode behave in "the standard way" used
> by all other (non-cc) major modes.  E.g. using syntax-propertize.

Ah, OK.

> I know we disagree on whether "like everyone else" is a quality or
> a defect, but I'd ask you to try at least not to actively and
> gratuitously prevent me from writing a mode that uses the cc-mode
> infrastructure yet behaves a bit more "like everyone else".

> So, to put it some other way: can you give me a concrete example where
> my change to c-after-font-lock-init is harmful?

Provided you have the functionality of c-after-change in there correctly
somewhere, then it shouldn't be harmful.

So I withdraw my objection to that change to c-after-font-lock-init.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).