RE: pop-up tool-bar

["Drew Adams" <drew.adams@oracle.com>]

Good input. I wasn't even aware of `make-variable-frame-local', though I see
now that it's at least as old as Emacs 20.

I see you put "valid" in quotes, but I'm still not sure I know what you
mean. If the next event is a (valid) mouse-down, that's seems to be OK. The
mouse-down occurs at the right position in the buffer (as evidenced by the
highlighted region and cursor position), so I don't think that's the pb.
What happens, I think, is that when the tool-bar disappears, without your
having moved the mouse relative to the display, the mouse nevertheless has
moved relative to the displayed buffer -- so a region has been selected.

Now that I think of it, that could provide a solution, if we could be sure
to know the tool-bar height at all times in terms of # of buffer lines. We
could scroll the buffer down that number of lines, to compensate for the
buffer lines moving up relative to the display because the tool-bar
disappears. Maybe I'll give that a try. (Looking at tool-bar margins and
button-relief margins might be kind of a pain, though, and perhaps the
tool-bar height is not always an integral number of buffer lines, and maybe
we'll have to worry about different-size fonts - ugh.)

Can you elaborate on your "Note" - Is it meant to apply to my original code
or to your code (or both)? With my code, if I click "Buttons" and then
delete the frame instead of clicking a button, it seems to behave as I would
expect, at least on Windows: the frame is gone, that's all.

Maybe I'm doing something wrong, but your code doesn't work for me:

 - The tool-bar doesn't disappear afterward, no matter how I end
   (click a button or do something else.
 - "Buttons" doesn't come back to the menu-bar, and I can't get it
   back again, even by turning tool-bar-mode on, then off.
 - I get this error when I click "Buttons":
   show-tool-bar-for-one-command: Wrong number of arguments:
   (lambda (hook function append local)...

No doubt the first two symptoms are due to the last pb.

Don't you need an unwind-protect to be sure to turn the mode back off, in
case, for instance, the user does C-g -- or will the post-command-hook
always take care of that?

 - Drew


---------------
From: Stefan Monnier

It looks like the problem is that the event you get from read-event is not
"valid" any more after you remove the toolbar (becaue the position is
changed).

Using read-event is generally a source a trouble.  But the alternatives
aren't great either.  Maybe you can try something like the appended code.

Note: you should pay attention to the case where the frame has been deleted
by the next command.

Also, you declare your minor mode to be ":global t" but it is frame-local,
so you should add (make-variable-frame-local 'tool-bar-here-mode) somewhere
at the toplevel.


        Stefan


(defun add-hook-once (hook function append local)
  "Same as `add-hook', but FUN is only run once.
Also contrary to `add-hook', this is not idempotent."
  (let ((code (list 'lambda)))
    (setcdr code `(() (,function) (remove-hook ',hook ',code ',local)))
    (add-hook hook code append local)))

...

(defun show-tool-bar-for-one-command ()
  "Pop up the tool bar so you can click a button.
The tool bar stays visible until one command is executed
\(whether or not it was initiated by clicking a button)."
  (interactive)
  (tool-bar-here-mode 1)
  (add-hook-once 'post-command-hook
                 `(lambda ()
                    ;; We're just now done with
show-tool-bar-for-one-command.
                    (add-hook-once 'post-command-hook
                                   (lambda ()
                                     ;; We're done with the next command.
                                     (select-frame ',(selected-frame))
                                     (tool--bar-here-mode -1))))))