From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nljlistbox2@gmail.com (N. Jackson) Newsgroups: gmane.emacs.bugs Subject: bug#16647: Imprecisions with window-resizing cursors Date: Fri, 14 Feb 2014 12:13:16 -0400 Message-ID: <8738jlk6zn.fsf@moondust.localdomain> References: <87y51qnlfe.fsf@gmail.com> <52F21707.9050509@gmx.at> <87k3d81tqz.fsf@gmail.com> <52F3635C.9040408@gmx.at> <877g96g76g.fsf@gmail.com> <52F530A7.1090104@gmx.at> <871tz7pcop.fsf@gmail.com> <52FE0059.4080508@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392394454 22078 80.91.229.3 (14 Feb 2014 16:14:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 16:14:14 +0000 (UTC) To: 16647@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 14 17:14:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WELP9-00034i-G7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Feb 2014 17:14:19 +0100 Original-Received: from localhost ([::1]:52584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELP8-00007T-Pf for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Feb 2014 11:14:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELOz-00005V-Ec for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:14:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WELOt-0004vG-1p for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:14:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELOs-0004vC-UE for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WELOs-00080b-I4 for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: nljlistbox2@gmail.com (N. Jackson) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Feb 2014 16:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16647 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.139239442530746 (code B ref -1); Fri, 14 Feb 2014 16:14:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 14 Feb 2014 16:13:45 +0000 Original-Received: from localhost ([127.0.0.1]:52528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WELOa-0007zp-Fa for submit@debbugs.gnu.org; Fri, 14 Feb 2014 11:13:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45974) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WELOY-0007zc-GR for submit@debbugs.gnu.org; Fri, 14 Feb 2014 11:13:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WELOO-0004nG-4e for submit@debbugs.gnu.org; Fri, 14 Feb 2014 11:13:37 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:50227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELON-0004nC-Q7 for submit@debbugs.gnu.org; Fri, 14 Feb 2014 11:13:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELOI-0008Lh-Cu for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:13:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WELOB-0004jS-HO for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:13:26 -0500 Original-Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:47544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WELOB-0004jO-D7 for bug-gnu-emacs@gnu.org; Fri, 14 Feb 2014 11:13:19 -0500 Original-Received: by mail-qc0-f178.google.com with SMTP id m20so20097185qcx.23 for ; Fri, 14 Feb 2014 08:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=D3pKrMBl3BvJkUpm6x19LKYV4P1t5mTzS4lKmmoxOVY=; b=AEfkTyi4nsdFSE03wea+w+jydmv4+fssM9ATpv1+YD7h4wT+3w/AHAiAWWI87GQMTK 3+kscm/GgTMhCJp3Ch/qzUhFxbTWmOQ32yN/UA+KkI1/wybj8SHYmkkeKu04K+seF/O9 5g3vV6KOVQZ7/9W3eQyv+Sq8QVVDyyhexn3Ynyc3ljV/z5fcJdTqhzTatIJih8WfXgSA Mupy3eOXyA2fQiKljSSyHCSHI5N93XyQ0jKNWpHKrEJDjrnyf2oNQ5SB/Dhw2D4QN1VZ doUQI0/Nrc0UsFBb5lovfZcx5vEgECBxo/Qds+NpPRTRUFKeVxH+NlhOTMCqUnmhcXBi cmKw== X-Received: by 10.224.49.69 with SMTP id u5mr14693626qaf.88.1392394398795; Fri, 14 Feb 2014 08:13:18 -0800 (PST) Original-Received: from moondust.localdomain.nodomain.none (T8630.WPA.Dal.Ca. [134.190.134.48]) by mx.google.com with ESMTPSA id b12sm16722352qag.23.2014.02.14.08.13.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Feb 2014 08:13:18 -0800 (PST) In-Reply-To: <52FE0059.4080508@gmx.at> (martin rudalics's message of "Fri, 14 Feb 2014 12:39:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85577 Archived-At: martin rudalics 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.