Re: mouse-drag-and-drop-region

[Alex]

martin rudalics <address@hidden> writes:

>> I imagine that this has to do with inputting a non-mouse-movement event
>> before moving the mouse at all. If you use your change and press "C-g"
>> before moving the mouse, then the region will still be pasted.
>>
>> Doing the above without your change currently results in an error due to
>> `insert' using a nil `value-selection', though.  So it's faulty either
>> way.
>
> I'm missing you.  Doesn't C-g deactivate the mark?

Usually, but I don't think it does in this case.  To be clear, it's not
just C-g that does this.  Here's a recipe:

1. Select a region.
2. Hold down-mouse-1 inside of this region.
3. Press any key before moving or releasing the mouse.

Doing this yields an error without your change, and it pastes the region
with your change.  Even when this key is C-g, `mark-active' is t after
step 3.

>>> (3) Showing tooltips can be distracting and should be optional.  Note
>>>      also, that usurping tooltips this way may prevent them from showing
>>>      interesting properties of the drop area like whether the text there
>>>      is read only.  OTOH we might consider retaining properties of the
>>>      text in (non-GTK) tooltips.
>>
>> Also, trying to use `tooltip-show' in text-terminals using
>> `xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
>> messages.
>
> That's a plain bug.  ‘tooltip-show’ on a text terminal must use the echo
> area.
>
>> Perhaps (3) should be fixed before release as well (at least disabling
>> tooltips when they can't be shown)?
>
> Sure.

I suppose (display-graphic-p) should be supplied as the 2nd argument to
`tooltip-show', then?

I also noticed that when dragging in an X window, the tooltip flickers
quite a bit. Is there any easy remedy for this?  Removing the
`mouse-set-point' call in `track-mouse' helps in some cases, but not
completely.