From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75219: 31.0.50; mouse-2 mode-line binding overridden by mouse-1-click-follows-link Date: Sun, 05 Jan 2025 17:17:45 +0200 Message-ID: <86zfk570iu.fsf@gnu.org> References: <87o70sbegu.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13411"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75219@debbugs.gnu.org To: Visuwesh , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 16:18:22 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUSOS-0003H8-Sf for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 16:18:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUSOE-0001o0-E7; Sun, 05 Jan 2025 10:18:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUSOB-0001nX-7C for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 10:18:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUSOA-0002Bx-N7 for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 10:18:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=c31OrZ23gdVin7EFFQcsRCmf8cYkg1KoCt9ypc4kwTs=; b=LfPIxmpN/xLhIq58tZVjeRdUPMghWVoCdxfHT+w7E84duYw6cnIv3VJGHT+YC4gO2fE/uZoZuhBDj3Smb8dErd/e72QLYLSxMTP/5yeV7e4tk/4o6t630sqAh5Dwjc4rK67fILC6uazrOav4dlx7tOkK4BJlOz71Ld5s3eXeB70neJuHJooxRLbNLBDzA65q/NllnWPzLEsoRlV8cDWtz9kLT02Rxc0F+oAV3bWlv+T9ZskUpOaE5mnIdld3Iw11YzjCEFYzKFgylIsh1U19RFfOQwg0qc2H8TInEjYkPMgEj67W4x5M3U7gD9oAJHlt2l0gbGcaOld3VuVDGoEzmA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUSOA-0000ly-Bk for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 10:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 15:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75219 X-GNU-PR-Package: emacs Original-Received: via spool by 75219-submit@debbugs.gnu.org id=B75219.17360902802961 (code B ref 75219); Sun, 05 Jan 2025 15:18:02 +0000 Original-Received: (at 75219) by debbugs.gnu.org; 5 Jan 2025 15:18:00 +0000 Original-Received: from localhost ([127.0.0.1]:34824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUSO7-0000lg-GN for submit@debbugs.gnu.org; Sun, 05 Jan 2025 10:17:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38742) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUSO5-0000lR-DG for 75219@debbugs.gnu.org; Sun, 05 Jan 2025 10:17:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUSNz-0002BJ-Pa; Sun, 05 Jan 2025 10:17:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=c31OrZ23gdVin7EFFQcsRCmf8cYkg1KoCt9ypc4kwTs=; b=kRDISEAosGqj TD3tVe8Hs4yhzXHtvBWw7w9Ulp80rfxfANU/BW8caWWOCU8mn98lXcPhnz1kqUWEU++rB0lzG56RZ jM0hhOSpvC0dN6ukH0Uvz8XJcKj6lT64oFFagF/G30EZJg62yN3KinOTous1XDIxYBqOjEQDtI7GH IlYCVV+FZ+FrmiXPIIA3SmicoIcH4HKxjveuSaU7i3MrVEiXX/kLCiiVmclynoKCg53g6GciNBdjx lf60yA9nL7yTWDUrmWSyKoSkxmqMmX5Lzsq62jvRQfOiD1HODx4koD2/c7Y6sUS0j1DzmeBPUgD9N I5BEBPhBPjDxpWtkxO8exA==; In-Reply-To: <87o70sbegu.fsf@gmail.com> (message from Visuwesh on Tue, 31 Dec 2024 11:07:05 +0530) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298570 Archived-At: > From: Visuwesh > Date: Tue, 31 Dec 2024 11:07:05 +0530 > > When the point is over a character with a keymap that has `follow-link', > mode-line mouse-1 binding is translated to mode-line mouse-2 binding. > > To reproduce, > > 1. emacs -Q > 2. M-: (define-key mode-line-buffer-identification-keymap [mode-line mouse-2] #'mouse-buffer-menu) RET > 3. M-s M-w something RET > 4. Move the point over to any link > 5. Click the buffer name in the mode-line with mouse-1 > 6. Observe how mouse-buffer-menu is executed instead of changing the > buffer This happens because key-binding considers the local keymap at point even if its POSITION argument specifies a mouse click in a completely different location (in this case: on the mode line). For example, try M-: (key-binding [follow-link] nil t (list (selected-window) 'mode-line '(82 . 549) 10000)) RET Evaluate this in EWW buffer, once with point on a link and another time with point on a regular character. In the second case this will return nil, but in the first case it will return 'mouse-face', an indication that the click should follow a link. The result of this is that mouse-on-link-p returns non-nil, and mouse--click-1-maybe-follows-link decides we need to follow the link. The reason why key-binding considers the local keymap at point is this part of current-active-maps (which key-binding calls): ptrdiff_t pt = click_position (position); <<<<<<<<<<<<<<<<<<<<< /* This usually returns the buffer's local map, but that can be overridden by a `local-map' property. */ Lisp_Object local_map = get_local_map (pt, current_buffer, Qlocal_map); /* This returns nil unless there is a `keymap' property. */ Lisp_Object keymap = get_local_map (pt, current_buffer, Qkeymap); Lisp_Object otlp = KVAR (current_kboard, Voverriding_terminal_local_map); and click_position does this: static ptrdiff_t click_position (Lisp_Object position) { EMACS_INT pos = (FIXNUMP (position) ? XFIXNUM (position) : MARKERP (position) ? marker_position (position) : PT); if (! (BEGV <= pos && pos <= ZV)) args_out_of_range (Fcurrent_buffer (), position); return pos; } So if POSITION is a mouse click event, click_position will always return the position of point. It is easy to prevent this strange result from click_position by ignoring local map at POSITION which is a list, but I don't know how much code out there relies on this "fallback" to point. Stefan, any ideas or suggestions?