CC Mode 5.31.3

CC Mode 5.31.3

[Alan Mackenzie]

Hi, Emacs!

I've just merged CC Mode 5.31.3 into Emacs's CVS at savannah.

It fixes several serious bugs (most of which were reported directly to
bug-cc-mode), and a few less serious ones too.  This release might even
be stable.

There are still things to do, however:

As agreed with RMS, C-M-[ae] should be be bound to
c-\(beginning\|end\)-of-defun by default, rather than the standard
commands \(beginning\|end\)-of-defun.  These two CC Mode commands could
do with some optimisation, but this seems optional rather than necessary.
This is still to do.  However, it is trivial, involving only drudge work,
mostly in the manual.  It should be there in 5.31.4.

The issues with the Mode Name, and minor mode flags in the mode line are
still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
of "C/la") now stay with the major mode, but this is done by setting
mode-name to "C/la", a stop-gap solution at best.  This is ugly, and I
don't find it an acceptable solution..

When the mouse is left over the "/la", it still doesn't give sensible
documentation.  This is also still to do.

A solution to both these problems would be to insert an element into
mode-line-format to display c-submode-indicators (the "/la"), and to give
this a doc-string for the mouse.  However, mode-line-format has
traditionally been a write-only variable, in which it is tedious to
locate the place to insert the extra element into[*].  I envisage a
recursive function which tests successive elements of mode-line-format
until it finds mode-name, then inserts c-submode-indicators after it.

[*] that is, tedious to locate in a portable, Emacs version-independent
fashion.

Has anybody already written such a function, or does anybody have any
better idea how to do it?  Suggestions would be welcome.  :-)

Also, if anybody notices more GUI things missing, please tell me.  I
normally run Emacs in a tty without a mouse, so I'm fairly likely to miss
these missing things.

-- 
Alan Mackenzie (Munich, Germany).




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Sean O'Rourke]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

Alan Mackenzie <acm@muc.de> writes:
> As agreed with RMS, C-M-[ae] should be be bound to
> c-\(beginning\|end\)-of-defun by default, rather than the standard
> commands \(beginning\|end\)-of-defun.  These two CC Mode commands could
> do with some optimisation, but this seems optional rather than necessary.
> This is still to do.  However, it is trivial, involving only drudge work,
> mostly in the manual.  It should be there in 5.31.4.

Have you thought instead of mode-locally setting
{beginning,end}-of-defun-function?  This way, other commands like
mark-defun that operate on functions automatically pick up the
language-specific versions.  I have been using this setting for
about a year without any problems after making the attached
trivial patch, which prevents infinite recursion when
beginning-of-defun-function itself calls beginning-of-defun.

/s


