From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 19988@debbugs.gnu.org
Subject: bug#19988: 25.0.50; Drag events ending in different frame
Date: Fri, 06 Mar 2015 08:12:14 +0100 [thread overview]
Message-ID: <87385ilhv5.fsf@gnu.org> (raw)
In-Reply-To: <83r3t3nqu5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Mar 2015 22:15:30 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> >> 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.
>> >
>> > That's not what I see. For me, the region extension ends when the
>> > mouse goes out of the frame, and the region stays as it was at the
>> > last extension.
>> >
>> > Through which side of the frame do you exit the frame while dragging?
>>
>> It doesn't matter, the behavior is as described above. As said in my
>> other mail, I don't use scroll-bars. But even with emacs -Q with
>> scroll-bars on the right compiled from commit cbc9d8d I have the same
>> behavior as above.
>
> So you are saying that you see the region extend to the edge of the
> text as long as you drag the mouse inside the frame, then shrink back
> when the mouse is dragged outside of the frame?
Not exactly.
1. As long as I drag inside the start window, the region
extends/shrinks. When releasing the mouse button, the region is
from the start point to the position where I released the button
and is active, i.e., highlighted by tmm.
2. When I drag into a different window of the left or right of the
start window *showing the same buffer*, the region (highlighting)
freezes at the position where the start window was left. When I
release the mouse button in the other window, the region suddenly
resized from the start position to the end position of the other
window. That's actually a cool feature as it allows to select
large regions without scrolling.
3. When I drag into a different window on the right of the start
window which shows a different buffer than the start window, the
region (highlighting) freezes as soon as I leave the start window.
When I release the mouse button, the region suddenly becomes
start-position to top of the buffer.
4. Doing the same as in 3. but dragging to the window on the left,
when releasing the mouse button the region suddenly becomes start
position to "somewhere above the end of the marked region which
froze when leaving the start window", i.e., the region-end jumps
up. Sometimes even higher than the region-start, sometimes below
it. Sorry, I don't see any system here...
5. Dragging outside of the frame (which has only one window) freezes
the selected region as soon as the mouse leaves the frame. It
doesn't matter if I leave to the left or to the right. When I then
release the mouse button outside of the frame, the region vanishes
and the mark is set at the start position of the drag.
So it seems you get a different behavior in at least case 5 (i.e., your
region doesn't vanish). Not sure what might be the difference but I can
reproduce that using emacs -Q.
GNU Emacs 25.0.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.9) of
2015-03-06, commit bfebebbc72c6a6ea375c6e8ed7f8641b25439770
Bye,
Tassilo
next prev parent reply other threads:[~2015-03-06 7:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 14:30 bug#19988: 25.0.50; Drag events ending in different frame Tassilo Horn
2015-03-03 20:27 ` Eli Zaretskii
2015-03-04 4:28 ` Stefan Monnier
2015-03-04 7:03 ` Tassilo Horn
2015-03-04 17:22 ` Eli Zaretskii
2015-03-04 21:09 ` Tassilo Horn
2015-03-04 22:58 ` Stefan Monnier
2015-03-05 8:05 ` martin rudalics
2015-03-05 17:05 ` Eli Zaretskii
2015-03-05 3:37 ` Eli Zaretskii
2015-03-05 7:19 ` Tassilo Horn
2015-03-05 17:02 ` Eli Zaretskii
2015-03-05 20:07 ` Tassilo Horn
2015-03-05 20:15 ` Eli Zaretskii
2015-03-06 7:12 ` Tassilo Horn [this message]
2015-03-06 14:13 ` Eli Zaretskii
2015-03-06 16:09 ` Drew Adams
2015-03-06 18:55 ` martin rudalics
2015-03-05 17:00 ` Eli Zaretskii
2015-03-05 20:01 ` Tassilo Horn
2015-03-05 8:05 ` martin rudalics
2015-03-04 17:19 ` Eli Zaretskii
2015-03-04 15:10 ` martin rudalics
2015-03-04 21:14 ` Tassilo Horn
2015-03-05 8:06 ` martin rudalics
2015-03-06 14:37 ` Stefan Monnier
2015-03-06 18:55 ` martin rudalics
2015-03-06 20:19 ` Stefan Monnier
2015-03-06 21:31 ` martin rudalics
2015-03-07 0:49 ` Stefan Monnier
2015-03-07 9:41 ` martin rudalics
2015-03-09 4:34 ` Stefan Monnier
2015-03-09 7:53 ` Jan D.
2015-03-09 10:38 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87385ilhv5.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=19988@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).