Re: Toolbar redraw causes unwanted selection

[storm@cua.dk (Kim F. Storm)]

JD Smith <jdsmith@as.arizona.edu> writes:

>> I just did M-x idlwave-mode in an empty buffer.  If that's not enough
>> to make the extra icons appear, that's why I didn't see them.
>
> Right, the icons appear only if the shell is running (which won't
> work without IDL installed).  Sorry for the confusion.  I have
> received numerous reports from users annoyed with the toolbar
> behavior, and have typically just instructed them how to disable to
> toolbar altogether.

Ok, so the current behaviour is not really acceptable.

I just implemented the `grow-only' setting for auto-resize-tool-bars,
and the use of C-l to reduce the height as suggested by RMS.

> Regarding the original spurious selection bug, I tried out your fix,
> and it does indeed defeat the selection when toolbar size changes.

Good!

> > However, I noticed two issues with the implementation:
>
> 1.  When you click to switch to another window within the frame, and
> the toolbar height changes, the point moves to the location of the
> cursor *after* the text is shifted.  Ideally, the point would be
> placed exactly where the user clicks (i.e. the click location before
> the toolbar resize occurs).

Yes.  I have noticed this too, but doing the right thing seems quite hard.

The problem is that the window+toolbar is redrawn before emacs sees
the mouse-up event -- so the position of the "up" event is the NEW
position.  We might find some way to DTRT, but it must wait until
after the release!

>
> 2. Clicking to drag a selection is now defeated when toolbar size
> changes.  Normally, if the focus is in a given window, click-dragging
> in another window in the frame immediately begins defining a
> selection.  With your fix in place, for windows with different
> toolbar heights, no selection is created when dragging in this manner
> (you must first give that window focus).

The problem is the same as above ... but it is even harder to do
right, as the position of the down event is handled before we update
the display, so if we have to handle this, we somehow have to go back
and patch that event to the new position ...  Not trivial!  So the
patch I made to fix the selection bug actually was an explicit flag to
ignore the the "drag" event imposed by the "down" event position
being at a different position that the new position after redisplay
has modified the toolbar height.

This is even harder to handle that 1, so it must also wait.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk