From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.bugs Subject: bug#31240: 26.1; mouse-save-then-kill does not kill rectangles Date: Sat, 29 Sep 2018 12:07:58 +0200 Message-ID: References: Reply-To: charles@aurox.ch NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1538215451 32146 195.159.176.226 (29 Sep 2018 10:04:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2018 10:04:11 +0000 (UTC) Cc: 31240@debbugs.gnu.org To: Federico Tedin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 29 12:04:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6C6Y-0008Ei-W1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 12:04:07 +0200 Original-Received: from localhost ([::1]:50235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6C8f-0001rT-Mn for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2018 06:06:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6C8T-0001rM-AR for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 06:06:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6C8Q-00044U-3V for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 06:06:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54025) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g6C8P-00044L-T7 for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 06:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g6C8P-0008N9-JK for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2018 06:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: charles@aurox.ch (Charles A. Roelli) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Sep 2018 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31240 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31240-submit@debbugs.gnu.org id=B31240.153821551332126 (code B ref 31240); Sat, 29 Sep 2018 10:06:01 +0000 Original-Received: (at 31240) by debbugs.gnu.org; 29 Sep 2018 10:05:13 +0000 Original-Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6C7c-0008M6-Ow for submit@debbugs.gnu.org; Sat, 29 Sep 2018 06:05:13 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:52088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g6C7Z-0008Lm-9d for 31240@debbugs.gnu.org; Sat, 29 Sep 2018 06:05:11 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id C0B5422879 for <31240@debbugs.gnu.org>; Sat, 29 Sep 2018 10:08:58 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= references:reply-to:subject:subject:in-reply-to:to:from:from :message-id:date:date; s=dkim; t=1538215737; x=1539079738; bh=RU U/XIkZz2ZulOTEShoMWCJcqMN06weGsYyrRx0bmyE=; b=GExrBg77fcYekvY091 NpKGubWKjAI6Ape0cxHMX+BIygLJQyscQ2ZNDaXuw2q4Hh8TL5FtnH8aRlgUeeXb P3BKCbT+kVv25u8ayt4X0XpeEgrfXnTS6ul8FwogMlxsPXu4LMGs1KUj4CA41xo1 YMkPFvlQ84J7ct4SfNnHLrfAo= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q_f-LYbCIfwq for <31240@debbugs.gnu.org>; Sat, 29 Sep 2018 10:08:57 +0000 (UTC) Original-Received: from gray (unknown [IPv6:2a02:1205:c693:2d60:c62c:3ff:fe30:b864]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id C9BA4226F4; Sat, 29 Sep 2018 10:08:56 +0000 (UTC) In-reply-to: (message from Federico Tedin on Thu, 27 Sep 2018 20:45:42 -0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:150752 Archived-At: > From: Federico Tedin > Date: Thu, 27 Sep 2018 20:45:42 -0300 > > For some reason, the region is not moved, and it gets re-activated as > > a normal region instead of a rectangular region. Maybe I'm missing > > something obvious. I was able to get the dragging of a rectangular > > region working sometimes, but not consistently. > > I've tried your test, and it does break my fix, as you mentioned. > > The problem was in the criteria used to define the variable > 'drag-but-negligible'. The drag action used in your test was being > incorrectly marked as negligible. Because of this, the region was > also re-activated, but not in Rectangle Mark mode (this was also a bug). > > I have made a correction where the variable 'drag-but-negligible' is > defined, so dragging a rectangle region outside of itself will no longer > mark it as negligible; and when it _is_ negligible, the region is > re-activated as a rectangle again. Thanks, sounds good. > I've also found some cases where the overlay list is not working well > enough to track the selected rectangle. For example, if a buffer > contains the following: > > aaaa > BBbb > CCcc > > Dragging a 2x2 square starting from the first 'B' (spaces added for > clarity): > > a a a a > [B B]b b > [C C]c c > > to the column where the second 'a' is, results in the following: > > a B B a a a > b b > c c > > In this case, two 'C's are missing in the second line (after the first > 'b'). The reason this is happening is the following: when > mouse-drag-and-drop-region is called, the initial overlays are the > following (shown with braces): > > a a a a > {B B}b b > {C C}c c > > After the 2x2 square is inserted on the second 'a', the first overlay > is automatically expanded, because characters where inserted between > its start/end: > > a B B a a a > {b C C b}b b > {c c}c c > > When the original text is then deleted (by deleting all overlays), the > result is: > > a B B a a a > b b > c c > > So I think I have two options now: either forbid the user from > dragging a rectangle to a position where the inserted rectangle would > intersect the original rectangle, or find another way to track the > originally selected rectangle in a way it can be accurately deleted > after inserting it in the new position. I guess I'll go with the > second option, since it would make function more useful for users. This second option sounds like it can be quite hard to define. If you decide in the end to prevent the user from dragging the region somewhere that would intersect with the dragged region (which, as Martin said, is in line with the original design of mouse-drag-and-drop-region) that would be fine.