Re: master 2f31dbeadf: Also show mouse DND tooltip contents during interprogram drag-and-drop

Re: master 2f31dbeadf: Also show mouse DND tooltip contents during interprogram drag-and-drop

[Eli Zaretskii]

> branch: master
> commit 2f31dbeadff0abc38ded5dd072df1ec179c49945
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
> 
>     Also show mouse DND tooltip contents during interprogram drag-and-drop
>     
>     * doc/lispref/frames.texi (Drag and Drop): Document new
>     parameter to `x-begin-drag'.
>     * lisp/mouse.el (mouse-drag-and-drop-region): Don't hide tooltip
>     when initiating interprogram drag-and-drop.
>     * lisp/term/haiku-win.el (x-begin-drag):
>     * lisp/term/ns-win.el (x-begin-drag): Add stubs for new
>     parameter.
>     * src/xfns.c (Fx_begin_drag): New parameter `follow-tooltip'.
>     (Fx_show_tip, syms_of_xfns): Add records of the last dx and dy
>     given to `x-show-tip'.
>     * src/xterm.c (x_clear_dnd_monitors): New function.
>     (x_dnd_begin_drag_and_drop): Save monitor attributes list if
>     appropriate.
>     (x_dnd_compute_tip_xy, x_dnd_update_tooltip_position): New
>     function.
>     (x_dnd_update_state, handle_one_xevent): Update tooltip position
>     during DND mouse movement.
>     (syms_of_xterm): Update staticpros.
>     * src/xterm.h: Update prototypes.

Instead of recording tooltip's coordinates in static C variables
(which then could cause potential problems with stale values),
wouldn't it be better to just move the tip frame from Lisp when the
mouse moves?

Re: master 2f31dbeadf: Also show mouse DND tooltip contents during interprogram drag-and-drop

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Instead of recording tooltip's coordinates in static C variables
> (which then could cause potential problems with stale values),
> wouldn't it be better to just move the tip frame from Lisp when the
> mouse moves?

We don't record the tooltip coordinates in a C variable, just the last
values of `dx' and `dy' passed to `x-show-tip'.  They are used to make
sure the tooltip moves to the location relative to the mouse pointer
specified by the caller of `x-show-tip'.

As for moving the tooltip from Lisp, that isn't possible, since we don't
allow running Lisp code inside the drag-and-drop event loop except under
very specific circumstances (i.e. the mouse moving onto one of our own
frames, or inside a selection converter).

Re: master 2f31dbeadf: Also show mouse DND tooltip contents during interprogram drag-and-drop

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 09 Jun 2022 15:50:11 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Instead of recording tooltip's coordinates in static C variables
> > (which then could cause potential problems with stale values),
> > wouldn't it be better to just move the tip frame from Lisp when the
> > mouse moves?
> 
> We don't record the tooltip coordinates in a C variable, just the last
> values of `dx' and `dy' passed to `x-show-tip'.  They are used to make
> sure the tooltip moves to the location relative to the mouse pointer
> specified by the caller of `x-show-tip'.
> 
> As for moving the tooltip from Lisp, that isn't possible, since we don't
> allow running Lisp code inside the drag-and-drop event loop except under
> very specific circumstances (i.e. the mouse moving onto one of our own
> frames, or inside a selection converter).

That's very unfortunate, because the current implementation is not
clean enough, IMO.  I cannot convince myself that we will never use
stale DX/DY values; can you?  Plus, using static variables means only
one such instance can ever be supported -- another restriction we'd be
better without.

Re: master 2f31dbeadf: Also show mouse DND tooltip contents during interprogram drag-and-drop

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's very unfortunate, because the current implementation is not
> clean enough, IMO.  I cannot convince myself that we will never use
> stale DX/DY values; can you?

I'm convinced: the DX and DY are always valid when `tip_frame' is a live
frame, and we don't use them otherwise.

> Plus, using static variables means only one such instance can ever be
> supported -- another restriction we'd be better without.

We already cannot refer to tip frames, and the toolkits we use currently
only support displaying a single system tooltip at the same time.

So there will be significantly more work involved in supporting multiple
tooltips than eliminating a few of the static tooltip state variables,
of which there are already a few anyway: tip_frame, tip_window,
tip_timer, tip_last_string, tip_last_frame and tip_last_parms.