From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tak Kunihiro Newsgroups: gmane.emacs.devel Subject: Re: mouse-drag-and-drop-region Date: Fri, 24 Nov 2017 08:28:44 +0900 (JST) Message-ID: <20171124.082844.327583219249620986.tak.kunihiro@gmail.com> References: <5A0D562D.1010803@gmx.at> <20171120.222937.949251858246319152.tak.kunihiro@gmail.com> <5A13F0CA.2030605@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511479753 23727 195.159.176.226 (23 Nov 2017 23:29:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Nov 2017 23:29:13 +0000 (UTC) Cc: eliz@gnu.org, tak.kunihiro@gmail.com, agrambot@gmail.com, emacs-devel@gnu.org To: rudalics@gmx.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 24 00:29:06 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 1eI0vT-0005Ja-Mr for ged-emacs-devel@m.gmane.org; Fri, 24 Nov 2017 00:28:59 +0100 Original-Received: from localhost ([::1]:46478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI0va-0002yD-Ne for ged-emacs-devel@m.gmane.org; Thu, 23 Nov 2017 18:29:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI0vT-0002wu-HO for emacs-devel@gnu.org; Thu, 23 Nov 2017 18:29:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eI0vS-0003f9-41 for emacs-devel@gnu.org; Thu, 23 Nov 2017 18:28:59 -0500 Original-Received: from mail-pl0-x22e.google.com ([2607:f8b0:400e:c01::22e]:41504) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eI0vO-0003Zx-4U; Thu, 23 Nov 2017 18:28:54 -0500 Original-Received: by mail-pl0-x22e.google.com with SMTP id u14so3370854plm.8; Thu, 23 Nov 2017 15:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-transfer-encoding; bh=JwwlafsRxLF10Xs7sHnGFREMbSE5kgWNe0cIAjYW4Y0=; b=GtYs8MjDyvP8LlNzLj+BZ4O+7MhDgPGN9I2IjBb9MS4m87aJMD6qLlXm5+LUWl9ecl +j6DHPweUUirLoji3XOdI+yK6VKRLInE22s9tmxWJBxes3sTy4v4FayptLjTKd1kzrW8 9COhRO1hfGE4ifZgH7QUMUkzxcvsX4q0RDq0WVordw/DVLxfPuGXZ5XZJH8Oeb3wo8nX kK6Mjcpyr72DuRxK7NNkHppgBEttdrDwAsjHT3bIh/nGCWcscfYx8o3rJBfCpN15jYHw TbUdkR558TkcEuuS3/xl2Yd9tNnTnLTS3LR0ONXCFriQxxmPss/VA3s8NhaG92Qy7npo zqRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:mime-version:content-transfer-encoding; bh=JwwlafsRxLF10Xs7sHnGFREMbSE5kgWNe0cIAjYW4Y0=; b=TxORyFHOff+aUyF1vADzj2Wvh4+wTbD9JeeR1+YC/ceSeby0DnFX+EK1Xc8IdfhwnX 8p2hSPs9qmCcYfxJOHf1dDqUVDw7lC7tWJXf1iCfynti7MAGSvaEqgpQXORUYUg+J8x5 xnk0HwTvRyLabrNjEAW9n87D9PubLZneSs3KTfWCYNhmP9YM5Zip+pxaUmsRk1i2stza gNqI/HU4ftaxUWa9rI8/LqD/IZZEC6xP4oBxl2j+sDrAtMQsofN2HmpvoanTFqqJEc5L qZmPnZOWZe1czEN8Y0QdXaI7dVqGX+UlX1TiQXuBMX0Dgwvr3001mZP7kcwq2gVJRtcm qohg== X-Gm-Message-State: AJaThX6HnGtPobc1QNKi4u2HopCF8IYmY8aONJ+W9psDMAt0i8p+KKRr b9/DQt9pUskROvV49qvw5X0= X-Google-Smtp-Source: AGs4zMZe8gmh+AzS/iwwR8psAv+SybmvkHVTmvAYovoEaP05BvtPljrTeBeuTEaoJ2tBKvroTC28aw== X-Received: by 10.84.232.138 with SMTP id i10mr27680318plk.104.1511479732383; Thu, 23 Nov 2017 15:28:52 -0800 (PST) Original-Received: from localhost (vesta.misasa.okayama-u.ac.jp. [150.46.48.154]) by smtp.gmail.com with ESMTPSA id w64sm38855570pfj.62.2017.11.23.15.28.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 15:28:51 -0800 (PST) In-Reply-To: <5A13F0CA.2030605@gmx.at> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c01::22e 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:220413 Archived-At: Thank you for the replay. >>> 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 meant I need to spend significant time to make secondary-overlay option. I have started to fix things from easy ones. >> 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. How to show insert point? Do you mean restore active cursor back to source text? >>>>> (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. 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 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. ... > (... ; save the state here > (condition-case nil > (progn > (track-mouse > ) > ) > (error ... ; restore the state here > ))) > > If you have any problems coding that, please ask. OK. I will (but not yet). >> +(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). OK. >> + (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. 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))) >> + (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. OK. >> + (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. To select window is necessary for the case. I try to use it when fits. > And if I'm not mistaken you still disallow to copy > text into itself. I forgot to mention, that was fixed. I think that there are two significant TODOs. - Make drag robust using condition-case - Make secondary-overlay option