bug#19988: 25.0.50; Drag events ending in different frame

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> And that situation is already covered as one would expect.
>> >
>> > What do you mean by "as one would expect"?  On my machine, the
>> > behavior is unreasonable: the wrong part of text is selected.
>> 
>> When I select a region by dragging Mouse-1 starting at the "selected."
>> above, as soon as the mouse cursor leaves the emacs frame, the region
>> won't grow or shrink anymore until I enter the frame and window again.
>> And when I release the drag outside of the frame and window where I
>> started, the final region is the last one before leaving the
>> frame/window.  That's pretty much what I'd expect except that releasing
>> the drag outside of the start frame/window inactivates the region.
>
> I wish I saw something like that, but I don't.  Could be a Windows
> specific issue, though.
>
> In any case, that doesn't explain the "already covered" part: isn't
> that "covered" _because_ we return the initial frame as the end of
> drag?

Now I get a different behavior as described yesterday [1]: when my drag
is released outside of the frame where it startet, no region is selected
and the mark is set at the start position of the selected text.  I
really wonder why I got a different behavior.

Having the initial frame as the drag end has to do with that, indeed,
but only because (posn-point (event-end click)) returns nil in this case
(see `mouse-set-region').  If it had the window of another frame as drag
end instead, it would use as region the position in the start window and
the correspondence of the end in the target window in the source window.
That would be nonsense if both windows show a different buffer, but if
they showed the same buffer that could infact be quite reasonable and
convenient to select large regions without needing to scroll.  (Of
course, that won't work if my drag leaves the start window on top or at
the bottom which triggeres scrolling...)

Anyway, if drag events would return the actual end window even if that's
on another frame (and the start frame only in case the drag ended
external to emacs), then `mouse-set-region' would need to check if start
and end window are the same and else do nothing.  Doing that right now
wouldn't hurt either, as it would inhibit setting the mark at the start
of the region which won't be selected anyhow.

Bye,
Tassilo

[1] I only updated my emacs checkout just now but there seem to be no
relevant changes from yesterday morning's version.  And I did a
bootstrap yesterday evening...