From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 134ba45: Allow two mouse functions to work with Rectangle Mark mode Date: Fri, 19 Oct 2018 23:48:12 -0400 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 X-Trace: blaine.gmane.org 1540007218 13181 195.159.176.226 (20 Oct 2018 03:46:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 03:46:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Federico Tedin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 20 05:46:54 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 1gDiE1-0003LE-HS for ged-emacs-devel@m.gmane.org; Sat, 20 Oct 2018 05:46:53 +0200 Original-Received: from localhost ([::1]:53616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDiG7-0006HC-TD for ged-emacs-devel@m.gmane.org; Fri, 19 Oct 2018 23:49:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDiFU-0006H5-3F for emacs-devel@gnu.org; Fri, 19 Oct 2018 23:48:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDiFP-0005YR-3V for emacs-devel@gnu.org; Fri, 19 Oct 2018 23:48:24 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:58675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDiFL-0005UY-V6 for emacs-devel@gnu.org; Fri, 19 Oct 2018 23:48:17 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w9K3mCR9004280; Fri, 19 Oct 2018 23:48:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A36B46A3F3; Fri, 19 Oct 2018 23:48:12 -0400 (EDT) In-Reply-To: (Federico Tedin's message of "Sat, 20 Oct 2018 00:21:30 -0300") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6399=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6399> : inlines <6936> : streams <1801820> : uri <2734108> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:230516 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 beggining 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. >> 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. >> 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. >> 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))))) > 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 noncontiguous 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? Stefan