From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: c-submode-indicators at wrong place in minor-mode-alist Date: Fri, 16 Dec 2005 10:57:42 +0000 (GMT) Message-ID: References: <87bqzinm0i.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1134752562 20985 80.91.229.2 (16 Dec 2005 17:02:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2005 17:02:42 +0000 (UTC) Cc: Nick Roberts , bug-cc-mode@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Fri Dec 16 18:02:35 2005 Return-path: Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EnIv8-0000XC-Ea for sf-cc-mode-help@m.gmane.org; Fri, 16 Dec 2005 17:59:03 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 9AB0989D3F; Fri, 16 Dec 2005 08:59:01 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1EnIuN-0007U6-2b for cc-mode-help@lists.sourceforge.net; Fri, 16 Dec 2005 08:58:15 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44) id 1EnIuM-00052g-Lr for cc-mode-help@lists.sourceforge.net; Fri, 16 Dec 2005 08:58:15 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1EnIsr-0006Tt-AD for bug-cc-mode@gnu.org; Fri, 16 Dec 2005 11:56:41 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1EnIxU-00008C-1C for bug-cc-mode@gnu.org; Fri, 16 Dec 2005 12:01:29 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EnIxS-00007R-FK; Fri, 16 Dec 2005 12:01:27 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id KAA00600; Fri, 16 Dec 2005 10:57:44 GMT X-Sender: root@acm.acm Original-To: Stefan Monnier In-Reply-To: <87bqzinm0i.fsf-monnier+emacs@gnu.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO Original-Sender: cc-mode-help-admin@lists.sourceforge.net Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 16 Dec 2005 10:57:42 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:2805 gmane.emacs.devel:47862 Archived-At: 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