bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

In emacs -Q, try to extend the selection by dragging the mouse upwards
over the tool bar.  This used to extend the selection upwards as
expected, in Emacs 27, and Emacs 28 from April, but doesn't work anymore
in both Emacs 28.0.60 and 29.0.50, complaining:

<tool-bar> <mouse-movement> is undefined.

While I'm reporting the bug from a modified copy of Emacs, I observed
the bug on X11 built with Lucid as well as this copy, so I don't think
this is a problem with my copy.

Thanks.


In GNU Emacs 29.0.50 (build 1, x86_64-unknown-haiku, Haiku R1/beta3)
 of 2021-10-03 built on shredder
Repository revision: 0418dbbf9c5ebca199e002b1db4c2c7627f12597
Repository branch: master
Windowing system distributor 'Haiku, Inc.', version 5.1.1
Configured using:
 'configure --with-be-app'

Configured features:
BE_APP GIF GLIB GNUTLS JPEG JSON LIBXML2 MODULES NOTIFY GFILENOTIFY
PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_COLLATE: en.UTF-8
  value of $LC_CTYPE: en.UTF-8
  value of $LC_MESSAGES: en.UTF-8
  value of $LC_MONETARY: en.UTF-8
  value of $LC_NUMERIC: en.UTF-8
  value of $LC_TIME: en.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> Date: Sun, 03 Oct 2021 20:06:13 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In emacs -Q, try to extend the selection by dragging the mouse upwards
> over the tool bar.  This used to extend the selection upwards as
> expected, in Emacs 27, and Emacs 28 from April, but doesn't work anymore
> in both Emacs 28.0.60 and 29.0.50, complaining:
> 
> <tool-bar> <mouse-movement> is undefined.

This is because of commit 2e595b3: we now report mouse gestures on
tool bar and tab bar with the corresponding prefixes.  And
keyboard.c+mouse.el evidently don't like to see [tool-bar mouse-movement].

I have no idea how to fix this mess; I tried many things, but gave up
eventually.  Perhaps Stefan knows what to do here.  As a kludge, maybe
remove the prefix if the full even has no binding?  Anyway, we cannot
revert that change because it was done to support mouse wheel on the
tab bar.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> This is because of commit 2e595b3: we now report mouse gestures on
> tool bar and tab bar with the corresponding prefixes.  And
> keyboard.c+mouse.el evidently don't like to see [tool-bar mouse-movement].
>
> I have no idea how to fix this mess; I tried many things, but gave up
> eventually.  Perhaps Stefan knows what to do here.  As a kludge, maybe
> remove the prefix if the full even has no binding?  Anyway, we cannot
> revert that change because it was done to support mouse wheel on the
> tab bar.

I'm afraid I don't have a good idea either: this business of adding
prefix events like `mode-line` and `tool-bar` is quite fiddly and
I haven't managed to wrap my head around precisely how it's supposed
to work.

I think it would make sense to drop those prefixes when the resulting
key sequence has otherwise no binding, but at the same time it feels
a bit like adding a hack on top of another one.


        Stefan "wondering if using modifiers instead of prefixes would
                have made things better or made them worse"

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  50993@debbugs.gnu.org
> Date: Sun, 10 Oct 2021 15:10:58 -0400
> 
> > I have no idea how to fix this mess; I tried many things, but gave up
> > eventually.  Perhaps Stefan knows what to do here.  As a kludge, maybe
> > remove the prefix if the full even has no binding?  Anyway, we cannot
> > revert that change because it was done to support mouse wheel on the
> > tab bar.
> 
> I'm afraid I don't have a good idea either: this business of adding
> prefix events like `mode-line` and `tool-bar` is quite fiddly and
> I haven't managed to wrap my head around precisely how it's supposed
> to work.
> 
> I think it would make sense to drop those prefixes when the resulting
> key sequence has otherwise no binding, but at the same time it feels
> a bit like adding a hack on top of another one.

OK, thanks.

