* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
@ 2013-11-11 19:30 Drew Adams
2013-11-12 8:15 ` Andreas Röhler
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Drew Adams @ 2013-11-11 19:30 UTC (permalink / raw
To: 15861
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@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'
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-11 19:30 Drew Adams
@ 2013-11-12 8:15 ` Andreas Röhler
2013-11-12 17:38 ` Drew Adams
2013-11-14 18:15 ` Eli Zaretskii
2013-11-14 19:50 ` Stefan Monnier
2 siblings, 1 reply; 10+ messages in thread
From: Andreas Röhler @ 2013-11-12 8:15 UTC (permalink / raw
To: 15861
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-12 8:15 ` Andreas Röhler
@ 2013-11-12 17:38 ` Drew Adams
2013-11-12 18:10 ` Andreas Röhler
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2013-11-12 17:38 UTC (permalink / raw
To: Andreas Röhler, 15861
> +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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-12 17:38 ` Drew Adams
@ 2013-11-12 18:10 ` Andreas Röhler
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Röhler @ 2013-11-12 18:10 UTC (permalink / raw
To: Drew Adams, 15861
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-11 19:30 Drew Adams
2013-11-12 8:15 ` Andreas Röhler
@ 2013-11-14 18:15 ` Eli Zaretskii
2013-11-14 19:50 ` Stefan Monnier
2 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2013-11-14 18:15 UTC (permalink / raw
To: Drew Adams; +Cc: 15861
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
[not found] ` <<83eh6izw6w.fsf@gnu.org>
@ 2013-11-14 18:50 ` Drew Adams
2013-11-14 23:01 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2013-11-14 18:50 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 15861
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-11 19:30 Drew Adams
2013-11-12 8:15 ` Andreas Röhler
2013-11-14 18:15 ` Eli Zaretskii
@ 2013-11-14 19:50 ` Stefan Monnier
2013-11-14 21:27 ` Drew Adams
2 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2013-11-14 19:50 UTC (permalink / raw
To: Drew Adams; +Cc: 15861
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-14 19:50 ` Stefan Monnier
@ 2013-11-14 21:27 ` Drew Adams
2013-11-14 22:59 ` Stefan Monnier
0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2013-11-14 21:27 UTC (permalink / raw
To: Stefan Monnier; +Cc: 15861
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-14 21:27 ` Drew Adams
@ 2013-11-14 22:59 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2013-11-14 22:59 UTC (permalink / raw
To: Drew Adams; +Cc: 15861
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime
2013-11-14 18:50 ` bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime Drew Adams
@ 2013-11-14 23:01 ` Stefan Monnier
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2013-11-14 23:01 UTC (permalink / raw
To: Drew Adams; +Cc: 15861
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-11-14 23:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <<701df652-aa30-4607-97dc-d02075f9094c@default>
[not found] ` <<83eh6izw6w.fsf@gnu.org>
2013-11-14 18:50 ` bug#15861: 24.3.50; lots of byte-compiler code written to *Messages* at runtime Drew Adams
2013-11-14 23:01 ` Stefan Monnier
2013-11-11 19:30 Drew Adams
2013-11-12 8:15 ` Andreas Röhler
2013-11-12 17:38 ` Drew Adams
2013-11-12 18:10 ` Andreas Röhler
2013-11-14 18:15 ` Eli Zaretskii
2013-11-14 19:50 ` Stefan Monnier
2013-11-14 21:27 ` Drew Adams
2013-11-14 22:59 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.