From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: mouse-drag-and-drop-region Date: Tue, 21 Nov 2017 10:24:26 +0100 Message-ID: <5A13F0CA.2030605@gmx.at> References: <5A0ABD41.5040402@gmx.at> <20171116.092825.1408561780440493246.tak.kunihiro@gmail.com> <5A0D562D.1010803@gmx.at> <20171120.222937.949251858246319152.tak.kunihiro@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511256330 32253 195.159.176.226 (21 Nov 2017 09:25:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 09:25:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tak Kunihiro , Eli Zaretskii , Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 21 10:25:18 2017 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 1eH4nt-0007bn-LM for ged-emacs-devel@m.gmane.org; Tue, 21 Nov 2017 10:25:17 +0100 Original-Received: from localhost ([::1]:33278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH4o0-0000rl-Ve for ged-emacs-devel@m.gmane.org; Tue, 21 Nov 2017 04:25:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH4nO-0000rf-3V for emacs-devel@gnu.org; Tue, 21 Nov 2017 04:24:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eH4nM-0000WD-Nd for emacs-devel@gnu.org; Tue, 21 Nov 2017 04:24:46 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:60111) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eH4nJ-0000Uu-DZ; Tue, 21 Nov 2017 04:24:41 -0500 Original-Received: from [192.168.1.100] ([46.125.249.33]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MEGIi-1eNdJH23c8-00FUC5; Tue, 21 Nov 2017 10:24:39 +0100 In-Reply-To: <20171120.222937.949251858246319152.tak.kunihiro@gmail.com> X-Provags-ID: V03:K0:5387hvohRCiu/ICbYWlfxV2TavaVcMy4DVl0ZUhHsjWqhcdPQNK 1nBzgOHHuAT+bImr3B5XoNZgYM7YxPL3X2Doc5mx1zDWBFYftJWBSdAz5Nn5hnhVnLK3+bD rli0PSlR7mEuWoZQQGkJxlofA9iOZdQRBs7DVM1vISa1OADkD0WUqjAdNPB8oMQCLhaktzP 7GWjVM7SzDCIRi39HBxTg== X-UI-Out-Filterresults: notjunk:1;V01:K0:HNCK8FAgOFI=:aHxlgDSuLwqcZr0wbc5AH6 NMZZOZ9Y0NepG3PFzRDQyRJxZ+tG83xlRyzqlU+YRmFlPaCZWRTFVTVtKKbZqpvwdeY9cHM0L /ZnCyrNMOVtweVrrP1DOIVoYd3vWvgOMIEfKTy/tV31dDa5Jl5QH0Y2P7V/LDrfO3IneaYWl9 xOqRZR4vzPYU5wwuA6Di2Bbzohu4VPwWPBBvA6Pj0locSuG5BV1zseIameqeTcLaj29cgHi/4 3Q0qsCosSoAwGwing0qA3wHdvQTFqRqre+ffLDwvD1REW8jPdd2Mn3mc5rAWDYqfp9D+0ThY9 CwqSLj8mcGuhUkBXmWk308uqb9kjQpfDTLwiQmTnvCNCS1mRF6+LQmFdzVWbWAFYyljdABhti a8sgy5qTH9bE5QGDrfV/FXfp5Ul1UU0Zqpef+k7HkZw8QsHWOR9yPt2os+9y9eYMn7vH4lJuX jTLaELS2z517coSo2edgthrT2k4dQWUQsTV+4fP+kNJ7wmk6kT2BODRFMTxlyDATMIVM63Fsb n1Ug9Iv2ZNWJeKWVRYA1G27S3skdfTLNsXb6XJM5HOSHvgWBTNxHWSPG0VnISQ/qBXdgzW7Wb YCx+QMgw52TSpbTfgfSK7J577ZO/cl4nOxX2SqVA60Rfno+3SmpZe5gMvwRUvQfHO0pofyt9Q 0BZVvtmtl202oUNUXspMAHI9cttzB1PUC8n4RLrylh+DUU8FFWlvrXDxLU4pJOYaWZeX0GSmY 9/XyFxfwnfwvOSFWuqZUcY6wqEb65Y7LmUx5SdmxT7kkGSbQBYn8sS/QD4+JAFy7YhdfrQnO X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.18 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:220320 Archived-At: >> Did you ever consider using the "r" interactive switch instead of the >> "e" one? > > I suppose you suggest something like below. I cannot make this work. > Thus this revision, I do not use "r" interactive switch. > > (defun mouse-drag-and-drop-region (event start and) > (interactive "e\nr") > ...) We would probably have to change 'mouse-drag-region' for that to work. >> I mean something like >> >> (defcustom mouse-drag-and-drop-region-show-secondary-overlay t ...) >> >> where setting this to nil means to just not show any overlay. And >> your code would have to accept that there is no secondary overlay at >> the time of the drop. > > I found this takes significant time. I skip to get rid of usage of > secondary-overlay on this revision. What takes significant time? Please elaborate. > I cannot think of a way to show insert point besides (mouse-set-point > event). Do you suggest overlay-put "|" or change cursor-type to 'bar > during drag? I thought who prefers bar changes the default cursor > anyway. I did not revise code in this respect. I think that using 'mouse-set-point' as we do for 'mouse-drag-track' is not necessarily a good idea. The idea with 'mouse-drag-track' is that its user usually wants point to go where the mouse moves. The idea with 'mouse-drag-and-drop-region' is that the user wants to drop text where the mouse goes but not necessarily also move point there. If we want 'mouse-drag-and-drop-region' to do additional things (like killing the region or moving point) we should make these customizable at least. >>>> (7) IMO either cutting should be the default too when the drop >>>> occurs in a different buffer or copying would be the default and >>>> pressing the modifier should produce a cut instead. The current >>>> behavior wants me to always keep in mind whether the target >>>> buffer is the same as the source buffer. At least, this >>>> behavior should be made optional. >>> >>> Default behavior followed that of file browser on `drag' a file. >> >> Which file browser? > > Finder on macOS and File Explorer on Windows 10 behave like that way. Do you mean that they move a file when the target directories differ and copy it when they are the same? Isn't that then the opposite of >>> Between the same volume (buffer), `drag' does `cut' instead of `copy'. In either case I fail to see the volume/buffer connection relationship. But maybe that's just me. >> I think that first of all you should use 'delete-region' instead of >> 'kill-region' to avoid the above-mentioned side effect. Then your >> code should silently swallow any bugs for cutting from read-only >> text provided 'kill-read-only-ok' is t. For that purpose, simply >> peruse the corresponding code from 'kill-region'. > > OK. Now `delete-region' is used. As mentioned, we can always add an option to kill the region instead. > I revised only to give message. I could not tell how to bring > condition-case to code. IMO this is one of the two major things to fix before the release. Think of someone using this function in a way you didn't anticipate (for example, take the bug mentioned by Alex that someone hits some other key while dragging). If mouse tracking then throws an error and you changed point or the region or leave the secondary overlay around, this can be very irritating. After all, we want people to have a smooth experience especially when using a new function. Obviously, if you do not move point, do not create a secondary overlay or do not change the region, these are not needed. Otherwise, the function should restore the entire configuration (selected window, point, region, overlays at least) that existed before dragging started so that the user can restart from there. More precisely, you should wrap 'track-mouse' and whatever you do after it terminates in a 'condition-case' form and in the error part restore everything to the saved values. Like so: (... ; save the state here (condition-case nil (progn (track-mouse ) ) (error ... ; restore the state here ))) If you have any problems coding that, please ask. > +(defvar mouse-drag-and-drop-region-cut-among-buffer nil > + "When t, text is cut instead of copy when dragged among buffers.") This should be a 'defcustom'. I would write instead (defcustom mouse-drag-and-drop-region-cut-when-buffers-differ nil "If non-nil, cut text also when source and destination buffers differ. If this option is nil, `mouse-drag-and-drop-region' will leave the text in the source buffer alone when dropping it in a different buffer. If this is non-nil, it will cut the text just as it does when dropping text in the source buffer." :type 'boolean :version "27.1" :group 'mouse) and likewise for 'mouse-drag-and-drop-region-show-tooltip' (note also the use of active voice and non-nil instead of t). > + (when mouse-drag-and-drop-region-show-tooltip > + (tooltip-show value-selection)))) Still not quite right: Never show a tooltip on text-only frames. Think of people who want to show tooltips but occasionally work on TTYs. > + (if buffer-read-only (message "Buffer is read-only")) ; (barf-if-buffer-read-only) 'buffer-read-only' is not sufficient. Please handle read-only text properties at this position. > + ;; Intert the text to destination buffer under mouse. ^ > + (let ((window1 (selected-window))) > + (select-window window) ; Select window with source buffer. > + (goto-char point) ; Move point to the original text on source buffer. [...] > (select-window window1)))) I think (set-window-point window point) instead of the above should suffice. And if I'm not mistaken you still disallow to copy text into itself. martin