GNU bug report logs - #225
23.0.60; tool bar icons missing or executing wrong commands

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 225 in the body.
You can then email your comments to 225 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Reiner Steib <reinersteib+gmane <at> imap.cc>
To: emacs-pretest-bug <at> gnu.org
Cc: "Sebastian P. Luque" <spluque <at> gmail.com>
Subject: 23.0.60; tool bar icons missing or executing wrong commands
Date: Mon, 12 May 2008 12:32:13 +0200

[Message part 1 (text/plain, inline)]

M-x report-emacs-bugs RET wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

With current Emacs CVS trunk, started with -Q, I don't get all tool
bar buttons, but only the icons corresponding to `cut' `copy',
`customize' and `help'.  Additionally *all* icon but `copy' display
the tool tip `Pop up the Help menu' and `<f1> k' shows:

,----[ <f1> k ... ]
| <tool-bar> <help> runs the command #[nil "\301^H!\207"
| [menu-bar-help-menu popup-menu] 2 nil nil], which is an interactive
| compiled Lisp function.
| 
| (anonymous)
| 
| Not documented.
`----

Here's a screen shot:

[tool-bar-missing-icons-bogus-help.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

Probably caused by the same bug, the tool bars in Gnus Summary buffers
are completely empty.  This has been reported by "Sebastian P. Luque"
<spluque <at> gmail.com> on gnu.emacs.gnus; I can reproduce this here.
<http://thread.gmane.org/87ve1ko6r5.fsf <at> patagonia.sebmags.homelinux.org>
Sebastian, you wrote "This problem was not there in the previous
snapshot".  Could you tell us the date of the previous snapshot?

> In GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version 2.10.6)
>  of 2008-05-12 on viandante
> Windowing system distributor `The X.Org Foundation', version 11.0.70199902
> configured using `configure '--prefix=[...]/emacs/HEAD'
> '--exec-prefix=[...]/emacs/HEAD-i686' 'CFLAGS=-Wno-pointer-sign -O0
> -fno-crossjumping -gdwarf-2 -g3''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=local
>   locale-coding-system: utf-8-unix
>   default-enable-multibyte-characters: t

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Message #10 received at 225-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Reiner Steib <reinersteib+gmane <at> imap.cc>,
        "Sebastian P. Luque" <spluque <at> gmail.com>,
        Juanma Barranquero <lekktu <at> gmail.com>,
        Tassilo Horn <thorn+news <at> fastmail.fm>,
        225-done <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Tool-bar changes
Date: Tue, 13 May 2008 14:07:50 -0400

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> I've just installed a change in tool-bar.el which delays the call to
>> find-image.  Instead of being called in tool-bar-setup, it's now called
>> when looking up the tool-bar keymap.  This may also allow the toolbar
>> to use different icons on different displays (e.g. some color, some b&w)
>> in the same Emacs instance.
>
> This change did Something Bad to the tool-bar on i686-pc-linux-gnu, GTK+
> Version 2.12.9.  Only the Cut, Paste, Customize, and Help icons are now
> displayed on the tool-bar; the other images are missing.

The problem was the the use of plist-get and plist-put in
tool-bar-make-keymap failed to account for the format of menu-item
lists, which can contain an optional KEY-BINDING-DATA entry that screws
up the property list ordering.  I just checked in a fix.

Message #11 received at 225-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Reiner Steib <reinersteib+gmane <at> imap.cc>,
        "Sebastian P. Luque" <spluque <at> gmail.com>,
        Juanma Barranquero <lekktu <at> gmail.com>,
        Tassilo Horn <thorn+news <at> fastmail.fm>,
        225-done <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Tool-bar changes
Date: Tue, 13 May 2008 14:19:29 -0400

> The problem was the the use of plist-get and plist-put in
> tool-bar-make-keymap failed to account for the format of menu-item
> lists, which can contain an optional KEY-BINDING-DATA entry that screws
> up the property list ordering.  I just checked in a fix.

Thank you.  I wonder why it never hit me.... Oh yes now I remember:
I threw away this caching code in my own Emacs (I threw it out a long
time ago, i.e. when I added the where-is-internal reverse keymap cache,
since this made on-the-fly recomputation sufficiently fast for me to
make the cache unnecessary (or even harmful since it's not correctly
maaintained: when the cache key-sequence becomes invalid, it is
correclty thrown out, but if a key-sequence becomes later available,
the cache will prevent it from being discovered)).


        Stefan

Previous Next

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