[-- Attachment #2: Type: text/plain, Size: 1620 bytes --]

Index: lisp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.74
diff -p -u -w -u -r1.74 lisp.el
--- lisp.el	6 Feb 2006 12:20:06 -0000	1.74
+++ lisp.el	24 Feb 2006 18:44:26 -0000
@@ -210,12 +210,14 @@ If variable `beginning-of-defun-function
 is called as a function to find the defun's beginning."
   (interactive "p")
   (if beginning-of-defun-function
+      (let ((bodf beginning-of-defun-function)
+            (beginning-of-defun-function nil))
       (if (> (setq arg (or arg 1)) 0)
 	  (dotimes (i arg)
-	    (funcall beginning-of-defun-function))
+              (funcall bodf))
 	;; Better not call end-of-defun-function directly, in case
 	;; it's not defined.
-	(end-of-defun (- arg)))
+            (end-of-defun (- arg))))
     (and arg (< arg 0) (not (eobp)) (forward-char 1))
     (and (re-search-backward (if defun-prompt-regexp
 				 (concat (if open-paren-in-column-0-is-defun-start
@@ -255,12 +257,14 @@ is called as a function to find the defu
       (push-mark))
   (if (or (null arg) (= arg 0)) (setq arg 1))
   (if end-of-defun-function
+      (let ((eodf end-of-defun-function)
+            (end-of-defun-function nil))
       (if (> arg 0)
 	  (dotimes (i arg)
-	    (funcall end-of-defun-function))
+              (funcall eodf))
 	;; Better not call beginning-of-defun-function
 	;; directly, in case it's not defined.
-	(beginning-of-defun (- arg)))
+            (beginning-of-defun (- arg))))
     (let ((first t))
       (while (and (> arg 0) (< (point) (point-max)))
 	(let ((pos (point)))

Re: CC Mode 5.31.3

[Alan Mackenzie]

On Fri, 24 Feb 2006, Sean O'Rourke wrote:

>Alan Mackenzie <acm@muc.de> writes:
>> As agreed with RMS, C-M-[ae] should be be bound to
>> c-\(beginning\|end\)-of-defun by default, rather than the standard
>> commands \(beginning\|end\)-of-defun.  These two CC Mode commands could
>> do with some optimisation, but this seems optional rather than necessary.
>> This is still to do.  However, it is trivial, involving only drudge work,
>> mostly in the manual.  It should be there in 5.31.4.

>Have you thought instead of mode-locally setting
>{beginning,end}-of-defun-function?  This way, other commands like
>mark-defun that operate on functions automatically pick up the
>language-specific versions.

\(beginning\|end\)-of-defun-function can't get a prefix argument.  In
Emacs 22, this is mitigated by calling the function in a loop.  However,
in other (X)Emacsen, the numeric argument is simply discarded, so to use
[be]-o-d-f would mean testing for the existence of this loop, then
binding key sequences one of two ways.  It's doable, but it's hassle.

The other problem is that the opportunity for optimisation would go out
the window: c-beginning-of-defun essentially moves back to the outermost
brace (very rapid operation) then gropes backwards to the start of the
function header (slow operation involving lengthy analysis).  The easiest
optimisation with (c-beginning-of-defun 10) involves skipping back 10
brace blocks and only then finding the start of the header.

C-M-h isn't a problem in CC Mode, because it's bound to c-mark-function.
However, if mark-defun is called from a lisp function, that would be a
problem.  Hmmm.  Surely I should be setting
\(beginning\|end\)-of-defun-function AS WELL AS (not instead of) binding
C-M-[aeh]?

>I have been using this setting for
>about a year without any problems after making the attached
>trivial patch, which prevents infinite recursion when
>beginning-of-defun-function itself calls beginning-of-defun.

Hee hee!  Good point.  I think your patch should be installed right now.

Index: lisp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.74
diff -p -u -w -u -r1.74 lisp.el
--- lisp.el	6 Feb 2006 12:20:06 -0000	1.74
+++ lisp.el	24 Feb 2006 18:44:26 -0000
@@ -210,12 +210,14 @@ If variable `beginning-of-defun-function
 is called as a function to find the defun's beginning."
   (interactive "p")
   (if beginning-of-defun-function
+      (let ((bodf beginning-of-defun-function)
+            (beginning-of-defun-function nil))
       (if (> (setq arg (or arg 1)) 0)
 	  (dotimes (i arg)
-	    (funcall beginning-of-defun-function))
+              (funcall bodf))
 	;; Better not call end-of-defun-function directly, in case
 	;; it's not defined.
-	(end-of-defun (- arg)))
+            (end-of-defun (- arg))))
     (and arg (< arg 0) (not (eobp)) (forward-char 1))
     (and (re-search-backward (if defun-prompt-regexp
 				 (concat (if open-paren-in-column-0-is-defun-start
@@ -255,12 +257,14 @@ is called as a function to find the defu
       (push-mark))
   (if (or (null arg) (= arg 0)) (setq arg 1))
   (if end-of-defun-function
+      (let ((eodf end-of-defun-function)
+            (end-of-defun-function nil))
       (if (> arg 0)
 	  (dotimes (i arg)
-	    (funcall end-of-defun-function))
+              (funcall eodf))
 	;; Better not call beginning-of-defun-function
 	;; directly, in case it's not defined.
-	(beginning-of-defun (- arg)))
+            (beginning-of-defun (- arg))))
     (let ((first t))
       (while (and (> arg 0) (< (point) (point-max)))
 	(let ((pos (point)))

-- 
Alan Mackenzie (Munich, Germany)




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Alan Mackenzie]

Hi, Stefan!

On Fri, 24 Feb 2006, Stefan Monnier wrote:

>> The issues with the Mode Name, and minor mode flags in the mode line are
>> still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
>> of "C/la") now stay with the major mode, but this is done by setting
>> mode-name to "C/la", a stop-gap solution at best.  This is ugly, and I
>> don't find it an acceptable solution..

>Could you remind me why you don't use mode-line-process?

Ignorance, mainly.  :-)  It sounds like a great idea, though.

mode-line-process appears to work fine for Emacs 2[012], but not for
XEmacs, where it is displayed to the right of the minor modes.

This variable is defined by the info it displays, not by its position in
the mode line.  It would have been nice to have the variable
`mode-right-of-name' (and even `mode-left-of-name').  It is a pity that
it is now too late to add these variables into the standard
mode-line-format and the Elisp manual.

Is there any guarantee that a buffer.c won't invoke any process (whatever
that might mean) that would overwrite mode-line-process?

>        Stefan

-- 
Alan.

Re: CC Mode 5.31.3

[Richard Stallman]

    The issues with the Mode Name, and minor mode flags in the mode line are
    still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
    of "C/la") now stay with the major mode, but this is done by setting
    mode-name to "C/la", a stop-gap solution at best.

I do not understand "now stay with the major mode".
What does that mean, concretely?

Anyway, can't you achieve what you want with a local
binding for mode-line-modes?  Or mode-line-process?


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Vivek Dasmohapatra]

