Opened 14 years ago
Closed 14 years ago
#352 closed defect (fixed)
Unexpected shift in toolbar buttons
Reported by: | Erik Martin-Dorel | Owned by: | David Aspinall |
---|---|---|---|
Priority: | major | Milestone: | PG-Emacs-4.0 |
Component: | 2:pg-emacs | Keywords: | |
Cc: | Erik Martin-Dorel |
Description
In the current ProofGeneral toolbar, the tooltip and underlying function of all buttons (except for the first 5) seem to be wrong, as if the semantics of the 6th button was skipped and replaced with the 7th, then the 7th with the 8th, and so on...
My System Info: GNU-Emacs-23.2.1, ProofGeneral-4.0pre100909, Coq-8.2pl2.
Kind regards, Erik Martin-Dorel.
Change History (4)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Resolution: | → needmoreinfo |
---|---|
Status: | new → closed |
comment:3 Changed 14 years ago by
Resolution: | needmoreinfo |
---|---|
Status: | closed → reopened |
The problem is actually reproducible when I use find-file-other-frame
,
e.g. with [C-x 5 f ~/bar.v RET].
The first button that breaks is the 6th one, but no button is missing
(there are 16 in total), since the last two buttons are bound to
proof-toolbar-help
.
comment:4 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Confirmed, thanks for the recipe to reproduce this. Now fixed.
It turned out to be a toolbar entry for a button which doesn't have an icon. The entry is ignored in the first frame, but in later frames it messes up the bindings. The standard toolbar is also affected for some reason and ends up with a broken binding to a PG function (switch to *scratch* in the new frame)!
Thanks for the report. Unfortunately I can't reproduce the problem on Emacs 23.2.1, Linux (Fedora 13 tried just now).
Not sure how to investigate further. Can you check that you start up with default options with:
How many toolbar buttons do you see in total, and which is the first one that breaks?