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

Previous Next

Full log

Message #68 received at 49247 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 49247 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 s930054123yaoyao <at> gmail.com
Subject: Re: bug#49247: 28.0.50; [Feature Request] Make tab-bar-lines dragable
Date: Wed, 7 Jul 2021 09:31:16 +0200

> 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

Previous Next

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