On Fri, 24 Feb 2006, Alan Mackenzie wrote:

> When the mouse is left over the "/la", it still doesn't give sensible
> documentation.  This is also still to do.

One thing I noticed while looking at mode-line-format was that 
minor-mode-alist was included as folllows:

(:propertize
   ("" minor-mode-alist)
   mouse-face mode-line-highlight help-echo "mouse-2: help for minor modes, 
mouse-3: minor mode menu" local-map
   (keymap
    (header-line keymap
                 (down-mouse-3 . mode-line-mode-menu-1))
    (mode-line keymap
               (down-mouse-3 . mode-line-mode-menu-1)
               (mouse-2 . mode-line-minor-mode-help))))

which seems to mean that any help-echo properties set in 
c-submode-indicators, eg the follwing value for c-submode-indicators:

(:propertize "/l" help-echo "C Electricity")

are overwritten by the generic help in the first :propertize form above.

Perhaps if the handling of :propertize were altered so that the priority
of properties were inverted, ie the outer :propertize properties were only
applied to those substrings which did not already have those same properties
assigned by the inner forms, then things like the /la mouseover tooltips
would be easier to accomplish.

[ This may be undesirable for other reasons, I haven't looked deeply into
   it, I just thought I'd make the suggestion ]





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Stefan Monnier]

>>> The issues with the Mode Name, and minor mode flags in the mode line are
>>> still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
>>> of "C/la") now stay with the major mode, but this is done by setting
>>> mode-name to "C/la", a stop-gap solution at best.  This is ugly, and I
>>> don't find it an acceptable solution..

>> Could you remind me why you don't use mode-line-process?
> Ignorance, mainly.  :-)

You mean you forgot: on Dec 15, you replied:

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

> Is there any guarantee that a buffer.c won't invoke any process (whatever
> that might mean) that would overwrite mode-line-process?

mode-line-process is not magically used by process primitives AFAIK.
It's the responsability of elisp code that runs subprocesses to setup the
mode-line-process variable if they so wish.

So no, there's guarantee, but I don't think it's a real problem.  After all,
it'd probably be a gud for a minor mode to interfere with the major mode's
use of mode-line-process.


        Stefan

Re: CC Mode 5.31.3

