🚀 go-pugleaf

>    (symbol-function 'replace-region)
>    (lambda (str-replace) "Replaces a regular expression or string, given prefix arg STR-REPLACE, in a region." (interactive "P") (byte-code "BBC	
>
>It appears that the byte-compiler version you sent was mangled by mailers.
>
>Could you try splitting up the lines using backslash-newline anbd send
>it again?
>
>I'd like to disassemble it and see if the code is incorrect.  I'd also
>like to compare it with what I get if I compile the same thing.
>
>      I should
>    mention that I have also demonstrated problems with the byte compiler in
>    the last few days such that .el code that works fine when loaded fails
>    when loaded in .elc form.
>
>That would certainly be a bug, and probably one much easier to
>investigate than unpredicatable crashes.  I don't remember seeing a
>report of this bug.  Could you please send one?

I did find the bug (not an actual Emacs bug) and solution.
Possibly, I forgot to report it to bug-gnu-emacs.
I repeat the message here.


Subject: I figured out byte-compiling/Emacs crashing problem.

A few days ago, I had the bright idea of using Emacs outlining mode
(actually outline-minor-mode, a non-standard Emacs Lisp package) while
editing from a terminal since the display size is limited and the
refresh time slow (over 2400 baud phone line).  That way I can quickly
move past functions I have collapsed into a single line and I don't get
long scroll delays.  This was so handy I decided to turn on
outline-minor-mode as part of emacs-lisp-mode-hook.

Well, Emacs replaces hidden newlines with ^M characters when in outline
mode and a comparison of the .elc files which don't work shows they all
have newline characters where the working ones have ^Ms, since whenever
the variable 'selective-display' is true in a buffer, Emacs converts ^Ms
to newlines before it saves the buffer.

Yet I would not expect the temp buffer the .elc file is written to, to
be in emacs-lisp-mode.  But a quick scan of the byte-compile-file
function shows that it does indeed put the temp buffer into this mode so
that it can use the definition of Lisp s-expressions when producing the
.elc code.

Quite a tricky problem.  This bad code in turn caused Emacs to crash on
me several times, within the past few days but only after several hours
of use, so the fact that the .elc files were invalid was not evident.

Given that this scenario can occur, I would suggest that the
byte-compile-file code locally bind emacs-lisp-mode-hook to nil so that
this will not happen to anyone else.

I am going to do that in my own local version.  If we put such a change
into our department local/lisp directory, we must remember to update it
with each new Emacs release that alters bytecomp.el.  I will try to get
the GNU people to put the change in themselves.

Bob

(Since I put in the fix and recompiled those files I had modified in
the week during which this was happening, all has been fine and the
crashes are gone.)