bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 11 Nov 2013 11:30:02 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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
> `ls-lisp--insert-directory').
> 
> 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
> behavior.
> 
> 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
yourself).

IOW, there's not enough information here to dig into the problem.