I also tried to bind [tool-bar mouse-movement] to the same command to
which we temporarily bind [mouse-movement] inside mouse-drag-region,
but it somehow didn't work.  Any idea why, or how to do it so it does
work?  Then we perhaps could bind those prefixed mouse movements, and
keep the feature working.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I also tried to bind [tool-bar mouse-movement] to the same command to
> which we temporarily bind [mouse-movement] inside mouse-drag-region,

Sounds like a good plan, yes.

> but it somehow didn't work.
> Any idea why, or how to do it so it does work?

I'll have to try it out to see *how* it fails to work :-(


        Stefan

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'll have to try it out to see *how* it fails to work :-(

mouse-drag-track calls mouse-minibuffer-check, but the event's
frame_or_window is a frame and not a window, so it fails in a call to
window-minibuffer-p.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 > mouse-drag-track calls mouse-minibuffer-check, but the event's
 > frame_or_window is a frame and not a window, so it fails in a call to
 > window-minibuffer-p.

I'm too silly to understand how this is related to the issue at hand.
Can you please elaborate?

So far I've been unable to reproduce this issue on Emacs 28.  Doesn't
'mouse-drag-track', once started, conceptually have to get through
wherever the mouse pointer is - a child frame, the tool bar, another
frame, no frame at all?  Like scroll bar dragging with the mouse?

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

> I'm too silly to understand how this is related to the issue at hand.
> Can you please elaborate?

AFAIU, mouse-movement events generated by moving the mouse over the
toolbar don't contain a window, but rather the frame the toolbar belongs
to.

However, mouse-drag-track wants START-EVENT to contain a window.

> So far I've been unable to reproduce this issue on Emacs 28.  Doesn't
> 'mouse-drag-track', once started, conceptually have to get through
> wherever the mouse pointer is - a child frame, the tool bar, another
> frame, no frame at all?  Like scroll bar dragging with the mouse?

You need a build without toolkit tool bars, I think.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 >> I'm too silly to understand how this is related to the issue at hand.
 >> Can you please elaborate?
 >
 > AFAIU, mouse-movement events generated by moving the mouse over the
 > toolbar don't contain a window, but rather the frame the toolbar belongs
 > to.

Yes, but how does 'mouse-minibuffer-check' enter this picture?

 > However, mouse-drag-track wants START-EVENT to contain a window.
 >
 >> So far I've been unable to reproduce this issue on Emacs 28.  Doesn't
 >> 'mouse-drag-track', once started, conceptually have to get through
 >> wherever the mouse pointer is - a child frame, the tool bar, another
 >> frame, no frame at all?  Like scroll bar dragging with the mouse?
 >
 > You need a build without toolkit tool bars, I think.

I see.  Dragging the secondary selection seems to work here with the
trivial patch below.  Can you try it?

martin


