Re: c-mark-function broken in cc-mode package 1.18 (= cc-mode 5.27)

Martin Buchholz <martin(a)xemacs.org&gt; wrote: I agree it's not a very good situation, and as you can see at the top of the relevant CC Mode files I've tried to add some code to fix it: (eval-when-compile (let ((load-path (if (and (boundp 'byte-compile-current-file) (stringp byte-compile-current-file)) (cons (file-name-directory byte-compile-current-file) load-path) load-path))) (load "cc-defs" nil t))) I'm aware that it doesn't work all the time; it seems like byte-compile-current-file doesn't always get set (can't remember exactly when and why it didn't work). I remembered I tried a couple of different ways and this was the best I could come up with. If you know a more failsafe solution I'd be happy to use it. Besides, don't you have to do special treatment of other multifile packages already? Gnus and calc comes to mind, and a quick look in the calc sources reveal no measures to ensure that the correct macros are loaded at compile time. That patch must've been submitted before I started working as maintainer. I've done some work reducing the number of warnings, and it's possible to eliminate almost all of them if you sacrifice compiled file compatibility between Emacs and XEmacs. Although I personally wouldn't count on such compatibility in any case, it became apparent that some people actually use it - I had to roll back those changes. So the warnings that are left are all there for good reasons; the problems that arises from fixing them are not considered worth it. I'd say that they should be fixed in the compiler instead, by introducing a pragma construct to turn them off in specific places and/or making the compiler smarter. E.g. a smart compiler wouldn't warn about using an unbound variable in this case: (if (boundp 'this-variable-exists-in-xemacs-only) (do-something this-variable-exists-in-xemacs-only)) Good idea. Generally I believe it's better if common variables never change at package load time, since different loading orders can produce different results. However in this case I can't directly see how that could be a problem, but I still think I'd go for a solution that doesn't change auto-mode-alist at load time, to be on the safe side: ;;;###autoload (setq auto-mode-alist ;;;###autoload (cons '("\\.\\(u?lpc\\|pike\\|pmod\\)\\'" . 'pike-mode) ;;;###autoload auto-mode-alist)) The effect of this would afaics be practically identical to maintaining a global auto-mode-alist default value. Since the code is executed at dump time, there's no need to check for prior settings and append to the variable. The only issue would be to ensure that the defvar for auto-mode-alist has been executed before loaddefs.el so that the prior default value doesn't get lost (which is a potential problem in your solution as well, btw). If this alternative is ok, I think I'd prefer to register the file extensions for all the CC Mode languages this way. Then I instead would like those entries be removed from the standard auto-mode-alist value (although it wouldn't be necessary). But before I can do such a change, I have to check if this sits well with the GNU Emacs folks too.