[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at
bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
Thu, 14 Nov 2013 20:15:35 +0200
> Date: Mon, 11 Nov 2013 11:30:02 -0800 (PST)
> From: Drew Adams <address@hidden>
> The subject line might not be the best description. And you might not
> see that this is a bug. In that case, please let me know how to work
> around the behavior I see, as it is quite annoying.
> In a Lisp file that I byte-compile and load, I have a redefinition of
> `ls-lisp--insert-directory'. (I do not see another, better way to
> accomplish the behavior change I need.) I added this when vanilla Emacs
> was changed recently to use this function. The bug does not appear for
> older Emacs code (e.g. older Emacs 24 Dev snapshots, which do not have
> It is true that I byte-compile this library using Emacs 20, because the
> library is used with multiple Emacs versions. I don't know whether
> byte-compiling it in Emacs 24 would make a difference wrt this annoying
> If doing that is the answer then I guess I'll have to split the file
> (the redefinition of this function is only done for Emacs 24.4+, i.e.,
> when that function is `fboundp').
> The symptom is that each time this function is called (at runtime, i.e.,
> using Dired), a boatload of binary byte-compile stuff is printed in
> *Messages*, and the entire doc string is printed there as well.
> What's more: when I start Emacs with a directory as the target, so it
> opens in Dired, the entire doc string is shown in the echo area (for
> which my standalone minibuffer frame is expanded automatically). So a
> user has to see that whole, irrelevant doc string for a few seconds.
> Please advise, whether or not you feel this is a bug. What can I do to
> prevent this noise. To me it seems like a bug: byte-compiled code has
> no business being logged to *Messages* or shown in the echo area during
> runtime. But you might not see it that way.
It's some snafu, but it's hard to say what is at work exactly. I
tried to reproduce this, but couldn't, because some function this code
calls is not defined. So I don't even know if compiling this in Emacs
24 would prevent the problem (but I guess you can check this
IOW, there's not enough information here to dig into the problem.