Release of CC Mode 5.31

Release of CC Mode 5.31

[Alan Mackenzie]

Hi Richard, Hi Emacs!

I have committed CC Mode 5.31 to the Emacs Repository.  It consists of
the relevant parts of the full CC Mode release (omitting, for example,
the backward compatibility file, cc-fix.el, and our NEWS, README, etc.),
modified for Emacs in line with previous releases.  The stand alone
release is available from <http://cc-mode.sf.net/release.php>.

So far, I have committed the files.el and cc-mode.texi.  Updates to NEWS
and the two ChangeLogs should follow shortly.

As always, it would be appreciated if bug reports were cc'd to
bug-cc-mode@gnu.org.

Here is a copy of our new NEWS:

#########################################################################

CC Mode NEWS -- user visible changes.  -*- outline -*-

* Changes in 5.31

This version contains only a few new visible features, but significant
internal improvements.

** Emacs 19.34 and XEmacs 19.15 are no longer supported.
The minimum versions required are now Emacs 20.4 or XEmacs 21.4.

** The CC Mode manual has been extensively revised.
The information about using CC Mode has been separated from the larger
and more difficult chapters about configuration.

*** There are now two variants of the manual - for GNU Emacs and XEmacs.
The only difference between them is where some cross references point
(e.g. GNU Emacs Manual vs. XEmacs Manual).  The default variant is for
GNU.  To build an XEmacs version, you must define the texinfo symbol
"XEMACS".  See README and cc-mode.texi.

** Changes in Key Sequences
*** c-toggle-auto-hungry-state is no longer bound to C-c C-t.

*** c-toggle-hungry-state is no longer bound to C-c C-d.
This binding has been taken over by c-hungry-delete-forwards.

*** c-toggle-auto-state (C-c C-t) has been renamed to c-toggle-auto-newline.
c-toggle-auto-state remains as an alias.

*** c-hungry-backspace and c-hungry-delete-forwards
now have permanent key bindings, respectively C-c C-DEL (or C-c DEL, for
the benefit of TTYs) and C-c C-d (or C-c C-<delete> or C-c <delete>).
These commands delete entire blocks of whitespace with a single
key-sequence.  [N.B. "DEL" is the <backspace> key.]

*** The new command c-toggle-electric-mode is bound to C-c C-l.

*** The new command c-subword-mode is bound to C-c C-w.

** C-c C-s (`c-show-syntactic-information') now highlights the anchor
position(s).

** The new GtkDoc Doc Comment style has become the default for C Mode.
Contributed by Masatake YAMOTO.

** New Minor Modes
*** Electric Minor Mode toggles the electric action of non-alphabetic keys.
The new command c-toggle-electric-mode is bound to C-c C-l.  Turning the
mode off can be helpful for editing chaotically indented code and for
users new to CC Mode, who sometimes find electric indentation
disconcerting.  Its current state is displayed in the mode line with an
'l', e.g. "C/al".

*** Subword Minor Mode makes Emacs recognize word boundaries at upper case
letters in StudlyCapsIdentifiers.  You enable this feature by C-c C-w.  It can
also be used in non-CC Mode buffers.  :-) Contributed by Masatake YAMOTO.
Subword Minor Mode doesn't (yet?) work in Emacs 20.n.

** New clean-ups

*** `comment-close-slash'.
With this clean-up, a block (i.e. c-style) comment can be terminated by
typing a slash at the start of a line.

*** `c-one-liner-defun'
This clean-up compresses a short enough defun (for example, an AWK
pattern/action pair) onto a single line.  "Short enough" is configurable.

** AWK support
AWK Mode is now better integrated into CC Mode as a whole.  In detail:

*** Comment and line-breaking commands now work for AWK.

*** M-a and M-e (c-beginning/end-of-statement) now work for AWK.

*** "awk" style, Auto-newline insertion, special AWK initialization hook.
A new style, "awk" has been introduced, and this is now the default
style for AWK code.  With its introduction, Auto-newline insertion can
be used freely for AWK code, and there is no longer a need for the
special initialization function in the AWK Mode hook.

*** The standard Line-up functions still haven't been adapted for AWK.
Some of these may work serendipitously.  There shouldn't be any problems
writing custom indentation functions for AWK mode.

*** AWK Font Locking still hasn't been fully integrated into CC Mode.
There is just a single level of font locking in AWK mode.

#########################################################################

--
Alan Mackenzie (Munich, Germnay)

Re: Release of CC Mode 5.31

[Henrik Enberg]

> Date: Fri, 2 Dec 2005 12:20:37 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> 
> I have committed CC Mode 5.31 to the Emacs Repository.  It consists of
> the relevant parts of the full CC Mode release (omitting, for example,
> the backward compatibility file, cc-fix.el, and our NEWS, README, etc.),
> modified for Emacs in line with previous releases.  The stand alone
> release is available from <http://cc-mode.sf.net/release.php>.

I get the following error when opening a C file:

	Eval error in the `c-lang-defvar' for `c-known-type-key':
	(void-function mapcan)

`mapcan' is defined in cl-extra, and not autoloaded.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Alan Mackenzie]

Hi, Henrik, Romain!

Thanks for the reports.

On Fri, 2 Dec 2005, Henrik Enberg wrote:

>> Date: Fri, 2 Dec 2005 12:20:37 +0000 (GMT)
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> I have committed CC Mode 5.31 to the Emacs Repository.  It consists of
>> the relevant parts of the full CC Mode release (omitting, for example,
>> the backward compatibility file, cc-fix.el, and our NEWS, README, etc.),
>> modified for Emacs in line with previous releases.  The stand alone
>> release is available from <http://cc-mode.sf.net/release.php>.
>
>I get the following error when opening a C file:
>
>	Eval error in the `c-lang-defvar' for `c-known-type-key':
>	(void-function mapcan)
>
>`mapcan' is defined in cl-extra, and not autoloaded.

Romain Francoise wrote:

>For example, start Emacs with `emacs -q -nw', open src/alloc.c, you get
>the following messages:

>| Loading cc-mode...done
>| Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)
>| Loading vc-cvs...done
>| Error during redisplay: (wrong-type-argument stringp nil)

