Re: mouse-drag-and-drop-region

[martin rudalics]

> I re-revised mouse-drag-and-drop-region.  I'm sending replay to
> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00589.html,
> ChangeLog, and patch.

Thanks.  Kindly send patches always as attachments, this one choked here
because of a missing form feed near the end.

> I got rid of usage of secondary-overlay.  I
> define a new variable mouse-drag-and-drop-region-face.

Very good.

>>> How to show insert point?
>>
>> I think that by default the insert point should be shown by the
>> mouse cursor alone.  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").
>
> OK.  Only set point by mouse-set-point when
> mouse-drag-and-drop-region-show-tooltip is non-nil with changing
> cursor type.  I also changed the default of
> mouse-drag-and-drop-region-show-tooltip to nil to be more stable
> against accident during dragging.

This reverts too much from your initial proposal.  Basically, all your
initial ideas are fine, just that if on one or the other system they
don't work as intended or some user finds them annoying, there should be
options to turn them off.  And, if accidents happen during dragging with
any of the options non-nil, we should try to handle or fix them anyway.
So I would use three options instead of one:

`mouse-drag-and-drop-region-show-tooltip' to toggle the showing of
tooltips during dragging and nothing else.

`mouse-drag-and-drop-region-highlight-region' to toggle highlighting the
region with `mouse-drag-and-drop-region-face' (which gives the user the
feedback whether cutting may fail when dropping into the region itself,
which was your initial intention IIUC).

`mouse-drag-and-drop-region-show-cursor' which should synchronize the
cursor with the mouse cursor just as `mouse-drag-track' does.  This is
the only option I personally would default to nil but if you or others
like it on by default I certainly won't insist.

>> 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.
>
> Even track-mouse is sandwiched by condition-case, I cannot catch a
> error typing during dragging.

When I try to drop the region on the toolbar or another frame (things
some users might try out soon because they are not too far-fetched) I
currently get something like

Wrong type argument: windowp, #<frame address@hidden 05408d00>

Before your last patch this was a complaint about an overlay.  In either
case, users who don't know much about the internals of Emacs will wonder
what these messages are about and where they come from.  We should tell
them instead something like "Drop failed" or "Cannot drop into initial
region".  And, if such an error occurs, we should be sure to delete the
`mouse-drag-and-drop-overlay' and restore the initial region, if
necessary.

> However, as inferred already, when
> mouse-drag-and-drop-region-show-tooltip is nil, it is more stable even
> typing key during dragging.

Yes.  But typing during dragging should be caught by us in some way.  It
should not defer us from showing tooltips by default.

One final remark: Stepping through every single character in

          ;; Check if selected text is read-only.
          (dolist (index (number-sequence start end))
            ;; (add-text-properties (region-beginning) (region-end) '(read-only 
t))
            (setq text-from-read-only (or text-from-read-only
                                          (get-text-property index 
'read-only)))))
                                        
is not very efficient if the region is large.  Please consider using
`next-single-char-property-change' instead.

Thanks again, martin