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: Sat, 20 Oct 2018 17:21:08 -0300 Message-ID: References: <20181017063829.3775.67018@vcs0.savannah.gnu.org> <20181017063831.03DCB2044D@vcs0.savannah.gnu.org> <810f1e04-1117-476d-9a7d-d57002609bf8@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1540066803 13557 195.159.176.226 (20 Oct 2018 20:20:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 20:20:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 20 22:19:59 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 1gDxj5-0003PN-9C for ged-emacs-devel@m.gmane.org; Sat, 20 Oct 2018 22:19:59 +0200 Original-Received: from localhost ([::1]:56465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDxlB-0003FT-GB for ged-emacs-devel@m.gmane.org; Sat, 20 Oct 2018 16:22:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDxkY-0003FO-Ux for emacs-devel@gnu.org; Sat, 20 Oct 2018 16:21:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDxkT-0007Vg-DL for emacs-devel@gnu.org; Sat, 20 Oct 2018 16:21:27 -0400 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:45340) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDxkS-0007Uq-1r for emacs-devel@gnu.org; Sat, 20 Oct 2018 16:21:25 -0400 Original-Received: by mail-lj1-x234.google.com with SMTP id j4-v6so33645035ljc.12 for ; Sat, 20 Oct 2018 13:21:23 -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=9bWlylf3v+3xRMh03D7HbJzgJg4QkGuntAS7a0wkDNk=; b=QNVUXu4kKkdiTv4QFTq2oREPEOZJcvbzHHLcPxeSO4qOCAXxvfp434lyeeOjfWyIeC n8tLqCtkk/S12G6zIn2LJuUrHKhJRN/oV+ItIsh5cyIml8AS1TljfyW9svY71dOSMk6f CdcnW5nza1aIDKuJ4Tzyubn/TDVh4mliQaFUh1Mpps+XzS1tT53+yj0KcVg672LllPd5 0NxR0FlCJ93baTKBvTL2OzHl5P6A4ERMD265zjzOuk9/i8jkZ0iqWNsx2w304o8HIfoq bbXayVPeOC77K31cYOAW2EmpR+wKmdr6wRza3t3e50uLyvRRRqXqWoMtx5i9bquTOIO1 53vw== 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=9bWlylf3v+3xRMh03D7HbJzgJg4QkGuntAS7a0wkDNk=; b=ukMY+glNTVu95pUDrk26c9YF2VIVGsBCDaov5ZsGboIChTspPKkexhluqCeXeG9q5u ATDBZkKcv4tWwWt8bYZgOC4wPcQd8aCt8INqxYDh47U0uNZuJqWoM0CWKhCLYxWL8Tu3 qyEM1yihCKWdhZHl1N2ORb135WuiBCkE4DQJi61zRheVR312brS/plFfumhcvMBxCSug 9zABb08uA4D123Wdnn3XW6K8eZvrI+3hg/tftjccY1mutABRDbUsg+ipUKLYLlVQTyYH wnatD5vAMNIBjp5suMPY2/J90dexf73mMsDIXYyV+p9h/R8d1cZY3NiNh9pwXQUb4H0P ZX3g== X-Gm-Message-State: ABuFfog6q8CZt80fXOwtoKa2j6x7XLzAgkViinI2rrzaD/bDs+xhxUW0 jPGUpUG5Yq5g3rp8HHP0PPJbW3yDZ4h3/7ym9OMM3Q5a X-Google-Smtp-Source: ACcGV61OouR/kL/yRHcwFwjrsLUW+XJF/EKOOciHZ/Jy0yITxfgkMN6JsZQSwatyRbeVTQ+CQiUBC2d8xlQw+LqCWgc= X-Received: by 2002:a2e:8347:: with SMTP id l7-v6mr15994375ljh.140.1540066881877; Sat, 20 Oct 2018 13:21:21 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::234 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:230531 Archived-At: > > I assumed (get-text-property start 'read-only) was an optimization to > > cover cases where the region was large, and at least the beginning of > > it was read only. I added (get-text-property end 'read-only) to > > complement this check, but on the ending. > > I see. No, the (get-text-property start 'read-only) was there because > the next test only verified if there's a *change* somewhere, so in order > to make sure it's nil everywhere you needed both: make sure it's nil > somewhere (in this case, at the beginning) and then make sure there's no > change anywhere. I see. Understood, then. > >> Same as above. Maybe those 3 lines should be moved to their own > >> little function. > > > > I'm not sure of what the function could do. Would it call > > activate-mark and then enable a special region mode? I imagine it > > would need to receive a parameter indicating what mode to choose. > > Not sure what it should do, indeed, but AFAIK it does the same at both > places. My point was only to combine those two places to avoid code > duplication: what the content should be is orthogonal. I agree. > >> Why "1-"? AFAIK you only compare those line numbers between themselves, > >> so this "1-" doesn't make any difference to your code and simply causes > >> this code to return "non-standard" line numbers. > > > > I wanted the "coordinates" to start at (0, 0) as I thought it would be > > easier to reason about when comparing them to other coordinates. > > For better or worse, we use (0, 1) as "origin" and I think it's better > to stick to this odd convention than to muddle the water even further. No problem, I'll remove the call to "1-". > >> BTW, your "width" is computed AFAICT as > >> > >> (- (overlay-end (car mouse-drag-and-drop-overlays)) > >> (overlay-start (car mouse-drag-and-drop-overlays))) > >> > >> which is a char-distance and not a column-distance (big difference in > >> the presence of TABs and double-width chars). > > > > You are right, I overlooked this. Using an overlay list then doesn't > > seem like a good option for tracking the contents of rectangular > > regions. > > Not sure why you think so. > You can probably just use. > > (save-excursion > (let ((ol (car mouse-drag-and-drop-overlays))) > (goto-char (overlay-end ol)) > (- (current-column) > (progn (goto-char (overlay-start ol)) (current-column))))) 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). Something I also realized is that the variables 'region-width' and 'region-height' are 1) rectangular region-specific and 2) are only used when checking if the region is being dragged into itself (setq drag-but-neglibible ...). Maybe their definition could be moved to that specific part of the code (and only define them when the region is rectangular). Also, region-width could be calculated using 'start' and 'end', probably using one of the functions in rect.el. Some of the functions in rect.el are not commented so I'll have to read them carefully to see if they can be used for this. On the other hand, using overlays to delete the original selection (whether it is rectangular or not) works fine, so maybe keeping them for that purpose is a good idea. > > Maybe I could change the code to make it look more like the > > original, and use rectangle--* functions with 'start' and 'end' where > > its needed. To do this, however, I would need to know the preferred > > way of checking the region's geometry. Right now I'm using > > 'region-noncontiguous-p' and assuming that t means rectangular, which > > could break things in the future. > > Maybe we should try and figure out what is special about rectangles, and > what should the code do for non-rectangular non-contiguous regions. > That might help us decide how best to get the needed information. > > > The code you mentioned is needed to ensure that when the user selects > > a rectangular region and drags it, the resulting content is selected > > with rectangular-mark-mode enabled. The same goes for when the drag > > operation fails. In both cases, the user expects that after dragging > > (or trying to drag) a rectangle, the resulting selected region will > > also be rectangular. > > Hmm... how 'bout attacking the problem as follows. There are 2 cases: > 1- the drag failed, so presumably nothing was changed. In that case, > naive thinks, there's nothing to do, the region is still active (and > rectangle-mark-mode is still active if applicable). If not why not? > In any case, if the region is not active any more (and > rectangle-mark-mode is hence also deactivated), there should be a way > to undo a region deactivation, i.e. "reactivate the region". > 2- the drag succeeded, so the text was just inserted somewhere with > insert-for-yank. Here as well, we just need some way to "activate" > that which we just inserted. > > So I think what we need is a generic `reactivate-region` command and > some way for it to work correctly for non contiguous regions (and the > insert-for-yank code should be able to set it up so that reactivating > the region after an insert-for-yank would activate it in the proper > mode as well). > > IIUC, this should solve your problems and be generally useful, right? 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 Then, the command you propose would be helpful for point 3. Points 1 and 2 would still need to be handled in a specific way, depending on the region's "mode". For that, we would need a way to get the current region's "mode" (or the one that was active when mouse-drag-and-drop-region was called).