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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15861 in the body.
You can then email your comments to 15861 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
Date: Mon, 11 Nov 2013 11:30:02 -0800 (PST)

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.


Here is the redefinition, in case its relevant to the bug or otherwise
helpful (doubtful):

;; REPLACE ORIGINAL in `ls-lisp.el'
;;
;; 1. If wildcard, set FILE to `default-directory' if FILE has no dir component.
;; 2. In second header line: include the number of files and subdirs in the directory.
;;
(when (fboundp 'ls-lisp--insert-directory) ; Emacs 24.4+
  (defun ls-lisp--insert-directory (orig-fun file switches &optional wildcard full-directory-p)
    "Insert directory listing for FILE, formatted according to SWITCHES.
Leaves point after the inserted text.
SWITCHES may be a string of options, or a list of strings.
Optional third arg WILDCARD means treat FILE as shell wildcard.
Optional fourth arg FULL-DIRECTORY-P means file is a directory and
switches do not contain `d', so that a full listing is expected.

This version of the function comes from `ls-lisp.el'.
If the value of `ls-lisp-use-insert-directory-program' is non-nil then
this advice just delegates the work to ORIG-FUN (the normal `insert-directory'
function from `files.el').
But if the value of `ls-lisp-use-insert-directory-program' is nil
then it runs a Lisp emulation.

The Lisp emulation does not run any external programs or shells.  It
supports ordinary shell wildcards if `ls-lisp-support-shell-wildcards'
is non-nil; otherwise, it interprets wildcards as regular expressions
to match file names.  It does not support all `ls' switches -- those
that work are: A a B C c F G g h i n R r S s t U u X.  The l switch
is assumed to be always present and cannot be turned off."
    (if ls-lisp-use-insert-directory-program
        (funcall orig-fun
                 file switches wildcard full-directory-p)
      ;; We need the directory in order to find the right handler.
      (let ((handler (find-file-name-handler (expand-file-name file)
                                             'insert-directory))
            (orig-file file)
            wildcard-regexp)
        (if handler
            (funcall handler 'insert-directory file switches
                     wildcard full-directory-p)
          ;; Remove --dired switch
          (if (string-match "--dired " switches)
              (setq switches (replace-match "" nil nil switches)))
          ;; Convert SWITCHES to a list of characters.
          (setq switches (delete ?\  (delete ?- (append switches nil))))
          ;; Sometimes we get ".../foo*/" as FILE.  While the shell and
          ;; `ls' don't mind, we certainly do, because it makes us think
          ;; there is no wildcard, only a directory name.
          (if (and ls-lisp-support-shell-wildcards
                   (string-match "[[?*]" file)
                   ;; Prefer an existing file to wildcards, like
                   ;; dired-noselect does.
                   (not (file-exists-p file)))
              (progn
                (or (not (eq (aref file (1- (length file))) ?/))
                    (setq file (substring file 0 (1- (length file)))))
                (setq wildcard t)))
          (if wildcard

              (setq wildcard-regexp
                    (if ls-lisp-support-shell-wildcards
                        (wildcard-to-regexp (file-name-nondirectory file))
                      (file-name-nondirectory file))
                    file             (or (file-name-directory file)  default-directory))
            (if (memq ?B switches) (setq wildcard-regexp "[^~]\\'")))
          (condition-case err
              (ls-lisp-insert-directory
               file switches (ls-lisp-time-index switches)
               wildcard-regexp full-directory-p)
            (invalid-regexp
             ;; Maybe they wanted a literal file that just happens to
             ;; use characters special to shell wildcards.
             (if (equal (cadr err) "Unmatched [ or [^")
                 (progn
                   (setq wildcard-regexp (if (memq ?B switches) "[^~]\\'")
                         file (file-relative-name orig-file))
                   (ls-lisp-insert-directory
                    file switches (ls-lisp-time-index switches)
                    nil full-directory-p))
               (signal (car err) (cdr err)))))
          ;; Try to insert the amount of free space.
          (save-excursion
            (goto-char (point-min))
            (while (re-search-forward "^total" nil t)
              (beginning-of-line)
              (let ((counted  (save-match-data (count-dired-files))))
                (if (zerop counted)
                    (insert "files 0/0 ")
                  (insert "files " (number-to-string counted)
                          "/" (number-to-string
                               (- (length (directory-files default-directory
                                                           nil nil t)) 2))
                          " ")))
              (goto-char (point-min))
              (re-search-forward "^files [0-9]+/[0-9]+ \\(total\\)" nil t)
              (replace-match "space used" nil nil nil 1)
              (let ((available (and (fboundp 'get-free-disk-space)
                                    (get-free-disk-space ".")))
                    (map (make-sparse-keymap))
                    (inhibit-field-text-motion t)) ; Just to be sure, for eol.
                (define-key map [mouse-2]
                  'dired-mouse-describe-listed-directory)
                (define-key map "\r" 'dired-describe-listed-directory)
                (when available (end-of-line) (insert " available " available))
                (add-text-properties
                 (save-excursion (beginning-of-line) (line-beginning-position))
                 (1- (match-beginning 1))
                 `(mouse-face highlight keymap ,map
                   help-echo "Files shown / total files in directory \
\[RET, mouse-2: more info]"))
                (add-text-properties (match-beginning 1) (line-end-position)
                                     `(mouse-face highlight keymap ,map
                                       help-echo "Kbytes used in directory, Kbytes \
available on disk [RET, mouse-2: more info]"))))))))))

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-19 on LEG570
Bzr revision: 114715 rgm <at> gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Tue, 12 Nov 2013 09:15:48 +0100

Am 11.11.2013 20:30, schrieb Drew Adams:
> 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.
>
>

+1

Suggest to introduce a variable WRT verbosity, so we might see more warnings if interested.

Message #11 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 15861 <at> debbugs.gnu.org
Subject: RE: bug#15861: 24.3.50; lots of byte-compiler code written to
 *Messages* at runtime
Date: Tue, 12 Nov 2013 09:38:08 -0800 (PST)

> +1
> 
> Suggest to introduce a variable WRT verbosity, so we might see more
> warnings if interested.

I would like to know why this is considered a warning.  And just what it is.
Why should redefining a function lead to a warning message?

Clearly, the message is not working as a message, and certainly not as a
warning.  I cannot even describe it well, let alone understand what it is
trying to tell me.

Message #14 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Drew Adams <drew.adams <at> oracle.com>, 15861 <at> debbugs.gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Tue, 12 Nov 2013 19:10:59 +0100

Am 12.11.2013 18:38, schrieb Drew Adams:
>> +1
>>
>> Suggest to introduce a variable WRT verbosity, so we might see more
>> warnings if interested.
>
> I would like to know why this is considered a warning.  And just what it is.
> Why should redefining a function lead to a warning message?
>
> Clearly, the message is not working as a message, and certainly not as a
> warning.  I cannot even describe it well, let alone understand what it is
> trying to tell me.
>

Seems terminus " boatload " triggered something here, led me at the wrong path.

Message #17 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15861 <at> debbugs.gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Thu, 14 Nov 2013 20:15:35 +0200

> Date: Mon, 11 Nov 2013 11:30:02 -0800 (PST)
> From: Drew Adams <drew.adams <at> 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.

Message #20 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15861 <at> debbugs.gnu.org
Subject: RE: bug#15861: 24.3.50;	lots of byte-compiler code written to
 *Messages* at runtime
Date: Thu, 14 Nov 2013 10:50:20 -0800 (PST)

> 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).

I have done that now, in this build:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-11-12 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

That made no difference.  But see below.

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

I took another look, and there is no bug; sorry.

FYI, I had some debug calls to `message' in the file, and one of
them printed the value of argument ORIG-FUN.  Apparently the value
of that argument is what has changed in recent builds.

Printing that argument now leads to tons of binary code plus the
complete doc string being logged.  IOW, the argument now seems
to be a byte-compiled function, whereas it was not compiled before.

Sorry for the noise.  I will close the bug.

Message #25 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15861 <at> debbugs.gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Thu, 14 Nov 2013 14:50:04 -0500

> 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.

Presumably there's something else than "boatload of binary" and "the
entire docstring" printed.  This something else is what we need to see
in order to know where this message comes from.


        Stefan

Message #28 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15861 <at> debbugs.gnu.org
Subject: RE: bug#15861: 24.3.50; lots of byte-compiler code written to
 *Messages* at runtime
Date: Thu, 14 Nov 2013 13:27:40 -0800 (PST)

> Presumably there's something else than "boatload of binary" and "the
> entire docstring" printed.  This something else is what we need to
> see in order to know where this message comes from.

See my previous message.  This was my bad.  I called `message'
to print the value of argument ORIG-FUN.  Recent Emacs 24 snapshots
apparently byte-compile the value passed as arg, and that I think was
not the case before.  Upgrading to a recent build had the effect
I reported because of that change.

So pilot error; no bug.  Sorry for the noise.

Message #31 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15861 <at> debbugs.gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Thu, 14 Nov 2013 17:59:36 -0500

> to print the value of argument ORIG-FUN.  Recent Emacs 24 snapshots
> apparently byte-compile the value passed as arg, and that I think was

They don't byte-compile, but they do macro-expand.


        Stefan

Message #34 received at 15861 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 15861 <at> debbugs.gnu.org
Subject: Re: bug#15861: 24.3.50;
 lots of byte-compiler code written to *Messages* at runtime
Date: Thu, 14 Nov 2013 18:01:07 -0500

> Printing that argument now leads to tons of binary code plus the
> complete doc string being logged.  IOW, the argument now seems
> to be a byte-compiled function, whereas it was not compiled before.

Oh, wait, I guess you're right.  The function might end up compiled
where it wasn't before.  In my previous email, I misunderstood the issue.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.