Re: mouse-drag-and-drop-region

[Alex <agrambot@gmail.com>]

martin rudalics <rudalics@gmx.at> writes:


> Anyway, here are some comments:
>
> (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?

I imagine that this has to do with inputting a non-mouse-movement event
before moving the mouse at all. If you use your change and press "C-g"
before moving the mouse, then the region will still be pasted.

Doing the above without your change currently results in an error due to
`insert' using a nil `value-selection', though.  So it's faulty either
way.

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

Also, trying to use `tooltip-show' in text-terminals using
`xterm-mouse-mode' yields a lot of "Error while displaying tooltip"
messages.

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

Perhaps (3) should be fixed before release as well (at least disabling
tooltips when they can't be shown)?

Eli, would it be okay to make the same `read-event' -> `read-key' change
(specific to xt-mouse as in Bug#29150) here as well to tide over until
the function uses `set-transient-map'?  This appears to be the last
`read-event' present in mouse.el to get rid of.