RE: pop-up tool-bar

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

Sigh. I didn't ask you to be diplomatic. Diplomacy I don't need. I asked you
to be specific.

I would like to see specific reports of pbs, before we start envisioning
solutions to hypothetical pbs. In other words, breaking the code would be
useful: show some specific pbs you encounter. Pound on it; it's just code.

Don't get me wrong. I'm not pushing away, for all time, any abstract
argument about possible future pbs such as potential "changes to the
scrolling behavior", or principles like ~avoid/prevent pbs instead of
undoing/reverting them~, or discussions of relative advantages of different
design approaches. I hear what you're saying, and I agree with much of it.
I'd just like to _first_ address what this code does and what concrete
problems it has (now).

As I said, I'm not attached to the design or the implementation of this
feature; I'm promoting the feature, not the code. Before anyone (I, anyway)
spends energy redesigning or reimplementing, however, let's at least see
what this does, concretely.

Beyond finding specific pbs, the reason I'd like people to try it is to see
if such a feature (a pop-up tool bar) is something we want to add to Emacs,
regardless of its implementation.

 - Drew

-----Original Message-----Stefan Monnier
> Abstractly name-calling the code or the UI doesn't help, I think.
> Please be specific.

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