[Alan Mackenzie]

Hi, Richard!

On Sun, 26 Feb 2006, Richard Stallman wrote:

>    The issues with the Mode Name, and minor mode flags in the mode line are
>    still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
>    of "C/la") now stay with the major mode, but this is done by setting
>    mode-name to "C/la", a stop-gap solution at best.

>I do not understand "now stay with the major mode".
>What does that mean, concretely?

Sorry, that was a sloppy explanation.  In this mode line:

  --1-:---F3  test.c            (C/l H Abbrev)--L338--C0--Bot--P6714/6981---
                                 ^^^

, when M-x smerge-mode is started, it previously became this:

  --1-:---F3  test.c            (C SMerge/l H Abbrev)--L338--C0--Bot--P6714/6981---
                                 ^       ^^

By "staying with the major mode", I meant that "C" and "/l" didn't get
separated by "SMerge".


>Anyway, can't you achieve what you want with a local
>binding for mode-line-modes?  Or mode-line-process?

The thing in the mode line I will use for the C submode flags (the "/l")
must be firmly clamped to the right of mode-name.

mode-line-process doesn't meet this requirement, since it's only
coincidentally to the right of mode-name in Emacs 22 and 21 (and, in
fact, is somewhere else in the XEmacs mode line).  Also, this variable
might get overwritten by some "process" (whatever that is, exactly) which
may become associated with the C Mode buffer.

mode-line-modes doesn't seem right either:

COMPLAINT(1):
mode-line-modes's doc string seems very vague: "Mode-line control for
displaying major and minor modes".  Or, in unforced English, "Something
to do with displaying major and minor modes".  I don't know what "a
control" is, if there is an implicit indefinite article there.  I don't
know what "for" means in this context.  It isn't clear exactly how many
major and minor modes will get dispalayed - is that what is getting
controlled?  Anybody wanting to use this variable would be forced to read
the fine source code to find out what it actually is and does.

COMPLAINT(2):
There is no entry for mode-line-modes in NEWS.

I think mode-line-modes was first introduced in Emacs 22, so it's not
(yet) a version-independent facility (which CC Mode obviously would
prefer).

Analysing mode line formats is hard, ridiculously hard - the
mode-line-format of a Emacs power user can come in any shape or form
whatsoever, possibly not even including mode-name.  There seems to be
little or any support for maintainers of modes who need to tweak it.

-- 
Alan Mackenzie (Munich, Germany)




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Alan Mackenzie]

Hi, Emacs!

On Sun, 26 Feb 2006, Richard Stallman wrote:

>    The issues with the Mode Name, and minor mode flags in the mode line are
>    still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
>    of "C/la") now stay with the major mode, but this is done by setting
>    mode-name to "C/la", a stop-gap solution at best.

>Anyway, can't you achieve what you want with a local
>binding for mode-line-modes?  Or mode-line-process?

I've now got a solution, almost complete, to the CC Mode submode flags.
It works in Emacs 2[012] and XEmacs 21.4.4.  My new functions walk
through mode-line-format, and insert c-submode-flags into whatever
appropriate structure, just after mode-name, making a buffer-local copy
of whatever.

It still needs text properties (help-echo) applying to it.  Anyhow, see
what you think of the following:

#########################################################################
(defvar c-submode-indicators "/la"
  "The dummy submode indicators for CC Mode")

