From: nljlistbox2@gmail.com (N. Jackson)
To: 16647@debbugs.gnu.org
Subject: bug#16647: Imprecisions with window-resizing cursors
Date: Fri, 14 Feb 2014 12:13:16 -0400 [thread overview]
Message-ID: <8738jlk6zn.fsf@moondust.localdomain> (raw)
In-Reply-To: <52FE0059.4080508@gmx.at> (martin rudalics's message of "Fri, 14 Feb 2014 12:39:05 +0100")
martin rudalics <rudalics@gmx.at> writes:
> Maybe this depends on the window manager used? Can someone else
> reproduce this behavior with emacs -Q:
>
> (progn
> (scroll-bar-mode -1) (split-window-right) )
>
> Slowly move the mouse from left to right across the vertical line
> splitting the windows. Once the mouse goes past the black line, it's
> still shown as <=>, although clicking-and-dragging on that area won't
> have any effect.
On GTK3 with Emacs built from trunk on 2014-02-10, I do not see the
symptoms above exactly, but I do see another bug.
With the recipe above:
lag in appearance of <=> handle (probably okay?)
================================================
As the mouse cursor crosses the vertical line there _is_ a distinct lag
in the appearance of the <=> handle, so that it _does_ appear to the
left or right of the line (depending upon which direction the mouse was
moving), unless the mouse movement is _extremely_ slow. I don't think
this behaviour is particularly unusual (although it seems part of a
distinct sluggishness in the windowing interface that wasn't there in
Emacs 24.3.1). The <=> handle never first appears further from the
vertical line than (roughly?) the width of the fringe. That is, the <=>
handle doesn't appear at all if one moves the mouse over the vertical
line too quickly, and this seems okay too.
Clicking on and dragging with <=> handle works correctly consistently
=====================================================================
Clicking on and dragging the <=> handle works every time. I cannot
duplicate any case in which doing so has no effect, _unless_ the
vertical line is already as far to the left or right in the frame as it
will go, in which case one can only drag it in one direction, which
behaviour is obviously correct.
Another bug
===========
When the vertical line is as far to the right in the frame as it will go
(i.e., when the right window is as narrow as permitted), then the <=>
handle only appears when the mouse cursor approaches the vertical line
from the right. If the mouse cursor approaches the vertical line from
the left, the <=> handle fails to appear. (Ditto with "left" and "right"
reversed in that statement.)
I hope this information helps.
Regards,
N.
next prev parent reply other threads:[~2014-02-14 16:13 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 6:05 bug#16647: Imprecisions with window-resizing cursors E Sabof
2014-02-05 10:48 ` martin rudalics
2014-02-06 9:21 ` Evgkeni Sampelnikof
2014-02-06 10:26 ` martin rudalics
2014-02-07 17:32 ` E Sabof
2014-02-07 19:14 ` martin rudalics
2014-02-13 9:46 ` E Sabof
2014-02-14 11:39 ` martin rudalics
2014-02-14 16:13 ` N. Jackson [this message]
2014-02-14 18:25 ` martin rudalics
2014-02-14 22:53 ` N. Jackson
2014-02-16 10:32 ` martin rudalics
2014-02-16 18:17 ` N. Jackson
2014-02-20 4:32 ` N. Jackson
2014-02-21 18:53 ` martin rudalics
2014-02-21 23:33 ` N. Jackson
2014-02-22 9:17 ` martin rudalics
2014-02-22 18:06 ` N. Jackson
2014-02-22 18:33 ` E Sabof
2014-02-22 18:52 ` martin rudalics
2014-02-22 19:07 ` E Sabof
2014-02-23 0:27 ` N. Jackson
2014-02-23 10:53 ` martin rudalics
2014-02-24 2:01 ` N. Jackson
2014-02-24 7:40 ` martin rudalics
2014-02-24 15:30 ` N. Jackson
2014-02-24 18:12 ` martin rudalics
2014-02-24 18:39 ` N. Jackson
2014-02-24 18:58 ` martin rudalics
2014-02-27 19:59 ` martin rudalics
2014-02-28 0:49 ` N. Jackson
2014-02-28 6:47 ` Eli Zaretskii
2014-02-28 17:30 ` bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors) N. Jackson
2014-03-01 7:18 ` Eli Zaretskii
2014-02-28 10:59 ` bug#16647: Imprecisions with window-resizing cursors martin rudalics
2014-02-28 17:25 ` bug#16647: OT: window-resizing cursor for minibuffer (Imprecisions with window-resizing cursors) N. Jackson
2014-02-28 18:24 ` martin rudalics
2014-02-28 21:19 ` bug#16647: Imprecisions with window-resizing cursors N. Jackson
2014-09-19 8:18 ` martin rudalics
2014-02-23 10:53 ` martin rudalics
2014-02-23 23:29 ` E Sabof
2014-02-24 7:39 ` martin rudalics
2014-02-24 13:00 ` E Sabof
2014-02-24 18:12 ` martin rudalics
2014-02-24 23:06 ` E Sabof
2014-02-26 10:17 ` martin rudalics
2014-02-26 16:45 ` Eli Zaretskii
2014-02-27 20:00 ` martin rudalics
2014-02-27 20:38 ` Eli Zaretskii
2014-02-28 11:00 ` martin rudalics
2014-02-28 11:32 ` Eli Zaretskii
2014-02-28 12:47 ` martin rudalics
2014-02-28 14:29 ` Eli Zaretskii
2014-02-28 18:23 ` martin rudalics
2014-03-01 7:43 ` Eli Zaretskii
2014-02-27 19:59 ` martin rudalics
2014-02-27 19:59 ` martin rudalics
2014-02-22 18:44 ` martin rudalics
2014-02-22 23:33 ` N. Jackson
2014-02-27 19:58 ` martin rudalics
2014-02-28 0:39 ` N. Jackson
2014-02-27 19:58 ` martin rudalics
2014-02-28 0:38 ` N. Jackson
2014-02-14 23:13 ` Drew Adams
2014-02-06 10:32 ` Eli Zaretskii
2014-02-06 13:34 ` Stefan Monnier
2014-02-07 19:14 ` martin rudalics
2014-02-27 19:58 ` martin rudalics
2014-02-27 20:33 ` Eli Zaretskii
2014-02-28 11:00 ` martin rudalics
2014-02-28 11:28 ` Eli Zaretskii
2014-02-28 12:47 ` 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=8738jlk6zn.fsf@moondust.localdomain \
--to=nljlistbox2@gmail.com \
--cc=16647@debbugs.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).