[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21465: [PATCH] CC-modes hierarchy
From: |
Stefan Monnier |
Subject: |
bug#21465: [PATCH] CC-modes hierarchy |
Date: |
Wed, 16 Sep 2015 21:49:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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
Message not available
bug#21465: [PATCH] CC-modes hierarchy, Zhang Kai Yu, 2015/09/15
bug#21465: [PATCH] CC-modes hierarchy, Jostein Kjønigsen, 2015/09/19