Re: mouse-drag-and-drop-region

[Tak Kunihiro]

> (1) Why does the value selection happen within the ‘track-mouse’
>     form and why do you delete the mouse overlay?  That is, why
>     don't we move this part
>
>         (unless value-selection ; initialization
>           (delete-overlay mouse-secondary-overlay)
>           (setq value-selection (buffer-substring
>           start end))
>           (move-overlay mouse-secondary-overlay
>           start end)) ; (deactivate-mark)
>
>     right to the beginning so we have something like
>
>   (let* ((start (region-beginning))
>          (end (region-end))
>          (point (point))
>          (buffer (current-buffer))
>          (window (selected-window))
>          (value-selection (buffer-substring start
>          end)))
>     (move-overlay mouse-secondary-overlay start
>     end)
>     (track-mouse
>       ...
>
>     there?

There could be two operations that are `click' and `drag'.  Later on
line 40, value-selection is also used to identify whether operation is
`drag'.  Probably code should be improved.

39:  ;; "drag negligible" or "drag to read-only", restore region.
40:  (value-selection
41:   (select-window window) ; In case miss drag to other window
42:   (goto-char point)

> (2) Activating the secondary overlay can be distracting and should
>     be made optional (facultatively keeping the primary overlay in
>     place provided (4) below is done).

Region on the other window is not visible.  Thus original region
should be hi-lighted somehow.  Since mouse-drag-and-drop-region is
located on mouse.el, mouse-secondary-overlay was used.

Do you suggest to have option such like
 (defvar mouse-drag-and-drop-region-overlay 'mouse-secondary-overlay)
?

> (3) Showing tooltips can be distracting and should be optional.
>     Note also, that usurping tooltips this way may prevent them from
>     showing interesting properties of the drop area like whether the
>     text there is read only.  OTOH we might consider retaining
>     properties of the text in (non-GTK) tooltips.

Do you suggest to have option like
 (defvar mouse-drag-and-drop-region-preview t)
or implement other way to show the text besides using tooltips?

> (4) The (deactivate-mark) and (mouse-set-point event) trick to allow
>     showing point the way ‘mouse-drag-track’ does can be distracting
>     and should be made optional.

I think that this is very related to 2, 3, and 5 (as you inferred).

> (5) The mouse pointer shape should take care of indicating the exact
>     position where the drop occurs.  We should probably also signal
>     whenever the current drop position is invalid.  This is IIUC
>     usual practice on most window systems now.

I think it is a good idea.

> (6) Dropping should allow to copy text into the region itself.
>     There's no reason forbidding that.

I suppose that you mean when drop onto region itself with key pressed.
I agree.

> (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.
Between the same volume (buffer), `drag' does `cut' instead of `copy'.
I prefer current behavior as default but have
no objection to have option something like
 (defvar mouse-drag-and-drop-region-cut-hungry t)
.

> (8) Read-only text should be handled.  An attempt to drop text into
>     a read-only area should be signalled to the user.  An attempt to
>     cut text from a read-only text/buffer should be signalled as
>     well.

> For the latter, we copy text instead (cf C-w in read-only text).  So
> I think this feature should behave similarly, at least by default.

> I just noticed that the code does use ‘kill-region’ already.  This
> has the side-effect of putting the text into the kill ring,
> something which should be documented at least.  But I think the code
> should rather use ‘delete-region’ instead with the behavior you
> proposed.

I suppose that you suggest to tell user more explicitly in echo area
how he cannot change the text.  I am not against the suggestion.

On an user perspective, operation `drag-and-drop-region' is a
combination of `cut' and `paste'.  Thus text was killed instead of
deleted.  How you think delete is more preferred?  I have no objection
to document it.

> (9) The code must become resilient against any failures by wrapping
>     it into a ‘condition-case’ and doing the necessary clean up
>     operations (restoring region and point, deleting the secondary
>     overlay).
>
> I think (8) and (9) should be fixed before the release.  As for
> future releases we might also consider a ‘set-transient-map’ based
> solution.

No objection.  There is other thread about mouse-drag-and-drop-region.

https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00588.html