From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Federico Tedin Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 134ba45: Allow two mouse functions to work with Rectangle Mark mode Date: Mon, 22 Oct 2018 10:04:57 -0300 Message-ID: References: <20181017063829.3775.67018@vcs0.savannah.gnu.org> <20181017063831.03DCB2044D@vcs0.savannah.gnu.org> <810f1e04-1117-476d-9a7d-d57002609bf8@default> <5BCC3743.8040103@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1540215421 14216 195.159.176.226 (22 Oct 2018 13:37:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Oct 2018 13:37:01 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 22 15:36:57 2018 Return-path: Envelope-to: ged-emacs-devel@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 1gEaO8-0003ar-6C for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 15:36:56 +0200 Original-Received: from localhost ([::1]:35156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEaQE-0006pI-Fr for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 09:39:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEZtR-0006zI-M3 for emacs-devel@gnu.org; Mon, 22 Oct 2018 09:05:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEZtP-0004o9-BA for emacs-devel@gnu.org; Mon, 22 Oct 2018 09:05:13 -0400 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:45269) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gEZtP-0004mM-0G for emacs-devel@gnu.org; Mon, 22 Oct 2018 09:05:11 -0400 Original-Received: by mail-lj1-x232.google.com with SMTP id j4-v6so36882040ljc.12 for ; Mon, 22 Oct 2018 06:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HjZRDmc8Io9x4sx8FU5jRT6CpZEm26Fe5Ni8ekGDAx0=; b=Ugyyi2a0JuLE4q8ClToUo049qdQMCjN6+kPMJgXit/XIhrDtCL/CydVAaaWeUfcozp McgWMn9KLPAG51JSuB5hkXkwImDFEgBtHBIzzLA6gOpBY4TYTocdqB+q1nCtmkovM3DX aUqVGQni6q9yHwoF6HA770qf4Bf3p34e7/nQDQMBY6ljQERtVz6w0yssPaaOVct3Ntln SungMqYuL2wj/LoZWcNAq3PqdPRACSyQa/WrwizTJVJ4bLCD+KsA6Btr9u0RnVEoL6/b KS/1xlvJ9/PXdOoqAbJofE1JYpkL/NFWl7UD4TlpGJs/YJlt1CfksXkpxeehaJTyWnB9 At5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HjZRDmc8Io9x4sx8FU5jRT6CpZEm26Fe5Ni8ekGDAx0=; b=qF5k8N3oTEDZx6qlCPbdC0ZE1AvjEtEeUIUsS7O4w70iydDYuMCbDgteqc0aB2zObP hd4sQuutnJXedxVYSXZs5cbk33pCUR/hh2qSpmYcgVCdDnmY9GbYB2hYFMyTPZbVSSwB eVO5g7sV7MGhzc86uQKtI+TiUhgzcEtwlwKGTkqdlYVjOWcogb8XfIpyPqkruRzvJRGN HKB5l5UbOR0hlFf7bLInFTW1EOnP55c2QvWYknkWni3/9nXYJHjwDiIXCNjecVhYAyxo Al4iL3HIg6q/vhInll8/amCKlaqYcb6O/3wWqIAFswPpol0baF4CyQdvFH/sUDg8A2ak BPHA== X-Gm-Message-State: ABuFfohrzJVTo1axqajmDujSe+WiTlLMMTvXZoAXnzbWt2IYE2+ZigiC jrqFgHXnv18eZh1hn77SP1WWwCZaP29RKdwrt+M= X-Google-Smtp-Source: ACcGV60wShrb/M6ym7Xp0fvXIUHvkXraiAybTN/D6y06/ZgYzPffe8PT8t+1MkX+0z8lxptneq3rfagGi0mOvvp5IPY= X-Received: by 2002:a2e:8347:: with SMTP id l7-v6mr19732829ljh.140.1540213509068; Mon, 22 Oct 2018 06:05:09 -0700 (PDT) In-Reply-To: <5BCC3743.8040103@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230554 Archived-At: > > I thought you were actually referring to another problem. Consider the > > following example, where a buffer contains the text (spaces added for > > clarity): > > > > a > > b b > > c c c > > d d d d > > > > ...and the user selects the following rectangular region: > > > > [a ] > > [b b ] > > [c c c ] > > [d d d d] > > > > In this case, the first overlay will actually only contain "a", so > > subtracting (current-column) in its end and start will yield 1. This > > makes sense, as evaluating (car (region-bounds)) yields (1 . 2). > > Ah, right, that's yet another problem, indeed. > > > Something I also realised is that the variables 'region-width' and > > 'region-height' are 1) rectangular region-specific > > Sorry for not mentioning it earlier. No problem, I should've noticed it when I added it in. > > and 2) are only used when checking if the region is being dragged into > > itself (setq drag-but-negligible ...). > > I don't understand enough of the "dragged into itself" test to know what > should be done here. I think part of the issue is that for rectangular > regions, the "insert-for-yank" will actually not just insert, so we > can't just test "is insertion-point inside region-bounds?" (which could > be easily implemented in a generic way). But at the same time, why > should we disallow dragging the rectangle to a place that overlaps its > original location? Here I'll refer to Martin's explanation, and add a bit more. For contiguous regions (i.e. the original code), mouse-drag-and-drop-region does the following during a drag operation (with some details omitted): 1) Create an overlay with start and end equal to the region's 2) Get the string contents of the region and save them in 'value-selection' 3) Check if the drag is negligible: if the point where the user dragged the region lies *inside* the overlay, then the operation is marked as negligible. Then, if the drag is not negligible: 4) 'value-selection' is inserted where the user dragged the region 5) The original selection is deleted using delete-region, using the overlay's start and end as parameters If the check for 'drag-but-negligible' wasn't there, then the following could happen: the user could drag the region into itself, then the contents would be inserted, and then both the original and the newly inserted contents would be deleted with the call to delete-region (because the text would have been inserted *inside* the overlay). With rectangular regions, I chose to use a list of overlays to represent the selected region. In my mind this made sense as I could keep the code that dealt with overlays when checking for read-only properties or when calling delete-region (with the overlay's start and end). The problem with this is that, in some cases, a rectangle can be dragged in a way where *some* parts of it are re-inserted into the overlays tracking the original selection. For example: Select a square: a a a [b b]b [c c]c Insert it at point marked with "|": a|a a [b b]b [c c]c a b b a a [b c c b]b [c c]c Call delete-region using the two overlays' boundaries: a b b a a b c ...which probably isn't what the user was expecting. By adding 'rectangle-intersect-p', and checking for a possible intersection between the original rectangular region and the potentially newly inserted rectangle, these cases could be avoided. The check for drag-but-negligible is easier to understand for contiguous regions: if dragging a region into itself was somehow possible, the text would remain unchanged, so the operation wouldn't make sense even from the user's perspective. With rectangles, however, it is harder to define which cases 'make sense'. For example, what should happen if a rectangle is dragged one column to the right, into itself? I think mouse-drag-and-drop-region could be greatly improved if we somehow implemented a way of checking the region's "type" (as we were talking) and if the results of dragging a rectangle were well defined and specified, from a user's perspective. > > Maybe their definition could be moved to > > that specific part of the code (and only define them when the region > > is rectangular). > > If that can be done, that sounds good. > > > I believe the only parts of the code that is rectangle-specific are: > > > > 1) Checking if the drag is negligible > > 2) Inserting the text in the new position > > 3) Re-activating the region after a successful or failed drag > > insert-for-yank takes care of (2), doesn't it? Yes, you're right. insert-for-yank is already "region type"-aware (because it uses the yank-handler property).