tab-bar: Defining another mouse-button binding?

tab-bar: Defining another mouse-button binding?

[Adam Porter]

Hi Juri, et al,

I've been trying to bind other mouse buttons, like mouse-2, to different
commands on the tab-bar tabs, but I've not been able to figure out how.
The comments at the top of tab-bar.el say:

;; The normal global binding for [tab-bar] (below) uses the value of
;; `tab-bar-map' as the actual keymap to define the tab bar.  Modes may
;; either bind items under the [tab-bar] prefix key of the local map to
;; add to the global bar or may set `tab-bar-map' buffer-locally to
;; override it.

I may be just missing some knowledge, but despite my best efforts, I
wasn't able to understand this.  From what I can tell by reading the
source code, the tab-bar tabs are actually stored as a keymap in the
variable tab-bar-map, which is recreated on every redisplay; so that
variable is not actually a user-modifiable keymap that can be used to
assign new actions to clicks on the tabs.

The function `tab-bar--format-tab' (unfortunately, lacking a docstring,
despite its apparently important purpose) seems to construct a
keymap-like or binding-like structure (I'm not an expert on keymaps),
and it inlines interactive lambdas for the mouse click actions (though
it doesn't specify mouse-1, and "C-h k [mouse-1]" on the tab bar
indicates that it's mapped to `ignore', so it's not obvious how that
works).

I guess this unconventional system is necessary for performance reasons,
and it seems to work well.  But does this mean that I can't bind
additional mouse-click actions on the tabs?  Or am I missing something
obvious?  :)

Thanks,
Adam

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

> I guess this unconventional system is necessary for performance reasons,
> and it seems to work well.  But does this mean that I can't bind
> additional mouse-click actions on the tabs?  Or am I missing something
> obvious?  :)

Indeed, you are missing that this feature is already implemented
in the branch 'feature/tab-bar-events' and waiting for a review
in bug#41343.  But I guess that everything is ok, so I'll merge it
to master now.

Re: tab-bar: Defining another mouse-button binding?

[Adam Porter]

Hi Juri,

Juri Linkov <juri@linkov.net> writes:

>> I guess this unconventional system is necessary for performance reasons,
>> and it seems to work well.  But does this mean that I can't bind
>> additional mouse-click actions on the tabs?  Or am I missing something
>> obvious?  :)
>
> Indeed, you are missing that this feature is already implemented
> in the branch 'feature/tab-bar-events' and waiting for a review
> in bug#41343.  But I guess that everything is ok, so I'll merge it
> to master now.

What an interesting coincidence in timing.  :)  I read through that
report, and it looks like you did a very thorough job.  Thanks.  I think
the context menu will be a great feature in Emacs 28.  Now I'll just
have to figure out how to add entries to it...

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

>>> I guess this unconventional system is necessary for performance reasons,
>>> and it seems to work well.  But does this mean that I can't bind
>>> additional mouse-click actions on the tabs?  Or am I missing something
>>> obvious?  :)
>>
>> Indeed, you are missing that this feature is already implemented
>> in the branch 'feature/tab-bar-events' and waiting for a review
>> in bug#41343.  But I guess that everything is ok, so I'll merge it
>> to master now.
>
> What an interesting coincidence in timing.  :)

Lucky coincidence - you asked for a feature, and in a moment it's done :)

> I read through that report, and it looks like you did a very thorough
> job.  Thanks.  I think the context menu will be a great feature in
> Emacs 28.  Now I'll just have to figure out how to add entries to it...

Thanks, any feedback would be greatly appreciated.

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

>> Indeed, you are missing that this feature is already implemented
>> in the branch 'feature/tab-bar-events' and waiting for a review
>> in bug#41343.  But I guess that everything is ok, so I'll merge it
>> to master now.
>
> What an interesting coincidence in timing.  :)  I read through that
> report, and it looks like you did a very thorough job.  Thanks.  I think
> the context menu will be a great feature in Emacs 28.  Now I'll just
> have to figure out how to add entries to it...

