* c-submode-indicators at wrong place in minor-mode-alist @ 2005-12-14 21:41 Stefan Monnier 2005-12-15 0:25 ` Nick Roberts 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2005-12-14 21:41 UTC (permalink / raw) 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). Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* c-submode-indicators at wrong place in minor-mode-alist 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 0 siblings, 1 reply; 11+ messages in thread From: Nick Roberts @ 2005-12-15 0:25 UTC (permalink / raw) Cc: emacs-devel, bug-cc-mode > 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). I have also made the following bug report for c-submode-indicators (4th Dec) but not heard anything, possibly because I didn't cc to bug-cc-mode@gnu.org last time: I have two suggestions: 1) Clicking mouse-2 on the characters after "C" on the mode-line describes c-submode-indicators. It would be helpful if this variable was documented to explain the meaning of its value. 2) The sub-menus of the "Toggle..." menu-item should be radio buttons so the user can see their current value. Also the menu item "Syntactic indentation" is permanently disabled and can't be toggled. For some reason none of the defvars in cc-langs.el seem to have doc strings. The missing functionality might be due to my setup: CC mode almost seems to be a dialect of Emacs Lisp with its own virtual world of macros. Nick ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-15 0:25 ` Nick Roberts @ 2005-12-15 14:25 ` Alan Mackenzie 2005-12-15 20:08 ` Nick Roberts 2005-12-15 20:40 ` Stefan Monnier 0 siblings, 2 replies; 11+ messages in thread From: Alan Mackenzie @ 2005-12-15 14:25 UTC (permalink / raw) Cc: Stefan Monnier, bug-cc-mode, emacs-devel Hi, Nick and Stefan! On Thu, 15 Dec 2005, Nick Roberts wrote: > > 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. >I have also made the following bug report for c-submode-indicators (4th Dec) >but not heard anything, possibly because I didn't cc to bug-cc-mode@gnu.org >last time: Sorry. It's not a matter of arrogant aloofness, I just didn't spot it in the mass of emails in emacs-devel. Always bug CC Mode with a cc to bug-cc-mode! :-) > I have two suggestions: > 1) Clicking mouse-2 on the characters after "C" on the mode-line describes > c-submode-indicators. It would be helpful if this variable was documented > to explain the meaning of its value. > 2) The sub-menus of the "Toggle..." menu-item should be radio buttons so > the user can see their current value. >Also the menu item "Syntactic indentation" is permanently disabled and can't >be toggled. As a matter of interest, are any of these mousey things coupled with a particular window manager or toolkit or the like? (Personally, I develop with Emacs on a tty.) >For some reason none of the defvars in cc-langs.el seem to have doc strings. Some do - `c-identifier-syntax-table', for example. 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. >The missing functionality might be due to my setup: CC mode almost seems >to be a dialect of Emacs Lisp with its own virtual world of macros. That's not unfair. ;-) Most of these macros are for smoothing over the differences between (X)Emacs versions (we've only just dropped support 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. Language variables are those whose values depend on the target language (C, C++, Java, Objective C, IDL, Pike, AWK). Here's an example: (c-lang-defconst c-string-escaped-newlines "Set if the language support backslash escaped newlines inside string literals." t nil (c c++ objc pike) t) (c-lang-defvar c-string-escaped-newlines (c-lang-const c-string-escaped-newlines)) This defines the variable `c-string-escaped-newlines', and sets it up to the value t for C, C++, Objective C and Pike, and nil for the other languages. The system also allows derived modes to hook into it. The simplicity of these declarations necessitates very hairy macros (which I don't fully understand either) to support them. 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. >Nick -- Alan Mackenzie (Munich, Germany). ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-15 14:25 ` Alan Mackenzie @ 2005-12-15 20:08 ` Nick Roberts 2005-12-16 10:18 ` Alan Mackenzie 2005-12-15 20:40 ` Stefan Monnier 1 sibling, 1 reply; 11+ messages in thread From: Nick Roberts @ 2005-12-15 20:08 UTC (permalink / raw) Cc: Stefan Monnier, bug-cc-mode, emacs-devel > > I have two suggestions: > > > 1) Clicking mouse-2 on the characters after "C" on the mode-line describes > > c-submode-indicators. It would be helpful if this variable was documented > > to explain the meaning of its value. > > > 2) The sub-menus of the "Toggle..." menu-item should be radio buttons so > > the user can see their current value. > > >Also the menu item "Syntactic indentation" is permanently disabled and can't > >be toggled. > > As a matter of interest, are any of these mousey things coupled with a > particular window manager or toolkit or the like? (Personally, I develop > with Emacs on a tty.) If you develop on a tty, how do you know if GUI related features work? The patch below seems to fix it for me. I think I have associated each function with the right variable but these aren't really minor modes in the normal sense (if they were the functions and variables would have the same name). > >For some reason none of the defvars in cc-langs.el seem to have doc strings. > > Some do - `c-identifier-syntax-table', for example. OK, but it seems particularly important that c-submode-indicators has one if the user is to understand the mode line. > >The missing functionality might be due to my setup: CC mode almost seems > >to be a dialect of Emacs Lisp with its own virtual world of macros. > > That's not unfair. ;-) Most of these macros are for smoothing over the > differences between (X)Emacs versions (we've only just dropped support > 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. CC mode seems to have become much more complicated, but that might be because its much more powerful. I don't know, I just find it hard to understand. Nick *** cc-langs.el 04 Dec 2005 00:50:02 +1300 1.35 --- cc-langs.el 14 Dec 2005 22:03:58 +1300 *************** *** 258,266 **** (c-fn-region-is-active-p)])) "----" ("Toggle..." ! ["Syntactic indentation" c-toggle-syntactic-indentation t] ! ["Auto newline" c-toggle-auto-newline t] ! ["Hungry delete" c-toggle-hungry-state t]))) \f ;;; Syntax tables. --- 258,269 ---- (c-fn-region-is-active-p)])) "----" ("Toggle..." ! ["Syntactic indentation" c-toggle-syntactic-indentation ! :style toggle :selected c-syntactic-indentation] ! ["Auto newline" c-toggle-auto-newline ! :style toggle :selected c-auto-newline] ! ["Hungry delete" c-toggle-hungry-state ! :style toggle :selected c-hungry-delete-key]))) \f ;;; Syntax tables. ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 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 0 siblings, 2 replies; 11+ messages in thread From: Alan Mackenzie @ 2005-12-16 10:18 UTC (permalink / raw) Cc: Stefan Monnier, bug-cc-mode, emacs-devel Hi, Nick! On Fri, 16 Dec 2005, Nick Roberts wrote: > > > I have two suggestions: > > > 1) Clicking mouse-2 on the characters after "C" on the mode-line > > > describes c-submode-indicators. It would be helpful if this > > > variable was documented to explain the meaning of its value. > > > 2) The sub-menus of the "Toggle..." menu-item should be radio > > > buttons so the user can see their current value. > > >Also the menu item "Syntactic indentation" is permanently disabled > > >and can't be toggled. > > As a matter of interest, are any of these mousey things coupled with > > a particular window manager or toolkit or the like? (Personally, I > > develop with Emacs on a tty.) >If you develop on a tty, how do you know if GUI related features work? Good point. I've just been having a look at C Mode in X, and there seem to be one or two things there needing sorted out. >The patch below seems to fix it for me. I think I have associated each >function with the right variable but these aren't really minor modes in >the normal sense (if they were the functions and variables would have >the same name). OK. Do you have any feel for how portable the fix is (In Emacs 20.n, 21.n, XEmacs 21.4.n)? > > >For some reason none of the defvars in cc-langs.el seem to have doc > > >strings. > > Some do - `c-identifier-syntax-table', for example. >OK, but it seems particularly important that c-submode-indicators has one >if the user is to understand the mode line. Another good point! The c-submode-indicators might be getting merged with the major-mode string, so this needs thinking about. > > >The missing functionality might be due to my setup: CC mode almost > > >seems to be a dialect of Emacs Lisp with its own virtual world of > > >macros. > > That's not unfair. ;-) Most of these macros are for smoothing over the > > differences between (X)Emacs versions (we've only just dropped support > > 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. >CC mode seems to have become much more complicated, but that might be >because its much more powerful. I don't know, I just find it hard to >understand. It is hard to understand. Partly, it's because C and friends are such a dreadful languages (to parse, that is ;-), partly because CC Mode handles seven different languages in a single package. It "jumped in complexity" between releases 5.28 and 5.30 (Summer 2003). It's probably more accurate to say that the complexity has been concentrated in a few hot-spots, allowing simplicity to pervade the rest. >Nick [ Supplied patch read] -- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-16 10:18 ` Alan Mackenzie @ 2005-12-16 20:03 ` Nick Roberts 2005-12-17 8:22 ` Eli Zaretskii 1 sibling, 0 replies; 11+ messages in thread From: Nick Roberts @ 2005-12-16 20:03 UTC (permalink / raw) Cc: Stefan Monnier, bug-cc-mode, emacs-devel > >The patch below seems to fix it for me. I think I have associated each > >function with the right variable but these aren't really minor modes in > >the normal sense (if they were the functions and variables would have > >the same name). > > OK. Do you have any feel for how portable the fix is (In Emacs 20.n, > 21.n, XEmacs 21.4.n)? I'm fairly sure it will work in Emacs 21.x but I don't know about the other versions. However, clearly the change could be commmitted to the Emacs repository. I don't how you store your changes, but a distributed RCS like Arch, would seem ideal for your purposes. Then the changes that you commit to Emacs 22.1 could be stored as a branch in your local repository. I don't know all the details (I've nwver used Arch) but Miles Bader keeps an Arch mirror for Emacs and I'm sure he would put you in the picture. > >CC mode seems to have become much more complicated, but that might be > >because its much more powerful. I don't know, I just find it hard to > >understand. > > It is hard to understand. Partly, it's because C and friends are such a > dreadful languages (to parse, that is ;-), partly because CC Mode handles > seven different languages in a single package. It "jumped in complexity" > between releases 5.28 and 5.30 (Summer 2003). It's probably more > accurate to say that the complexity has been concentrated in a few > hot-spots, allowing simplicity to pervade the rest. You do most of the development. It only needs to be simpler if you want to look to others like emacs-devel, to help you. One way to do that, I guess, is to strip down the branch for Emacs 22.1 in your hypothetical Arch repository, to just work in Emacs 22.1. Nick ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 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 1 sibling, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2005-12-17 8:22 UTC (permalink / raw) Cc: nickrob, bug-cc-mode, emacs-devel > Date: Fri, 16 Dec 2005 10:18:35 +0000 (GMT) > From: Alan Mackenzie <acm@muc.de> > Cc: bug-cc-mode@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, > emacs-devel@gnu.org > > >CC mode seems to have become much more complicated, but that might be > >because its much more powerful. I don't know, I just find it hard to > >understand. > > It is hard to understand. Partly, it's because C and friends are such a > dreadful languages (to parse, that is ;-) Really? as compared to what? From what I know, C is actually a relatively easily parsable language. ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-17 8:22 ` Eli Zaretskii @ 2005-12-18 9:26 ` Alan Mackenzie 0 siblings, 0 replies; 11+ messages in thread From: Alan Mackenzie @ 2005-12-18 9:26 UTC (permalink / raw) Cc: bug-cc-mode, nickrob, emacs-devel Hi, Eli! On Sat, 17 Dec 2005, Eli Zaretskii wrote: >> Date: Fri, 16 Dec 2005 10:18:35 +0000 (GMT) >> From: Alan Mackenzie <acm@muc.de> >> Cc: bug-cc-mode@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, >> emacs-devel@gnu.org >> >CC mode seems to have become much more complicated, but that might be >> >because its much more powerful. I don't know, I just find it hard to >> >understand. >> It is hard to understand. Partly, it's because C and friends are such a >> dreadful languages (to parse, that is ;-) >Really? as compared to what? As compared with Emacs Lisp, certainly. ;-) >From what I know, C is actually a relatively easily parsable language. It is for a compiler, which parses from beginning to end. It's more difficult for Emacs, which has to parse incomplete text, often backwards. It's very context dependent: when is a "<" a less-than sign, when is a template delimiter (OK, we're talking about C++ now)? From font-lock.el: ;; I am most proud and humbly honoured today [murmur murmur cough] to present ;; to you good people, the winner of the Second Millennium Award for The Most ;; Hairy Language Syntax. [Ahhh!] All rise please. [Shuffle shuffle ;; shuffle.] And a round of applause please. For... The C Language! [Roar.] I don't know who wrote that, though. Jamie Zawinski? Simon Marshall? -- Alan Mackenzie (Munich, Germany) ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-15 14:25 ` Alan Mackenzie 2005-12-15 20:08 ` Nick Roberts @ 2005-12-15 20:40 ` Stefan Monnier 2005-12-16 10:57 ` Alan Mackenzie 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2005-12-15 20:40 UTC (permalink / raw) Cc: Nick Roberts, bug-cc-mode, emacs-devel >> > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-15 20:40 ` Stefan Monnier @ 2005-12-16 10:57 ` Alan Mackenzie 2005-12-17 1:05 ` Richard M. Stallman 0 siblings, 1 reply; 11+ messages in thread From: Alan Mackenzie @ 2005-12-16 10:57 UTC (permalink / raw) Cc: Nick Roberts, bug-cc-mode, emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: c-submode-indicators at wrong place in minor-mode-alist 2005-12-16 10:57 ` Alan Mackenzie @ 2005-12-17 1:05 ` Richard M. Stallman 0 siblings, 0 replies; 11+ messages in thread From: Richard M. Stallman @ 2005-12-17 1:05 UTC (permalink / raw) Cc: monnier, bug-cc-mode, nickrob, emacs-devel >> 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. This is how I used to do things, back when doc strings took up space in Emacs. But now they don't, so I suggest that you aim in the future to give all functions and variables real doc strings. ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-12-18 9:26 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2005-12-16 10:57 ` Alan Mackenzie 2005-12-17 1:05 ` Richard M. Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.