RE: pop-up tool-bar

[Drew Adams]

What else have I tried? Well, I tried the code you offered, but it didn't
work for me, as I mentioned previously. You never replied to my report of
those pbs and my request for info on what I might be doing wrong (copied
below). Did you actually _run_ your code successfully?

If you have another suggestion, let's try it. But please _try_ this code
too, before dismissing it out of hand. Please pound on it, so we can see
just how brittle it is.

I'm curious: just what part of the quoted mouse-click fix do you find to be
a "really super ugly nasty brittle dark hack"?  What makes it so? Are you
speaking in terms of the code being brittle or the user experience (e.g.
being nonintuitive), or both?

You raise (I guess) two issues:

 - bad code
 - bad user interface

I'm open to improvement on both accounts. But let's be specific about what
is wrong. In terms of the code, please point out just what is brittle/bad
style/poor performance/whatever or suggest improvements. In terms of the UI,
please _try_ the code, and then report on what you find to be a pb. So far,
you seem to be reacting to a description of the behavior, and, as I said,
it's easier to experience the behavior than to describe it.

Abstractly name-calling the code or the UI doesn't help, I think. Please be
specific. I'm sure that you can come up with good, concrete improvements,
just as you did with the Info quotes highlighting. You already did offer a
concrete suggestion about `make-variable-frame-local', which I used.

I think we should offer users a pop-up tool-bar feature; that's all. I don't
push for my implementation of that feature; the best implementation should
be used. Frankly, I'd rather that someone else code this feature.

Thanks,

  Drew


-----Original Message-----From: Stefan

> The fix was to scroll the buffer (window) `tool-bar-lines' to compensate
for
> the window movement. This scrolling happens for mouse events only, since
> other events do not cause the problem (and you don't want to scroll the
> buffer each time you click a tool-bar button).

This kind of really super ugly nasty brittle dark hack should be kept for
extreme circumstances where there's really no other possible option.
What else have you tried?

        Stefan

-----Original Message-----From: Drew Adams

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))))))