(or (fboundp 'caddr)
    (defun caddr (kons) (car (cdr (cdr kons)))))

(defun c-locate-mode-name (ml-form)
  "In ML-FORM, a mode-line construct, locate the variable `mode-name'.

Returns:
\(i) (t . SYMBOL) if SYMBOL is the symbol within ml-form that directly
contains mode-name.
\(ii) The cons whose car is or generates mode-name.
\(iii) t if ml-form is an atom which is mode-name, or an eval: form which
generates it.
\(iv) nil, if we don't find it."
  (let (rec-return
	(mode-name "Ceci n'est pas un nom de mode."))
    (cond
     ((null ml-form) nil)
     ((stringp ml-form)
      (string= ml-form mode-name))

     ((symbolp ml-form)
      (when (and (boundp ml-form)
		 (setq rec-return (c-locate-mode-name (symbol-value ml-form))))
	(cond
	 ((eq rec-return t) t)		; the symbol is `mode-name'.
	 ((consp rec-return)
	  (if (eq (car rec-return) t)
	      rec-return		; a recursively included symbol.
	    `(t . ,ml-form))))))   ; `mode-name' is directly "in" this symbol.

     ((consp ml-form)
      (cond
       ((eq (car ml-form) ':eval)
	(if (string= mode-name (eval (cadr ml-form)))
	    t))			 ; maybe we should test for string inclusion??
     
       ((symbolp (car ml-form))
	(if (boundp (car ml-form))
	    (c-locate-mode-name (if (symbol-value (car ml-form))
				    (cadr ml-form)
				  (caddr ml-form)))))

       (t
	(while
	    (and ml-form
		 (not (setq rec-return (c-locate-mode-name (car ml-form))))
		 (consp (cdr ml-form)))
	  (setq ml-form (cdr ml-form)))
	(if (and ml-form (not rec-return)) ; dotted pair at end of list (XEmacs)
	    (setq rec-return (c-locate-mode-name (cdr ml-form))))
	(if (eq rec-return t)
	    ml-form
	  rec-return)))))))

(defun c-copy-tree (kons)
  "Make a copy of the list structure, KONS, such that it is completely
distinct from the original list.  Don't use on circular lists!"
  (if (consp kons)
      (cons (c-copy-tree (car kons))
	    (c-copy-tree (cdr kons)))
    kons))

(defun c-splice-submode-indicators ()
  (interactive)				; Remove this, eventually.  FIXME!!!
  (let (target-cons new-link symb)
    ;; Identify the variable we need to make buffer-local and copy.
    (setq target-cons (c-locate-mode-name 'mode-line-format))
    (unless (and (consp target-cons)
		 (eq (car target-cons) t))
      (error "c-locate-mode-name, seeking symbol, returned %s" target-cons))
    (setq symb (cdr target-cons))

    ;; Make a buffer local copy of this symbol's value.
    (make-local-variable symb)
    (set symb (c-copy-tree (symbol-value symb)))

    ;; Find the cons within this symbol which generates MODE-NAME.
    (setq target-cons (c-locate-mode-name (symbol-value symb)))
    (if (or (not (consp target-cons))
	    (eq (car target-cons) t))
	(error "c-locate-mode-name, seeking cons, returned %s" target-cons))

    ;; Splice c-submode-indicators into the list structure.
    (setcdr target-cons (cons 'c-submode-indicators (cdr target-cons)))))
#########################################################################

-- 
Alan Mackenzie (Munich, Germany)




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Kim F. Storm]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Emacs!
>
> On Sun, 26 Feb 2006, Richard Stallman wrote:
>
>>    The issues with the Mode Name, and minor mode flags in the mode line are
>>    still unresolved.  On typing M-x smerge-mode, C Mode's flags (the "/la"
>>    of "C/la") now stay with the major mode, but this is done by setting
>>    mode-name to "C/la", a stop-gap solution at best.
>
>>Anyway, can't you achieve what you want with a local
>>binding for mode-line-modes?  Or mode-line-process?
>

I don't see why we cannot just make a new variable for this.
After all, CC Mode is an important feature of Emacs.

Of course, this only works for 22.x and forward, but that's life :-)


*** bindings.el	06 Feb 2006 18:21:19 +0100	1.157
--- bindings.el	27 Feb 2006 10:03:17 +0100	
***************
*** 220,225 ****
--- 220,231 ----
  (defvar mode-line-frame-identification '("-%F  ")
    "Mode-line control to describe the current frame.")
  
+ (defvar mode-line-submode nil "\
+ Mode-line control for displaying submodes of the major mode.
+ Normally nil in most modes, since there is no submode to display.")
+ 
+ (make-variable-buffer-local 'mode-line-submode)
+ 
  (defvar mode-line-process nil "\
  Mode-line control for displaying info on process status.
  Normally nil in most modes, since there is no process to display.")
***************
*** 313,318 ****
--- 319,325 ----
  		   help-echo "mouse-1: major-mode-menu mouse-2: help for current major mode"
  		   mouse-face mode-line-highlight
  		   local-map ,mode-line-major-mode-keymap)
+      '("" mode-line-submode)
       '("" mode-line-process)
       `(:propertize ("" minor-mode-alist)
  		   mouse-face mode-line-highlight

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CC Mode 5.31.3

[Stefan Monnier]

> It works in Emacs 2[012] and XEmacs 21.4.4.  My new functions walk
> through mode-line-format, and insert c-submode-flags into whatever
> appropriate structure, just after mode-name, making a buffer-local copy
> of whatever.

It's really too bad that the simplest solution:

  (setq mode-name '("C" c-submode-indicators))

isn't well supported (AFAIK in Emacs-CVS the only remaining problem is that
the help-echo, face, and mouse-face properties are overridden by the
ones applied generically to major mode name).


        Stefan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Alan Mackenzie]

Hi, Kim!

On Mon, 27 Feb 2006, Kim F. Storm wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> Hi, Emacs!

>> On Sun, 26 Feb 2006, Richard Stallman wrote:

>>>    The issues with the Mode Name, and minor mode flags in the mode
>>>    line are still unresolved.  On typing M-x smerge-mode, C Mode's
>>>    flags (the "/la" of "C/la") now stay with the major mode, but this
>>>    is done by setting mode-name to "C/la", a stop-gap solution at
>>>    best.

>>>Anyway, can't you achieve what you want with a local binding for
>>>mode-line-modes?  Or mode-line-process?

>I don't see why we cannot just make a new variable for this.
>After all, CC Mode is an important feature of Emacs.

Hey, do you want me to buy you a beer?  ;-)

>Of course, this only works for 22.x and forward, but that's life :-)

Just like syntax-table text properties only work for Emacs 20.x forwards.
Even CC Mode won't be maintaining support for 21.x for ever.  ;-)

>*** bindings.el	06 Feb 2006 18:21:19 +0100	1.157
>--- bindings.el	27 Feb 2006 10:03:17 +0100	
>***************
>*** 220,225 ****
>--- 220,231 ----
>  (defvar mode-line-frame-identification '("-%F  ")
>    "Mode-line control to describe the current frame.")

>+ (defvar mode-line-submode nil "\
>+ Mode-line control for displaying submodes of the major mode.
>+ Normally nil in most modes, since there is no submode to display.")

I'd be more emphatic in that doc-string:  "Mode line format element for
displaying extra major-mode information.  THIS SHOULD ALWAYS APPEAR TO
THE RIGHT OF VARIABLE `mode-name' WITHOUT INTERVENING SPACE.", or
something like that.

[ .... ]

>-- 
>Kim F. Storm <storm@cua.dk> http://www.cua.dk

-- 
Alan Mackenzie (Munich, Germany)




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Richard Stallman]

We try to provide features to do the jobs that need doing, but we
cannot undertake to retroactively put them into old releases of Emacs.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Richard Stallman]

    It still needs text properties (help-echo) applying to it.  Anyhow, see
    what you think of the following:

I'd prefer that the version released in Emacs make a simple
reference to mode-line-modes.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Richard Stallman]

    I don't see why we cannot just make a new variable for this.
    After all, CC Mode is an important feature of Emacs.

That's basically what mode-line-process is for.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: CC Mode 5.31.3

[Richard Stallman]

      (setq mode-name '("C" c-submode-indicators))

    isn't well supported (AFAIK in Emacs-CVS the only remaining problem is that
    the help-echo, face, and mouse-face properties are overridden by the
    ones applied generically to major mode name).

If there is some simple way to make this work better, that would be
fine with me.  But I suspect it is rather hard.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642