>Then if you hit TAB on the first line (which is a comment), an error is
>signaled:

>| c-forward-type: Wrong type argument: stringp, nil

>(This is in a freshly compiled Emacs after `make maintainer-clean'.)


This looks like a known problem, which was discussed in the thread "CC
mode loads CL" in the mailing lists emacs-pretext-bug@gnu.org and
bug-cc-mode@gnu.org starting ~6th January 2004.  That thread's rather
heavy going - I'm looking for the solution there at the moment.

-- 
Alan Mackenzie (Munich, Germany)

Re: Release of CC Mode 5.31

[Richard M. Stallman]

The solution is, don't use mapcan.
Would you please fix that?


-------------------------------------------------------
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: Release of CC Mode 5.31

[Alan Mackenzie]

Hi,

On Sat, 3 Dec 2005, Richard M. Stallman wrote:

>The solution is, don't use mapcan.
>Would you please fix that?

Fixed.  The CC Mode source files now only (attempt to) use mapcan at byte
compile time.

All the same, it would be nice to have mapcan in the Emacs core.  It is
such a basic useful function.  Not having mapcan available at runtime (in
combination with other circumstances) got me horribly confused, causing
me to commit buggy files, not only to the Emacs repository but also to
the CC Mode project at SourceForge.

Again, any chance of getting mapcan into the Emacs 22 core?

-- 
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: Release of CC Mode 5.31

[Alan Mackenzie]

Hi, Henrik, Romain!

Thanks for these reports:

On Fri, 2 Dec 2005, Henrik Enberg wrote:
>
>	Eval error in the `c-lang-defvar' for `c-known-type-key':
>	(void-function mapcan)
>
>`mapcan' is defined in cl-extra, and not autoloaded.

Romain Francoise wrote:

>For example, start Emacs with `emacs -q -nw', open src/alloc.c, you get
>the following messages:

>| Loading cc-mode...done
>| Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)

I think I've fixed this, and I've commited the fix, in cc-langs.el, to
the repository.  It was a run-time `mapcan', which had to be replaced.
Could you test the fix, please?

HEY YOU GUYS (in emacs-devel)!  Is there any chance we could have mapcan
(and possibly the other mapping functions in the table on page 85 of the
orange Lisp Machine Manual ;-) in the Emacs core for 22.1?  Please?
Pretty Please?

-- 
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: Release of CC Mode 5.31

[Romain Francoise]

Alan Mackenzie <acm@muc.de> writes:

> I think I've fixed this, and I've commited the fix, in cc-langs.el, to
> the repository.  It was a run-time `mapcan', which had to be replaced.
> Could you test the fix, please?

