Ar an deichiú lá de mí Méan Fómhair, scríobh Alan Mackenzie:
On Fri, Sep 09, 2011 at 11:14:29PM +0100, Aidan Kehoe wrote:
> In general, there’s no particular problem with it, but you’re
> interfering with the guts of byte-compilation in cc-defs.el, we don’t
> (and can’t really) guarantee that functions with side effects like
> #'set-buffer won’t cause problems if those side effects aren’t wrapped,
> when you do something like that.
OK. But cc-defs.el is included in every other cc-*.el, yet only causes
(?appears to cause?) problems in cc-align.el. This worries me a bit.
It causes problems in cc-align.el because that’s the first file compiled and
the sequence of buffers made current is slightly different for the first
file compiled than for later files. I can equally provoke the (new) error
message like so:
$ /Sources/xemacs-21.5-buffer-warning/src/xemacs -batch -no-site-file -q -f
While compiling toplevel forms in file /tmp/aidan/cc-mode-5.32/cc-engine.el:
!! Invalid state (("byte compiling didn't save-excursion appropriately"
>Error occurred processing cc-engine.el: Invalid state: byte
compiling didn't save-excursion appropriately, #<buffer
Killing the current buffer is analogous to this:
(let ((old-buffer (current-buffer)))
(set-buffer (other-buffer old-buffer))
and #'other-buffer doesn’t offer any guarantee that it will be particularly
predictable, neither in its documentation nor in its implementation. Wrap
And it doesn't interfere with M-x byte-compile-file. That might
you a bit. ;-)
Right now it throws the error for me if I call M-x byte-compile-file RET;
I’m glad it no longer fails silently.
The cc-defs.el fix does indeed work for me. I'll get CC Mode
released as soon as I can, which might be the middle of next week.
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
XEmacs-Beta mailing list