Re: Further CC-mode changes

[Alan Mackenzie]

Hello, Stefan.

On Thu, Sep 11, 2014 at 09:55:29AM -0400, Stefan Monnier wrote:
> While waiting for your guidance as to which parts of my patches need to
> be reverted and why, here's some candidate patch which (contrary to the
> one you reverted) actually changes the code's behavior.

> It's to be applied on top of the ones you removed (tho since the ones
> you remove are mostly cosmetic, it shouldn't make much of a difference).

> Questions:
> - should C-c C-n and friends be moved to c-derivative-mode-map
>   (AFAIK neither Java nor IDL nor Pike have CPP conditionals)?

No.  Less disruptive is either to remove these bindings from
c-mode-base-map and put them in c-mode-map etc., or to splat them out
from java-mode-map, etc., as is done in awk-mode-map.  This is a bug, I
suppose, but a tiny one - attempting C-c C-n in Java Mode throws an error
immediately.

> - I notice that all cc-mode enable abbrev-mode except for idl-mode.
>   Was that on purpose or is it just accidental?

Probably deliberate.  IDL Mode doesn't have keywords like "else", as far
as I'm aware.  I'm also not aware of anyone using IDL Mode, there having
been no bug reports for it for many years, if ever.

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

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

>         Stefan


> - 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, and break uniformity between the
modes.  Putting all the mode defuns together was a deliberate decision,
though I can't remember whether it was Martin or me that made it.  This
change wouldn't enhance functionality or maintainability.

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

Why?  It's a lot of work to change, 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.  This
change wouldn't enhance functionality or maintainability.

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

c-make-inherited-keymap is simpler.  This change wouldn't enhance
functionality or 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.

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

> - 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.  The major mode
functions (and several commands, of course) are the natural places to
call c-update-modeline from.  How about enhancing define-derived-mode so
that modes that have things to do after running their hooks can do them?
That would surely be a simple change?

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

> - add a new parent mode c-derivative-mode which can hold those things
>   common to c, c++, and objc (i.e. languages which include C as a subset).
>   I was tempted to simply use c-mode as the parent for c++-mode and
>   objc-mode, but this would be a lot more intrusive and it would force
>   the presence of a "C" menu in both C++ and ObjC modes (we could fix
>   that for Emacs, but I'm not sure how to do it for XEmacs, and it
>   doesn't seem worth the trouble).

Why?  What complixity would c-derivative-mode save that would justify its
existence?  I think your last clause is true for the entire paragraph.

[ Snipped ~750 lines of patch. ]

In that patch, your assumptions about what AWK Mode needs in
c-{before,after}-change were incorrect.  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.

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.  It's trying to fix what's not
broken.  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.

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.

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.

Exasperated,

-- 
Alan Mackenzie (Nuremberg, Germany).