Now the branch 'feature/tab-bar-events' is merged to master.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 09 Sep 2021 10:53:15 +0300
> Cc: emacs-devel@gnu.org
> 
> Now the branch 'feature/tab-bar-events' is merged to master.

Thanks.  I tried this on MS-Windows, using your previous suggestions:

> What remains to do is to test it on Windows.  Could you please try
> on Windows GUI and on Windows console to use mouse-1 to select a tab,

Works

> to click mouse-1 a close button to close it

works

> to drag a tab by mouse-1

works, but feels strange, because we don't really drag the button: it
is never shown in an intermediate position while dragging.  I wonder
whether we should advertise such a strange "dragging".

> to click mouse-2 to close the clicked tab

works

> mouse-3 to pop up the context menu and select "Close"

works, but on TTY frames the menu is only shown on down-mouse-3, as
everywhere else with context menus.

> and also wheel-left/wheel-right to switch to the next/previous tab,
> and S-wheel-left/wheel-right to move the tab.

This doesn't work, neither on GUI frames nor on TTY frames.  I get an
error message about "<nil> <mouse-wheel> is undefined".

Thanks again for your work in this area.

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

>> to drag a tab by mouse-1
>
> works, but feels strange, because we don't really drag the button: it
> is never shown in an intermediate position while dragging.  I wonder
> whether we should advertise such a strange "dragging".

There is no indication during dragging, and currently I have no idea
how to shown an intermediate indication, but at the end it works,
so maybe this could be explained in the documentation.

>> and also wheel-left/wheel-right to switch to the next/previous tab,
>> and S-wheel-left/wheel-right to move the tab.
>
> This doesn't work, neither on GUI frames nor on TTY frames.  I get an
> error message about "<nil> <mouse-wheel> is undefined".