Works great here, thanks!

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter


-------------------------------------------------------
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: Release of CC Mode 5.31

[Henrik Enberg]

> Date: Sat, 3 Dec 2005 11:48:02 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> 
> Hi, Henrik, Romain!
> 
> Thanks for these reports:
> 
> On Fri, 2 Dec 2005, Henrik Enberg wrote:
> >
> >	Eval error in the `c-lang-defvar' for `c-known-type-key':
> >	(void-function mapcan)
> >
> >`mapcan' is defined in cl-extra, and not autoloaded.
> 
> Romain Francoise wrote:
> 
> >For example, start Emacs with `emacs -q -nw', open src/alloc.c, you get
> >the following messages:
> 
> >| Loading cc-mode...done
> >| Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)
> 
> I think I've fixed this, and I've commited the fix, in cc-langs.el, to
> the repository.  It was a run-time `mapcan', which had to be replaced.
> Could you test the fix, please?

Yep, works just fine now.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Richard M. Stallman]

    HEY YOU GUYS (in emacs-devel)!  Is there any chance we could have mapcan
    (and possibly the other mapping functions in the table on page 85 of the
    orange Lisp Machine Manual ;-) in the Emacs core for 22.1?  Please?
    Pretty Please?

I don't see any great need for mapcan.  It has never been very
common, and it is easy to do (apply 'nconc (mapcar ...)).

Since I do not have a copy of the Lisp Machine Manual, I do not know
which other functions you are talking about here.

Re: Release of CC Mode 5.31

[Alan Mackenzie]

Hi, Richard!

On Sat, 3 Dec 2005, Richard M. Stallman wrote:

>    HEY YOU GUYS (in emacs-devel)!  Is there any chance we could have
>    mapcan (and possibly the other mapping functions in the table on
>    page 85 of the orange Lisp Machine Manual ;-) in the Emacs core for
>    22.1?  Please?  Pretty Please?

>I don't see any great need for mapcan.  It has never been very
>common, and it is easy to do (apply 'nconc (mapcar ...)).

Well, mapcan might be uncommon because it exists only in cl-extra - a
chicken and egg situation.

(apply 'nconc (mapcar ...)) is more difficult to read and understand than
(mapcan ....).  The macros in CC Mode's cc-langs.el and cc-defs.el are
difficult enough to understand, even without this added difficulty.  This
complexity in CC Mode is, I believe, essential rather than frivolous.

>Since I do not have a copy of the Lisp Machine Manual, I do not know
>which other functions you are talking about here.

The "Lisp chine nual" is a work of art, a model of clarity, the epitome
of effective technical writing, and I can recommend it to anybody.  ;-)

The table on page 85 contrasts the various mapping functions according to
how they select the bits of the list to work on, and what they return as
a result.  It looks like this:


                              applies function to

                         |  successive  |   successive  |
                         |   sublists   |    elements   |
          ---------------+--------------+---------------+
              its own    |              |               |
              second     |    map(l)    |    mapc       |
             argument    |              |               |
          ---------------+--------------+---------------+
            list of the  |              |               |
returns      function    |   maplist    |    mapcar     |
              results    |              |               |
          ---------------+--------------+---------------+
            nconc of the |              |               |
              function   |   mapcon     |    mapcan     |
              results    |              |               |
          ---------------+--------------+---------------+

Of these six functions, only mapc and mapcar exist in vanilla Emacs 22.
For the rest, you need to load cl-extra first.  This seems a shame.

-- 
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: Release of CC Mode 5.31

[Richard M. Stallman]

    Of these six functions, only mapc and mapcar exist in vanilla Emacs 22.

map, maplist and mapcon are hardly ever used.

I don't want to make Emacs bigger for reasons of the sort
you are arguing now.



-------------------------------------------------------
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: Release of CC Mode 5.31

[Eli Zaretskii]

> Date: Sat, 3 Dec 2005 11:48:02 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> Cc: bug-cc-mode@gnu.org, mast@lysator.liu.se, emacs-devel@gnu.org
> 
> >For example, start Emacs with `emacs -q -nw', open src/alloc.c, you get
> >the following messages:
> 
> >| Loading cc-mode...done
> >| Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)
> 
> I think I've fixed this, and I've commited the fix, in cc-langs.el, to
> the repository.  It was a run-time `mapcan', which had to be replaced.
> Could you test the fix, please?

Sorry, but it doesn't seem to be fixed just yet.  I still get the same
error message when I try to visit any *.c file (in "emacs -q"):

  Loading cc-mode...done
  Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)

I can see a few calls to mapcan in cc-langs.el, if that matters.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, but it doesn't seem to be fixed just yet.  I still get the same
> error message when I try to visit any *.c file (in "emacs -q")

Try bootstrapping, or removing lisp/progmodes/cc-*.elc before recompiling.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Release of CC Mode 5.31

[Alan Mackenzie]

Hi, Eli!

On Sun, 4 Dec 2005, Eli Zaretskii wrote:

>> Date: Sat, 3 Dec 2005 11:48:02 +0000 (GMT)
>> From: Alan Mackenzie <acm@muc.de>
>> Cc: bug-cc-mode@gnu.org, mast@lysator.liu.se, emacs-devel@gnu.org
 
>> >For example, start Emacs with `emacs -q -nw', open src/alloc.c, you get
>> >the following messages:
 
