bug#49247: 28.0.50; [Feature Request] Make tab-bar-lines dragable

[martin rudalics <rudalics@gmx.at>]

 > The problem also can be fixed by removing this line from info.el
 > from Info-mode-map:
 >
 >    (define-key map [follow-link] 'mouse-face)

The same would have to be done at least for *Backtrace* where I've seen
the same problem.  And there are lots of other modes that use the above
idiom, I haven't looked into them.

 > Why buffer's mode keymap affects the behavior of clicking
 > on the tab-line?
[...]
 > The difference is that in the broken case it says:
 >
 >    "Those are influenced by `mouse-1-click-follows-link'"
 >
 > and translates <mouse-1> to <mouse-2>, where <mouse-2> is a valid
 > binding that closes the tab.  But translating <mouse-1> to <mouse-2>
 > is a bug, I don't know how to fix it.

It might happen in `mouse--click-1-maybe-follows-link' but that is
written in terms of `pcase' which I cannot read fluently.  Honestly,
key translations are a mystery to me.

I see two possibilities to fix this without further hassle.  Either I
revert my changes or you give up on binding mouse-1 and mouse-2 to
different actions.  I think that the mouse-2 binding at hand is not
useful because not all people can use it reliably (for example here the
scroll wheel may always slip slightly before pressing it) and all your
remaining keymaps bind mouse-1 and mouse-2 to the same action.  BTW, I
think that the mouse wheel should scroll the tab-line, if applicable.

martin