* bug#19480: (no subject)
[not found] ` <8761cr79i5.fsf@web.de>
@ 2015-01-01 15:35 ` Eli Zaretskii
2015-01-01 20:37 ` Michael Heerdegen
2022-05-03 16:58 ` bug#19480: Tool-bar modifications not reflected on display Lars Ingebrigtsen
0 siblings, 2 replies; 4+ messages in thread
From: Eli Zaretskii @ 2015-01-01 15:35 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: bjvilfan, 19480
[Moved this here from help-gnu-emacs. For the original thread, see
http://lists.gnu.org/archive/html/help-gnu-emacs/2014-12/msg00379.html.]
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Wed, 31 Dec 2014 23:13:54 +0100
> Cc: Emacs Help <help-gnu-emacs@gnu.org>,
> Stefan Monnier <monnier@iro.umontreal.ca>
>
> Bostjan Vilfan <bjvilfan@gmail.com> writes:
>
> (progn
> (define-key global-map [tool-bar bvdotex] 'tex-file)
> (tool-bar-local-item "save" 'tex-file 'bvdotex tool-bar-map
> :help "Process file with default tex command"))
>
> Evaluate it, and you have to "do some things" until the item is displayed.
> No way of redisplay helps to force the displaying of the button, and it
> seems to appear after a random command.
>
> I guess all the Emacs modes set up the toolbar before it is actually
> displayed. Doing it afterwards doesn't seem to work reliably. I don't
> see such a limitation being described in the manual
This should fix the problem:
(progn
(define-key global-map [tool-bar bvdotex] 'tex-file)
(tool-bar-local-item "save" 'tex-file 'bvdotex tool-bar-map
:help "Process file with default tex command")
(force-mode-line-update)
(garbage-collect))
The last line is the reason that you need to "do some things" in order
for the tool bar to get updated: you need to eval enough stuff so that
Emacs enters GC.
This is a clear bug, and it has 2 parts, an easy one and a harder one.
The easy part is to add a call to force-mode-line-update to 2
functions that modify tool-bar-map (done in commit 5a9710f on the
emacs-24 branch).
The harder part, the one that requires a GC, has something to do with
the fact that we use a hash table to avoid recomputing tool-bar items
when the tool bar didn't change. From tool-bar.el:
(global-set-key [tool-bar]
`(menu-item ,(purecopy "tool bar") ignore
:filter tool-bar-make-keymap))
(defconst tool-bar-keymap-cache (make-hash-table :weakness t :test 'equal))
(defun tool-bar-make-keymap (&optional _ignore)
"Generate an actual keymap from `tool-bar-map'.
Its main job is to figure out which images to use based on the display's
color capability and based on the available image libraries."
(let ((key (cons (frame-terminal) tool-bar-map)))
(or (gethash key tool-bar-keymap-cache)
(puthash key (tool-bar-make-keymap-1) tool-bar-keymap-cache))))
We started doing this in Emacs 23, and sure enough, this problem
didn't exist in Emacs 22, where just evaluating the original progn
above, without the last two lines, immediately caused the tool bar to
be updated. Emacs 23 already exhibits the problem.
By stepping through tool-bar-make-keymap, I've discovered that after
the tool-bar-map is updated, gethash still returns non-nil, as if the
old value of tool-bar-map were still in effect. So we don't recompute
the updated keymap from tool-bar-map, and redisplay doesn't think the
tool bar changed and should be redrawn.
Mind you, this is on MS-Windows, which represents the toolkits where
Emacs itself displays the tool bar; the GTK and NS builds might have
different or additional quirks.
I hope the above will give enough info to keymap experts to fix the
remaining problem (please do that on the emacs-24 branch).
^ permalink raw reply [flat|nested] 4+ messages in thread