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: Fri, 24 Nov 2017 10:02:52 +0100 Message-ID: <5A17E03C.4000304@gmx.at> References: <5A0D562D.1010803@gmx.at> <20171120.222937.949251858246319152.tak.kunihiro@gmail.com> <5A13F0CA.2030605@gmx.at> <20171124.082844.327583219249620986.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 1511514218 16385 195.159.176.226 (24 Nov 2017 09:03:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Nov 2017 09:03:38 +0000 (UTC) Cc: eliz@gnu.org, agrambot@gmail.com, emacs-devel@gnu.org To: Tak Kunihiro Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 24 10:03:32 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 1eI9tK-0003OA-TV for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 10:03:23 +0100 Original-Received: from localhost ([::1]:48076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI9tS-0001Sz-8h for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 04:03:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI9t3-0001L8-9M for emacs-devel@gnu.org; Fri, 24 Nov 2017 04:03:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eI9su-0002TY-Ip for emacs-devel@gnu.org; Fri, 24 Nov 2017 04:03:05 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:49741) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eI9su-0002S3-AU; Fri, 24 Nov 2017 04:02:56 -0500 Original-Received: from [192.168.1.100] ([46.125.249.103]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJSx9-1eJXrJ10Ch-0038TS; Fri, 24 Nov 2017 10:02:54 +0100 In-Reply-To: <20171124.082844.327583219249620986.tak.kunihiro@gmail.com> X-Provags-ID: V03:K0:aCeHGzf5gdA5bjoQx+ME6j+76jZywuXs58S6DSBgwxN0GomA5yF g/jMUXkTc3vqx/1/J6YKjnIFU/HeirzwxM2s+aGSxMSylutia1bdMMu3fsKzGIumnZSSMdQ 8sziF1DaulREx6FtzlXlb+glHzIg4UI8qi2fLtkM0sLLY9blPz8qxZXWhN3qoqIcjWHvzvE blC8lRCKzjitcLe4ih3/g== X-UI-Out-Filterresults: notjunk:1;V01:K0:uZEQKZU/LVI=:FYMQF+OSB/eH4IyWehYlfa T7OiVhL+e1HDh5rqlrc36+HdyuWqkFF/ifhSQ5tz55Dm4A6IzjT2HF6gdno4O7hgfFvZ1PmK4 f9sMPM02jUtoVu7SNXVVWjpCsk5KtsqXESHXZankm/yA5PpK5IAIxi801aFyy8wJlIvW8VaID d+jjfOvWLPFR+9UHLn5j9hYO1Qzl9JfQem/y2W/oAantlJwdyWJcAfciwm3AcyGuApPBZKtv6 ZxRhnjDYCcIjHjY/LKnmA3JEiTjphRh0R2CWl6vFZxmOgXbGzOXxM/tNJgLLfUOOaq8KYpPWB CLWEriCjeBxNFOMB4l2SQbdyUpiVoAMBvWB6GwN396KqGK9CEaqOyEZPajtnTmjdiUGLOL/5Y TV84qoDPkA2lMg9Mj3TerC9XcJsIGwTrY2C1UNf3rtx+qB3wPONuW/9CGVwVx7SR1mP28rVDP z+iZ9PXgabjdajhAd25mKJnmeXKkfDn55e6HsaiUm5UFfM1WHKxYxp1RAiVWAfTHn3F6mkRe9 +kMwL8Uvs/00M7pMasOOK734Ctnro/RFzzV0l0SjbIknPQqkvX8s6Gh8EMWkqATVXghv2PXFK 4qCvMHI1vR/JTxF5GvnabRXW6dTr+obOJXNHkXB9QSWVmYzc/UelcxsxAQhkusX5IPjBwr5DA JXLoXMw5A8G8frVfUaXFJ3ivitdskXwDVkH/kid/aU7hyX0q3zp9+C1E4i9a52KA8cmN2+Ees cyTzuX9UAxt2iTOD8y5eeriO/j9P3947dUn1vfN1ZakzSJOJkg2ndA4o408QSdBHy30Reksw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.19 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:220423 Archived-At: > I meant I need to spend significant time to make secondary-overlay > option. I have started to fix things from easy ones. Do you mean that it's difficult to make the code work if it does not use the secondary overlay? I don't understand why, instead of perusing the secondary overlay, you don't use your own overlay to indicate start and end of the text you cut or copy. When done with the operation or when an error occurs during dragging, you simply remove that overlay. In addition, you can define a face the user can customize in order to highlight that overlay. This way, any secondary overlay that existed already when the user started dragging would be just left alone. > How to show insert point? I think that by default the insert point should be shown by the mouse cursor alone. Personally, I'd also prefer that when the original position of point is scrolled off-screen, the normal cursor should not be shown at all because it's by no means sure that it will stay there after the drop occurred: If the drop happens in another buffer, you restore the original point to where it was before. Note that this is not the case with `mouse-drag-region' which always leaves the normal cursor at its last position even after the window was auto-scrolled. Optionally, I see no problem showing the normal cursor just as `mouse-drag-region' does, maybe with some customizable cursor type (I think "bar" would give a better feeling than "box"). > Do you mean restore active cursor back to source text? When an error occurs, definitely so. Then you should do what you do when the drop happens in another buffer. Maybe in these cases you additionally should restore the window start position too, so that the user can start from where she left off. If you restore the window's point only as you do now, then the region will be often partially off-screen (at least here) although it was on-screen before. When everything "goes well", point obviously will go to the position of the inserted text. Although when the drop happens in another window showing the same buffer, it might be interesting to restore the source window's state just as if the drop happened in another buffer. > When an Icon of c:/runemacs.exe is dragged to d:/, copy. When an Icon > of c:/runemacs.exe is dragged to c:/emacs-26.0.90/bin, cut. I see what you mean now but I doubt that many users of `mouse-drag-and-drop-region' will be aware of such an analogy. > I think the patch covered that. The approach is to overwrite > mouse-drag-and-drop-region-show-tooltip locally. > > (let ((mouse-drag-and-drop-region-show-tooltip > (and mouse-drag-and-drop-region-show-tooltip > (display-multi-frame-p) > (require 'tooltip))) You're right. I apparently missed that. > I think that there are two significant TODOs. > - Make drag robust using condition-case Definitely. > - Make secondary-overlay option This would be nice to have. Thank you, martin