>> >| Loading cc-mode...done
>> >| Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)

>> I think I've fixed this, and I've commited the fix, in cc-langs.el, to
>> the repository.  It was a run-time `mapcan', which had to be replaced.
>> Could you test the fix, please?

>Sorry, but it doesn't seem to be fixed just yet.  I still get the same
>error message when I try to visit any *.c file (in "emacs -q"):

After downloading the new cc-langs.el, you need to byte-compile first
cc-langs.el (which builds the macro c-init-language-vars), then
cc-mode.el (which expands this macro (in the defun
c-init-language-vars-for)).

>  Loading cc-mode...done
>  Eval error in the `c-lang-defvar' for `c-known-type-key': (void-function mapcan)

Do you still get this problem, or has it gone away?

>I can see a few calls to mapcan in cc-langs.el, if that matters.

All of these (hopefully) are only called at byte-compile time.

-- 
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: Release of CC Mode 5.31

[Eli Zaretskii]

> Date: Tue, 6 Dec 2005 12:11:58 +0000 (GMT)
> From: Alan Mackenzie <acm@muc.de>
> cc: henrik.enberg@telia.com, romain@orebokech.com, bug-cc-mode@gnu.org,
>         mast@lysator.liu.se, emacs-devel@gnu.org
> 
> >Sorry, but it doesn't seem to be fixed just yet.  I still get the same
> >error message when I try to visit any *.c file (in "emacs -q"):
> 
> After downloading the new cc-langs.el, you need to byte-compile first
> cc-langs.el (which builds the macro c-init-language-vars), then
> cc-mode.el (which expands this macro (in the defun
> c-init-language-vars-for)).

After I saw the problem, but before I reported it, I recompiled all
the cc-*.el files, by "make recompile".  Perhaps that command does not
compile the files in the order you mention.  It would be nice if it
did that automatically.

> Do you still get this problem, or has it gone away?

No, I don't.

> >I can see a few calls to mapcan in cc-langs.el, if that matters.
> 
> All of these (hopefully) are only called at byte-compile time.

Why leave them there in the first place?  The replacement is easy
enough; having some of the mapcan's replaced and some left in the code
is confusing, IMHO.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Richard M. Stallman]

    After I saw the problem, but before I reported it, I recompiled all
    the cc-*.el files, by "make recompile".  Perhaps that command does not
    compile the files in the order you mention.  It would be nice if it
    did that automatically.

There is no Emacs feature to control order of compilation,
so there would be no easy way to make that automatic.

However, I wonder about this:

    > After downloading the new cc-langs.el, you need to byte-compile first
    > cc-langs.el (which builds the macro c-init-language-vars), then
    > cc-mode.el (which expands this macro (in the defun
    > c-init-language-vars-for)).

Why is it crucial to compile cc-langs.el before compiling cc-mode.el?
Once you have deleted cc-langs.elc, compilation of cc-mode.el will use
the source file, cc-langs.el.  Does compilation of cc-mode.el fail to
work properly with the interpreted cc-langs.el?


-------------------------------------------------------
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: Release of CC Mode 5.31

[Alan Mackenzie]

On Wed, 7 Dec 2005, Richard M. Stallman wrote:

>    After I saw the problem, but before I reported it, I recompiled all
>    the cc-*.el files, by "make recompile".  Perhaps that command does not
>    compile the files in the order you mention.  It would be nice if it
>    did that automatically.

>There is no Emacs feature to control order of compilation,
>so there would be no easy way to make that automatic.

