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

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

[Liang-Jie Lee]

As title. I think this might be useful for people who disable the external
border and use tab-bar as their status bar. I found there is option to
move the frame by draging header-line (the drag-with-header-line frame
parameter), so I think it's reasonable to also support something like
"drag-with-tab-bar-line" for tab-bar-mode users.



In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-06-21 built on debian
Repository revision: 09f17ac4752e18bf834d2f20ceef561cc516d917
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-mailutils --with-native-compilation --with-xwidgets
 --enable-link-time-optimization --with-xdbe=no 'CFLAGS=-march=native
 -O3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  async-bytecomp-package-mode: t
  show-paren-mode: t
  display-time-mode: t
  display-battery-mode: t
  mlscroll-mode: t
  recentf-mode: t
  delete-selection-mode: t
  electric-pair-mode: t
  global-so-long-mode: t
  savehist-mode: t
  save-place-mode: t
  windmove-mode: t
  winner-mode: t
  global-auto-revert-mode: t
  midnight-mode: t
  company-tng-mode: t
  global-company-mode: t
  company-mode: t
  minibuffer-depth-indicate-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/booaa/.emacs.d/elpa/transient-20210619.1100/transient hides /usr/local/share/emacs/28.0.50/lisp/transient

Features:
(shadow sort mail-extr emacsbug sendmail face-remap magit-submodule
magit-obsolete magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff
smerge-mode diff git-commit log-edit message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert
magit-margin magit-transient magit-process with-editor server magit-mode
transient magit-git magit-section magit-utils crm dash eieio-opt
speedbar ezimage dframe shortdoc text-property-search help-fns
radix-tree comp comp-cstr warnings rx tramp-archive tramp-gvfs
tramp-cache zeroconf thingatpt helm-elisp helm-files tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete comint ansi-color parse-time iso8601 time-date ls-lisp
helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp
helm-eval edebug backtrace find-func helm-info helm-utils helm-types
helm-help vc-git diff-mode vc-dispatcher misearch multi-isearch helm
async-bytecomp helm-global-bindings helm-easymenu helm-source
helm-multi-match helm-lib async paren time format-spec battery dbus xml
mlscroll recentf tree-widget wid-edit delsel elec-pair so-long savehist
saveplace move-text windmove winner ring autorevert filenotify midnight
company-tng company-keywords company-dabbrev-code company-dabbrev
company-files company-capf company pcase init init-misc init-dev
init-search init-completion mb-depth init-shell init-mail init-dired
init-buffer init-window init-editor edmacro kmacro init-ui cl-extra
help-mode zenburn-theme init-packages no-littering use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib early-init iso-transl tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 296566 220841)
 (symbols 48 22474 141)
 (strings 32 74701 33768)
 (string-bytes 1 2626507)
 (vectors 16 43820)
 (vector-slots 8 761082 425384)
 (floats 8 223 1035)
 (intervals 56 869 1021)
 (buffers 992 21))

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

[Juri Linkov]

> As title. I think this might be useful for people who disable the external
> border and use tab-bar as their status bar. I found there is option to
> move the frame by draging header-line (the drag-with-header-line frame
> parameter), so I think it's reasonable to also support something like
> "drag-with-tab-bar-line" for tab-bar-mode users.

I guess you meant tab-line, right?  Because the currently draggable
header-line corresponds to tab-line, not to tab-bar.  Whereas tab-bar
corresponds to tool-bar that is not draggable.

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

[Juri Linkov]

[Please keep posting to the public list.]

>>> As title. I think this might be useful for people who disable the external
>>> border and use tab-bar as their status bar. I found there is option to
>>> move the frame by draging header-line (the drag-with-header-line frame
>>> parameter), so I think it's reasonable to also support something like
>>> "drag-with-tab-bar-line" for tab-bar-mode users.
>>
>> I guess you meant tab-line, right?  Because the currently draggable
>> header-line corresponds to tab-line, not to tab-bar.  Whereas tab-bar
>> corresponds to tool-bar that is not draggable.
>
> No. I do mean tab-bar, the utility to store window configuration and switch
> between them.
>
> I propose adding draggable feature for tab-bar since I know many people are
> using it.
> For people using tab-bar-mode and disabling the frame title, it would be
> nice to move the frame by dragging the tab-bar.

