GNU bug report logs - #49247
28.0.50; [Feature Request] Make tab-bar-lines dragable

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Juri Linkov <juri <at> linkov.net>
Cc: "49247 <at> debbugs.gnu.org" <49247 <at> debbugs.gnu.org>, "s930054123yaoyao <at> gmail.com" <s930054123yaoyao <at> gmail.com>
Subject: bug#49247: [External] : bug#49247: 28.0.50; [Feature Request] Make tab-bar-lines dragable
Date: Wed, 7 Jul 2021 14:02:48 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.