Re: mouse-drag-and-drop-region

[martin rudalics]

> 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.

Did you ever consider using the "r" interactive switch instead of the
"e" one?

>> (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.

You mean that you highlight the original region with the secondary
overlay so that the overlay shows up on the target window as well and
the user is informed that dropping there might lead to say "dubious"
results?

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

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.

>> (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?

I would say

(defcustom mouse-drag-and-drop-region-show-tooltip t)

and never show a tooltip on text-only terminals even if this is t.

>> (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).

Yes.  It's irritating to drag a block cursor with the mouse.  Do you
know of any other applications which do such a thing?

>> (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.

We probably need to define additional cursors for this so it's not for
Emacs 26.

>> (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?

> 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)

I would be more radical with

(defcustom mouse-drag-and-drop-region-cut-or-copy t)

where the values 'cut and 'copy would always categorically cut or copy
(unless the value of 'mouse-drag-and-drop-region' implies to copy
instead of cut) and t means your original behavior.

>> (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.

The echo area should be avoided during tracking.  Think of users who
invoke 'mouse-drag-and-drop-region' on a frame without a minibuffer.

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'.

A final drop into read-only text should always give an error.  We should
be able to redeem that by providing a feedback in form of a mouse cursor
when the mouse is either over read-only text or no buffer text at all.

> 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.

IMO using 'kill-region' is an unexpected side effect.  If people
think differently, we could add yet another option like

(defucstom mouse-drag-and-drop-region-cut-does-kill-region t)

> There is other thread about mouse-drag-and-drop-region.
>
> https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00588.html

I'm aware of that.  I have changed some Emacs internals to make it work
here but I have no idea of the consequences these changes might have for
other mouse-tracking functions.  So this is strictly for Emacs 27.

Thanks, martin