Re: c-submode-indicators at wrong place in minor-mode-alist

[Stefan Monnier]

>> > After opening a C file and activating smerge-mode, I get a modeline
>> > that reads:
>> > 
>> > ............... (C SMerge/l Fly Abbrev)
>> > 
>> > The /l comes from c-submode-indicators and has nothing to do
>> > with SMerge.
>> > The problem is that SMerge was loaded after C mode was turned on so it
>> > ended up in front of c-submode-indicators in minor-mode-alist.
>> > I think that c-submode-indicators should either be put in
>> > mode-line-process, or that c-mode sets mode-name to '("C"
>> > c-submode-indicators).

> Problem Acknowledged.

Thanks, and sorry 'bout forgetting bug-cc-mode.

> CC Mode has a convention that defuns/variables with doc strings are part
> of the API (i.e. things like line-up functions and derived modes are
> "permitted" to use them), but those without doc strings are "internal",
> i.e. subject to arbitrary change/disappearance between CC Mode versions.

I must say I dislike this convention.  Docstrings are also very convenient
for hacking on the code, debugging, etc... where you definitely do not want
to be limited to the "official API".

Another convention would be preferable.  Some packages use "foo-bar"
vs "foo--bar" to make the distinction (that's also what I tend to use),
others use "foo-bar" vs "Foo-bar", ..., you can invent your own.

Note also that in practice the "official API" changes anyway.  And even for
the non-official "API", when you change it you often find out that you still
need to add backward-compatibility cruft because someone didn't stick to
your "official API" (and this someone's package is sufficiently important
and won't be updated soon enough).

> for Emacs 19.34), getting a steady compilation environment (so that byte
> compilation will do the Right Thing regardless of what's loaded in the
> Emacs Lisp space) or for language variables.

And as we've seen countless times here, including one occurrence very
recently, this is a losing battle.  It just makes it harder for an external
casual hacker (e.g. myself) to debug your code.
[ speaking as someone who's suffered trying to understand why some change in
  the macro-expansion code completely broken the cc-require horror. ]

> It is also fair to point out that a great deal of CC Mode (cc-engine.el,
> cc-cmds.el, ...) is written in "standard" Elisp.

Indeed.  And a very useful piece of code on top of that.


        Stefan