>However, I wonder about this:

>    > After downloading the new cc-langs.el, you need to byte-compile first
>    > cc-langs.el (which builds the macro c-init-language-vars), then
>    > cc-mode.el (which expands this macro (in the defun
>    > c-init-language-vars-for)).

>Why is it crucial to compile cc-langs.el before compiling cc-mode.el?

To be honest, I'm not sure any more whether this is accurate.  cc-mode
uses a macro (c-init-language-vars) in cc-langs which generates a massive
setq form for all the language dependant variables.  This macro is
expanded 7 times, once for each constituent language.

So, if cc-mode picks up an (old) cc-langs.elc in preference to a (newer)
cc-langs.el, things will fail.

>Once you have deleted cc-langs.elc, compilation of cc-mode.el will use
>the source file, cc-langs.el.  Does compilation of cc-mode.el fail to
>work properly with the interpreted cc-langs.el?

It should work fine with the interpreted cc-langs.el, as long as it
doesn't load the (older) cc-langs.elc instead.  Deleting an outdated
cc-langs.elc should definitely make it work.

-- 
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: Release of CC Mode 5.31

[Richard M. Stallman]

    So, if cc-mode picks up an (old) cc-langs.elc in preference to a (newer)
    cc-langs.el, things will fail.

Yes, I understand that, but...

    It should work fine with the interpreted cc-langs.el, as long as it
    doesn't load the (older) cc-langs.elc instead.

that's exactly my point.  Eli said he deleted the .elc files.
So why did it fail?


-------------------------------------------------------
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: Release of CC Mode 5.31

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: acm@muc.de, bug-cc-mode@gnu.org, henrik.enberg@telia.com,
> 	romain@orebokech.com, mast@lysator.liu.se, emacs-devel@gnu.org
> Date: Wed, 07 Dec 2005 12:07:04 -0500
> 
>     After I saw the problem, but before I reported it, I recompiled all
>     the cc-*.el files, by "make recompile".  Perhaps that command does not
>     compile the files in the order you mention.  It would be nice if it
>     did that automatically.
> 
> There is no Emacs feature to control order of compilation,
> so there would be no easy way to make that automatic.

I thought about some Make magic, like making some of the *.elc files
dependent on some other *.elc files which need to be compiled first.
(We already have COMPILE_FIRST files that work around similar
problems.)  Is there any reason why this wouldn't work?


-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

>> After I saw the problem, but before I reported it, I recompiled all
>> the cc-*.el files, by "make recompile".  Perhaps that command does not
>> compile the files in the order you mention.  It would be nice if it
>> did that automatically.
>> 
>> There is no Emacs feature to control order of compilation,
>> so there would be no easy way to make that automatic.

> I thought about some Make magic, like making some of the *.elc files
> dependent on some other *.elc files which need to be compiled first.
> (We already have COMPILE_FIRST files that work around similar
> problems.)  Is there any reason why this wouldn't work?

That would work.  It'd be even better to generate this dependency info
automatically.  Ideally, the byte-compiler would keep track of which macros
are used, so that it can automatically generate exact
dependency information.

Note that e.g. if we change the dolist macro, it's not enough to recompile
subr.el before the other files, since we also need to redump the executable
after recompiling subr.el.


        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: Release of CC Mode 5.31

[Eli Zaretskii]

> Cc: rms@gnu.org, mast@lysator.liu.se, romain@orebokech.com,
> 	emacs-devel@gnu.org, bug-cc-mode@gnu.org, henrik.enberg@telia.com,
> 	acm@muc.de
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 07 Dec 2005 14:51:22 -0500
> 
> > I thought about some Make magic, like making some of the *.elc files
> > dependent on some other *.elc files which need to be compiled first.
> > (We already have COMPILE_FIRST files that work around similar
> > problems.)  Is there any reason why this wouldn't work?
> 
> That would work.  It'd be even better to generate this dependency info
> automatically.  Ideally, the byte-compiler would keep track of which macros
> are used, so that it can automatically generate exact
> dependency information.

WIBNI we had something like "gcc -MM"?

> Note that e.g. if we change the dolist macro, it's not enough to recompile
> subr.el before the other files, since we also need to redump the executable
> after recompiling subr.el.

Well, yeah, I know that there are hard cases where even Make will be
unable to help.  But I think there's a lot to be done before we get
there.

Re: Release of CC Mode 5.31