Does the mouse wheel work on a tab-line?  tab-line has such bindings
for Windows:

  (global-set-key [tab-line mouse-4]    'tab-line-hscroll-left)
  (global-set-key [tab-line mouse-5]    'tab-line-hscroll-right)
  (global-set-key [tab-line wheel-up]   'tab-line-hscroll-left)
  (global-set-key [tab-line wheel-down] 'tab-line-hscroll-right)
  (global-set-key [tab-line wheel-left] 'tab-line-hscroll-left)
  (global-set-key [tab-line wheel-right] 'tab-line-hscroll-right)

that were copied to tab-bar-map.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: adam@alphapapa.net,  emacs-devel@gnu.org
> Date: Thu, 09 Sep 2021 21:58:49 +0300
> 
> >> to drag a tab by mouse-1
> >
> > works, but feels strange, because we don't really drag the button: it
> > is never shown in an intermediate position while dragging.  I wonder
> > whether we should advertise such a strange "dragging".
> 
> There is no indication during dragging, and currently I have no idea
> how to shown an intermediate indication, but at the end it works,
> so maybe this could be explained in the documentation.

What would you like to explain there?

> >> and also wheel-left/wheel-right to switch to the next/previous tab,
> >> and S-wheel-left/wheel-right to move the tab.
> >
> > This doesn't work, neither on GUI frames nor on TTY frames.  I get an
> > error message about "<nil> <mouse-wheel> is undefined".
> 
> Does the mouse wheel work on a tab-line?

No, it doesn't, AFAICT.

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

>> >> to drag a tab by mouse-1
>> >
>> > works, but feels strange, because we don't really drag the button: it
>> > is never shown in an intermediate position while dragging.  I wonder
>> > whether we should advertise such a strange "dragging".
>> 
>> There is no indication during dragging, and currently I have no idea
>> how to shown an intermediate indication, but at the end it works,
>> so maybe this could be explained in the documentation.
>
> What would you like to explain there?

That there is no indication during dragging, but at the point of
releasing the mouse button, the tab is moved here.

>> >> and also wheel-left/wheel-right to switch to the next/previous tab,
>> >> and S-wheel-left/wheel-right to move the tab.
>> >
>> > This doesn't work, neither on GUI frames nor on TTY frames.  I get an
>> > error message about "<nil> <mouse-wheel> is undefined".
>>
>> Does the mouse wheel work on a tab-line?
>
> No, it doesn't, AFAICT.

Then could you please send both event names of <mouse-wheel>
for both directions of mouse wheel scrolling.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: adam@alphapapa.net,  emacs-devel@gnu.org
> Date: Thu, 09 Sep 2021 22:19:34 +0300
> 
> >> >> to drag a tab by mouse-1
> >> >
> >> > works, but feels strange, because we don't really drag the button: it
> >> > is never shown in an intermediate position while dragging.  I wonder
> >> > whether we should advertise such a strange "dragging".
> >> 
> >> There is no indication during dragging, and currently I have no idea
> >> how to shown an intermediate indication, but at the end it works,
> >> so maybe this could be explained in the documentation.
> >
> > What would you like to explain there?
> 
> That there is no indication during dragging, but at the point of
> releasing the mouse button, the tab is moved here.

That doesn't need to be explained, people can see it.  I just don't
think we can call this "dragging the tabs", because that's not how
this looks in other applications, and people will be disappointed.

> >> >> and also wheel-left/wheel-right to switch to the next/previous tab,
> >> >> and S-wheel-left/wheel-right to move the tab.
> >> >
> >> > This doesn't work, neither on GUI frames nor on TTY frames.  I get an
> >> > error message about "<nil> <mouse-wheel> is undefined".
> >>
> >> Does the mouse wheel work on a tab-line?
> >
> > No, it doesn't, AFAICT.
> 
> Then could you please send both event names of <mouse-wheel>
> for both directions of mouse wheel scrolling.

I don't understand: I just told you, above, what events are sent in
this case.  is that not what you are asking about?

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

> That doesn't need to be explained, people can see it.  I just don't
> think we can call this "dragging the tabs", because that's not how
> this looks in other applications, and people will be disappointed.

Maybe then "moving the tabs"?

>> >> >> and also wheel-left/wheel-right to switch to the next/previous tab,
>> >> >> and S-wheel-left/wheel-right to move the tab.
>> >> >
>> >> > This doesn't work, neither on GUI frames nor on TTY frames.  I get an
>> >> > error message about "<nil> <mouse-wheel> is undefined".
>> >>
>> >> Does the mouse wheel work on a tab-line?
>> >
>> > No, it doesn't, AFAICT.
>>
>> Then could you please send both event names of <mouse-wheel>
>> for both directions of mouse wheel scrolling.
>
> I don't understand: I just told you, above, what events are sent in
> this case.  is that not what you are asking about?

Maybe I'm missing something but I see only <mouse-wheel>.
I don't understand how the same event can be used to scroll
in both directions.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: adam@alphapapa.net,  emacs-devel@gnu.org
> Date: Fri, 10 Sep 2021 09:36:43 +0300
> 
> >> >> > This doesn't work, neither on GUI frames nor on TTY frames.  I get an
> >> >> > error message about "<nil> <mouse-wheel> is undefined".
> >> >>
> >> >> Does the mouse wheel work on a tab-line?
> >> >
> >> > No, it doesn't, AFAICT.
> >>
> >> Then could you please send both event names of <mouse-wheel>
> >> for both directions of mouse wheel scrolling.
> >
> > I don't understand: I just told you, above, what events are sent in
> > this case.  is that not what you are asking about?
> 
> Maybe I'm missing something but I see only <mouse-wheel>.

Sorry, my bad.  The real message text is

  <nil> <wheel-down> is undefined

and similarly for wheel-up.

Re: tab-bar: Defining another mouse-button binding?

[Juri Linkov]

> The real message text is
>
>   <nil> <wheel-down> is undefined
>
> and similarly for wheel-up.

Thanks for clarification.  Actually, there is already such bindings:

    (define-key map [wheel-up]    'tab-previous)
    (define-key map [wheel-down]  'tab-next)

So the problem is that it emits <nil> instead of <tab-bar>.
And as I understand, the same <nil> is emitted on the tab-line
instead of <tab-line> on GUI frames and on TTY frames.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: adam@alphapapa.net,  emacs-devel@gnu.org
> Date: Fri, 10 Sep 2021 19:19:39 +0300
> 
> > The real message text is
> >
> >   <nil> <wheel-down> is undefined
> >
> > and similarly for wheel-up.
> 
> Thanks for clarification.  Actually, there is already such bindings:
> 
>     (define-key map [wheel-up]    'tab-previous)
>     (define-key map [wheel-down]  'tab-next)
> 
> So the problem is that it emits <nil> instead of <tab-bar>.
> And as I understand, the same <nil> is emitted on the tab-line
> instead of <tab-line> on GUI frames and on TTY frames.

Yes, that's the problem.

Re: tab-bar: Defining another mouse-button binding?

[martin rudalics]

 >> The real message text is
 >>
 >>    <nil> <wheel-down> is undefined
 >>
 >> and similarly for wheel-up.
 >
 > Thanks for clarification.  Actually, there is already such bindings:
 >
 >      (define-key map [wheel-up]    'tab-previous)
 >      (define-key map [wheel-down]  'tab-next)
 >
 > So the problem is that it emits <nil> instead of <tab-bar>.
 > And as I understand, the same <nil> is emitted on the tab-line
 > instead of <tab-line> on GUI frames and on TTY frames.

With mouse wheel scrolls one has to be always prepared that the scroll
is intended for one window while the mouse is positioned anywhere on
your frame.  ISTR a problem with multiple Windows windows - I had an
external application that determined which window it should scroll from
the position of the mouse and the nearest scroll bar widget it found.
Something like `mouse-wheel-follow-mouse' on a widget base ...  Windows
without scroll bar lost in this regard.

BTW `mouse-wheel-down-event' and `mouse-wheel-up-event' are customizable
so it should work by setting these to mouse-4 and mouse-5.

martin

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> Cc: adam@alphapapa.net, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 11 Sep 2021 10:39:01 +0200
> 
>  >> The real message text is
>  >>
>  >>    <nil> <wheel-down> is undefined
>  >>
>  >> and similarly for wheel-up.
>  >
>  > Thanks for clarification.  Actually, there is already such bindings:
>  >
>  >      (define-key map [wheel-up]    'tab-previous)
>  >      (define-key map [wheel-down]  'tab-next)
>  >
>  > So the problem is that it emits <nil> instead of <tab-bar>.
>  > And as I understand, the same <nil> is emitted on the tab-line
>  > instead of <tab-line> on GUI frames and on TTY frames.
> 
> With mouse wheel scrolls one has to be always prepared that the scroll
> is intended for one window while the mouse is positioned anywhere on
> your frame.

That's not the problem here, AFAICT.  The problem here, at least for
GUI frames, is that the code Juri wrote supports only mice that report
wheel events as button events.  That code doesn't support mice which
report true mouse-wheel events (so I guess NS is also affected?).  I'm
working on a fix.

I didn't yet look at the TTY frame case.

Re: tab-bar: Defining another mouse-button binding?

[Eli Zaretskii]

> Date: Sat, 11 Sep 2021 12:39:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: adam@alphapapa.net, emacs-devel@gnu.org, juri@linkov.net
> 
> > With mouse wheel scrolls one has to be always prepared that the scroll
> > is intended for one window while the mouse is positioned anywhere on
> > your frame.
> 
> That's not the problem here, AFAICT.  The problem here, at least for
> GUI frames, is that the code Juri wrote supports only mice that report
> wheel events as button events.  That code doesn't support mice which
> report true mouse-wheel events (so I guess NS is also affected?).  I'm
> working on a fix.
> 
> I didn't yet look at the TTY frame case.

OK, I think I fixed this: tab-bar scrolling should now work for mice
which report mouse-wheel events.

I recalled the problem with supporting that on MS-Windows consoles:
the coordinates reported by console APIs for the mouse-scroll events
is relative to the top-level corner of the display screen, not that of
the console window (see the comment in w32inevt.c).  This, of course,
make the coordinates inappropriate for detecting scrolling of the tab
bar and tab line on MS-Windows consoles, so they don't work there.  If
someone knows how to fix this, I'm all ears.