diff --git a/lisp/mouse.el b/lisp/mouse.el
index 5d4e05fa25..6da4635114 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -2121,6 +2121,7 @@ mouse-drag-secondary
  	  (while (progn
  		   (setq event (read--potential-mouse-event))
  		   (or (mouse-movement-p event)
+		       (eq event 'tool-bar)
  		       (memq (car-safe event) '(switch-frame select-window))))

  	    (if (memq (car-safe event) '(switch-frame select-window))
@@ -2129,7 +2130,8 @@ mouse-drag-secondary
  		    end-point (posn-point end))
  	      (cond
  	       ;; Are we moving within the original window?
-	       ((and (eq (posn-window end) start-window)
+	       ((and (not (eq event 'tool-bar))
+		     (eq (posn-window end) start-window)
  		     (integer-or-marker-p end-point))
  		(let ((range (mouse-start-end start-point end-point
  					      click-count)))

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

>>> I'm too silly to understand how this is related to the issue at hand.
>>> Can you please elaborate?
>>
>> AFAIU, mouse-movement events generated by moving the mouse over the
>> toolbar don't contain a window, but rather the frame the toolbar belongs
>> to.

> Yes, but how does 'mouse-minibuffer-check' enter this picture?

It's called by mouse-drag-track, with START-EVENT as its argument.

> I see.  Dragging the secondary selection seems to work here with the
> trivial patch below.  Can you try it?

I'm sorry, but it doesn't resolve the problem.

Binding [tool-bar mouse-movement] to mouse-drag-region still results in
the same error from mouse-minibuffer-track when the mouse is dragged
over the toolbar.

Thanks

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 >> Yes, but how does 'mouse-minibuffer-check' enter this picture?
 >
 > It's called by mouse-drag-track, with START-EVENT as its argument.

But is START-EVENT the problem here?

 >> I see.  Dragging the secondary selection seems to work here with the
 >> trivial patch below.  Can you try it?
 >
 > I'm sorry, but it doesn't resolve the problem.

The purpose of the patch is to allow dragging the secondary selection
with the mouse when the cursor crosses the tool bar on Lucid.  When,
during mouse tracking, we leave the initial window, we use an exit
strategy that samples the mouse position and scrolls the window
accordingly.  I'd first like to know whether it works for the secondary
selection.  If so, we should be able to fix 'mouse-drag-track' in a
similar way.

 > Binding [tool-bar mouse-movement] to mouse-drag-region still results in
 > the same error from mouse-minibuffer-track when the mouse is dragged
 > over the toolbar.

I'm afraid such binding won't help.  We just have to be able to enter
the part in 'mouse-drag-track' starting with

                (let ((mouse-row (cdr (cdr (mouse-position)))))

to be able to compare mouse-row with the top of the start window,
ignoring any binding.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

> The purpose of the patch is to allow dragging the secondary selection
> with the mouse when the cursor crosses the tool bar on Lucid.  When,
> during mouse tracking, we leave the initial window, we use an exit
> strategy that samples the mouse position and scrolls the window
> accordingly.  I'd first like to know whether it works for the secondary
> selection.  If so, we should be able to fix 'mouse-drag-track' in a
> similar way.

Thanks, with your explanation it does seem to work now, but if the mouse
is released over the toolbar then it seems to never stop tracking the
mouse, unless I click it again.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 > Thanks, with your explanation it does seem to work now, but if the mouse
 > is released over the toolbar then it seems to never stop tracking the
 > mouse, unless I click it again.

Maybe, I didn't check.  How about brute force like the below?

martin

diff --git a/src/keyboard.c b/src/keyboard.c
index bc6f97586d..ba625c4f77 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5122,7 +5122,8 @@ make_lispy_position (struct frame *f, Lisp_Object x, Lisp_Object y,
  #endif
        )
      {
-      posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
+      if (NILP (track_mouse))
+	posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
        /* Kludge alert: for mouse events on the tab bar and tool bar,
  	 keyboard.c wants the frame, not the special-purpose window
  	 we use to display those, and it wants frame-relative

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics <rudalics@gmx.at> writes:

> Maybe, I didn't check.  How about brute force like the below?
>
> martin
>
> diff --git a/src/keyboard.c b/src/keyboard.c
> index bc6f97586d..ba625c4f77 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -5122,7 +5122,8 @@ make_lispy_position (struct frame *f, Lisp_Object x, Lisp_Object y,
>  #endif
>        )
>      {
> -      posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
> +      if (NILP (track_mouse))
> +	posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
>        /* Kludge alert: for mouse events on the tab bar and tool bar,
>  	 keyboard.c wants the frame, not the special-purpose window
>  	 we use to display those, and it wants frame-relative

This seems to work.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 >> diff --git a/src/keyboard.c b/src/keyboard.c
 >> index bc6f97586d..ba625c4f77 100644
 >> --- a/src/keyboard.c
 >> +++ b/src/keyboard.c
 >> @@ -5122,7 +5122,8 @@ make_lispy_position (struct frame *f, Lisp_Object x, Lisp_Object y,
 >>   #endif
 >>         )
 >>       {
 >> -      posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
 >> +      if (NILP (track_mouse))
 >> +	posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
 >>         /* Kludge alert: for mouse events on the tab bar and tool bar,
 >>   	 keyboard.c wants the frame, not the special-purpose window
 >>   	 we use to display those, and it wants frame-relative
 >
 > This seems to work.

If nobody objects I'll push this to Emacs 28 in the next days.

Thanks, martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>,
>  50993@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 12 Oct 2021 10:12:01 +0200
> 
>  >> diff --git a/src/keyboard.c b/src/keyboard.c
>  >> index bc6f97586d..ba625c4f77 100644
>  >> --- a/src/keyboard.c
>  >> +++ b/src/keyboard.c
>  >> @@ -5122,7 +5122,8 @@ make_lispy_position (struct frame *f, Lisp_Object x, Lisp_Object y,
>  >>   #endif
>  >>         )
>  >>       {
>  >> -      posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
>  >> +      if (NILP (track_mouse))
>  >> +	posn = EQ (window_or_frame, f->tab_bar_window) ? Qtab_bar : Qtool_bar;
>  >>         /* Kludge alert: for mouse events on the tab bar and tool bar,
>  >>   	 keyboard.c wants the frame, not the special-purpose window
>  >>   	 we use to display those, and it wants frame-relative
>  >
>  > This seems to work.
> 
> If nobody objects I'll push this to Emacs 28 in the next days.

Rationale?  It means no mouse movement on the tool bar or tab bar will
ever be reported as such.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 >> If nobody objects I'll push this to Emacs 28 in the next days.
 >
 > Rationale?  It means no mouse movement on the tool bar or tab bar will
 > ever be reported as such.

When mouse tracking is enabled, yes.  As soon as people decide that they
want to track the mouse from or to the tool or tab bar or within it -
for example, to drag tabs from one position to another or to drag tool
bar icons from some window displaying all possible icons to the tool bar
or vice versa - we can make that check react to other special values
than 'dragging' or 'dropping'.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 50993@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 12 Oct 2021 16:25:08 +0200
> 
>  >> If nobody objects I'll push this to Emacs 28 in the next days.
>  >
>  > Rationale?  It means no mouse movement on the tool bar or tab bar will
>  > ever be reported as such.
> 
> When mouse tracking is enabled, yes.  As soon as people decide that they
> want to track the mouse from or to the tool or tab bar or within it -
> for example, to drag tabs from one position to another or to drag tool
> bar icons from some window displaying all possible icons to the tool bar
> or vice versa - we can make that check react to other special values
> than 'dragging' or 'dropping'.

Dragging tabs is already supported, I think?  Did you check that it
still works after that change?

Anyway, we should have a big FIXME comment near that code to document
what you say above.

And I'm not sure I understand: that single change with the
mouse-tracking condition is the only one needed to fix this bug's
original report?  Including when there's no tool bar and no tab bar,
only one of them, or both of them?

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

Possibly resending - the last attempt to send this apparently failed.

 > Dragging tabs is already supported, I think?  Did you check that it
 > still works after that change?

I don't see no tab dragging implemented anywhere.  Maybe Juri can tell
us more.  Are you sure you don't mean scrolling the tab-bar?

 > Anyway, we should have a big FIXME comment near that code to document
 > what you say above.

We can do that.  But before implementing something like tab dragging,
someone will have to find out how to handle tab-bar prefixes with the
keymap based 'mouse-drag-track'.  I bet that the first person to
implement mouse-dragging on the tab-bar will use 'track-mouse' and an
event based approach, side-stepping the current issue.  So IMHO the
thing that really needs a FIXME is 'mouse-drag-track'.

 > And I'm not sure I understand: that single change with the
 > mouse-tracking condition is the only one needed to fix this bug's
 > original report?  Including when there's no tool bar and no tab bar,
 > only one of them, or both of them?

It hopefully fixes all sorts of mouse dragging which are currently
broken including 'mouse-drag-and-drop-region'.  Testing all of them with
all builds and issues is beyond the scope of what I reasonably can do.
But I did test quite a few.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

>> Dragging tabs is already supported, I think?  Did you check that it
>> still works after that change?
>
> I don't see no tab dragging implemented anywhere.  Maybe Juri can tell
> us more.  Are you sure you don't mean scrolling the tab-bar?

Tab dragging is implemented in tab-bar.el with this:

  (define-key map [drag-mouse-1] 'tab-bar-mouse-move-tab)

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 >> I don't see no tab dragging implemented anywhere.  Maybe Juri can tell
 >> us more.  Are you sure you don't mean scrolling the tab-bar?
 >
 > Tab dragging is implemented in tab-bar.el with this:
 >
 >    (define-key map [drag-mouse-1] 'tab-bar-mouse-move-tab)

That's harmless because it doesn't use mouse-movement.  IIUC dragging
tabs from one frame to another is not supported (yet).  BTW the shape of
the mouse pointer should change while dragging tabs.  Currently there's
absolutely no feedback wrt what's going on.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, luangruo@yahoo.com,
>  monnier@iro.umontreal.ca, 50993@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 13 Oct 2021 10:36:55 +0200
> 
>  >> I don't see no tab dragging implemented anywhere.  Maybe Juri can tell
>  >> us more.  Are you sure you don't mean scrolling the tab-bar?
>  >
>  > Tab dragging is implemented in tab-bar.el with this:
>  >
>  >    (define-key map [drag-mouse-1] 'tab-bar-mouse-move-tab)
> 
> That's harmless because it doesn't use mouse-movement.  IIUC dragging
> tabs from one frame to another is not supported (yet).

OK, then please install your fix with the adjustments pointed out in
this discussion.

> BTW the shape of the mouse pointer should change while dragging
> tabs.  Currently there's absolutely no feedback wrt what's going on.

Yes, I said that much to Juri some time ago, but AFAIU he thinks it's
better than not having this at all.

Thanks.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

>> Tab dragging is implemented in tab-bar.el with this:
>>
>>    (define-key map [drag-mouse-1] 'tab-bar-mouse-move-tab)
>
> That's harmless because it doesn't use mouse-movement.

I confirm that your patch breaks nothing.

> IIUC dragging tabs from one frame to another is not supported (yet).

Yep, not yet.

> BTW the shape of the mouse pointer should change while dragging tabs.
> Currently there's absolutely no feedback wrt what's going on.

Please suggest how the shape of the mouse pointer could be changed
in [down-mouse-1], and restored in [drag-mouse-1].

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 > OK, then please install your fix with the adjustments pointed out in
 > this discussion.

Done, hopefully.  Maybe, in the light of Bug#51199 (which I consider as
something to unconditionally fix before the release), we find a better
solution.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 > I confirm that your patch breaks nothing.

Thanks.  I installed it meanwhile.  Does tab-dragging work on
mouse-capable TTYs?

 > Please suggest how the shape of the mouse pointer could be changed
 > in [down-mouse-1], and restored in [drag-mouse-1].

Have you tried setting a 'pointer' property on the entire text in the
tab-bar window for that while?  Honestly, I have never looked into how
the tab-bar is implemented.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, luangruo@yahoo.com,
>  monnier@iro.umontreal.ca, 50993@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 14 Oct 2021 11:13:33 +0200
> 
>  > I confirm that your patch breaks nothing.
> 
> Thanks.  I installed it meanwhile.  Does tab-dragging work on
> mouse-capable TTYs?

No, not AFAICT.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

>> Please suggest how the shape of the mouse pointer could be changed
>> in [down-mouse-1], and restored in [drag-mouse-1].
>
> Have you tried setting a 'pointer' property on the entire text in the
> tab-bar window for that while?  Honestly, I have never looked into how
> the tab-bar is implemented.

Do you mean adding 'mouse-face highlight' to tab strings?
It has no effect on the tab bar.  Maybe something is missing
in note_tab_bar_highlight?

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

 > Do you mean adding 'mouse-face highlight' to tab strings?
 > It has no effect on the tab bar.  Maybe something is missing
 > in note_tab_bar_highlight?

Probably.  Try the attached only "cursorily" tested patch.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar-drag-maybe.diff --]
[-- Type: text/x-patch; name="tab-bar-drag-maybe.diff", Size: 2292 bytes --]

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index ccecdbc044..162c721751 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -113,6 +113,8 @@ tab-bar-select-tab-modifiers
   :group 'tab-bar
   :version "27.1")

+(defvar tab-bar-drag-maybe)
+
 (defun tab-bar--define-keys ()
   "Install key bindings for switching between tabs if the user has configured them."
   (when tab-bar-select-tab-modifiers
@@ -236,6 +238,7 @@ tab-bar--key-to-number
    (t t)))

 (defun tab-bar--event-to-item (posn)
+  (setq tab-bar-drag-maybe nil)
   (if (posn-window posn)
       (let ((caption (car (posn-string posn))))
         (when caption
@@ -263,6 +266,7 @@ tab-bar-mouse-select-tab
   (interactive "e")
   (let* ((item (tab-bar--event-to-item (event-start event)))
          (tab-number (tab-bar--key-to-number (nth 0 item))))
+    (setq tab-bar-drag-maybe t)
     ;; Don't close the tab when clicked on the close button.
     ;; Let `tab-bar-mouse-close-tab-from-button' do this.
     (unless (nth 2 item)
@@ -331,6 +335,7 @@ tab-bar-mouse-context-menu

 (defun tab-bar-mouse-move-tab (event)
   (interactive "e")
+  (setq tab-bar-drag-maybe nil)
   (let ((from (tab-bar--key-to-number
                (nth 0 (tab-bar--event-to-item
                        (event-start event)))))
diff --git a/src/xdisp.c b/src/xdisp.c
index f802e89834..eb6e717a5b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -33411,7 +33411,13 @@ note_mouse_highlight (struct frame *f, int x, int y)
   if (EQ (window, f->tab_bar_window))
     {
       note_tab_bar_highlight (f, x, y);
-      return;
+      if (tab_bar_drag_maybe)
+	{
+	  cursor = FRAME_OUTPUT_DATA (f)->hand_cursor;
+	  goto set_cursor;
+	}
+      else
+	return;
     }
 #endif

@@ -35543,6 +35549,10 @@ syms_of_xdisp (void)
 mouse stays within the extent of a single glyph (except for images).  */);
   mouse_fine_grained_tracking = false;

+  DEFVAR_BOOL ("tab-bar-drag-maybe", tab_bar_drag_maybe,
+    doc: /* Non-nil when maybe dragging tab bar item.  */);
+  tab_bar_drag_maybe = false;
+
   DEFVAR_BOOL ("redisplay-skip-initial-frame", redisplay_skip_initial_frame,
     doc: /* Non-nil to skip redisplay in initial frame.
 The initial frame is not displayed anywhere, so skipping it is

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

>> Do you mean adding 'mouse-face highlight' to tab strings?
>> It has no effect on the tab bar.  Maybe something is missing
>> in note_tab_bar_highlight?
>
> Probably.  Try the attached only "cursorily" tested patch.

Thanks, this is much better!  Dragging is more nice with this indication.

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[martin rudalics]

 > Thanks, this is much better!  Dragging is more nice with this indication.

Feel free to peruse it at your like.

martin

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

>> Thanks, this is much better!  Dragging is more nice with this indication.
>
> Feel free to peruse it at your like.

Maybe it should be installed in emacs-28?

bug#50993: 29.0.50; Problems when dragging the mouse over the toolbar

[Juri Linkov]

close 50993 28.0.60
thanks

>> Thanks, this is much better!  Dragging is more nice with this indication.
>
> Feel free to peruse it at your like.

Thanks for the patch, now pushed and closed.