[Richard M. Stallman]

    Note that e.g. if we change the dolist macro, it's not enough to recompile
    subr.el before the other files, since we also need to redump the executable
    after recompiling subr.el.

Bootstrapping ought to handle this case properly, right?

I do not want to introduce dependency information about macros in
subr.el and other preloaded files.  It would be a lot of added
complexity, a lot of work, and not worth the trouble.

However, for macros defined in non-preloaded files, the files that use
them should use `require' to insure they are loaded before they are
needed.  This way, deleting the .elc files for the macro definitions
ought to be enough to make them work properly.



-------------------------------------------------------
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: Release of CC Mode 5.31

[Richard M. Stallman]

    I thought about some Make magic, like making some of the *.elc files
    dependent on some other *.elc files which need to be compiled first.
    (We already have COMPILE_FIRST files that work around similar
    problems.)  Is there any reason why this wouldn't work?

It would be possible, but very inconvenient.  And it would not do any good
for people that do M-x byte-recompile-directory.  The right thing to do
is figure out what really went wrong here, and then change the files
to avoid the problem.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

>     I thought about some Make magic, like making some of the *.elc files
>     dependent on some other *.elc files which need to be compiled first.
>     (We already have COMPILE_FIRST files that work around similar
>     problems.)  Is there any reason why this wouldn't work?

> It would be possible, but very inconvenient.  And it would not do any good
> for people that do M-x byte-recompile-directory.  The right thing to do
> is figure out what really went wrong here, and then change the files
> to avoid the problem.

I think a good change to avoid (or at least reduce) such problems would be:

When the byte-compiler sees a `require', and the corresponding .elc file is
older than the corresponding .el file, it should load the .el file.


        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: Release of CC Mode 5.31

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, mast@lysator.liu.se,
> 	romain@orebokech.com, emacs-devel@gnu.org, bug-cc-mode@gnu.org,
> 	henrik.enberg@telia.com, acm@muc.de
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 08 Dec 2005 11:43:13 -0500
> 
> When the byte-compiler sees a `require', and the corresponding .elc file is
> older than the corresponding .el file, it should load the .el file.

By this very logic, when you (load "foo")---after all, `load' and
`require' are very similar---Emacs should load foo.el if it is newer
than foo.elc.  And yet we don't do that, and I think for a very good
reason.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

>> When the byte-compiler sees a `require', and the corresponding .elc file is
>> older than the corresponding .el file, it should load the .el file.

> By this very logic, when you (load "foo")---after all, `load' and
> `require' are very similar---Emacs should load foo.el if it is newer
> than foo.elc.

Yes, that too.

> And yet we don't do that, and I think for a very good reason.

I don't know about "very good".  AFAIK the reason is so that you can mess up
the .el file as badly as you want (e.g. with conflict markers when merging
updates) without breaking things and only once you byte-compile will you
make your changes visible to Emacs (kind of like a "commit").

While I don't claim that it's a bad reason, I'm not sure it's that much
better than the reason we're facing which argues to use the other behavior
(prefer the .el over the .elc if the .el is more recent).


        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: Release of CC Mode 5.31

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> When the byte-compiler sees a `require', and the corresponding .elc file is
>>> older than the corresponding .el file, it should load the .el file.
>
>> By this very logic, when you (load "foo")---after all, `load' and
>> `require' are very similar---Emacs should load foo.el if it is newer
>> than foo.elc.
>
> Yes, that too.
>
>> And yet we don't do that, and I think for a very good reason.
>
> I don't know about "very good".  AFAIK the reason is so that you can mess up
> the .el file as badly as you want (e.g. with conflict markers when merging
> updates) without breaking things and only once you byte-compile will you
> make your changes visible to Emacs (kind of like a "commit").

This means that you can work on a .el file for a period of time
without making emacs useless if you happen to exit and restart emacs
in case there are errors in that file.

OTOH, I wish emacs would unconditionally load .el files if started
with -D option so it was easier to debug stuff without having to guess
what code is executed by the byte-compiler.

But then again, it would make debugging of errors in byte-compiler
more difficult...


Anyways, none of this as any effect on lisp code loaded into the
dumped emacs, which is also known to confuse users...

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



-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

> This means that you can work on a .el file for a period of time
> without making emacs useless if you happen to exit and restart emacs
> in case there are errors in that file.

My suggestion was to only do it when byte-compiling, so no: it wouldn't make
Emacs useless; just unable to byte-compile files that require it.


        Stefan

Re: Release of CC Mode 5.31

[Eli Zaretskii]

> Cc: mast@lysator.liu.se,  romain@orebokech.com,  emacs-devel@gnu.org,
> 	  bug-cc-mode@gnu.org,  henrik.enberg@telia.com,  acm@muc.de,
> 	  Eli Zaretskii <eliz@gnu.org>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 08 Dec 2005 18:46:28 -0500
> 
> > This means that you can work on a .el file for a period of time
> > without making emacs useless if you happen to exit and restart emacs
> > in case there are errors in that file.
> 
> My suggestion was to only do it when byte-compiling, so no: it wouldn't make
> Emacs useless; just unable to byte-compile files that require it.

Kim was talking about what `load' does (which you agreed should follow
the same logic as `require').  And use of `load' is not limited to
byte-compiling.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

