Re: Further CC-mode changes

[Stefan Monnier]

>> - BTW, I think it would be better not to enable abbrev-mode (let it be
>> a user's choice).  IIUC CC-mode relies on abbrev-mode internally
>> for some of its electric-indent functionality, so we'd have to use
>> some other approach (e.g. a post-self-insert-hook).
> I tend to agree, having been a bit disgusted myself when I discovered how
> "else" and friends were being electrically indented.
> after-change-functions might be better here, since it's more general, and
> also better supported.

I think "more general" is a disadvantage in this case (I'd rather not
have auto-indentation after I paste a space).
As for better supported, I don't care too much: I'd just keep the old
abbrev code for the Emacsen that don't have post-self-insert-hook yet.

>> This is not really tested, especially not on XEmacs, but AFAIK it
>> doesn't depend on any feature specific to a particular Emacs version.
> "This"??

The patch.

>> - Move awk-mode's actual definition to cc-awk so as to get rid of the
>> (require 'cc-awk) and the ":syntax-table nil" hack.
> Would leave traps for maintainers,

Such as?

> and break uniformity between the modes.

Actually, I think the right move would be to move all awk-related code
into cc-awk.el, thus making it more uniform with the various externally
maintained cc-modes.

> This change wouldn't enhance functionality or maintainability.

The code is cleaner and simpler with the change than without.

>> - make awk-mode use syntax-propertize when available.
> Why?

You know why: `syntax-propertize' is used by all major modes except
cc-mode derived ones.  And it's more efficient, because it's more lazy.
Also its correctness argument is much simpler since it doesn't rely on
interactions between before-change-functions, after-change-functions
(and font-lock), contrary to your code.

> It's a lot of work to change,

It's work I did, pro bono.  Just enjoy it.

> syntax-propertize is only available in relatively recent versions of
> GNU Emacs, and the documentation suggests that syntax-propertize is
> not called after buffer changes in general, the documentation not
> being entirely clear on this point.

Indeed it's not.  If you want to be sure that syntax properties have
been applied upto POS, you need to call (syntax-propertize POS).

> This change wouldn't enhance functionality or maintainability.

Yes, it enhances maintainability of awk-mode by making it work more like
all other modes.  It also stops cc-mode from doing all kinds of weird
unrelated crap having to do with maintaining c-found-types and
c-state-cache, which are not used in cc-awk.

>> - Use define-derived-mode's built-in keymap inheritance rather than
>> c-make-inherited-keymap.
> c-make-inherited-keymap is simpler.

Huh?  Have you even looked at the patch?  There is nothing to do to use
define-derived-mode's built-in keymap inheritance, so how can your extra
code be simpler?

> This change wouldn't enhance functionality or maintainability.

It removes unneeded code.  That improves maintainability.

>> - initialize c-mode-base-map in its defvar.
> An inconsequential change that wouldn't enhance functionality or
> maintainability.  It's work to make, though.

It just makes code more standard, with no known downside.

>> - fix c-after-font-lock-init so it doesn't accidentally add
>> a c-after-change which wasn't there to begin with.
> ???  There's nothing broken here, surely?

The current code of c-after-font-lock-init has a bug, but no the current
cc-mode does not trigger this bug.

The bug is that c-after-font-lock-init is supposed to *move*
c-after-change to the front of after-change-functions, but in case
c-after-change is not in after-change-functions, it ends up *adding*
it instead.

Your approach to syntax-table properties requires you to be extra
careful about ordering between c-after-change and font-lock's own
after-change-functions, hence the c-after-font-lock-inithack.  But if
for some reason some cc-mode (such as cc-awk when it uses
syntax-propertize) does not need/want c-after-change, the current code
in c-after-font-lock-init will end up making it needlessly difficult to
remove c-after-change from after-change-functions.

>> - Run c-update-modeline from after-change-major-mode-hook and
>> hack-local-variables-hook rather than from the major mode function.
>> This lets us fix the bug where c-mode-hook is run twice and saves us
>> from having to define c-run-mode-hooks.
> after-change-major-mode-hook is a GNU Emacs speciality.

That's why I also do it from hack-local-variables-hook.

> How about enhancing define-derived-mode so that modes that have things
> to do after running their hooks can do them?

That's not late enough, since you need to do it after setting the
file-local variables.

In this particular case, the better fix would be to introduce a new
`mode-name-sidekick' in the mode-line-format, so we can get rid of
c-update-modeline altogether.

>> - make c-mode-common into an actual parent mode.  There is a naming problem
>> since we have c-mode-base-map for the "parent map" but
>> c-mode-common-hook for the "parent hook", and also because this "mode"
>> doesn't end in "-mode", but I think we can live with it.
> Why?

Why not?

> There is no such mode c-mode-common; nobody's ever going to have a
> buffer in this mode; it would merely be a software-engineeringy way of
> achieving... what?  It would add complexity where none is warranted.

What complexity?  It reduces code duplication, if anything.

> In that patch, your assumptions about what AWK Mode needs in
> c-{before,after}-change were incorrect.

Could you help me understand what I missed?

> There are likely other bugs in the patch too.  Remember, a previous,
> "simple, cosmetic" change, using define-derived-mode to derive CC
> Mode's modes from prog-mode, introduced two bugs, each of which took
> several hours to track down.  One of these is still unfixed.

I admit to not remembering, especially not the remaining bug due to
using prog-mode.  Can you remind us which bug this is?

> It has taken me several hours to study your email and answer it.  Your
> patch is all about rearranging the deckchairs around the cruise ship's
> pool when the engines need looking at.

Any package always has several problems that need fixing.  Just because
a change doesn't fix what you see as the main problem doesn't mean it
should be rejected.  My overall aim is to make cc-modes more "standard"
so as to lower the entry barrier for other people.  I also want to make
it more modular, which I thought I'd start by moving all the awk
functionality out of the generic part of the code and into cc-awk.

> It's trying to fix what's not broken.

I'm not sure what other people on this list feel like w.r.t cc-mode, but
personally so far my attitude has been to close my eyes and pinch my
nose while forwarding the bugs to you because the code is so
horrendously outlandish, messy, and outdated.

> It would not contribute one single thing to fixing the many things in
> CC Mode which need fixing.  On the contrary, it would act as
> a distraction, merely consuming lots more of my time reconciling these
> changes with the stand-alone CC Mode.

The problem here is not my changes, it's having those two separate
code bases.  There is no good reason to have 2 different code bases.
So let's fix this problem once and for all by merging the two and then
make sure they can't diverge any more (i.e. by using the Emacs code as
the place where development happens).

> In the mean time, there are several reported bugs not being fixed, and
> the enhancements needed for, e.g., C++11 are not progressing.  The time I
> can spend on Emacs and CC Mode is much less than both of us would like.

On the one hand you say that you don't have enough time to deal with
CC-mode, and on the other you reject the rare patches sent your way.

If you prefer that I keep just forwarding bug-reports to you and never
ever again look at cc-mode, I can do that.  But if you want help, you'll
need to be a bit more flexible.

> What needs attending to in CC Mode is NOT its embedding within X?Emacs
> and it's definitely NOT the lang-var system, which works just fine.  It's
> the complexity in c-guess-basic-syntax, in c-font-lock-declarations,
> c-forward-type, c-forward-decl-or-cast-1, and many other such functions,
> and the difficulties this causes.

One thing at a time.


        Stefan