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: Tue, 07 Jan 2025 20:57:30 +0200 Message-ID: <86ed1e4fl1.fsf@gnu.org> References: <87o70sbegu.fsf@gmail.com> <86zfk570iu.fsf@gnu.org> <86ikqt6qmf.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75219@debbugs.gnu.org, visuweshm@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 07 19:58:35 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 1tVEmh-0009BW-1p for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jan 2025 19:58:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVEmD-0007Se-I0; Tue, 07 Jan 2025 13:58:05 -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 1tVEmB-0007PG-Ot for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 13:58:04 -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 1tVEmB-0004LN-GI for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 13:58:03 -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=KaOtlyfQQV+m2nXyICLDMDDThWzsaWZyMgwFykA21vY=; b=GipPNCG3oZcFoE38spMleDWO5/qts0HCpdMOo/doj/mFcMoF2GvpFN4K4vxK4l1XSp0ZTho0TxM3xIXjz33lvUm7NNZ7Bzx/5IXy6ELweH17LK8fwPxFOWjeU85OubSZ6sTsX8rQ4t1boXhJ4tgz2v072ryVcL/PzrsWdDtoX+JoLq1OzChZKHgZAX/Xs0C6YhKc17WiE5OL8U9f79dqvttic0VZYN0OX7pigTohvOx6BuMsRzBhTOALgi8y7CsuFr/yvhalrivz+ELhaJbp0LbnKKpPZH9nf7d7Ezn3EQd5HHWIjKaJEJCKy5WZQnNxB355ny4HPd8yIybQyf1oKg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVEmA-0007yn-FE for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2025 13:58: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: Tue, 07 Jan 2025 18:58: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.173627627730654 (code B ref 75219); Tue, 07 Jan 2025 18:58:02 +0000 Original-Received: (at 75219) by debbugs.gnu.org; 7 Jan 2025 18:57:57 +0000 Original-Received: from localhost ([127.0.0.1]:44673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVEm4-0007yK-Nm for submit@debbugs.gnu.org; Tue, 07 Jan 2025 13:57:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56070) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVEm2-0007y2-99 for 75219@debbugs.gnu.org; Tue, 07 Jan 2025 13:57:55 -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 1tVElw-0004KC-Nh; Tue, 07 Jan 2025 13:57:48 -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=O1SAcr1B+PXiey0pperdUG/Crd1AwZFKvCQ/GVivB58=; b=ILG5XIRRnP+U uLOaLhsksukfO1LokdeDDaAbVEnWn7SORXRdATdT1uFFz/53KhYRQuLi7TR3mu4sj42PlCIX7tstR uidJeZq7zzHMGWPnHmKUN5sSsMfx5DxhK7YICY0FLQLyblXni1pRdWA3XQWYy+bFskf7RBxz8wn1n 4+okmebd/SVVsLzJK+hVlUrXvKyHU1NG52DA5Hs/ghPf6Dodq/x/sLcpqQw5TyJINZ5L4VfbxZDrB 9gx67VXSxLoFeXuZNcz2xO57vv5WJdVRNTuffbGSQ6r+RS3M6xWvVpgxOZZZjMNWpds82UKySapbD uKNp2oU6OvvgeyXF/ciVAA==; In-Reply-To: (message from Stefan Monnier on Sun, 05 Jan 2025 16:51:03 -0500) 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:298741 Archived-At: > From: Stefan Monnier > Cc: visuweshm@gmail.com, 75219@debbugs.gnu.org > Date: Sun, 05 Jan 2025 16:51:03 -0500 > > > Also, for clicks on mode line there will be no buffer position in the > > event, and then it sounds like your patch will again fall back on > > returning point? I thought that clicks on the mode line should > > examine local keymaps only on the mode-line's string at the click, > > don't you agree? > > +1 Wait a minute... we already have in current-active-maps code to support this, right below the call to click_position: if (CONSP (position)) { Lisp_Object string = POSN_STRING (position); /* For a mouse click, get the local text-property keymap of the place clicked on, rather than point. */ if (POSN_INBUFFER_P (position)) { Lisp_Object pos = POSN_BUFFER_POSN (position); if (FIXNUMP (pos) && XFIXNUM (pos) >= BEG && XFIXNUM (pos) <= Z) { local_map = get_local_map (XFIXNUM (pos), current_buffer, Qlocal_map); keymap = get_local_map (XFIXNUM (pos), current_buffer, Qkeymap); } } /* If on a mode line string with a local keymap, or for a click on a string, i.e. overlay string or a string displayed via the `display' property, consider `local-map' and `keymap' properties of that string. */ if (CONSP (string) && STRINGP (XCAR (string))) { Lisp_Object pos = XCDR (string); string = XCAR (string); if (FIXNUMP (pos) && XFIXNUM (pos) >= 0 && XFIXNUM (pos) < SCHARS (string)) { Lisp_Object map = Fget_text_property (pos, Qlocal_map, string); if (!NILP (map)) local_map = map; map = Fget_text_property (pos, Qkeymap, string); if (!NILP (map)) keymap = map; } } } The "STRINGP (XCAR (string))" case is ours. The problem there is that it overrides the previous values of local_map and keymap only if the corresponding properties on the string are non-nil. I think we should override them unconditionally, since the values calculated from point are irrelevant when the click was on a mode line. And indeed, with the patch below (which basically does the same with properties on a string as we already do with properties on buffer text), the bug is solved. My only hesitation is whether we should do this with _any_ string or only with mode-line and header-line strings. If the string is a display string or an overlay string, and the keymap properties of that string at the click are nil, should we fall back on the keymap properties at point, or should we ignore the buffer properties and behave as if there are no keymap properties at the click? diff --git a/src/keymap.c b/src/keymap.c index c0f49a7..4defe3a 100644 --- a/src/keymap.c +++ b/src/keymap.c @@ -1745,13 +1745,8 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps, && XFIXNUM (pos) >= 0 && XFIXNUM (pos) < SCHARS (string)) { - Lisp_Object map = Fget_text_property (pos, Qlocal_map, string); - if (!NILP (map)) - local_map = map; - - map = Fget_text_property (pos, Qkeymap, string); - if (!NILP (map)) - keymap = map; + local_map = Fget_text_property (pos, Qlocal_map, string); + keymap = Fget_text_property (pos, Qkeymap, string); } }