>> > This means that you can work on a .el file for a period of time
>> > without making emacs useless if you happen to exit and restart emacs
>> > in case there are errors in that file.
>> 
>> My suggestion was to only do it when byte-compiling, so no: it wouldn't make
>> Emacs useless; just unable to byte-compile files that require it.

> Kim was talking about what `load' does (which you agreed should follow
> the same logic as `require').  And use of `load' is not limited to
> byte-compiling.

He didn't specify *when*.  I agreed that `load' should do the same in the
same context (i.e. when triggered from byte-compiling such as when
autoloading a macro).


        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: Release of CC Mode 5.31

[Richard M. Stallman]

    He didn't specify *when*.  I agreed that `load' should do the same in the
    same context (i.e. when triggered from byte-compiling such as when
    autoloading a macro).

I'm certainly not going to make such a radical change now,
so please let it drop.

(I would be reluctant to make this change at any time.)


-------------------------------------------------------
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: Release of CC Mode 5.31

[Eli Zaretskii]

> Cc: mast@lysator.liu.se,  romain@orebokech.com,  emacs-devel@gnu.org,
> 	  bug-cc-mode@gnu.org,  henrik.enberg@telia.com,  acm@muc.de
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 08 Dec 2005 17:24:45 -0500
> 
> I don't know about "very good".  AFAIK the reason is so that you can mess up
> the .el file as badly as you want (e.g. with conflict markers when merging
> updates) without breaking things

Yes.

> While I don't claim that it's a bad reason, I'm not sure it's that much
> better than the reason we're facing which argues to use the other behavior

It's certainly better for when you update Emacs from CVS and then run
"make" to build the new version.  Currently, you at least can build
Emacs from C sources before you "make recompile" in the lisp
directory; with the logic you suggest, it might fail due to mixing old
*.elc files with new *.el files.


-------------------------------------------------------
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: Release of CC Mode 5.31

[Stefan Monnier]

>> While I don't claim that it's a bad reason, I'm not sure it's that much
>> better than the reason we're facing which argues to use the other behavior

> It's certainly better for when you update Emacs from CVS and then run
> "make" to build the new version.  Currently, you at least can build
> Emacs from C sources before you "make recompile" in the lisp
> directory; with the logic you suggest, it might fail due to mixing old
> *.elc files with new *.el files.

Not if you only use the new behavior during byte-compilation, as I suggest.


        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: Release of CC Mode 5.31

[Richard M. Stallman]

    While I don't claim that it's a bad reason, I'm not sure it's that much
    better than the reason we're facing which argues to use the other behavior
    (prefer the .el over the .elc if the .el is more recent).

Please stop arguing for such a radical change.  We should not even be
discussing such ideas now.

You have seen my decision.




-------------------------------------------------------
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: Release of CC Mode 5.31

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> When the byte-compiler sees a `require', and the corresponding .elc file is
> older than the corresponding .el file, it should load the .el file.

IMHO there should at least be an option to do this.  That would make
byte-recompile-directory less error-prone.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Release of CC Mode 5.31

[Richard M. Stallman]

    When the byte-compiler sees a `require', and the corresponding .elc file is
    older than the corresponding .el file, it should load the .el file.

There are arguments both for and against this, so I think we should
not change it now.

In any case, Eli just saw it fail after he deleted all these .elc
files.  That must be _a different problem_, and we don't understand
it.

Please, everyone, let' focus on finding out what caused _that_
problem.  Now is not the time to suggest changes which are not bug
fixes and are more radical than bugs require.