The problem is that tab-bar is based on tool-bar, but the native tool-bar
doesn't support dragging.  So this feature will be difficult to implement.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 29 Jun 2021 11:30:47 +0300
> Cc: 49247@debbugs.gnu.org
> 
> > I propose adding draggable feature for tab-bar since I know many people are
> > using it.
> > For people using tab-bar-mode and disabling the frame title, it would be
> > nice to move the frame by dragging the tab-bar.
> 
> The problem is that tab-bar is based on tool-bar, but the native tool-bar
> doesn't support dragging.  So this feature will be difficult to implement.

I actually don't quite see how to implement it even if it wasn't hard:
dragging the frame by its title bar or the external border is
implemented in the window manager, not in Emacs.  What would be the
way of implementing something similar in Emacs?

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

[martin rudalics]

 > I actually don't quite see how to implement it even if it wasn't hard:
 > dragging the frame by its title bar or the external border is
 > implemented in the window manager, not in Emacs.  What would be the
 > way of implementing something similar in Emacs?

See section 30.4.3.7 Mouse Dragging Parameters of the Elisp manual.

martin

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

[Juri Linkov]

>> > I propose adding draggable feature for tab-bar since I know many people are
>> > using it.
>> > For people using tab-bar-mode and disabling the frame title, it would be
>> > nice to move the frame by dragging the tab-bar.
>> 
>> The problem is that tab-bar is based on tool-bar, but the native tool-bar
>> doesn't support dragging.  So this feature will be difficult to implement.
>
> I actually don't quite see how to implement it even if it wasn't hard:
> dragging the frame by its title bar or the external border is
> implemented in the window manager, not in Emacs.  What would be the
> way of implementing something similar in Emacs?

I don't know, I can't find any existing Emacs code that does something like
frame dragging.  But it seems this is not needed because many window managers
already support this feature where it's easy to drag the frame
after clicking anywhere in the frame while holding a modifier key.
So if no one has an idea how to implement the same in Emacs,
this request could be closed.

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

[Eli Zaretskii]

> Cc: 49247@debbugs.gnu.org, s930054123yaoyao@gmail.com
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 29 Jun 2021 15:16:59 +0200
> 
>  > I actually don't quite see how to implement it even if it wasn't hard:
>  > dragging the frame by its title bar or the external border is
>  > implemented in the window manager, not in Emacs.  What would be the
>  > way of implementing something similar in Emacs?
> 
> See section 30.4.3.7 Mouse Dragging Parameters of the Elisp manual.

Thanks.

So you are saying that the original problem already has a solution?

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

[Juri Linkov]

>> I actually don't quite see how to implement it even if it wasn't hard:
>> dragging the frame by its title bar or the external border is
>> implemented in the window manager, not in Emacs.  What would be the
>> way of implementing something similar in Emacs?
>
> See section 30.4.3.7 Mouse Dragging Parameters of the Elisp manual.

This is an impressive feature - it works like in window managers.

