GNU bug report logs - #21465
[PATCH] CC-modes hierarchy

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 21465 <at> debbugs.gnu.org
Subject: bug#21465: [PATCH] CC-modes hierarchy
Date: Wed, 16 Sep 2015 21:49:49 -0400

> 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?

> 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.

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?


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.