emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bad defcustom in speedbar, or non-interactive message in locate-library


From: Drew Adams
Subject: Bad defcustom in speedbar, or non-interactive message in locate-library (was: How to suppress messages?)
Date: Thu, 27 Jan 2005 14:46:52 -0800

        how about binding `executing-kbd-macro' to t ?

    Oddly enough, that doesn't seem to do the trick in this case.
    If I comment out the call to `default-boundp', then
    the messages stop appearing, but if I put the call inside
    (let ((executing-kbd-macro t))...), the
    messages still appear.

I think that what is happening here is that a default value for
speedbar-use-imenu-flag, which causes a message to be written to the echo
area, is being reexecuted repeatedly. I believe that this is a bug, and that
the defcustom of speedbar-use-imenu-flag needs to be redefined. One possible
fix (surely not the best) is to wrap the defcustom's init value in (let
((executing-kbd-macro t))...) to prevent its locate-library message from
appearing. (This was why I asked for a way to inhibit messages, which I
still think is needed as an enhancement.)

A better fix would be to prevent locate-library from issuing a message if
not used interactively. The code defining locate-library uses its argument
`interactive-call' to test interactivity, but that is apparently not
sufficient.

The situation appears to be the same in the code of Emacs 20 and Emacs 21. I
see the pb only in Emacs 20. However, I get a different message periodically
(same symptoms) in Emacs 21, and that message may be masking this message.
[That other pb has already been reported (and fixed, I believe): superfluous
message "Defining colors..." in w32-win.el's version of xw-defined-colors.]
In any case, I believe that the defcustom and/or locate-library should
probably be improved to prevent such an inappropriate message.

Here is some data about this bug (with guesses).

- This definition appears in speedbar.el:
(defcustom speedbar-use-imenu-flag (stringp (locate-library "imenu"))
  "..." :tag "User Imenu" :group 'speedbar :type 'boolean)

- I have code that calls `default-boundp' on each user variable, including
speedbar-use-imenu-flag .

- (I guess that) `default-boundp' causes the defcustom to be executed. The C
code doesn't indicate that, but that's my guess.

- locate-library displays the message "Library is ...". The message I get
redisplayed periodically (see next) is "Library is "imenu"", so I suspect
this defcustom call to locate-library.

- My code runs on an idle timer, so it periodically reexecutes the
`default-boundp' and prints the message.

- If I comment-out my call to default-boundp, it stops the periodic message
display.

- If I wrap the defcustom init value in (let ((executing-kbd-macro t))...),
that also stops the periodic message display. [That would be a fix to the
bug, though not necessarily the best fix.]

- If I wrap my call to default-boundp in (let ((executing-kbd-macro t))...),
it has no effect.

- If I never turn on speedbar-frame-mode, I don't get the messages,
presumably because library speedbar.el was never loaded. However, once I
have turned speedbar on, turning it off has no effect - I continue to get
the messages periodically. Likewise, speedbar-toggle-updates has no effect
in turning the messages off. This also reinforces my guess that the
defcustom is the culprit.

- speedbar-update-speed doesn't seem to affect the period of the messages.
Instead, the period of my timer (the other timer) seems to affect it. Again,
that seems right: this has nothing to do with speedbar's timer; it has only
to do with its defcustom init value using locate-library.

- speedbar.el has two occurrences of (locate-library "imenu"), one in a
defcustom, one in top-level eval-when-compile. I suspect only the defcustom
occurrence.

Thanks,

   Drew








reply via email to

[Prev in Thread] Current Thread [Next in Thread]