The only difference is that after trying

  (set-frame-parameter nil 'drag-with-header-line t)

then dragging is limited only to the screen boundaries
and doesn't allow dragging parts of the frame off the screen
(to leave frame partly visible) like window managers do.

Also can't drag by the mode-line with

  (set-frame-parameter nil 'drag-with-mode-line t)

but probably because it affects only frames without minibuffer window.

So it seems it should be possible to do the same for tab-line by implementing

  (set-frame-parameter nil 'drag-with-tab-line t)

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

[martin rudalics]

 >> See section 30.4.3.7 Mouse Dragging Parameters of the Elisp manual.
 >
 > Thanks.
 >
 > So you are saying that the original problem already has a solution?

What is the original problem?

martin

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

[martin rudalics]

 > This is an impressive feature - it works like in window managers.
 >
 > The only difference is that after trying
 >
 >    (set-frame-parameter nil 'drag-with-header-line t)
 >
 > then dragging is limited only to the screen boundaries
 > and doesn't allow dragging parts of the frame off the screen
 > (to leave frame partly visible) like window managers do.

This should be customizable via the `top-visible' and `bottom-visible'
parameters.  Note that dragging frames is mainly intended for child
frames - frames contained within another frame - which with all GNU
Linux window managers I know of are neither equipped with a title bar
nor with a border.  It's too easy to drag a child frame off the area of
its parent in a way that you can't recover it with the mouse - also
because in such case the mouse-sensitive regions of parent and child
frame overlap.  The default should keep you on the safe side.

 > Also can't drag by the mode-line with
 >
 >    (set-frame-parameter nil 'drag-with-mode-line t)
 >
 > but probably because it affects only frames without minibuffer window.

That's not a principal restriction.  But I considered it confusing to
allow dragging with a bar that is not located on top or bottom of the
containing frame.

 > So it seems it should be possible to do the same for tab-line by implementing
 >
 >    (set-frame-parameter nil 'drag-with-tab-line t)

It should be also possible to drag a frame with the tab bar.  Unless
dragging should conceptually have different semantics with tabs as, for
example, to drag them from left to right and vice versa on their bar or
line.

martin

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

[Eli Zaretskii]

> Cc: juri@linkov.net, 49247@debbugs.gnu.org, s930054123yaoyao@gmail.com
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 1 Jul 2021 09:53:12 +0200
> 
>  >> See section 30.4.3.7 Mouse Dragging Parameters of the Elisp manual.
>  >
>  > Thanks.
>  >
>  > So you are saying that the original problem already has a solution?
> 
> What is the original problem?

Quoting from the original report:

  As title. I think this might be useful for people who disable the
  external border and use tab-bar as their status bar. I found there
  is option to move the frame by draging header-line (the
  drag-with-header-line frame parameter), so I think it's reasonable
  to also support something like "drag-with-tab-bar-line" for
  tab-bar-mode users.

You explained that it is possible to drag such frames by the mode line
of the bottommost window, which provides solution for frames that have
no header line.

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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 49247@debbugs.gnu.org,
>  s930054123yaoyao@gmail.com
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 1 Jul 2021 09:54:49 +0200
> 
> It should be also possible to drag a frame with the tab bar.

That would require significant changes in how mouse clicks on the tab
bar are processed.  Currently, if the click is not on some glyph of
the tab-bar text, it is ignored.

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

[martin rudalics]

 >> What is the original problem?
 >
 > Quoting from the original report:
 >
 >    As title. I think this might be useful for people who disable the
 >    external border and use tab-bar as their status bar. I found there
 >    is option to move the frame by draging header-line (the
 >    drag-with-header-line frame parameter), so I think it's reasonable
 >    to also support something like "drag-with-tab-bar-line" for
 >    tab-bar-mode users.
 >
 > You explained that it is possible to drag such frames by the mode line
 > of the bottommost window, which provides solution for frames that have
 > no header line.

I've tried to implement now what the OP wanted - the parameter is called
`drag-with-tab-line'.

martin

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

[Juri Linkov]

> I've tried to implement now what the OP wanted - the parameter is called
> `drag-with-tab-line'.

I tried it out, and it works nicely.  Would it be possible also to
implement the same for `drag-with-tab-bar'?

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

[Juri Linkov]

>> It should be also possible to drag a frame with the tab bar.
>
> That would require significant changes in how mouse clicks on the tab
> bar are processed.  Currently, if the click is not on some glyph of
> the tab-bar text, it is ignored.

There were also user requests to change the mouse pointer shape
to ‘hand’ when the mouse pointer is over the tab-bar tabs,
the same way as currently the mouse pointer changes to ‘hand’
when it's over the tab-line tabs.

I guess this will also require significant changes in how
mouse mouse motion events on the tab-bar are processed?
Would it be possible to implement the same handling for the tab-bar
as it's already implemented for the tab-line?

BTW, during frame dragging, window managers change the mouse pointer to
‘hand’.  But Emacs frame dragging doesn't change the mouse pointer.
Is it possible to change the mouse pointer also while dragging the
frame from Emacs?

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

[Drew Adams]

> BTW, during frame dragging, window managers
> change the mouse pointer to ‘hand’.

I guess you must mean _some_ window managers.
I don't see that with MS Windows, for example.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: martin rudalics <rudalics@gmx.at>,  49247@debbugs.gnu.org,
>   s930054123yaoyao@gmail.com
> Date: Sun, 04 Jul 2021 23:37:21 +0300
> 
> There were also user requests to change the mouse pointer shape
> to ‘hand’ when the mouse pointer is over the tab-bar tabs,
> the same way as currently the mouse pointer changes to ‘hand’
> when it's over the tab-line tabs.
> 
> I guess this will also require significant changes in how
> mouse mouse motion events on the tab-bar are processed?

No, I think you need to change only a little in
note_tab_bar_highlight for this.

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

[martin rudalics]

 > BTW, during frame dragging, window managers change the mouse pointer to
 > ‘hand’.  But Emacs frame dragging doesn't change the mouse pointer.
 > Is it possible to change the mouse pointer also while dragging the
 > frame from Emacs?

I've tried to do that now.  Please have a look.

martin

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

[Juri Linkov]

>> BTW, during frame dragging, window managers change the mouse pointer to
>> ‘hand’.  But Emacs frame dragging doesn't change the mouse pointer.
>> Is it possible to change the mouse pointer also while dragging the
>> frame from Emacs?
>
> I've tried to do that now.  Please have a look.

Thanks, now it's better looking.  There is only small difference:
frame dragging displays a hand with the pointing index finger (hand_cursor),
but some window managers display a hand without fingers (closed_hand_cursor).
I guess there is no such icon in Emacs.

But there is a more serious problem: the implementation of
'drag-with-tab-line' now closes the tab even after just
clicking on it to select (not on the close button).
I can reproduce this only when one of tabs on the tab-line
contains an *info* buffer (maybe because it has the header-line?)

The problem doesn't exist after evaluating:
  (global-unset-key [tab-line down-mouse-1])
I haven't debugged it yet.

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

[martin rudalics]

 > But there is a more serious problem: the implementation of
 > 'drag-with-tab-line' now closes the tab even after just
 > clicking on it to select (not on the close button).
 > I can reproduce this only when one of tabs on the tab-line
 > contains an *info* buffer (maybe because it has the header-line?)
 >
 > The problem doesn't exist after evaluating:
 >    (global-unset-key [tab-line down-mouse-1])
 > I haven't debugged it yet.

I think the culprit is this binding

     (define-key map [tab-line mouse-2] 'tab-line-close-tab)

in `tab-line-tab-map' likely together with some queer mouse-1/mouse-2
mapping.  I'd suggest to don't do that, if possible.  Otherwise, we have
to dig further.

martin

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

[Juri Linkov]

> I think the culprit is this binding
>
>     (define-key map [tab-line mouse-2] 'tab-line-close-tab)
>
> in `tab-line-tab-map' likely together with some queer mouse-1/mouse-2
> mapping.  I'd suggest to don't do that, if possible.  Otherwise, we have
> to dig further.

The problem also can be fixed by removing this line from info.el
from Info-mode-map:

  (define-key map [follow-link] 'mouse-face)

Why buffer's mode keymap affects the behavior of clicking
on the tab-line?

1. Here is what 'C-h k' and clicking on the tab-line shows
   in normal case when mouse-1 selects the tab:

  "There were several key-sequences:

    <tab-line> <down-mouse-1> (translated from <down-mouse-1>) at that spot runs the command mouse-drag-tab-line
    <tab-line> <mouse-1> (translated from <mouse-1>) at that spot runs the command tab-line-select-tab

    <tab-line> <down-mouse-1> (translated from <down-mouse-1>) at that
    spot runs the command mouse-drag-tab-line (found in global-map)

    <tab-line> <mouse-1> (translated from <mouse-1>) at that spot runs the
    command tab-line-select-tab (found in tab-line-tab-map)"

2. Here is what 'C-h k' and clicking on the tab-line shows
   when mouse-1 closes the tab instead of selecting:

  "There were several key-sequences:

    <tab-line> <down-mouse-1> (translated from <down-mouse-1>) at that spot runs the command mouse-drag-tab-line
    <tab-line> <mouse-2> (translated from <mouse-1>) at that spot runs the command tab-line-close-tab

    Those are influenced by `mouse-1-click-follows-link'

    <tab-line> <down-mouse-1> (translated from <down-mouse-1>) at that
    spot runs the command mouse-drag-tab-line (found in global-map)

    <tab-line> <mouse-2> (translated from <mouse-1>) at that spot runs the
    command tab-line-close-tab (found in tab-line-tab-map)"

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.

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

[martin rudalics]

 > 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

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

[Drew Adams]

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

I'm not following this thread, and I can't speak
to what might be needed for mouse behavior on the
tab bar.

But in general it should (must) be the case that
users can continue to customize option
`mouse-1-click-follows-link' to nil, to get the
sane (and once default Emacs) behavior of mouse-1
acting differently from mouse-2 -- in particular
to let mouse-1 just set point (or drag), without
any fiddling with delays etc.

Emacs overriding that, to force mouse-1 on a link
to act like mouse-2 on a link, would be wrong, IMO.
(But again, maybe tab bar needs to be an exception
for some special reason.)

Apologies if my comment is off-topic.

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

[Juri Linkov]

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

Please don't revert your changes: 'drag-with-tab-line' is a valid feature.

> or you give up on binding mouse-1 and mouse-2 to different actions.

I can't give up on binding mouse-2 to closing the tab
because this is what browsers do where mouse-2 closes the tab.

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

Drew suggested to make an exception for the tab-bar.
This could solve the problem when the exception
will be added somewhere in mouse--click-1-maybe-follows-link.

> BTW, I think that the mouse wheel should scroll the tab-line,
> if applicable.

The mouse wheel already scrolls the tab-line when it's long enough.

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

[Drew Adams]

> Drew suggested to make an exception for the tab-bar.

I don't think I did that at all.  What did I say
that gave that impression?  I have no idea whether
tab-bar should be an exception to anything wrt
`mouse-1' or `mouse-2'.

I said up front, as a caveat:

  I'm not following this thread, and I can't speak
                                       ^^^^^^^^^^^
  to what might be needed for mouse behavior on the
  tab bar.

Other than that, I tried to say that, in general,
for mouse clicks on links, option
`mouse-1-click-follows-link' should govern whether
`mouse-1' follows a link (which `mouse-2' does
anyway).

Users (such as myself) who don't want `mouse-1'
to follow links can customize the option to `nil'.
(IMO it should be `nil' by default, but that was
overruled long ago.)

I tried to say that the option should in general
be respected for link clicks (why not?).  E.g.,
Emacs should not force `mouse-1' on a link to act
like `mouse-2' (disrespecting user customization
of the option to `nil').

I did end by repeating parenthetically that I
can't speak to any special behavior that might be
needed for the tab bar:

  (But again, maybe tab bar needs to be an
  exception for some special reason.)

I certainly wasn't claiming that it needs to be
an exception.  The thrust of my message was that
we _shouldn't want_ exceptional behavior that
disrespects the option.  But if an exception is
needed for some good reason, so be it.

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

[Juri Linkov]

>> But there is a more serious problem: the implementation of
>> 'drag-with-tab-line' now closes the tab even after just
>> clicking on it to select (not on the close button).
>> I can reproduce this only when one of tabs on the tab-line
>> contains an *info* buffer (maybe because it has the header-line?)
>>
>> The problem doesn't exist after evaluating:
>>    (global-unset-key [tab-line down-mouse-1])
>> I haven't debugged it yet.
>
> I think the culprit is this binding
>
>     (define-key map [tab-line mouse-2] 'tab-line-close-tab)

This is fixed now in tab-line.el by using the property 'follow-link'
with the value 'ignore'.