From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 28 06:55:47 2025 Received: (at submit) by debbugs.gnu.org; 28 Mar 2025 10:55:47 +0000 Received: from localhost ([127.0.0.1]:53034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ty7NK-0003dF-PX for submit@debbugs.gnu.org; Fri, 28 Mar 2025 06:55:47 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41976) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ty7NH-0003cy-Q7 for submit@debbugs.gnu.org; Fri, 28 Mar 2025 06:55:44 -0400 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 1ty7NB-0002H8-MX for bug-gnu-emacs@gnu.org; Fri, 28 Mar 2025 06:55:38 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ty7N9-00050T-Bp for bug-gnu-emacs@gnu.org; Fri, 28 Mar 2025 06:55:37 -0400 Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.stl.internal (Postfix) with ESMTP id 363451140187 for ; Fri, 28 Mar 2025 06:55:34 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Fri, 28 Mar 2025 06:55:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pengjiz.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1743159334; x=1743245734; bh=/ljTKLeSgYPVIOoCxqU/BdblvY3HyS9m T+4JTeIHnC0=; b=o9NLzeUoKIhKNK8hN4eJU4wjBNopZOB0k+BDCrY9lM5Y7689 7pQeR5JrNLyyZiKlNEm57CFXyYN/i5fz22rNuy+YD9Utfs6B48nKrclE1yHAvQdX 7hLNjUcKWoLhq4VTJm5sIk5V1kBTdCRe9LoVxCsk1b4DOIP4e0NmsBPlYNVAAzrN ql9F2ZiSDKZt4gX910i832eAi98giBHTILNST30KWPE/K50ukEUC//qtvYm0Cyaf 3uc48YFo0NxQofCplEJyEobUCKCQbiLv1Cf7D4liuPNFxAh9XOoEovnztjtxxW4O X1N2nGKMGhBi4Zk0elb8aPLk2m3G2YQvg0IKuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1743159334; x= 1743245734; bh=/ljTKLeSgYPVIOoCxqU/BdblvY3HyS9mT+4JTeIHnC0=; b=f UrUdgLGpYYWJmXIkMrBMal+3p1Xl8q1NgDqEO9hKJVOZVSPjYghdyWPpEW/AYorA QA84ESGPfmtRaiPp6Hm/rsE5dF2IdyVyef9+Ulz7wbwGc4h6/6QmcxDEMgMvFFZf sV6jeHeDKSqqDxQcb7o5HFpWABcqhkM/tZ3GXE+sm07srJvy02/Ntl28FVelTg+/ nocsj5MrmV9F6jZevJot3vI30NwMbDINd7kujUoZtH76P1tyAlg9/w7y7Np2x5CI y8NNmndycnn1CgPXRTAQ1vnkHf7hx5jXYDVnApVT6SrG/HpCKA7c753yYFNEOyt8 WixVk0/ci9REIkNVkBZJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujeduuddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvf fufffkgggtsehmtderredttddtnecuhfhrohhmpefrvghnghhjihcukghhrghnghcuoehm vgesphgvnhhgjhhiiidrtghomheqnecuggftrfgrthhtvghrnhepfffgiefhgfduleelvd eiiedtvdefieegkedtkefftdeljefgheelvdffjeegteegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgvsehpvghnghhjihiirdgtohhmpd hnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsuhhg qdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i16614472:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 28 Mar 2025 06:55:32 -0400 (EDT) From: Pengji Zhang To: bug-gnu-emacs@gnu.org Subject: [PATCH] Fix mouse highlighting for compact mode lines Date: Fri, 28 Mar 2025 18:55:30 +0800 Message-ID: <87iknt4e71.fsf@pengjiz.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=202.12.124.146; envelope-from=me@pengjiz.com; helo=fout-b3-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --=-=-= Content-Type: text/plain Hello, I found that with 'mode-line-compact' being non-nil, mouse highlighting would not work properly. To reproduce: - emacs -Q - (setq mode-line-compact t) or (setq mode-line-compact 'long) - Hover mouse cursor over the major mode part on the mode line Now the minor mode lighters are also highlighted. That is presumably because when 'mode-line-compact' is non-nil, the whole mode line string is displayed at once. So the glyphs produced all have the same 'object' field. That confuses the computation of boundaries for mouse highlighting. In this patch we instead split the mode line string into elements and display them one by one. Thanks! --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Fix-mouse-highlighting-for-compact-mode-lines.patch >From 5c7538aceb7e80ea44be7d74890d36e88d36169c Mon Sep 17 00:00:00 2001 From: Pengji Zhang Date: Sun, 23 Mar 2025 20:19:09 +0800 Subject: [PATCH] Fix mouse highlighting for compact mode lines When 'mode-line-compact' is non-nil, the mode line string is displayed as a whole. That confuses the computation of ranges of mouse highlighting on the mode line because all the glyphs have the same Lisp object source. As such, in this commit we instead split the mode line string by sources, and display those elements one by one, so the boundaries of each element could be correctly detected for the purpose of mouse highlighting. * src/xdisp.c (display_mode_line): Display mode line elements one by one when 'mode-line-compact' is non-nil. (display_mode_element): Record source of the stored string via a text property. (syms_of_xdisp): New symbol for the text property. --- src/xdisp.c | 132 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 93 insertions(+), 39 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index f2b158f00e3..193f9767c6f 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -27745,57 +27745,102 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) { /* The window is wide enough; just display the mode line we just computed. */ - display_string (NULL, mode_string, Qnil, - 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt; + AUTO_LIST2 (props, Qmode_line_element, Qnil); + + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do + { + end = Fnext_single_property_change (start, Qmode_line_element, + mode_string, Qnil); + elt = Fsubstring (mode_string, start, end); + Fremove_text_properties (make_fixnum (0), + make_fixnum (SCHARS (elt)), + props, elt); + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + start = end; + } + while (!NILP (end)); } else { /* Compress the mode line. */ - ptrdiff_t i = 0, i_byte = 0, start = 0; + ptrdiff_t i = 0, i_byte = 0; int prev = 0; + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt = empty_unibyte_string; + AUTO_LIST2 (props, Qmode_line_element, Qnil); - while (i < SCHARS (mode_string)) + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do { - int c = fetch_string_char_advance (mode_string, &i, &i_byte); - if (c == ' ' && prev == ' ') + end = Fnext_single_property_change (start, + Qmode_line_element, + mode_string, + make_fixnum (SCHARS (mode_string))); + while (i < XFIXNUM (end)) { - Lisp_Object prev_pos = make_fixnum (i - 1); - - /* SPC characters with 'display' properties are not - really "empty", since they have non-trivial visual - effects on the mode line. */ - if (NILP (Fget_text_property (prev_pos, Qdisplay, - mode_string))) + int c = fetch_string_char_advance (mode_string, &i, &i_byte); + if (c == ' ' && prev == ' ') { - display_string (NULL, - Fsubstring (mode_string, - make_fixnum (start), - prev_pos), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); - /* Skip past the rest of the space characters. */ - while (c == ' ' && i < SCHARS (mode_string) - && NILP (Fget_text_property (make_fixnum (i), - Qdisplay, - mode_string))) + Lisp_Object prev_pos = make_fixnum (i - 1); + Lisp_Object display = Fget_text_property (prev_pos, + Qdisplay, + mode_string); + + /* SPC characters with 'display' properties are not + really "empty", since they have non-trivial visual + effects on the mode line. */ + if (NILP (display)) { - c = fetch_string_char_advance (mode_string, - &i, &i_byte); + elt = concat2 (elt, Fsubstring (mode_string, + start, + prev_pos)); + + /* Skip past the rest of the space characters. */ + Lisp_Object display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + while (c == ' ' && i < XFIXNUM (end) + && NILP (display)) + { + c = fetch_string_char_advance (mode_string, + &i, &i_byte); + display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + } + + /* Skip the final space no matter how the loop + above ends. */ + if (c == ' ' && NILP (display)) + start = end; + else + start = make_fixnum (i - 1); } - start = i - 1; } + prev = c; } - prev = c; - } - /* Display the final bit. */ - if (start < i) - display_string (NULL, - Fsubstring (mode_string, make_fixnum (start), - make_fixnum (i)), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + /* Append the final bit. */ + if (XFIXNUM (start) < XFIXNUM (end)) + elt = concat2 (elt, Fsubstring (mode_string, start, end)); + + Fremove_text_properties (make_fixnum (0), + make_fixnum (SCHARS (elt)), + props, elt); + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + elt = empty_unibyte_string; + start = end; + } + while (XFIXNUM (end) < SCHARS (mode_string)); } } pop_kboard (); @@ -28014,7 +28059,10 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop (SSDATA (elt), -1, prec); break; case MODE_LINE_STRING: - n += store_mode_line_string (NULL, elt, true, 0, prec, Qnil); + { + AUTO_LIST2 (src, Qmode_line_element, elt); + n += store_mode_line_string (NULL, elt, true, 0, prec, src); + } break; case MODE_LINE_DISPLAY: n += display_string (NULL, elt, Qnil, 0, 0, it, @@ -28067,8 +28115,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, Lisp_Object mode_string = Fsubstring (elt, make_fixnum (charpos), make_fixnum (endpos)); + AUTO_LIST2 (src, Qmode_line_element, elt); n += store_mode_line_string (NULL, mode_string, false, - 0, 0, Qnil); + 0, 0, src); } break; case MODE_LINE_DISPLAY: @@ -28148,6 +28197,7 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, { Lisp_Object tem = build_string (spec); props = Ftext_properties_at (make_fixnum (charpos), elt); + props = plist_put (props, Qmode_line_element, elt); /* Should only keep face property in props */ n += store_mode_line_string (NULL, tem, false, field, prec, props); @@ -28363,6 +28413,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop ("", field_width - n, 0); break; case MODE_LINE_STRING: + /* NOTE: Padding implicitly has 'mode-line-element' property + to be nil. Normally padding spaces are between two real + elements, so this should be good. */ n += store_mode_line_string ("", Qnil, false, field_width - n, 0, Qnil); break; @@ -37657,6 +37710,7 @@ syms_of_xdisp (void) DEFSYM (Qfontification_functions, "fontification-functions"); DEFSYM (Qlong_line_optimizations_in_fontification_functions, "long-line-optimizations-in-fontification-functions"); + DEFSYM (Qmode_line_element, "mode-line-element"); /* Name of the symbol which disables Lisp evaluation in 'display' properties. This is used by enriched.el. */ -- 2.49.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 29 05:21:12 2025 Received: (at 77336) by debbugs.gnu.org; 29 Mar 2025 09:21:12 +0000 Received: from localhost ([127.0.0.1]:56805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tySNM-0004Td-4W for submit@debbugs.gnu.org; Sat, 29 Mar 2025 05:21:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43876) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tySNJ-0004TN-Oc for 77336@debbugs.gnu.org; Sat, 29 Mar 2025 05:21:11 -0400 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 1tySNE-00067e-34; Sat, 29 Mar 2025 05:21:04 -0400 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=wADLitfz/LRX1mpUQks+Hoa9LcI7se6Oqhy636K2AZc=; b=DKssuHcAK2LG 4OAU6mNhelz5R8AYZ1YkZ3B+Uts1o6LZbPPLY3d/wCYvOCau4rZhcTIl7tzZ2Zif3DRiY+7qMz5br hl0cRC/vDERerzEJW7pL+dCc0de7oXrdckfUd/pr63wBEW4sAD5I1fJsdwJB1ZTp8djbyQUqbvgL/ d6qANlyk95PLTNquLsruwm3MxNLajLYFEG9k2hwf9BgK4jKDLwh9h15/6lnWaxGilz5N1B7W0i0A2 Pd4t3HmYR8vneFDOuOyARfNV3o9QiNwOsfeBKx9Ip5tZp/dUTr7Y85huhE1p6l5EE8Kdtkqgsp81G ObJ3QLScDkjJHHCO0sa18w==; Date: Sat, 29 Mar 2025 12:21:01 +0300 Message-Id: <86tt7c8a6a.fsf@gnu.org> From: Eli Zaretskii To: Pengji Zhang In-Reply-To: <87iknt4e71.fsf@pengjiz.com> (message from Pengji Zhang on Fri, 28 Mar 2025 18:55:30 +0800) Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines References: <87iknt4e71.fsf@pengjiz.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pengji Zhang > Date: Fri, 28 Mar 2025 18:55:30 +0800 > > @@ -28014,7 +28059,10 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, > n += store_mode_line_noprop (SSDATA (elt), -1, prec); > break; > case MODE_LINE_STRING: > - n += store_mode_line_string (NULL, elt, true, 0, prec, Qnil); > + { > + AUTO_LIST2 (src, Qmode_line_element, elt); > + n += store_mode_line_string (NULL, elt, true, 0, prec, src); > + } > break; > case MODE_LINE_DISPLAY: > n += display_string (NULL, elt, Qnil, 0, 0, it, > @@ -28067,8 +28115,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, > Lisp_Object mode_string > = Fsubstring (elt, make_fixnum (charpos), > make_fixnum (endpos)); > + AUTO_LIST2 (src, Qmode_line_element, elt); > n += store_mode_line_string (NULL, mode_string, false, > - 0, 0, Qnil); > + 0, 0, src); > } > break; > case MODE_LINE_DISPLAY: > @@ -28148,6 +28197,7 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, > { > Lisp_Object tem = build_string (spec); > props = Ftext_properties_at (make_fixnum (charpos), elt); > + props = plist_put (props, Qmode_line_element, elt); > /* Should only keep face property in props */ > n += store_mode_line_string (NULL, tem, false, > field, prec, props); Thanks, but why do we need to make the value of this mode-line-element property be the element itself? Why not give it some simple value, like the ordinal number of the element (which should be incremented whenever we process another element)? So we could call this property mode-line-elt-number and assign the elements values 1, 2, 3, etc. I'm concerned that having the elements themselves be values will prevent them from being GC'd, which might increase the memory pressure. By contrast, fixnums are immediate values that don't need to be GC'ed, and the element itself will not have any references after the mode line is processed. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 30 07:45:12 2025 Received: (at 77336) by debbugs.gnu.org; 30 Mar 2025 11:45:12 +0000 Received: from localhost ([127.0.0.1]:34985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tyr6F-0003RQ-Uy for submit@debbugs.gnu.org; Sun, 30 Mar 2025 07:45:12 -0400 Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:43195) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tyr6D-0003Lr-7B for 77336@debbugs.gnu.org; Sun, 30 Mar 2025 07:45:09 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id C68012540127; Sun, 30 Mar 2025 07:45:03 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sun, 30 Mar 2025 07:45:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pengjiz.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1743335103; x=1743421503; bh=BrnF/ZgX97 saqR2wtYBvJFAyL0VQ77wFhrZZKHIczSI=; b=0YD+CeUbJuEKOTzIF64CUEzjdx FXGrg1HjUKm3/EIXI2vEUmagDlC71PXFMAmX+E5rnRLvmz5eO8AsTfrRTJ1isWck gd0n8N7sM/WQiP6IDil2FXAEDvvZzFoXj7ZBeCAtLrp7sM0UO7pmZ88DiaSXQziC zhsgAPRTkM716iR8QyHAYXfr9bkoNao7CtmmeJfbHg6BZwE1PmC3Sst4yFy8Ret8 d0S0Lva5QNHXt6vCaK9lKSgIb0+kxlVcgscoIO4UttNSnuKJwOUqup0wZWnaE/4m qTjKayf9HBJ08fP8hSTOyDkqg6bcliUuAruKwGi9iEk0C8Fth9HuzYbWSUmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743335103; x=1743421503; bh=BrnF/ZgX97saqR2wtYBvJFAyL0VQ77wFhrZ ZKHIczSI=; b=vOscRsDsN1vsa9AuiOSPRB2pTmvglyEbrW+vl1dv8VCrJxRsYOe Koko5x3o7qtHB9DiQsBMckjVoGGd4biRCZPUqVJCz8hNB6nBnYXv0V5ZFTgxPI1D UM1QvRTp+dvMErRRsmc31+OBFUQCDqk+154dsXpf+d9+gZzVwkjmYnh+MuuItsdG mBAf/2AgP7TuWEUaa2LoxwWgLdsmT/XYt2kDMa8AhXghMLUdNi4s6EMfLL8ySwGH Wyn8PeTbpmya5xS1q0VPKA4cFkn+PGPSoksNe6AhmfEUD7xs+8xaSQpO6swMcGe1 EY/QVk6xp6XAp6ttlC6C6jobGbo2DYXN7WQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujeeileeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkgggtsehmtderredttddt necuhfhrohhmpefrvghnghhjihcukghhrghnghcuoehmvgesphgvnhhgjhhiiidrtghomh eqnecuggftrfgrthhtvghrnhepieffgfeiueelgfejjeeivdelheffffeuieeihffhffev jeeuhfegvdfhkefgleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhgvsehpvghnghhjihiirdgtohhmpdhnsggprhgtphhtthhopedvpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtph htthhopeejjeeffeeiseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i16614472:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 30 Mar 2025 07:45:02 -0400 (EDT) From: Pengji Zhang To: Eli Zaretskii Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines In-Reply-To: <86tt7c8a6a.fsf@gnu.org> References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> Date: Sun, 30 Mar 2025 19:44:59 +0800 Message-ID: <871pueagjo.fsf@pengjiz.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > Thanks, but why do we need to make the value of this mode-line-element > property be the element itself? Why not give it some simple value, > like the ordinal number of the element (which should be incremented > whenever we process another element)? So we could call this property > mode-line-elt-number and assign the elements values 1, 2, 3, etc. Is casting the 'Lisp_Object' to a number acceptable here? Please have a look at the updated patch. I tried an incremental counter but gave up. Because 'display_mode_element' could be called recursively, we may have to change its signature or introduce a new global variable. That feels a bit less clean to me. > I'm concerned that having the elements themselves be values will > prevent them from being GC'd, which might increase the memory > pressure. By contrast, fixnums are immediate values that don't need > to be GC'ed, and the element itself will not have any references after > the mode line is processed. I thought all objects would be GC'd. Since fixnums are not, I guess now we do not need to remove the text property before displaying the string? Please let me know what you think and I will update the patch if needed. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Fix-mouse-highlighting-for-compact-mode-lines.patch >From 73bc97111ace409a5de27930d0dadcd18490fa5e Mon Sep 17 00:00:00 2001 From: Pengji Zhang Date: Sun, 30 Mar 2025 19:24:10 +0800 Subject: [PATCH] Fix mouse highlighting for compact mode lines (bug#77336) When 'mode-line-compact' is non-nil, the mode line string is displayed as a whole. That confuses the computation of ranges of mouse highlighting on the mode line because all the glyphs have the same Lisp object source. As such, in this commit we instead split the mode line string by sources, and display those elements one by one, so the boundaries of each element could be correctly detected for the purpose of mouse highlighting. * src/xdisp.c (display_mode_line): Display mode line elements one by one when 'mode-line-compact' is non-nil. (display_mode_element): Record source of the stored string via a text property. (syms_of_xdisp): New symbol for the text property. --- src/xdisp.c | 132 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 93 insertions(+), 39 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 2c676c09827..d712e3d02ae 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -27754,57 +27754,102 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) { /* The window is wide enough; just display the mode line we just computed. */ - display_string (NULL, mode_string, Qnil, - 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt; + AUTO_LIST2 (props, Qmode_line_element, Qnil); + + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do + { + end = Fnext_single_property_change (start, Qmode_line_element, + mode_string, Qnil); + elt = Fsubstring (mode_string, start, end); + Fremove_text_properties (make_fixnum (0), + make_fixnum (SCHARS (elt)), + props, elt); + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + start = end; + } + while (!NILP (end)); } else { /* Compress the mode line. */ - ptrdiff_t i = 0, i_byte = 0, start = 0; + ptrdiff_t i = 0, i_byte = 0; int prev = 0; + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt = empty_unibyte_string; + AUTO_LIST2 (props, Qmode_line_element, Qnil); - while (i < SCHARS (mode_string)) + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do { - int c = fetch_string_char_advance (mode_string, &i, &i_byte); - if (c == ' ' && prev == ' ') + end = Fnext_single_property_change (start, + Qmode_line_element, + mode_string, + make_fixnum (SCHARS (mode_string))); + while (i < XFIXNUM (end)) { - Lisp_Object prev_pos = make_fixnum (i - 1); - - /* SPC characters with 'display' properties are not - really "empty", since they have non-trivial visual - effects on the mode line. */ - if (NILP (Fget_text_property (prev_pos, Qdisplay, - mode_string))) + int c = fetch_string_char_advance (mode_string, &i, &i_byte); + if (c == ' ' && prev == ' ') { - display_string (NULL, - Fsubstring (mode_string, - make_fixnum (start), - prev_pos), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); - /* Skip past the rest of the space characters. */ - while (c == ' ' && i < SCHARS (mode_string) - && NILP (Fget_text_property (make_fixnum (i), - Qdisplay, - mode_string))) + Lisp_Object prev_pos = make_fixnum (i - 1); + Lisp_Object display = Fget_text_property (prev_pos, + Qdisplay, + mode_string); + + /* SPC characters with 'display' properties are not + really "empty", since they have non-trivial visual + effects on the mode line. */ + if (NILP (display)) { - c = fetch_string_char_advance (mode_string, - &i, &i_byte); + elt = concat2 (elt, Fsubstring (mode_string, + start, + prev_pos)); + + /* Skip past the rest of the space characters. */ + Lisp_Object display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + while (c == ' ' && i < XFIXNUM (end) + && NILP (display)) + { + c = fetch_string_char_advance (mode_string, + &i, &i_byte); + display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + } + + /* Skip the final space no matter how the loop + above ends. */ + if (c == ' ' && NILP (display)) + start = end; + else + start = make_fixnum (i - 1); } - start = i - 1; } + prev = c; } - prev = c; - } - /* Display the final bit. */ - if (start < i) - display_string (NULL, - Fsubstring (mode_string, make_fixnum (start), - make_fixnum (i)), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + /* Append the final bit. */ + if (XFIXNUM (start) < XFIXNUM (end)) + elt = concat2 (elt, Fsubstring (mode_string, start, end)); + + Fremove_text_properties (make_fixnum (0), + make_fixnum (SCHARS (elt)), + props, elt); + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + elt = empty_unibyte_string; + start = end; + } + while (XFIXNUM (end) < SCHARS (mode_string)); } } pop_kboard (); @@ -28023,7 +28068,10 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop (SSDATA (elt), -1, prec); break; case MODE_LINE_STRING: - n += store_mode_line_string (NULL, elt, true, 0, prec, Qnil); + { + AUTO_LIST2 (src, Qmode_line_element, make_fixnum (XLI (elt))); + n += store_mode_line_string (NULL, elt, true, 0, prec, src); + } break; case MODE_LINE_DISPLAY: n += display_string (NULL, elt, Qnil, 0, 0, it, @@ -28076,8 +28124,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, Lisp_Object mode_string = Fsubstring (elt, make_fixnum (charpos), make_fixnum (endpos)); + AUTO_LIST2 (src, Qmode_line_element, make_fixnum (XLI (elt))); n += store_mode_line_string (NULL, mode_string, false, - 0, 0, Qnil); + 0, 0, src); } break; case MODE_LINE_DISPLAY: @@ -28157,6 +28206,7 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, { Lisp_Object tem = build_string (spec); props = Ftext_properties_at (make_fixnum (charpos), elt); + props = plist_put (props, Qmode_line_element, make_fixnum (XLI (elt))); /* Should only keep face property in props */ n += store_mode_line_string (NULL, tem, false, field, prec, props); @@ -28372,6 +28422,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop ("", field_width - n, 0); break; case MODE_LINE_STRING: + /* NOTE: Padding implicitly has 'mode-line-element' property + to be nil. Normally padding spaces are between two real + elements, so this should be good. */ n += store_mode_line_string ("", Qnil, false, field_width - n, 0, Qnil); break; @@ -37666,6 +37719,7 @@ syms_of_xdisp (void) DEFSYM (Qfontification_functions, "fontification-functions"); DEFSYM (Qlong_line_optimizations_in_fontification_functions, "long-line-optimizations-in-fontification-functions"); + DEFSYM (Qmode_line_element, "mode-line-element"); /* Name of the symbol which disables Lisp evaluation in 'display' properties. This is used by enriched.el. */ -- 2.49.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 30 08:01:32 2025 Received: (at 77336) by debbugs.gnu.org; 30 Mar 2025 12:01:32 +0000 Received: from localhost ([127.0.0.1]:35068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tyrM4-0004FO-E7 for submit@debbugs.gnu.org; Sun, 30 Mar 2025 08:01:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58906) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tyrM2-0004FA-3o for 77336@debbugs.gnu.org; Sun, 30 Mar 2025 08:01:30 -0400 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 1tyrLw-0005GH-OF; Sun, 30 Mar 2025 08:01:24 -0400 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=dxUSwEV7o39KPiWlQ8fTpuzNcmMgcNXZF0FWtskDarI=; b=QqTkBV+H73cG NsDbqjLGetVcqz8crv3VKMXQrYxNZZCeEiSbVqjTlq1c9x3n4c6sqSyJ2fffMStoJKt8JsZk7fpdj VIYvbh86N65uTyqed1C0XUVPMm+3EMuXYJI0wzo3tFoeDPTJ0z6fNLuRURKwxtHisJdt8ajYuqqg8 q/9ESduXg0ZZ7ncBL3ehJVMXtg1RSr7ICbnwheTMiPfSHpROQcivGFGyH1qzFcddvd+eqNEsD1yYo HMaT2RhEubFlqwgYZ10nISuruFT797aN39+BBwYbr0ggrOMn2NYoZJAzp1sdHQWLw8sZxJxgjAgZH QpkGr+nuR14aA/ZuG3SjgQ==; Date: Sun, 30 Mar 2025 15:01:21 +0300 Message-Id: <86zfh24tim.fsf@gnu.org> From: Eli Zaretskii To: Pengji Zhang In-Reply-To: <871pueagjo.fsf@pengjiz.com> (message from Pengji Zhang on Sun, 30 Mar 2025 19:44:59 +0800) Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> <871pueagjo.fsf@pengjiz.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pengji Zhang > Cc: 77336@debbugs.gnu.org > Date: Sun, 30 Mar 2025 19:44:59 +0800 > > > Thanks, but why do we need to make the value of this mode-line-element > > property be the element itself? Why not give it some simple value, > > like the ordinal number of the element (which should be incremented > > whenever we process another element)? So we could call this property > > mode-line-elt-number and assign the elements values 1, 2, 3, etc. > > Is casting the 'Lisp_Object' to a number acceptable here? No, because Lisp_Object could be a struct (if Emacs was configured with "--enable-check-lisp-object-type"). What I had in mind was to have a static global int variable named, say elt_no, initialized to zero when display_mode_line is called, and then give each segment of the mode line a value like this: AUTO_LIST2 (src, Qmode_line_element, make_fixnum (elt_no++)); n += store_mode_line_string (NULL, elt, true, 0, prec, src); > I tried an incremental counter but gave up. Because > 'display_mode_element' could be called recursively, we may have to > change its signature or introduce a new global variable. That feels a > bit less clean to me. A global variable is what I had in mind. I don't see why it would be less clean. > > I'm concerned that having the elements themselves be values will > > prevent them from being GC'd, which might increase the memory > > pressure. By contrast, fixnums are immediate values that don't need > > to be GC'ed, and the element itself will not have any references after > > the mode line is processed. > > I thought all objects would be GC'd. Since fixnums are not, I guess now > we do not need to remove the text property before displaying the string? > Please let me know what you think and I will update the patch if needed. If you remove the text property because of GC, then indeed you don't need to do that anymore with fixnums. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 30 23:31:57 2025 Received: (at 77336) by debbugs.gnu.org; 31 Mar 2025 03:31:58 +0000 Received: from localhost ([127.0.0.1]:38917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tz5sR-0005rd-8m for submit@debbugs.gnu.org; Sun, 30 Mar 2025 23:31:57 -0400 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:35171) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tz5sI-0005pV-KS for 77336@debbugs.gnu.org; Sun, 30 Mar 2025 23:31:52 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id D93CB1383820; Sun, 30 Mar 2025 23:31:40 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Sun, 30 Mar 2025 23:31:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pengjiz.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1743391900; x=1743478300; bh=/Pk3rpBKdI WKQZ4T3OaVYG0OuzLyy8SFX4+a6c/bQPI=; b=3xSCIG04BNWSj/2gdyoO5btQ61 X5B/SWDb4JSpCEv7D46mBq/BKFYwEqjEklsZjXZ4jXKA42q8nETQRZizRVZmAhNO oXbdTTlYlkKMsToLhRL+D3yK0lBJlpg6JcJpTmxt1gt1YZoAPjLwm6tN7QApMeRE UewKS8wFw+3wDg4Qmcz+rIyHcRlURdQkkUZmALI0MIRXZhqeFnLHeYhVrsmN0csm 42exMM4BhjhEy4k1lsb14Hy7GJDGzfYmu4/lqafANvET/dO39O5xgF/fJlhJq6pu 1vmSrXEjj1Zb081yAXWmZLqjka6X4RQZS7cTNUtJR3+x6u7/kBiRe8yU+tWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743391900; x=1743478300; bh=/Pk3rpBKdIWKQZ4T3OaVYG0OuzLyy8SFX4+ a6c/bQPI=; b=UN9aDycR/LEMj+E0GCSQ1K41/0uuntyKlkDGn9Th4tx28284x7E iVL7dNT/eA6qM3KJXTsi0ByqdOWsZRzoySMfDiq50fqkEX+5UWv8EftPmIwzCSre AWSTKAV6nSICMqH/yTPwAQxS66yXdbQ/wdc5fC9bUFV/NDMuRPcj08f4M6f6eRUo JJ/iroNEkUwAG7lnDUtX1ScpScqONleNXhXZFGIuDLtwawTUrVGqabpqJrxvV+UQ 3jjl1WvCy8StsfmXtCNycYraaOtKhVGxITpzLgyFNO9Ib1Iw/fMvfwmho9AmKtbf WUaR/WUFNpQ1IMrkSFOhKMI1X/vcs+RcmrQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujeekkeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkgggtsehttdertddttddt necuhfhrohhmpefrvghnghhjihcukghhrghnghcuoehmvgesphgvnhhgjhhiiidrtghomh eqnecuggftrfgrthhtvghrnhepgeefieeivddukeeitdegudeftdevtdeuteeifffhvdeh ffetgfeijeeileelheegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhgvsehpvghnghhjihiirdgtohhmpdhnsggprhgtphhtthhopedvpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtph htthhopeejjeeffeeiseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i16614472:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 30 Mar 2025 23:31:39 -0400 (EDT) From: Pengji Zhang To: Eli Zaretskii Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines In-Reply-To: <86zfh24tim.fsf@gnu.org> References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> <871pueagjo.fsf@pengjiz.com> <86zfh24tim.fsf@gnu.org> Date: Mon, 31 Mar 2025 11:31:36 +0800 Message-ID: <87ldslho4n.fsf@pengjiz.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Pengji Zhang >> Cc: 77336@debbugs.gnu.org >> Date: Sun, 30 Mar 2025 19:44:59 +0800 >> >> > Thanks, but why do we need to make the value of this mode-line-element >> > property be the element itself? Why not give it some simple value, >> > like the ordinal number of the element (which should be incremented >> > whenever we process another element)? So we could call this property >> > mode-line-elt-number and assign the elements values 1, 2, 3, etc. >> >> Is casting the 'Lisp_Object' to a number acceptable here? > > No, because Lisp_Object could be a struct (if Emacs was configured with > "--enable-check-lisp-object-type"). Sorry I did not make it clear. I meant 'make_fixnum(XLI(elt))'. I suppose 'XLI' will handle that case correctly? I am actually concerned that there could be a collision between two different 'elt's, e.g., a symbol and a string, because 'make_fixnum' alters the tag of 'elt'. I think it might be fine because 'elt' should always be a 'Lisp_String' when this is called. > What I had in mind was to have a static global int variable named, say > elt_no, initialized to zero when display_mode_line is called, and then > give each segment of the mode line a value like this: > > AUTO_LIST2 (src, Qmode_line_element, make_fixnum (elt_no++)); > n += store_mode_line_string (NULL, elt, true, 0, prec, src); > >> I tried an incremental counter but gave up. Because >> 'display_mode_element' could be called recursively, we may have to >> change its signature or introduce a new global variable. That feels a >> bit less clean to me. > > A global variable is what I had in mind. I don't see why it would be > less clean. It is just that maintaining a global state is not as tasteful to me. If 'make_fixnum(XLI(elt))' is not good here, I am happy to go this way. >> > I'm concerned that having the elements themselves be values will >> > prevent them from being GC'd, which might increase the memory >> > pressure. By contrast, fixnums are immediate values that don't need >> > to be GC'ed, and the element itself will not have any references after >> > the mode line is processed. >> >> I thought all objects would be GC'd. Since fixnums are not, I guess now >> we do not need to remove the text property before displaying the string? >> Please let me know what you think and I will update the patch if needed. > > If you remove the text property because of GC, then indeed you don't > need to do that anymore with fixnums. Thanks. I will update the patch accordingly. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 31 09:03:31 2025 Received: (at 77336) by debbugs.gnu.org; 31 Mar 2025 13:03:31 +0000 Received: from localhost ([127.0.0.1]:40281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzEnb-0001Ah-7U for submit@debbugs.gnu.org; Mon, 31 Mar 2025 09:03:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49480) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzEnX-00019M-OK for 77336@debbugs.gnu.org; Mon, 31 Mar 2025 09:03:28 -0400 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 1tzEnS-0001ec-0u; Mon, 31 Mar 2025 09:03:22 -0400 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=p9c0prGt5Ub84hX6TaOjR4hnWQA+O1IczJ3Q2zayGuo=; b=P9ga4MEy18WH 9Xl4eVGimVI64auHlkP8PUoA0NJTx1G8S4TemHha/Oefq3VL/xso7UofWJj3lMFiPkMZxl/KYRwdf K6avJKJCsf0HGXgQZSWv1qOOIGSd3+F7V1WUiRFi6MhYfG8OQPEbVUxghn3YHuvWxVGTUQmUbvn4V 81NAbg4HcU+Xr0rUKBa30IQIX3cvG+4UpvTWxoGLcqsmsDOPcdwQnbp7zlmTtPvceQ/NgxG7N8qBH WqsBzecW9rgBG/oi29n77/V0AJpWtUc4xA5tJ5oOnFqVc2iysr219M4srhEKwyjWSZzBJgxhjnFTB VmQ4roa49U/n8yj9RQVSuA==; Date: Mon, 31 Mar 2025 16:03:18 +0300 Message-Id: <86cydx4ajt.fsf@gnu.org> From: Eli Zaretskii To: Pengji Zhang In-Reply-To: <87ldslho4n.fsf@pengjiz.com> (message from Pengji Zhang on Mon, 31 Mar 2025 11:31:36 +0800) Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> <871pueagjo.fsf@pengjiz.com> <86zfh24tim.fsf@gnu.org> <87ldslho4n.fsf@pengjiz.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pengji Zhang > Cc: 77336@debbugs.gnu.org > Date: Mon, 31 Mar 2025 11:31:36 +0800 > > Eli Zaretskii writes: > > >> Is casting the 'Lisp_Object' to a number acceptable here? > > > > No, because Lisp_Object could be a struct (if Emacs was configured with > > "--enable-check-lisp-object-type"). > > Sorry I did not make it clear. I meant 'make_fixnum(XLI(elt))'. I > suppose 'XLI' will handle that case correctly? I'd prefer not to do that unless there's no other reasonable solution. > I am actually concerned that there could be a collision between two > different 'elt's, e.g., a symbol and a string, because 'make_fixnum' > alters the tag of 'elt'. I think it might be fine because 'elt' should > always be a 'Lisp_String' when this is called. Sorry, I don't understand: what do you mean by "alters the tag of 'elt'", and how could make_fixnum affect 'elt'? > > A global variable is what I had in mind. I don't see why it would be > > less clean. > > It is just that maintaining a global state is not as tasteful to me. If > 'make_fixnum(XLI(elt))' is not good here, I am happy to go this way. Yes, a global variable is cleaner than using XLI for this purpose. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 02 09:02:38 2025 Received: (at 77336) by debbugs.gnu.org; 2 Apr 2025 13:02:38 +0000 Received: from localhost ([127.0.0.1]:56082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzxjo-0008De-Nk for submit@debbugs.gnu.org; Wed, 02 Apr 2025 09:02:38 -0400 Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]:43219) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzxjl-0008Cl-TH for 77336@debbugs.gnu.org; Wed, 02 Apr 2025 09:02:35 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 370FB1140098; Wed, 2 Apr 2025 09:02:28 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 02 Apr 2025 09:02:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pengjiz.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1743598948; x=1743685348; bh=VU886JGfLT 4iZ9wCVS7zkPUfteYI38UY5LofjWOMDSc=; b=As/WyPdRoC/AEnqkUMIF6NNJgk BVAsThcBPyjW2cUfIyfUAYV7mk9ua4QPshWot84CmBv4lUjKsyMmzh89e5eOxb3G 7Az5uz2SS42poGir2hLGfvZsyND4wQ8cBviMnHZjrZ3b9gkF6hgH3vk6iWtN5d+z DVVSTfxwrMHzjh/wmwrvCIfy1E9NM0d1LOejNl0WuBc5dR9g7rB2MX6HybHdTBe6 kmM7FUNnvUGYGZx4c4yPEKqdUz23Jl5yrNZ+ncA1fENUN7EKpfBUR1WBVtXTBuOF BZ43QWsZ3jyaIbGlqYdCi/tYGb/XcM12UVXU14q2Oo9BowRI+C0RL2uCLljQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743598948; x=1743685348; bh=VU886JGfLT4iZ9wCVS7zkPUfteYI38UY5Lo fjWOMDSc=; b=WTR4OodXJ/F+kSgnvUzCEWX+G32yq5BILIZmQ/neefScOEHWYj7 Juvd/PT7IIL5f68bjl8HJIWUEjZF2S0knFOLV9WKGqL+Fiw4P4B8A+E1GYU7EmRq ImQIYk54MEiBtz2hiDX83abiXJzQtzTbyD8yG0DP0/ZH1j1YeHdmAXLKAMKWTQGq 6RlC6JSk6Qr7smUPsAUw5KY6hJzI+DxfxwROdRKcPJkcUyeureaHhTKFS+XDabCs 6a0oayFZ2HRnres3tNQ3+G65lh91qpnlnA6rlpv8XjrjzkUSP/es+XZOF5Wu0MSg 6/OPZjj9SQGmPWcF9SHIvFQV1bPWcEmm5zQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukeehjeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkgggtsehmtderredttddt necuhfhrohhmpefrvghnghhjihcukghhrghnghcuoehmvgesphgvnhhgjhhiiidrtghomh eqnecuggftrfgrthhtvghrnhepieffgfeiueelgfejjeeivdelheffffeuieeihffhffev jeeuhfegvdfhkefgleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhgvsehpvghnghhjihiirdgtohhmpdhnsggprhgtphhtthhopedvpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtph htthhopeejjeeffeeiseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i16614472:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Apr 2025 09:02:27 -0400 (EDT) From: Pengji Zhang To: Eli Zaretskii Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines In-Reply-To: <86cydx4ajt.fsf@gnu.org> References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> <871pueagjo.fsf@pengjiz.com> <86zfh24tim.fsf@gnu.org> <87ldslho4n.fsf@pengjiz.com> <86cydx4ajt.fsf@gnu.org> Date: Wed, 02 Apr 2025 21:02:19 +0800 Message-ID: <877c42u36s.fsf@pengjiz.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77336 Cc: 77336@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Pengji Zhang >> Cc: 77336@debbugs.gnu.org >> Date: Mon, 31 Mar 2025 11:31:36 +0800 >> >> Eli Zaretskii writes: >> >> >> Is casting the 'Lisp_Object' to a number acceptable here? >> > >> > No, because Lisp_Object could be a struct (if Emacs was configured with >> > "--enable-check-lisp-object-type"). >> >> Sorry I did not make it clear. I meant 'make_fixnum(XLI(elt))'. I >> suppose 'XLI' will handle that case correctly? > > I'd prefer not to do that unless there's no other reasonable solution. > >> I am actually concerned that there could be a collision between two >> different 'elt's, e.g., a symbol and a string, because 'make_fixnum' >> alters the tag of 'elt'. I think it might be fine because 'elt' should >> always be a 'Lisp_String' when this is called. > > Sorry, I don't understand: what do you mean by "alters the tag of > 'elt'", and how could make_fixnum affect 'elt'? It does not affect 'elt'. I meant that 'make_fixnum' may change the value of the number from the tagged pointer: INLINE Lisp_Object make_fixnum (EMACS_INT n) { ... { n &= INTMASK; n += (int0 << VALBITS); } return XIL (n); } So if I understand it correctly, that means 'make_fixnum(XLI(x))' could give the same result for, e.g., a fixnum and a string. >> > A global variable is what I had in mind. I don't see why it would be >> > less clean. >> >> It is just that maintaining a global state is not as tasteful to me. If >> 'make_fixnum(XLI(elt))' is not good here, I am happy to go this way. > > Yes, a global variable is cleaner than using XLI for this purpose. Thanks. Please see the attached patch. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Fix-mouse-highlighting-for-compact-mode-lines-bug-77.patch >From e6ca2165f2e49364f57c53c5c1472a127a7b76a4 Mon Sep 17 00:00:00 2001 From: Pengji Zhang Date: Wed, 2 Apr 2025 20:52:30 +0800 Subject: [PATCH] Fix mouse highlighting for compact mode lines (bug#77336) When 'mode-line-compact' is non-nil, the mode line string is displayed as a whole. That confuses the computation of ranges of mouse highlighting on the mode line because all the glyphs have the same Lisp object source. As such, in this commit we instead split the mode line string by sources, and display those elements one by one, so the boundaries of each element could be correctly detected for the purpose of mouse highlighting. * src/xdisp.c (display_mode_line): Display mode line elements one by one when 'mode-line-compact' is non-nil. (display_mode_element): Record source element number of the stored string via a text property. (Fformat_mode_line): Initialize 'mode_line_elt_no' to 0. (syms_of_xdisp): New symbol for the text property. --- src/xdisp.c | 145 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 106 insertions(+), 39 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 886f070753f..673b5c19c20 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -13674,6 +13674,9 @@ #define MODE_LINE_NOPROP_LEN(start) \ /* List of strings making up the mode-line. */ static Lisp_Object mode_line_string_list; +/* Element number for the stored mode line string. */ +static ptrdiff_t mode_line_elt_no; + /* Base face property when building propertized mode line string. */ static Lisp_Object mode_line_string_face; static Lisp_Object mode_line_string_face_prop; @@ -27754,57 +27757,94 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format) { /* The window is wide enough; just display the mode line we just computed. */ - display_string (NULL, mode_string, Qnil, - 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt; + + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do + { + end = Fnext_single_property_change (start, Qmode_line_elt_no, + mode_string, Qnil); + elt = Fsubstring (mode_string, start, end); + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + start = end; + } + while (!NILP (end)); } else { /* Compress the mode line. */ - ptrdiff_t i = 0, i_byte = 0, start = 0; + ptrdiff_t i = 0, i_byte = 0; int prev = 0; + Lisp_Object start = make_fixnum (0), end; + Lisp_Object elt = empty_unibyte_string; - while (i < SCHARS (mode_string)) + /* Display the mode line string one element by one element. + This is to make the ranges of mouse highlighting + correct. */ + do { - int c = fetch_string_char_advance (mode_string, &i, &i_byte); - if (c == ' ' && prev == ' ') + end = Fnext_single_property_change (start, + Qmode_line_elt_no, + mode_string, + make_fixnum (SCHARS (mode_string))); + while (i < XFIXNUM (end)) { - Lisp_Object prev_pos = make_fixnum (i - 1); - - /* SPC characters with 'display' properties are not - really "empty", since they have non-trivial visual - effects on the mode line. */ - if (NILP (Fget_text_property (prev_pos, Qdisplay, - mode_string))) + int c = fetch_string_char_advance (mode_string, &i, &i_byte); + if (c == ' ' && prev == ' ') { - display_string (NULL, - Fsubstring (mode_string, - make_fixnum (start), - prev_pos), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); - /* Skip past the rest of the space characters. */ - while (c == ' ' && i < SCHARS (mode_string) - && NILP (Fget_text_property (make_fixnum (i), - Qdisplay, - mode_string))) + Lisp_Object prev_pos = make_fixnum (i - 1); + Lisp_Object display = Fget_text_property (prev_pos, + Qdisplay, + mode_string); + + /* SPC characters with 'display' properties are not + really "empty", since they have non-trivial visual + effects on the mode line. */ + if (NILP (display)) { - c = fetch_string_char_advance (mode_string, - &i, &i_byte); + elt = concat2 (elt, Fsubstring (mode_string, + start, + prev_pos)); + + /* Skip past the rest of the space characters. */ + Lisp_Object display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + while (c == ' ' && i < XFIXNUM (end) + && NILP (display)) + { + c = fetch_string_char_advance (mode_string, + &i, &i_byte); + display = Fget_text_property (make_fixnum (i), + Qdisplay, + mode_string); + } + + /* Skip the final space no matter how the loop + above ends. */ + if (c == ' ' && NILP (display)) + start = end; + else + start = make_fixnum (i - 1); } - start = i - 1; } + prev = c; } - prev = c; - } - /* Display the final bit. */ - if (start < i) - display_string (NULL, - Fsubstring (mode_string, make_fixnum (start), - make_fixnum (i)), - Qnil, 0, 0, &it, 0, 0, 0, - STRING_MULTIBYTE (mode_string)); + /* Append the final bit. */ + if (XFIXNUM (start) < XFIXNUM (end)) + elt = concat2 (elt, Fsubstring (mode_string, start, end)); + + display_string (NULL, elt, Qnil, 0, 0, &it, 0, 0, 0, + STRING_MULTIBYTE (elt)); + elt = empty_unibyte_string; + start = end; + } + while (XFIXNUM (end) < SCHARS (mode_string)); } } pop_kboard (); @@ -27926,6 +27966,20 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, if (depth > 100) elt = build_string ("*too-deep*"); + /* NOTE: Increment the number only for 'MODE_LINE_STRING', because for + other cases this variable is not used. So we do not need to reset + the variable in every callers of this function. + + NOTE: This might result in gaps in the stored element numbers + because some elements are processed recursively. However, we + cannot increment this number when the number is stored because an + element could be stored by parts. For example, "a%b" is stored as + two elements in the 'mode_line_string_list', but they should be + considered as one element, so we cannot increment this number when + "a" is stored. */ + if (mode_line_target == MODE_LINE_STRING) + mode_line_elt_no++; + depth++; switch (XTYPE (elt)) @@ -28023,7 +28077,11 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop (SSDATA (elt), -1, prec); break; case MODE_LINE_STRING: - n += store_mode_line_string (NULL, elt, true, 0, prec, Qnil); + { + AUTO_LIST2 (src, Qmode_line_elt_no, + make_fixnum (mode_line_elt_no)); + n += store_mode_line_string (NULL, elt, true, 0, prec, src); + } break; case MODE_LINE_DISPLAY: n += display_string (NULL, elt, Qnil, 0, 0, it, @@ -28076,8 +28134,10 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, Lisp_Object mode_string = Fsubstring (elt, make_fixnum (charpos), make_fixnum (endpos)); + AUTO_LIST2 (src, Qmode_line_elt_no, + make_fixnum (mode_line_elt_no)); n += store_mode_line_string (NULL, mode_string, false, - 0, 0, Qnil); + 0, 0, src); } break; case MODE_LINE_DISPLAY: @@ -28157,6 +28217,8 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, { Lisp_Object tem = build_string (spec); props = Ftext_properties_at (make_fixnum (charpos), elt); + props = plist_put (props, Qmode_line_elt_no, + make_fixnum (mode_line_elt_no)); /* Should only keep face property in props */ n += store_mode_line_string (NULL, tem, false, field, prec, props); @@ -28372,6 +28434,9 @@ display_mode_element (struct it *it, int depth, int field_width, int precision, n += store_mode_line_noprop ("", field_width - n, 0); break; case MODE_LINE_STRING: + /* NOTE: Padding implicitly has 'mode-line-elt-no' property + to be nil. Normally padding spaces are between two real + elements, so this should be good. */ n += store_mode_line_string ("", Qnil, false, field_width - n, 0, Qnil); break; @@ -28579,6 +28644,7 @@ DEFUN ("format-mode-line", Fformat_mode_line, Sformat_mode_line, } push_kboard (FRAME_KBOARD (it.f)); + mode_line_elt_no = 0; display_mode_element (&it, 0, 0, 0, format, Qnil, false); pop_kboard (); @@ -37675,6 +37741,7 @@ syms_of_xdisp (void) DEFSYM (Qfontification_functions, "fontification-functions"); DEFSYM (Qlong_line_optimizations_in_fontification_functions, "long-line-optimizations-in-fontification-functions"); + DEFSYM (Qmode_line_elt_no, "mode-line-elt-no"); /* Name of the symbol which disables Lisp evaluation in 'display' properties. This is used by enriched.el. */ -- 2.49.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 05 05:36:58 2025 Received: (at 77336-done) by debbugs.gnu.org; 5 Apr 2025 09:36:58 +0000 Received: from localhost ([127.0.0.1]:41563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u0zxR-0007tm-VB for submit@debbugs.gnu.org; Sat, 05 Apr 2025 05:36:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36954) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u0zxP-0007tX-Mg for 77336-done@debbugs.gnu.org; Sat, 05 Apr 2025 05:36:56 -0400 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 1u0zxK-0002U1-3b; Sat, 05 Apr 2025 05:36:50 -0400 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=K4UdppPB4OU/YDrWdHDGE1/AbtmdkqFZ8auwrDa5n1c=; b=FamxbGQvgp7L 9hV0HtjqtnrmKcB8hpS98alJqlt53B1RgO7Fwyhvk8HTWFYIoRhTZzCA3KRQVvlH+ySgOXliuu7Gs GYEYj5UgdyN4qdpNxfo/U5S42kk9zqgvlDzDK40To5sCkkKam4CAtu3JFoNHA3rZ4BQFPI9qhHRnu GU+/F63F7IOeRWQcMGL/9DoRpWCPrH+6REOrv8n9Ri2+WfKxZG3zvJ0XuqScut9v8FjDNul9lm+A9 9t4nOyzWXKDYNUknmOi9PmmgVJ22wHMmTHfrlsH4amkvB3hIOxDFvPUYzEr8ZRd57SNhOtJs4bgsA gHZRKN6R2TiYxiuXu7sD7Q==; Date: Sat, 05 Apr 2025 12:36:46 +0300 Message-Id: <86tt73vtjl.fsf@gnu.org> From: Eli Zaretskii To: Pengji Zhang In-Reply-To: <877c42u36s.fsf@pengjiz.com> (message from Pengji Zhang on Wed, 02 Apr 2025 21:02:19 +0800) Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines References: <87iknt4e71.fsf@pengjiz.com> <86tt7c8a6a.fsf@gnu.org> <871pueagjo.fsf@pengjiz.com> <86zfh24tim.fsf@gnu.org> <87ldslho4n.fsf@pengjiz.com> <86cydx4ajt.fsf@gnu.org> <877c42u36s.fsf@pengjiz.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77336-done Cc: 77336-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pengji Zhang > Cc: 77336@debbugs.gnu.org > Date: Wed, 02 Apr 2025 21:02:19 +0800 > > Eli Zaretskii writes: > > >> From: Pengji Zhang > >> Cc: 77336@debbugs.gnu.org > >> Date: Mon, 31 Mar 2025 11:31:36 +0800 > >> > >> Eli Zaretskii writes: > >> > >> >> Is casting the 'Lisp_Object' to a number acceptable here? > >> > > >> > No, because Lisp_Object could be a struct (if Emacs was configured with > >> > "--enable-check-lisp-object-type"). > >> > >> Sorry I did not make it clear. I meant 'make_fixnum(XLI(elt))'. I > >> suppose 'XLI' will handle that case correctly? > > > > I'd prefer not to do that unless there's no other reasonable solution. > > > >> I am actually concerned that there could be a collision between two > >> different 'elt's, e.g., a symbol and a string, because 'make_fixnum' > >> alters the tag of 'elt'. I think it might be fine because 'elt' should > >> always be a 'Lisp_String' when this is called. > > > > Sorry, I don't understand: what do you mean by "alters the tag of > > 'elt'", and how could make_fixnum affect 'elt'? > > It does not affect 'elt'. I meant that 'make_fixnum' may change the > value of the number from the tagged pointer: > > INLINE Lisp_Object > make_fixnum (EMACS_INT n) > { > ... > { > n &= INTMASK; > n += (int0 << VALBITS); > } > return XIL (n); > } > > So if I understand it correctly, that means 'make_fixnum(XLI(x))' could > give the same result for, e.g., a fixnum and a string. > > >> > A global variable is what I had in mind. I don't see why it would be > >> > less clean. > >> > >> It is just that maintaining a global state is not as tasteful to me. If > >> 'make_fixnum(XLI(elt))' is not good here, I am happy to go this way. > > > > Yes, a global variable is cleaner than using XLI for this purpose. > > Thanks. Please see the attached patch. Thanks, I've now installed this on the master branch, and I'm therefore closing this bug. From unknown Fri Jun 20 20:12:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 03 May 2025 11:24:14 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator