unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Nick Roberts <nickrob@snap.net.nz>,
	bug-cc-mode@gnu.org, emacs-devel@gnu.org
Subject: Re: c-submode-indicators at wrong place in minor-mode-alist
Date: Thu, 15 Dec 2005 15:40:47 -0500	[thread overview]
Message-ID: <87bqzinm0i.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <Pine.LNX.3.96.1051215135211.674A-100000@acm.acm> (Alan Mackenzie's message of "Thu, 15 Dec 2005 14:25:19 +0000 (GMT)")

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


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


  parent reply	other threads:[~2005-12-15 20:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14 21:41 c-submode-indicators at wrong place in minor-mode-alist Stefan Monnier
2005-12-15  0:25 ` Nick Roberts
2005-12-15 14:25   ` Alan Mackenzie
2005-12-15 20:08     ` Nick Roberts
2005-12-16 10:18       ` Alan Mackenzie
2005-12-16 20:03         ` Nick Roberts
2005-12-17  8:22         ` Eli Zaretskii
2005-12-18  9:26           ` Alan Mackenzie
2005-12-15 20:40     ` Stefan Monnier [this message]
2005-12-16 10:57       ` Alan Mackenzie
2005-12-17  1:05         ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bqzinm0i.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=bug-cc-mode@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).