Re: pop-up tool-bar

[Stefan Monnier]

> What else have I tried? Well, I tried the code you offered, but it didn't
> work for me, as I mentioned previously.

Sorry, I thought the problem was obvious enough: just add an `&optional'
before the last two args of add-hook-once.

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

No, my code was 100% untested, of course ;-).  It was only shown to give you
a hint of a possible other approach, not necessarily about the
implementation (I just used Elisp instead of English).  I don't even know
whether the approach might work.
And as for the "Note", it only referred to my suggested code, in your case
the frame should still be guaranteed to be live.

> 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 sure it works.  But the approach used is brittle in the face of the fact
that scroll-down might fail, or in the face of variable height lines, or in
the face of changes to the scrolling behavior, or in the presence of other
events like mouse-4, or ...  I.e. it's brittle.

> 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

Neither: it simply relies on way too many unguaranteed assumptions.

A good rule of thumb is that if a code works around a problem by reverting
a bad action rather than by eliminating it, it's a "nasty ugly brittle hack"
because reverting an action is usually not 100% possible and because it
will break every time the bad action changes.
Doesn't mean such code doesn't deserve to exist, but just that it "should be
kept for extreme circumstances where there's really no other possible
option".

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

OK, you're right, I'm sorry, I should have been more diplomatic.
All the suggestion I can think of is to try and remove the tool-bar from
a timer function or from a post-command-hook so that it happens at a moment
of relative quietness.  Basically my suggestion decomposed in two parts:
1 - use post-command-hook in place of read-event to wait for the
    next event.
2 - use post-command-hook to delay the "remove tool-bar" to after the next
    command is executed.
I think point 2 is the one that holds promise of solving your problem (tho
it'll probably come with its own set of problems).


        Stefan