-------------------------------------------------------
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: Release of CC Mode 5.31

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: acm@muc.de, bug-cc-mode@gnu.org, henrik.enberg@telia.com,
> 	romain@orebokech.com, mast@lysator.liu.se, emacs-devel@gnu.org
> Date: Wed, 07 Dec 2005 23:53:49 -0500
> 
>     I thought about some Make magic, like making some of the *.elc files
>     dependent on some other *.elc files which need to be compiled first.
>     (We already have COMPILE_FIRST files that work around similar
>     problems.)  Is there any reason why this wouldn't work?
> 
> It would be possible, but very inconvenient.

Why inconvenient?

> And it would not do any good for people that do M-x
> byte-recompile-directory.

I don't think I'd mind if byte-recompile-directory couldn't handle
such problems, since it isn't supposed to be used for such situations.
By contrast, Make was invented to handle this.

> The right thing to do is figure out what really went wrong here, and
> then change the files to avoid the problem.

I agree that we should find that out, but we already know that the .el
files with macros need to be compiled before those which use the
macros, so why not do something that would fix this?


-------------------------------------------------------
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: Release of CC Mode 5.31

[Richard M. Stallman]

    > It would be possible, but very inconvenient.

    Why inconvenient?

To start using make to recompile Lisp files would be inconvenient.

This proposal is a major change in how things work.  Please don't
propose such big changes now.  I don't want to spend time thinking
about them, or discussing them, so please do not propose them.




-------------------------------------------------------
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: Release of CC Mode 5.31

[Romain Francoise]

Alan Mackenzie <acm@muc.de> writes:

> *** Subword Minor Mode makes Emacs recognize word boundaries at upper case
> letters in StudlyCapsIdentifiers.  You enable this feature by C-c C-w.
> It can also be used in non-CC Mode buffers.  :-) Contributed by
> Masatake YAMOTO.

For the record, this is awesome.  Thanks!

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Release of CC Mode 5.31

[Alan Mackenzie]

On Tue, 6 Dec 2005, Romain Francoise wrote:

>Alan Mackenzie <acm@muc.de> writes:
>
>> *** Subword Minor Mode makes Emacs recognize word boundaries at upper case
>> letters in StudlyCapsIdentifiers.  You enable this feature by C-c C-w.
>> It can also be used in non-CC Mode buffers.  :-) Contributed by
>> Masatake YAMOTO.

Correction:  Masatake YAMATO, with sincere apologies to him for
mis-spelling his name (since corrected in the repository).

>For the record, this is awesome.  Thanks!

>-- 
>Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
>it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
>                                        | ever free! --Bryan W. Procter

-- 
Alan Mackenzie

Re: Release of CC Mode 5.31

[Masatake YAMATO]

> Alan Mackenzie <acm@muc.de> writes:
> 
> > *** Subword Minor Mode makes Emacs recognize word boundaries at upper case
> > letters in StudlyCapsIdentifiers.  You enable this feature by C-c C-w.
> > It can also be used in non-CC Mode buffers.  :-) Contributed by
> > Masatake YAMOTO.
> 
> For the record, this is awesome.  Thanks!

ThankYou. 
I recommend you to try cc-guess.el which is extra part of 
cc-mode. With the program, cc-mode learns indentation rules
from the current buffer contents.

Masatake YAMATO

Re: Release of CC Mode 5.31

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Date: Tue, 06 Dec 2005 11:32:00 +0100
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > *** Subword Minor Mode makes Emacs recognize word boundaries at upper case
> > letters in StudlyCapsIdentifiers.  You enable this feature by C-c C-w.
> > It can also be used in non-CC Mode buffers.  :-) Contributed by
> > Masatake YAMOTO.
> 
> For the record, this is awesome.  Thanks!

Perhaps you should try the Glasses Mode.

Re: Release of CC Mode 5.31

[Romain Francoise]

Eli Zaretskii <eliz@gnu.org> writes:

> Perhaps you should try the Glasses Mode.

I know about it and I don't like it:

- if you configure it to add a separator, the buffer contents and the
  code don't match, you end up confusing the real names and the
  overlayed ones;

- if you configure it to just change the face, you get a gruesome fruit
  salad.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Release of CC Mode 5.31

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 06 Dec 2005 21:49:35 +0100
> 
> > Perhaps you should try the Glasses Mode.
> 
> I know about it and I don't like it:

You should dislike NamesLikeThisOne, not Glasses Mode, because the
former is the real culprit.