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

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

[Stefan Monnier]

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

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

[Nick Roberts]

 > 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

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

[Alan Mackenzie]

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

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

[Nick Roberts]

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

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

[Alan Mackenzie]

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

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

[Nick Roberts]

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

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

[Eli Zaretskii]

> 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

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

[Alan Mackenzie]

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

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

[Stefan Monnier]

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

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

[Alan Mackenzie]

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

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

[Richard M. Stallman]

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