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

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan!

On Thu, 15 Dec 2005, Stefan Monnier wrote:

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

OK.  That's something for the future, not now.

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

CC Mode has backward compatibility stuff all the way back to Emacs 20.4.
;-)  Nevertheless, the clear distinction between "internal" and "API" is
very reassuring when hacking: the former can be swept away with abandon,
the latter gets changed only after much deliberation. 

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

It's a battle, yes, even though cc-bytecomp.el has been around since
2000.  It makes heavy development in CC Mode much easier, since one can
be confident that byte-compile-file will get up to date definitions.  The
simple (require 'cc-langs) wouldn't do this.  Maybe it would be possible,
somehow, to have some sort of option in cc-bytecomp so that at building
time and packaging time, cc-require would simply to require, and so on.
Again, this is for the future.

>[ speaking as someone who's suffered trying to understand why some
>change in the macro-expansion code completely broke the cc-require
>horror. ]

Oh, I've suffered too!  But I've benefitted often enough from being
_sure_ that my latest changes to, say, cc-langs get immediately compiled
in.  There seems to be a need for such compilation control features in
the Emacs base.  I suppose that when Martin wrote cc-bytecomp, he was
having continual problems with this, the sort of problems that get normal
sane placid people to screaming in rage and frustration and banging the
keyboard.  (Normal sane placid hackers, OTOH, code the problem away. ;-)

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

Thanks!

>
>        Stefan

-- 
Alan.




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click