From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 08 18:22:31 2024 Received: (at submit) by debbugs.gnu.org; 8 Sep 2024 22:22:31 +0000 Received: from localhost ([127.0.0.1]:60258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIg-0007xI-W1 for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:54178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snQIe-0007x8-Oh for submit@debbugs.gnu.org; Sun, 08 Sep 2024 18:22:29 -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 1snQIY-0005W1-GU for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:24 -0400 Received: from smtp-26.smtpout.orange.fr ([80.12.242.26] helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1snQIV-0005hs-8G for bug-gnu-emacs@gnu.org; Sun, 08 Sep 2024 18:22:22 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id nQINsls3DQYYunQINsjKHw; Mon, 09 Sep 2024 00:22:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725834133; bh=aTiBrMz/4VEju3pejI30rqdqFLvppE9BaHgA7BcVt1s=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=QmucgkLvonCqqKx0fgJ7eTZwHwq8xza/o+8WS7WH/mqnO/H3bnVabUGZ086OKwcaq dzL3yrC4Z07PvJejRHBE6Ap/dvo7p4mEN0po3oS1C4gD+AMcuXoPuCR8plWBxMjoqv NCdD9UMX+NVkQteHXTRFT9WRakbn3z3aJjAJ4f5tUqn0Y2BGpBbU0ZGzbZzj9PfGAV XSGfBe2GiAR5Iab1aiBP52qkHr4eM8UFGLzyeOl1PGayNsJAbuZo0dANOnR0l0BaDq c84oCduQ4JPkxd19IJk28N4vP1aZFa7tn1nrV9v8+S4YqGBU6bgPnG+QMzptv60TQQ Tswy/223iOHEA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 09 Sep 2024 00:22:13 +0200 X-ME-IP: 2.7.225.247 Message-ID: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> Date: Mon, 9 Sep 2024 00:22:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr, en-US To: bug-gnu-emacs@gnu.org From: David Ponce Subject: 31.0.50; buffer-text-pixel-size vs. newlines Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=80.12.242.26; envelope-from=da_vid@orange.fr; helo=smtp.smtpout.orange.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) 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: -2.3 (--) Hello, Its seems that the function `buffer-text-pixel-size' is not working as described when there are newlines in the buffer. Here is a quick illustration (on my laptop (frame-char-width) returns 12 pixels): ;; As expected. (with-temp-buffer (insert "abcdef") (car (buffer-text-pixel-size nil nil t))) 72 ;; I suppose it is as expected because newline is not displayed. (with-temp-buffer (insert "\n") (car (buffer-text-pixel-size nil nil t))) 0 ;; ? (with-temp-buffer (insert "abcd\nef") (car (buffer-text-pixel-size nil nil t))) 48 The doc string of `buffer-text-pixel-size' mentions: "Return size of whole text of BUFFER-OR-NAME in WINDOW." So ,I expect that the last example will return 72px (6 x 12px) + 0px for the newline. But the result is 48px, which means that all the text after the first newline is not counted. This also impacts "string-pixel-width" which is supposed to return the pixel size of the passed string, not part of it: (string-pixel-width "abcdef") => 72 (string-pixel-width "\n") => 0 (string-pixel-width "abcd\nef") => 48 (string-pixel-width "abcd\nef\ngh") => 48 At least this limitation should be mentioned in the doc string? A possible fix for `string-pixel-width' could be to remove all the newlines from the passed string before to call `buffer-text-pixel-size'? Something like this: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 4cdb065feeb..c68b3b37f9b 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -406,6 +406,11 @@ string-pixel-width face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (insert string) + ;; Remove newlines. + (forward-line 0) + (while (not (bobp)) + (delete-char -1) + (forward-line 0)) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties Thanks! In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) Repository revision: 2ce0d397b12cafcb3e1ac5630bc3fbca61bd6b87 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 40 (KDE Plasma) Configured using: 'configure --with-x-toolkit=gtk3 --with-cairo-xcb --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 09 07:34:54 2024 Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 11:34:54 +0000 Received: from localhost ([127.0.0.1]:60799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sncfW-0007xc-DV for submit@debbugs.gnu.org; Mon, 09 Sep 2024 07:34:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sncfU-0007xJ-Ln for 73129@debbugs.gnu.org; Mon, 09 Sep 2024 07:34:53 -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 1sncfL-0000p3-4L; Mon, 09 Sep 2024 07:34:43 -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=7Uu8oiTo2/AJSvHTX76jY/IyxJy2DhIaagACPV8Aahs=; b=e8199RfdTpC8 BeG7SOE/GyEM+fONPpkGxTTiP+3bQGRbCW0DjLiKUMvXd7qIGotjZsqHti/bf5I8V0K0/RQbitWNT ZuLlJwHJ9/uGQoiN5K1rVQdhny/vv9oAbdH6WQMfmOdQsWG5lgAwnvMqEH0kGP/hi3f+XWVusvZLm aXjXFX9pAM3s6WTnblZB7+WoeSzExW8JBn3ujrFRjso+mmHpyMpGMqqTFM/x9n4vKVRDIbv6yD8C8 4XMVfmCTII/SakJm2ZP/nnOGvjdT6PqBTRbWwaectj9fjnxBzqrgKjjO28zKLJuCTQQEz+ZTdMhJ7 EN28B1kh6XWXotQTP7RHgg==; Date: Mon, 09 Sep 2024 14:34:38 +0300 Message-Id: <868qw1vz5d.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> (bug-gnu-emacs@gnu.org) Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73129 Cc: 73129@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 (---) > Date: Mon, 9 Sep 2024 00:22:11 +0200 > From: David Ponce via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Its seems that the function `buffer-text-pixel-size' is not working > as described when there are newlines in the buffer. Here is a quick > illustration (on my laptop (frame-char-width) returns 12 pixels): > > ;; As expected. > (with-temp-buffer > (insert "abcdef") > (car (buffer-text-pixel-size nil nil t))) > 72 > > ;; I suppose it is as expected because newline is not displayed. > (with-temp-buffer > (insert "\n") > (car (buffer-text-pixel-size nil nil t))) > 0 > > ;; ? > (with-temp-buffer > (insert "abcd\nef") > (car (buffer-text-pixel-size nil nil t))) > 48 The above is the intended behavior, assuming that the default width of the frame's characters is 12 in your case. The maximum width of the text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels. The part after the newline is only 2 characters, so it is narrower, and does not affect the result. IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text, not is total width. > The doc string of `buffer-text-pixel-size' mentions: > > "Return size of whole text of BUFFER-OR-NAME in WINDOW." It also says: The return value is a cons of the maximum pixel-width of any text line and the pixel-height of all the text lines of the buffer specified by BUFFER-OR-NAME. Does the above explain the behavior you see? This is not a bug. > So ,I expect that the last example will return 72px (6 x 12px) + 0px > for the newline. But the result is 48px, which means that all the > text after the first newline is not counted. Your expectations are incorrect, see above. > This also impacts "string-pixel-width" which is supposed to return > the pixel size of the passed string, not part of it: > > (string-pixel-width "abcdef") => 72 > (string-pixel-width "\n") => 0 > (string-pixel-width "abcd\nef") => 48 > (string-pixel-width "abcd\nef\ngh") => 48 Yes. If you want the _total_ width of a string, remove the newlines from it. I think I understand the source of your confusion, so I have now clarified these subtle points in the doc strings of window-text-pixel-size, buffer-text-pixel-size, and string-pixel-width. > At least this limitation should be mentioned in the doc string? I've now done so (and they are not limitations, but conscious design decisions which have good reasons). > A possible fix for `string-pixel-width' could be to remove all > the newlines from the passed string before to call > `buffer-text-pixel-size'? Something like this: Thanks, but that would be the wrong thing. If the caller wants a total width, the caller should remover the newlines or measure each substring separately and add the results. May I ask where and for what purpose did you need to measure pixel width of a string that included newlines? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 09 08:56:33 2024 Received: (at 73129) by debbugs.gnu.org; 9 Sep 2024 12:56:34 +0000 Received: from localhost ([127.0.0.1]:60844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sndwX-0003sp-4s for submit@debbugs.gnu.org; Mon, 09 Sep 2024 08:56:33 -0400 Received: from smtp-73.smtpout.orange.fr ([80.12.242.73]:63387 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sndwU-0003sg-IM for 73129@debbugs.gnu.org; Mon, 09 Sep 2024 08:56:31 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id ndwMsFlX3lL4CndwMsRuVc; Mon, 09 Sep 2024 14:56:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725886585; bh=gbuRedXSOstkWt6HYSP7HCCkK8tGM4TgdTbOvias5Wo=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=GpysuSSCa7A/y7UZ4TFbHPIa90clHXDUXAC0zZmvM1TGIdJLcar4yh9Zbt54QcMba xav6bKDs9hXGNo2v3CaPvZi8PS9/Sv8Gs0hi9WJpnJaAiQjI7NZCzLJMv/+s9ibgnB n6BsOrHu2TB/1iB5ddlpzH+QhkGvYGX+IADcLcRTapZIFMtS2uheqrG0TiS0h6CiDw 7s0YRvfp4MqrCUIrdhlCzpYGJGxkWkQj5HC/ke5WCp/6gutxSMFudbL51AU7ilQTX5 SpaVMYkdak3WxwYaz3HPUs0J0tucTK+wgNJ8SHYNqMn4fxMKev5+d8oU7DKoULHR9G zoqA6k52McV7g== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 09 Sep 2024 14:56:25 +0200 X-ME-IP: 2.7.225.247 Message-ID: <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> Date: Mon, 9 Sep 2024 14:56:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines To: Eli Zaretskii References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> <868qw1vz5d.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <868qw1vz5d.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 73129 Cc: 73129@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.0 (-) On 09/09/2024 1:34 PM, Eli Zaretskii wrote: >> Date: Mon, 9 Sep 2024 00:22:11 +0200 >> From: David Ponce via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Its seems that the function `buffer-text-pixel-size' is not working >> as described when there are newlines in the buffer. Here is a quick >> illustration (on my laptop (frame-char-width) returns 12 pixels): >> >> ;; As expected. >> (with-temp-buffer >> (insert "abcdef") >> (car (buffer-text-pixel-size nil nil t))) >> 72 >> >> ;; I suppose it is as expected because newline is not displayed. >> (with-temp-buffer >> (insert "\n") >> (car (buffer-text-pixel-size nil nil t))) >> 0 >> >> ;; ? >> (with-temp-buffer >> (insert "abcd\nef") >> (car (buffer-text-pixel-size nil nil t))) >> 48 > > The above is the intended behavior, assuming that the default width of > the frame's characters is 12 in your case. The maximum width of the > text "abcd\nef" is 4 characters ("abcd"), which are 12*4 = 48 pixels. > The part after the newline is only 2 characters, so it is narrower, > and does not affect the result. > > IOW, buffer-text-pixel-size measures the 2D _dimensions_ of the text, > not is total width. Thanks for clarifying. > >> The doc string of `buffer-text-pixel-size' mentions: >> >> "Return size of whole text of BUFFER-OR-NAME in WINDOW." > > It also says: > > The return value is a cons of the maximum pixel-width of any text > line and the pixel-height of all the text lines of the buffer > specified by BUFFER-OR-NAME. > > Does the above explain the behavior you see? Yes > > This is not a bug. > >> So ,I expect that the last example will return 72px (6 x 12px) + 0px >> for the newline. But the result is 48px, which means that all the >> text after the first newline is not counted. > > Your expectations are incorrect, see above. > >> This also impacts "string-pixel-width" which is supposed to return >> the pixel size of the passed string, not part of it: >> >> (string-pixel-width "abcdef") => 72 >> (string-pixel-width "\n") => 0 >> (string-pixel-width "abcd\nef") => 48 >> (string-pixel-width "abcd\nef\ngh") => 48 > > Yes. If you want the _total_ width of a string, remove the newlines > from it. > > I think I understand the source of your confusion, so I have now > clarified these subtle points in the doc strings of > window-text-pixel-size, buffer-text-pixel-size, and > string-pixel-width. Thanks you very much! > >> At least this limitation should be mentioned in the doc string? > > I've now done so (and they are not limitations, but conscious design > decisions which have good reasons). > >> A possible fix for `string-pixel-width' could be to remove all >> the newlines from the passed string before to call >> `buffer-text-pixel-size'? Something like this: > > Thanks, but that would be the wrong thing. If the caller wants a > total width, the caller should remover the newlines or measure each > substring separately and add the results. I agree now that you clarified the behavior of `string-pixel-width' when it is passed a string with embedded newlines. > May I ask where and for what purpose did you need to measure pixel > width of a string that included newlines? Actually, the current behavior doesn't really impact my current work. I just noticed it while experimenting, having passed to `string-pixel-width' a buffer substring that spanned multiple lines. And I thought it would be good to, at least, clarify the behavior I observed ;-) You can close this bug. Many thanks again for your time and assistance! From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 09 09:25:21 2024 Received: (at 73129-done) by debbugs.gnu.org; 9 Sep 2024 13:25:21 +0000 Received: from localhost ([127.0.0.1]:60915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sneOP-0005gK-Bh for submit@debbugs.gnu.org; Mon, 09 Sep 2024 09:25:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sneOM-0005YF-VG for 73129-done@debbugs.gnu.org; Mon, 09 Sep 2024 09:25:19 -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 1sneOD-0006Lk-Sl; Mon, 09 Sep 2024 09:25:09 -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=pPrZfRaWRD42r2mS28Us6x2WRCTxeF7URaWwDgyzI/g=; b=L7NN7RPmCV3W Osnc4hye+Ut7CkPuZhCHDJNvbC2TjWm4nO6+/KINzaLOWCRF3LEb7jxSgF0xDAadwEoBIeIwX24jG /5zwQjxN4ayN4cHqYRAEBluFRt3bd0zfRXF4RLD0wNMZ7JWuo2TEuqLZOguUrRhgfDi0fC+iXC4ZK 18I2Te8pwVeIclK0POarGKPGNFqUgrd7sYPB/Dfw4MlF46UXYa54swbnqpflbxCTAo+OpYOaQkFmI egykhNIipy7lH/KCSm6FC+xdmYqtu4NwgO3cdFReDfHZ7R5CdbuRyXLh3Qxi/MTVNsf0K8yECYfv6 wsjbSuMnEK4IXiwnVqgVxw==; Date: Mon, 09 Sep 2024 16:25:07 +0300 Message-Id: <86wmjlufgs.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> (message from David Ponce on Mon, 9 Sep 2024 14:56:22 +0200) Subject: Re: bug#73129: 31.0.50; buffer-text-pixel-size vs. newlines References: <76135c62-bc5c-4bcd-9caa-ccd9f939d78f@orange.fr> <868qw1vz5d.fsf@gnu.org> <20985fc8-7b1f-409e-9f89-3b976a6f5150@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73129-done Cc: 73129-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 (---) > Date: Mon, 9 Sep 2024 14:56:22 +0200 > Cc: 73129@debbugs.gnu.org > From: David Ponce > > > May I ask where and for what purpose did you need to measure pixel > > width of a string that included newlines? > > Actually, the current behavior doesn't really impact my current work. I > just noticed it while experimenting, having passed to `string-pixel-width' > a buffer substring that spanned multiple lines. And I thought it would be > good to, at least, clarify the behavior I observed ;-) > > You can close this bug. Thanks, closing. From unknown Fri Aug 08 22:15:25 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 08 Oct 2024 11:24:09 +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