Re: c-mark-function broken in cc-mode package 1.18 (= cc-mode 5.27)
>>>> "AJ" == Andreas Jaeger <aj(a)suse.de>
writes:
APA> I get this backtrace when I try to
APA> C-M-h runs the command c-mark-function
APA> inside a c function.
> /.../
>> This is with CC-Mode 5.27.
>>
>> Andreas
>>
APA> Signaling: (invalid-function (macro . #<compiled-function
(&optional arg) "...(38)" [arg 1 goto-char or scan-sexps (point) 0
(point-max) (point-min) if > (0) ((point-max) (point-min))] 7>))
> I can't duplicate this with a CC Mode I've compiled from
the source
> package with XEmacs 21.
> I think this is due to incorrect compilation in the XEmacs
package - a
> macro wasn't defined during compilation, so the compiler put in a
> function call to it. Then during execution the macro can't be
> evaluated in place of the function call.
> So my suggestion is that the XEmacs package maintainer redo the
> compilation and makes sure that no old CC Mode installation affects
> the compilation (specifically, that the right cc-defs.el file is
> loaded during compilation; it contains (almost) all macros that CC
> Mode uses internally). The compilation instructions in the README file
> _should_ ensure that the compilation is performed correctly even if
> there are other versions of CC Mode in the load path.
AJ> We're not
using the normal cc-make.el and I had to preload cc-defs.el
AJ> to get it working. I've just uploaded a new package (1.19) which
AJ> works for me.
I believe it rather evil that the cc-mode elisp files need special
compilation support. In 1996, both I and a colleague of mine
encountered the bug of cc-mode elisp files not being properly
compiled. I believe in 1996 or 1997 I submitted a patch to cc-mode
that fixes all the .el files that are part of that package so that
each can be independently bytecompiled without warnings, and by both
emacs and xemacs. This actually is (or was) rather tricky because of
the circular requires. Andreas is the third person to have run into
this problem. I predict that anyone who hacks on cc-mode in the
future is likely to shoot themselves in the foot in exactly the same
way. It is expected that anyone should be able to use the menu item
"Byte-compile this buffer" and have meaningful results. Elisp files
are supposed to ensure this by having correct protection forms at the
top, usually of the form
(eval-when-compile
...)
I would be willing to work on this again (or dig up my old patch) if
the current CC mode maintainers (thats you, Martin S!) would be
willing to accept it.
> Btw, CC Mode supports a new language Pike for some time now
(since
> 5.23), but as of yet the XEmacs distribution doesn't contain the file
> extension bindings for Pike files in the standard auto-mode-alist
> (although I've requested it to be added). I'd be grateful if someone
> with the necessary access could add the binding
> ("\\.\\(u?lpc\\|pike\\|pmod\\)\\'" . pike-mode)
> to the standard auto-mode-alist. (It'd be neat if standard
settings to
> variables like that one could be decentralised somehow. Modifying it
> at package load time, like some other packages do, introduces problems
> that you probably already are aware of.)
AJ> That would really be neat.
Martin, what do you think? Is there a way
AJ> to do this automatically - I didn't follow the last discussion closely
AJ> enough.
We didn't come to a definite conclusion.
If autoload cookies are acceptable to the package maintainers, then
(completely untested)
;;;###autoload
(unless (rassq 'pike-mode auto-mode-alist)
(setq auto-mode-alist (append auto-mode-alist
'(("\\.\\(u?lpc\\|pike\\|pmod\\)\\'" . pike-mode)))))
The above has the advantage that:
- It's much more efficient to compare the symbols than the strings
- you never get duplicate entries in auto-mode-alist
- the entries are appended, rather than prepended, so the user's
settings get precedence.
- control is centralized in the package sources.
On the other hand, someone pointed out that you'd like a warning even
if cc-mode is not installed, like
Warning: If cc-mode were installed, this buffer would be in Pike mode.
But warnings are annoying as well, so this has pluses and minuses.
Anyways, please try the above code or something like it.
Martin