From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 17 18:04:21 2024 Received: (at submit) by debbugs.gnu.org; 17 Aug 2024 22:04:22 +0000 Received: from localhost ([127.0.0.1]:55040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfRX3-0006Ld-8x for submit@debbugs.gnu.org; Sat, 17 Aug 2024 18:04:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:40506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfRX0-0006LU-4k for submit@debbugs.gnu.org; Sat, 17 Aug 2024 18:04:19 -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 1sfRWL-0000oR-Sz for bug-gnu-emacs@gnu.org; Sat, 17 Aug 2024 18:03:38 -0400 Received: from smtp-72.smtpout.orange.fr ([80.12.242.72] helo=msa.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 1sfRWH-0003MD-0c for bug-gnu-emacs@gnu.org; Sat, 17 Aug 2024 18:03:36 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id fRW6slCzTQRySfRW6sTElJ; Sun, 18 Aug 2024 00:03:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1723932204; bh=xHiS+w4y8rC0eBjQuK4nJa9QBB1YnZlG/pvDMvonVPM=; h=Message-ID:Date:MIME-Version:To:From:Subject; b=H5UqWgnq594rEnSDi2em3Mm3Ysqo4S8YxDWoaObEWYvZk0Yk3JILzN37SZmFH48Tb cwapRKPdVcdhczNzWpPPrieL8Yf1pdSQmWm2kwBQPZzFYwVNB0WsF/Lis/lR1ytSlz Pn8G6oqftiumFjM0cwSW9+aw3aIvzJcTS0kJpLj12l/IICF0TmizRcL4Z4arc/S2s5 Ijx634RWSZF52IC/ZD6MddgyRcl3KLPqRX6t6e20hICtrma4ggmf/LlsRsdq+FvMPc Vs/FLf+57uxPq3Y/joR374r/EFd3Ko4Y5WZwttp57klFTPhI1ue8Od7McRUmPwNN1n x05xiz59TmYLQ== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 18 Aug 2024 00:03:24 +0200 X-ME-IP: 2.7.225.247 Content-Type: multipart/mixed; boundary="------------uPXkRH5auj0C9sXHDP0kdNMG" Message-ID: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> Date: Sun, 18 Aug 2024 00:03:22 +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; Proposal to improve string-pixel-width Received-SPF: pass client-ip=80.12.242.72; envelope-from=da_vid@orange.fr; helo=msa.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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 (--) This is a multi-part message in MIME format. --------------uPXkRH5auj0C9sXHDP0kdNMG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, The function string-pixel-width is essential for calculating pixel dimensions, especially for UI components. And in this context this function can be called very often when the display is refreshed. I propose the attached patch to make string-pixel-width faster while using less memory, as shown by the following results of a basic benchmark run in emacs -Q to compare the current implementation and this proposal: ;; Basic benchmark (let* ((text1 (make-string 1000 ?x)) (text2 (propertize text1 'line-prefix "XXXX "))) (list (string-pixel-width text1) (string-pixel-width text2) (progn (garbage-collect) (benchmark-run 10000 (string-pixel-width text1))) (progn (garbage-collect) (benchmark-run 10000 (string-pixel-width text2))) ;;(insert text "\n") )) ;; Result with current implementation (4 run): (12000 12000 (1.854707611 17 0.120106147) (1.884129905 17 0.12258791599999996)) (12000 12000 (1.846544798 17 0.12243524500000003) (1.8822177530000002 17 0.12349287399999997)) (12000 12000 (1.851244125 17 0.12162041699999998) (1.860517709 17 0.12352999599999998)) (12000 12000 (1.8542218929999998 17 0.12164553900000001) (1.856302462 17 0.122891689)) ;; Result with proposed implementation (4 run): (12000 12000 (1.698974522 0 0.0) (1.727446 2 0.014782505999999973)) (12000 12000 (1.701800124 0 0.0) (1.728024111 2 0.014718454999999908)) (12000 12000 (1.6850850800000001 0 0.0) (1.732370238 2 0.014801913000000111)) (12000 12000 (1.7356390130000001 0 0.0) (1.7858915800000001 2 0.014816158000000135)) From my observations, the new implementation is around 8% faster, and trigger less GC. When there is no line-prefix property to remove, the new implementation doesn't trigger any GC after 10000 runs. Otherwise, only 2 GC are triggered instead of 17. Maybe this proposal might be of interest, or at least provide some ideas for improvement. Thanks In GNU Emacs 31.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-08-17 Repository revision: 40eecd594ac60f38b6729fd9cf3474a8b9d133b9 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 --------------uPXkRH5auj0C9sXHDP0kdNMG Content-Type: text/x-patch; charset=UTF-8; name="improve-string-pixel-width-V00.patch" Content-Disposition: attachment; filename="improve-string-pixel-width-V00.patch" Content-Transfer-Encoding: base64 MjAyNC0wOC0xNyAgRGF2aWQgUG9uY2UgIDxkYV92aWRAb3JhbmdlLmZyPgoKCVR3ZWFrIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiBzdHJpbmctcGl4ZWwtd2lkdGggdG8gcnVuIGZhc3RlciBh bmQKCXVzZSBsZXNzIG1lbW9yeS4KCgkqIHN1YnIteC5lbCAoc3RyaW5nLS1waXhlbC13aWR0 aC1idWZmZXIpOiBOZXcgdmFyaWFibGUgYW5kIGZ1bmN0aW9uLgoJKHN0cmluZy0tcGl4ZWwt d2lkdGgpOiBVc2UgaXQuICBQcmVmZXIgYHJlbW92ZS10ZXh0LXByb3BlcnRpZXMnIHRvCglg cHJvcGVydGl6ZScgdG8gYXZvaWQgY3JlYXRpbmcgYSBuZXcgc3RyaW5nIG9uIGVhY2ggY2Fs bC4KCgpkaWZmIC0tZ2l0IGEvbGlzcC9lbWFjcy1saXNwL3N1YnIteC5lbCBiL2xpc3AvZW1h Y3MtbGlzcC9zdWJyLXguZWwKaW5kZXggMDU4YzA2YmM1ZjYuLjFmNTY0ZmE1NjI4IDEwMDY0 NAotLS0gYS9saXNwL2VtYWNzLWxpc3Avc3Vici14LmVsCisrKyBiL2xpc3AvZW1hY3MtbGlz cC9zdWJyLXguZWwKQEAgLTMzNiw2ICszMzYsMjMgQEAgbmFtZWQtbGV0CiAgICAgICAoY2wt bGFiZWxzICgoLG5hbWUgLGZhcmdzIC4gLGJvZHkpKSAjJyxuYW1lKQogICAgICAgLiAsYWFy Z3MpKSkKIAorKGRlZnZhciBzdHJpbmctLXBpeGVsLXdpZHRoLWJ1ZmZlciBuaWwpCisKKyhk ZWZzdWJzdCBzdHJpbmctLXBpeGVsLXdpZHRoLWJ1ZmZlciAoKQorICAiR2V0IGludGVybmFs IGJ1ZmZlciB1c2VkIHRvIGNhbGN1bGF0ZSB0aGUgcGl4ZWwgd2lkdGggb2YgYSBzdHJpbmcu IgorICA7OyBLZWVwaW5nIGEgd29yayBidWZmZXIgYXJvdW5kIGlzIG1vcmUgZWZmaWNpZW50 IHRoYW4gY3JlYXRpbmcgYQorICA7OyBuZXcgdGVtcG9yYXJ5IGJ1ZmZlciBvbiBlYWNoIGNh bGwgdG8gYHN0cmluZy1waXhlbC13aWR0aCcuCisgIChpZiAoYnVmZmVyLWxpdmUtcCBzdHJp bmctLXBpeGVsLXdpZHRoLWJ1ZmZlcikKKyAgICAgIHN0cmluZy0tcGl4ZWwtd2lkdGgtYnVm ZmVyCisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgKGdldC1idWZmZXItY3JlYXRlICIgKnN0 cmluZy1waXhlbC13aWR0aCoiIHQpCisgICAgICA7OyBJZiBgZGlzcGxheS1saW5lLW51bWJl cnMnIGlzIGVuYWJsZWQgaW4gaW50ZXJuYWwgYnVmZmVycworICAgICAgOzsgKGUuZy4gZ2xv YmFsbHkpLCBpdCBicmVha3Mgd2lkdGggY2FsY3VsYXRpb24gKGJ1ZyM1OTMxMSkuCisgICAg ICA7OyBEaXNhYmxlIGxpbmUtcHJlZml4IGFuZCB3cmFwLXByZWZpeCwgZm9yIHRoZSBzYW1l IHJlYXNvbi4KKyAgICAgIDs7IFNldCBhbGwgdGhlc2UgdmFyaWFibGVzIG9ubHkgb25lIHRp bWUgaGVyZTogdGhleQorICAgICAgOzsgYXV0b21hdGljYWxseSBiZWNvbWUgYnVmZmVyLWxv Y2FsIHdoZW4gc2V0LgorICAgICAgKHNldHEgZGlzcGxheS1saW5lLW51bWJlcnMgbmlsIGxp bmUtcHJlZml4IG5pbCB3cmFwLXByZWZpeCBuaWwpCisgICAgICAoc2V0cSBzdHJpbmctLXBp eGVsLXdpZHRoLWJ1ZmZlciAoY3VycmVudC1idWZmZXIpKSkpKQorCiA7OzsjIyNhdXRvbG9h ZAogKGRlZnVuIHN0cmluZy1waXhlbC13aWR0aCAoc3RyaW5nICZvcHRpb25hbCBidWZmZXIp CiAgICJSZXR1cm4gdGhlIHdpZHRoIG9mIFNUUklORyBpbiBwaXhlbHMuCkBAIC0zNDQsMjIg KzM2MSwxOCBAQCBzdHJpbmctcGl4ZWwtd2lkdGgKICAgKGRlY2xhcmUgKGltcG9ydGFudC1y ZXR1cm4tdmFsdWUgdCkpCiAgIChpZiAoemVyb3AgKGxlbmd0aCBzdHJpbmcpKQogICAgICAg MAotICAgIDs7IEtlZXBpbmcgYSB3b3JrIGJ1ZmZlciBhcm91bmQgaXMgbW9yZSBlZmZpY2ll bnQgdGhhbiBjcmVhdGluZyBhCi0gICAgOzsgbmV3IHRlbXBvcmFyeSBidWZmZXIuCi0gICAg KHdpdGgtY3VycmVudC1idWZmZXIgKGdldC1idWZmZXItY3JlYXRlICIgKnN0cmluZy1waXhl bC13aWR0aCoiKQotICAgICAgOzsgSWYgYGRpc3BsYXktbGluZS1udW1iZXJzJyBpcyBlbmFi bGVkIGluIGludGVybmFsIGJ1ZmZlcnMKLSAgICAgIDs7IChlLmcuIGdsb2JhbGx5KSwgaXQg YnJlYWtzIHdpZHRoIGNhbGN1bGF0aW9uIChidWcjNTkzMTEpCi0gICAgICAoc2V0cS1sb2Nh bCBkaXNwbGF5LWxpbmUtbnVtYmVycyBuaWwpCi0gICAgICAoZGVsZXRlLXJlZ2lvbiAocG9p bnQtbWluKSAocG9pbnQtbWF4KSkKLSAgICAgIDs7IERpc2FibGUgbGluZS1wcmVmaXggYW5k IHdyYXAtcHJlZml4LCBmb3IgdGhlIHNhbWUgcmVhc29uLgotICAgICAgKHNldHEgbGluZS1w cmVmaXggbmlsCi0JICAgIHdyYXAtcHJlZml4IG5pbCkKKyAgICAod2l0aC1jdXJyZW50LWJ1 ZmZlciAoc3RyaW5nLS1waXhlbC13aWR0aC1idWZmZXIpCisgICAgICAoZXJhc2UtYnVmZmVy KQogICAgICAgKGlmIGJ1ZmZlcgogICAgICAgICAgIChzZXRxLWxvY2FsIGZhY2UtcmVtYXBw aW5nLWFsaXN0CiAgICAgICAgICAgICAgICAgICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIg YnVmZmVyCiAgICAgICAgICAgICAgICAgICAgICAgICBmYWNlLXJlbWFwcGluZy1hbGlzdCkp CiAgICAgICAgIChraWxsLWxvY2FsLXZhcmlhYmxlICdmYWNlLXJlbWFwcGluZy1hbGlzdCkp Ci0gICAgICAoaW5zZXJ0IChwcm9wZXJ0aXplIHN0cmluZyAnbGluZS1wcmVmaXggbmlsICd3 cmFwLXByZWZpeCBuaWwpKQorICAgICAgKGluc2VydCBzdHJpbmcpCisgICAgICA7OyBQcmVm ZXIgYHJlbW92ZS10ZXh0LXByb3BlcnRpZXMnIHRvIGBwcm9wZXJ0aXplJyB0byBhdm9pZAor ICAgICAgOzsgY3JlYXRpbmcgYSBuZXcgc3RyaW5nIG9uIGVhY2ggY2FsbC4KKyAgICAgIChy ZW1vdmUtdGV4dC1wcm9wZXJ0aWVzCisgICAgICAgKHBvaW50LW1pbikgKHBvaW50LW1heCkg JyhsaW5lLXByZWZpeCBuaWwgd3JhcC1wcmVmaXggbmlsKSkKICAgICAgIChjYXIgKGJ1ZmZl ci10ZXh0LXBpeGVsLXNpemUgbmlsIG5pbCB0KSkpKSkKIAogOzs7IyMjYXV0b2xvYWQK --------------uPXkRH5auj0C9sXHDP0kdNMG-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 00:43:45 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 04:43:46 +0000 Received: from localhost ([127.0.0.1]:55212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfXlZ-00007i-FQ for submit@debbugs.gnu.org; Sun, 18 Aug 2024 00:43:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfXlX-00007U-CO for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 00:43:44 -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 1sfXig-000540-Mm; Sun, 18 Aug 2024 00:40:46 -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=9J9tRKdpKzbA4kRIUKfL2PBJEGPwsN+yOVkJNfkkDQQ=; b=qBTbCaCuTlQL d3VvWm4vB+NFRlAgjslUusslrxa4LYcm+ptMJfk3IgL0lGwFt+lnDAnIwY//N4X1VIOVVVuyxgA3f J9PUUiL1tpA2wTlJ71FqpWID5qwC3OmWEBTbyMf1LV3aWjYheXuwsHeh9yuLTnl8+vBjhjn8OUTbJ 0vvhouxjkHYBuH6A9xRIZPrX91HKeOcJoj9aKMJ8Lv6x90nRzuSUw/p4emMBpVHG3P14bIY/q6YqL pkTXN7KalJ+bow/Fg2CsaNCAo1qyGUyBywUMzVnX6a1TdBy6XWDvXofCa6DkCWuDH+BvP58xmTggO m0Zn95cbH9aoxiDOg9dTAA==; Date: Sun, 18 Aug 2024 07:40:42 +0300 Message-Id: <86bk1q1m0l.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> (bug-gnu-emacs@gnu.org) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Sun, 18 Aug 2024 00:03:22 +0200 > From: David Ponce via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > The function string-pixel-width is essential for calculating pixel > dimensions, especially for UI components. And in this context this > function can be called very often when the display is refreshed. > > I propose the attached patch to make string-pixel-width faster while > using less memory, as shown by the following results of a basic > benchmark run in emacs -Q to compare the current implementation and this > proposal: > > ;; Basic benchmark > (let* ((text1 (make-string 1000 ?x)) > (text2 (propertize text1 'line-prefix "XXXX "))) > (list > (string-pixel-width text1) > (string-pixel-width text2) > (progn (garbage-collect) > (benchmark-run 10000 (string-pixel-width text1))) > (progn (garbage-collect) > (benchmark-run 10000 (string-pixel-width text2))) > ;;(insert text "\n") > )) > > ;; Result with current implementation (4 run): > (12000 12000 (1.854707611 17 0.120106147) (1.884129905 17 0.12258791599999996)) > > (12000 12000 (1.846544798 17 0.12243524500000003) (1.8822177530000002 17 0.12349287399999997)) > > (12000 12000 (1.851244125 17 0.12162041699999998) (1.860517709 17 0.12352999599999998)) > > (12000 12000 (1.8542218929999998 17 0.12164553900000001) (1.856302462 17 0.122891689)) > > ;; Result with proposed implementation (4 run): > (12000 12000 (1.698974522 0 0.0) (1.727446 2 0.014782505999999973)) > > (12000 12000 (1.701800124 0 0.0) (1.728024111 2 0.014718454999999908)) > > (12000 12000 (1.6850850800000001 0 0.0) (1.732370238 2 0.014801913000000111)) > > (12000 12000 (1.7356390130000001 0 0.0) (1.7858915800000001 2 0.014816158000000135)) > > From my observations, the new implementation is around 8% faster, and > trigger less GC. When there is no line-prefix property to > remove, the new implementation doesn't trigger any GC after 10000 runs. > Otherwise, only 2 GC are triggered instead of 17. > > Maybe this proposal might be of interest, or at least provide some ideas > for improvement. Thanks. The idea SGTM, but I think the implementation needs to cater for the case where more than one execution thread performs this job "in parallel" (however improbable this could sound), so we need to be able to detect when this buffer is "busy". The simplest way is to use some boolean buffer-local variable, which will be set non-nil when the function starts using the buffer and reset to nil when the function is done with its job. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 02:05:52 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 06:05:52 +0000 Received: from localhost ([127.0.0.1]:55311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfZ32-0002sv-4N for submit@debbugs.gnu.org; Sun, 18 Aug 2024 02:05:52 -0400 Received: from smtp-81.smtpout.orange.fr ([80.12.242.81]:63810 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfZ2z-0002sl-4V for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 02:05:50 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id fZ2HswoSpu3XKfZ2Hse7Zb; Sun, 18 Aug 2024 08:05:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1723961107; bh=w3sZPmrcjZQnmES2mhTCE4kHV0nK9V3QPOM511Vg1SA=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=MRbr9NuMLcdUQDvdVIQfy6Dj0m4NX1SN4v9c1WFPapJn6kX3Lk37xbNTh7mBeK9jV na5oW+CQbdU7KLpBk/q1ho2wTOsRhAcO4uQTOdOEZLjvG8yI1zhX+xWc24mVprmFm8 9/etUiSRxGaou50Ryni9wB7EPpQ6UhoN6oUHKuAa8iuIH2kGviVQhN1VVD3fLZvQaJ xKmFOt7/EUSlPwCI4sX3I8keRr+qvUhhwtp59T/KJ0HfeuBWFzCmw/5tIyzHb1eTV9 WHKmnTDBeI3RQ/qRR/5mn3YqEbhe8S6t34YbO7fgQs0aFA55COZAXUxkNV9Rc4fEAX zPbZkHtR3hP9A== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 18 Aug 2024 08:05:07 +0200 X-ME-IP: 2.7.225.247 Message-ID: Date: Sun, 18 Aug 2024 08:05:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <86bk1q1m0l.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: 72689 Cc: 72689@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 18/08/2024 6:40 AM, Eli Zaretskii wrote: >> Date: Sun, 18 Aug 2024 00:03:22 +0200 >> From: David Ponce via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> The function string-pixel-width is essential for calculating pixel >> dimensions, especially for UI components. And in this context this >> function can be called very often when the display is refreshed. >> >> I propose the attached patch to make string-pixel-width faster while >> using less memory, as shown by the following results of a basic >> benchmark run in emacs -Q to compare the current implementation and this >> proposal: >> >> ;; Basic benchmark >> (let* ((text1 (make-string 1000 ?x)) >> (text2 (propertize text1 'line-prefix "XXXX "))) >> (list >> (string-pixel-width text1) >> (string-pixel-width text2) >> (progn (garbage-collect) >> (benchmark-run 10000 (string-pixel-width text1))) >> (progn (garbage-collect) >> (benchmark-run 10000 (string-pixel-width text2))) >> ;;(insert text "\n") >> )) >> >> ;; Result with current implementation (4 run): >> (12000 12000 (1.854707611 17 0.120106147) (1.884129905 17 0.12258791599999996)) >> >> (12000 12000 (1.846544798 17 0.12243524500000003) (1.8822177530000002 17 0.12349287399999997)) >> >> (12000 12000 (1.851244125 17 0.12162041699999998) (1.860517709 17 0.12352999599999998)) >> >> (12000 12000 (1.8542218929999998 17 0.12164553900000001) (1.856302462 17 0.122891689)) >> >> ;; Result with proposed implementation (4 run): >> (12000 12000 (1.698974522 0 0.0) (1.727446 2 0.014782505999999973)) >> >> (12000 12000 (1.701800124 0 0.0) (1.728024111 2 0.014718454999999908)) >> >> (12000 12000 (1.6850850800000001 0 0.0) (1.732370238 2 0.014801913000000111)) >> >> (12000 12000 (1.7356390130000001 0 0.0) (1.7858915800000001 2 0.014816158000000135)) >> >> From my observations, the new implementation is around 8% faster, and >> trigger less GC. When there is no line-prefix property to >> remove, the new implementation doesn't trigger any GC after 10000 runs. >> Otherwise, only 2 GC are triggered instead of 17. >> >> Maybe this proposal might be of interest, or at least provide some ideas >> for improvement. > > Thanks. The idea SGTM, but I think the implementation needs to cater > for the case where more than one execution thread performs this job > "in parallel" (however improbable this could sound), so we need to be > able to detect when this buffer is "busy". The simplest way is to use > some boolean buffer-local variable, which will be set non-nil when the > function starts using the buffer and reset to nil when the function is > done with its job. Thanks. Your point about "parallelism" is quite relevant. However I'm not sure I understand your suggestion to introduce a buffer-local boolean variable. In particular, what to do when the buffer-local flag is set when entering the function? Wait until the flag is reset? Create another buffer? Perhaps for parallelism, using temporary buffers might be a better approach? But I have no idea how much stress would be put on Emacs if thousands of temporary buffers were created/freed during a session? Could you elaborate further? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 02:14:10 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 06:14:10 +0000 Received: from localhost ([127.0.0.1]:55315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfZB4-00035R-DM for submit@debbugs.gnu.org; Sun, 18 Aug 2024 02:14:10 -0400 Received: from mail-pl1-f173.google.com ([209.85.214.173]:44430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfZB1-00035E-OU for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 02:14:08 -0400 Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-20208830de8so15323795ad.1 for <72689@debbugs.gnu.org>; Sat, 17 Aug 2024 23:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723961542; x=1724566342; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=X1tCnuF3kdhXWvs7AV7MpmZkG6+tJEmeuUJgJNWH5lI=; b=d755JELP+lZRHnB4jB1Th5wEXg6mfLjXLJeWFjwafK4Rpy1VRHTDu+lTczFfgkh90J +hA0Pg3JjVQWoWjYpbF+MT4bctmmHzjv+8rdUEiJAkHUUdK1tz/5hSiD9CdMte0n7yPl hhQ1sYd4jBveMezmNuVQWMgXZanZvV+cRv/kWPgxO/w00wTULO18n47HylNr5K2IA1RE Jj1mnFSQJ1Q79q/SGbRPMmqVUS96VOtkyYNQGtyCzAJLw5ks/qPasbJy6UHqr61bFHLI CPJf7Op3BwSryNQcr8z3Xoc1n0BZfpTmzA2/A6+kYT2+fiKmaTdmrfamA3gv2f9PEzvq DHqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723961542; x=1724566342; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X1tCnuF3kdhXWvs7AV7MpmZkG6+tJEmeuUJgJNWH5lI=; b=o2KzZuRTn445ItPds5sXiSYrBYZaydLqcXZebYoYvCTu0OGYCq8+EiuGfRktyJhLNp /PuyRwZpEeg05tuCXAnc+skbbNHpUXdNdVDz24PAnut49BpgrB+LuMhCAxyaV2QvZtQ1 UjY6oubSFnCKIIeSVlD49qIRl8kK+z7CFLJm5sqm5aPoSVxnUXn/arGp+rjSFgQvcHhn 4JbaEPPPXwTOJznSgoUhuT59cE8VOWF+wCv3v4glablDIa+N0mSAjh+mMCHAC9gB97K6 LUcrM3NrPV/H6pDrMg1nIWisNcMb33n2/GY3+Z/gvBdsEhbfg0NYLxXyNVxznU4CUQPb UXtg== X-Forwarded-Encrypted: i=1; AJvYcCW+oJZCESl/GRIeqzoV5dc5tGCB39FH9XUpXZBl1UNJb3lfZdSublhzaCpyeK1fDDM/pIZzajVLt5x9kSM0pNLFguGU6p0= X-Gm-Message-State: AOJu0YwaKQHYQl/UZTWP33x/NYlvEOB6Pzbj7iDks6Zs85JruLRK3OdC QThTI1w1yS2u2Qv+ehjuSOLbmZDpMws8GCcigrOH7tBmMSUaCrQl X-Google-Smtp-Source: AGHT+IFCgmjAN3H05nLSGuaOykxI0h2oaE8wQilCjfASa59RG/Fyil3be6egLbtEdSptHkCtNk3t2g== X-Received: by 2002:a17:902:ea10:b0:1fd:a7a7:20b7 with SMTP id d9443c01a7336-202195eb41fmr51211125ad.30.1723961541701; Sat, 17 Aug 2024 23:12:21 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-201f03a587csm46383195ad.290.2024.08.17.23.12.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Aug 2024 23:12:21 -0700 (PDT) Message-ID: Date: Sat, 17 Aug 2024 23:12:21 -0700 MIME-Version: 1.0 Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width Content-Language: en-US To: David Ponce , 72689@debbugs.gnu.org References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> From: Jim Porter In-Reply-To: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72689 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 8/17/2024 3:03 PM, David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > I propose the attached patch to make string-pixel-width faster while > using less memory, as shown by the following results of a basic > benchmark run in emacs -Q to compare the current implementation and this > proposal:[snip] > - (insert (propertize string 'line-prefix nil 'wrap-prefix nil)) > + (insert string) > + ;; Prefer `remove-text-properties' to `propertize' to avoid > + ;; creating a new string on each call. > + (remove-text-properties > + (point-min) (point-max) '(line-prefix nil wrap-prefix nil)) Is this change safe? I suppose most of the time, this wouldn't matter, but I could imagine a case where a caller wanted the pixel-width of a string that had one of those properties set, and they'd want those properties to be preserved (e.g. if the string was to be inserted into a buffer later). Maybe this code could just check for the presence of 'line-prefix' or 'wrap-prefix' properties and only call 'propertize' if they're in the string? (Or maybe it's even possible to leave the string as-is and compute the width in some way that accounts for these properties in the correct way...) I'm not sure how much this matters, but I always get a bit nervous about a function changing something about one of its arguments when it's not obvious. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 03:37:32 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 07:37:32 +0000 Received: from localhost ([127.0.0.1]:55360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfaTj-0005Ja-Lw for submit@debbugs.gnu.org; Sun, 18 Aug 2024 03:37:32 -0400 Received: from smtp-67.smtpout.orange.fr ([80.12.242.67]:52105 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfaTh-0005JS-HZ for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 03:37:30 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id faT1sg2P05QjafaT1s34dr; Sun, 18 Aug 2024 09:36:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1723966608; bh=Jko2O3hDQJ3wePrANbubTLZlRVxmo4e6yAQAW/CrZOw=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Og3ohCnEUcog9mBvMTXinkTrbu1R6D8+JHCZ2z3uNZYM1L7h3EbCFQsFUHN56siBx JHldYJbafBxVku3sw2ZSNONc2nPQyZpiqCrf48WfqQxiLsMftro6+AB4LKnPq5omxn oMKJScUMfbaNRZPGrmMCDks57wNwViDOlDSiHC58RI4kxz1h0k2HtRVP73xAizGo2M +pVFY4iY3FDM3zgCsoQo2FegapUSX+42lEUiQ62PXSkKx/vLCtotQi7Fny0z/bYENN JLttfaQ4i81M+JcBf1BvYMiZAFJ0Inuo2RL45uhepT7w43pUEtejlF5/Has4NYzeGq y8OWcPwn+c4HA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sun, 18 Aug 2024 09:36:48 +0200 X-ME-IP: 2.7.225.247 Message-ID: Date: Sun, 18 Aug 2024 09:36:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Jim Porter References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> Content-Language: fr, en-US From: David Ponce In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 72689 Cc: Eli Zaretskii , 72689@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 18/08/2024 8:12 AM, Jim Porter wrote: > On 8/17/2024 3:03 PM, David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >> I propose the attached patch to make string-pixel-width faster while >> using less memory, as shown by the following results of a basic >> benchmark run in emacs -Q to compare the current implementation and this >> proposal:[snip] > >> -      (insert (propertize string 'line-prefix nil 'wrap-prefix nil)) >> +      (insert string) >> +      ;; Prefer `remove-text-properties' to `propertize' to avoid >> +      ;; creating a new string on each call. >> +      (remove-text-properties >> +       (point-min) (point-max) '(line-prefix nil wrap-prefix nil)) > > Is this change safe? I suppose most of the time, this wouldn't matter, but I could imagine a case where a caller wanted the pixel-width of a string that had one of those properties set, and they'd want those properties to be preserved (e.g. if the string was to be inserted into a buffer later). > > Maybe this code could just check for the presence of 'line-prefix' or 'wrap-prefix' properties and only call 'propertize' if they're in the string? (Or maybe it's even possible to leave the string as-is and compute the width in some way that accounts for these properties in the correct way...) > > I'm not sure how much this matters, but I always get a bit nervous about a function changing something about one of its arguments when it's not obvious. My implementation proposal does not change the behavior of the function. It is just an attempt to improve its performance. As far as I am concerned I do not think that the values ​​of line-prefix, wrap prefix and display-line-numbers should be taken into account because the number of pixels of a string should not depend on the position where this string is displayed, but only on its own display attributes like faces and other display properties. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 05:16:11 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 09:16:11 +0000 Received: from localhost ([127.0.0.1]:55410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfc1C-0007zQ-S1 for submit@debbugs.gnu.org; Sun, 18 Aug 2024 05:16:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfc1A-0007z8-RX for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 05:16:09 -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 1sfc0O-0007aV-Rc; Sun, 18 Aug 2024 05:15:20 -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=cWLn8Aaud0zYh2SsCfowHobyQ/XCxjWERydOn2E1pf8=; b=KGdNQVTlEhM7 y8i1e3+r0zz3w8/fjrqdP+fdNxjedE1d8aa+x8FVbC9l9NIEy18GfwJ2SwErFZ5sVsTwjshdr55PI 9h3UM1SMNSRRW1TEGz6YWMT44C/jg+S5eHrCPqD9eCfr3ciKHdoRPDKDO0hzUFxrGHdq6BHFP1ZyA jL3Ipsjk9ndtpTMoNxCPaIBf88oXiMKE1M4DNQUQjME9Sx/qY7WwB2s7b/82vkpPGCA5c6iIQGND6 NnE/nFqKLTf8fecOreYlA94/43AtKcBsMqftHZJPhTNpskiCTcV0oqbWN1pgl6uG/urkuccLEWWMc ztRsY/62Htwi8W0ya7KRLA==; Date: Sun, 18 Aug 2024 12:15:14 +0300 Message-Id: <8634n219b1.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: (message from David Ponce on Sun, 18 Aug 2024 08:05:04 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Sun, 18 Aug 2024 08:05:04 +0200 > Cc: 72689@debbugs.gnu.org > From: David Ponce > > On 18/08/2024 6:40 AM, Eli Zaretskii wrote: > >> Date: Sun, 18 Aug 2024 00:03:22 +0200 > >> From: David Ponce via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" > >> > >> The function string-pixel-width is essential for calculating pixel > >> dimensions, especially for UI components. And in this context this > >> function can be called very often when the display is refreshed. > >> > >> I propose the attached patch to make string-pixel-width faster while > >> using less memory, as shown by the following results of a basic > >> benchmark run in emacs -Q to compare the current implementation and this > >> proposal: > >> > >> ;; Basic benchmark > >> (let* ((text1 (make-string 1000 ?x)) > >> (text2 (propertize text1 'line-prefix "XXXX "))) > >> (list > >> (string-pixel-width text1) > >> (string-pixel-width text2) > >> (progn (garbage-collect) > >> (benchmark-run 10000 (string-pixel-width text1))) > >> (progn (garbage-collect) > >> (benchmark-run 10000 (string-pixel-width text2))) > >> ;;(insert text "\n") > >> )) > >> > >> ;; Result with current implementation (4 run): > >> (12000 12000 (1.854707611 17 0.120106147) (1.884129905 17 0.12258791599999996)) > >> > >> (12000 12000 (1.846544798 17 0.12243524500000003) (1.8822177530000002 17 0.12349287399999997)) > >> > >> (12000 12000 (1.851244125 17 0.12162041699999998) (1.860517709 17 0.12352999599999998)) > >> > >> (12000 12000 (1.8542218929999998 17 0.12164553900000001) (1.856302462 17 0.122891689)) > >> > >> ;; Result with proposed implementation (4 run): > >> (12000 12000 (1.698974522 0 0.0) (1.727446 2 0.014782505999999973)) > >> > >> (12000 12000 (1.701800124 0 0.0) (1.728024111 2 0.014718454999999908)) > >> > >> (12000 12000 (1.6850850800000001 0 0.0) (1.732370238 2 0.014801913000000111)) > >> > >> (12000 12000 (1.7356390130000001 0 0.0) (1.7858915800000001 2 0.014816158000000135)) > >> > >> From my observations, the new implementation is around 8% faster, and > >> trigger less GC. When there is no line-prefix property to > >> remove, the new implementation doesn't trigger any GC after 10000 runs. > >> Otherwise, only 2 GC are triggered instead of 17. > >> > >> Maybe this proposal might be of interest, or at least provide some ideas > >> for improvement. > > > > Thanks. The idea SGTM, but I think the implementation needs to cater > > for the case where more than one execution thread performs this job > > "in parallel" (however improbable this could sound), so we need to be > > able to detect when this buffer is "busy". The simplest way is to use > > some boolean buffer-local variable, which will be set non-nil when the > > function starts using the buffer and reset to nil when the function is > > done with its job. > > Thanks. Your point about "parallelism" is quite relevant. However > I'm not sure I understand your suggestion to introduce a buffer-local > boolean variable. In particular, what to do when the buffer-local > flag is set when entering the function? Wait until the flag is > reset? Create another buffer? The latter, I think. > Perhaps for parallelism, using temporary buffers might be a better > approach? But I have no idea how much stress would be put on Emacs if > thousands of temporary buffers were created/freed during a session? > > Could you elaborate further? I think you understood the issue, and just creating a new buffer if the "normal" one is "taken" should be good enough. I don't expect this situation to be a frequent one, so creating too many buffers should not be a danger. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 05:24:07 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 09:24:07 +0000 Received: from localhost ([127.0.0.1]:55420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfc8t-0008D9-EQ for submit@debbugs.gnu.org; Sun, 18 Aug 2024 05:24:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfc8s-0008Cf-5A for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 05:24:06 -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 1sfc85-0008Er-4U; Sun, 18 Aug 2024 05:23:19 -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=+7u74pGIp6EJ6++lp25lotKLFVKVBFzzybnGhgliqDU=; b=HNB2XFi3Mzyc eUcrflCtZCLtRz4WWaBZMFLomEDf3Zc3FIO4U+XjgPkEbym6kAnwJZ3BhxX+8bvunfckiZKcaRMmp oudDiULyFADG2pyX9ctrbcesqNzrx33eCFjEeZ1ERu3d8IeiOBdlGwvrULwrScu6fj6qW/2I5srat DzJCWgcXdCh8gO92IEwWVXWsTUz6SItIe0TrQJtlsw28Te4doyQcPv9zg0vVwxhsW4nEACwmsYKn1 dE0VEdgutVfAFRASZkqlbNCfzXWKoBvTYpO7xxmTrXAL6/+pNKN5lm/81eFXWZanrRG6rf1XoMWJB xza+WNLkxSt+VaMipv20sA==; Date: Sun, 18 Aug 2024 12:23:14 +0300 Message-Id: <86zfpayykd.fsf@gnu.org> From: Eli Zaretskii To: Jim Porter In-Reply-To: (message from Jim Porter on Sat, 17 Aug 2024 23:12:21 -0700) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: da_vid@orange.fr, 72689@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: Sat, 17 Aug 2024 23:12:21 -0700 > From: Jim Porter > > On 8/17/2024 3:03 PM, David Ponce via Bug reports for GNU Emacs, the > Swiss army knife of text editors wrote: > > I propose the attached patch to make string-pixel-width faster while > > using less memory, as shown by the following results of a basic > > benchmark run in emacs -Q to compare the current implementation and this > > proposal:[snip] > > > - (insert (propertize string 'line-prefix nil 'wrap-prefix nil)) > > + (insert string) > > + ;; Prefer `remove-text-properties' to `propertize' to avoid > > + ;; creating a new string on each call. > > + (remove-text-properties > > + (point-min) (point-max) '(line-prefix nil wrap-prefix nil)) > > Is this change safe? It's how this function behaved since day one. These properties are meaningless for a string's width, since for them to take effect the string should be at the beginning of a screen line, which is not a property of an arbitrary string. > I suppose most of the time, this wouldn't matter, > but I could imagine a case where a caller wanted the pixel-width of a > string that had one of those properties set, and they'd want those > properties to be preserved (e.g. if the string was to be inserted into a > buffer later). If a Lisp program wants to know the width of the line-prefix, it can do that separately. > I'm not sure how much this matters, but I always get a bit nervous about > a function changing something about one of its arguments when it's not > obvious. The argument isn't changed, only the text inserted into the temporary buffer gets its properties changed. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 18 12:37:16 2024 Received: (at 72689) by debbugs.gnu.org; 18 Aug 2024 16:37:16 +0000 Received: from localhost ([127.0.0.1]:56586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfiu4-0003Nu-Bd for submit@debbugs.gnu.org; Sun, 18 Aug 2024 12:37:16 -0400 Received: from mail-pg1-f181.google.com ([209.85.215.181]:43157) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfiu2-0003Nc-18 for 72689@debbugs.gnu.org; Sun, 18 Aug 2024 12:37:15 -0400 Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-7afd1aeac83so3006842a12.0 for <72689@debbugs.gnu.org>; Sun, 18 Aug 2024 09:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723998928; x=1724603728; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=nii7hofiG3u1cKM3D/N5LlnASMZfpQr1W+z+kCx4m60=; b=N4YOqUCo8yiNFRVzDvpobqczHPu5hx/DqTUmZ29K2+1BDM8SV9fSnwniKCWPHSUFz6 psRCz5G8ZSaM4Q7obSwDQoz47y2WUniFU1AWNJgFn4auSSa11ZaxP4IjJ7ey8F33wQaZ GZLeHDR/QX2/JEeHqktK3hVeAyIFaJmz8H06umNnWwLewlA8qpOIdxJ+nynWCQ69OP4z sTOASgQZoDpO24KHZ9vMvi4z3DTe57i82cgfFFrmz8pmAtI8nW/38GfHEJgBdR8ZhEAH fd9gxpVCt1XYIbMYeodsgv69LGaGmKtedDKQj+fca29QgsIjmiVldcVmSopOn24G/9L9 JolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723998928; x=1724603728; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nii7hofiG3u1cKM3D/N5LlnASMZfpQr1W+z+kCx4m60=; b=Hn+VwKMeyVkLXqjpO4sKlZg2jG+mpyHns0gBighU0t+4mpUPytz+Mzk6nUuuu0E85a 8HN2oXaV/AaVvB5W3yLXMnL1wH0sYGaLvOjCc8FzDzLoh/ogwWgJnguzXe0rui5vv+h0 cJKdy9n7PfpmxHX2GE1OfQyfdahusT5TteMg3DueCCLueOGwApGNmwLHdD/uyx9iH+yf 4svQfBLis45FmxT7bi2rf5D8n6/UujIYhShXr2OVHEgkNa8+jNwmuVHMLd1P1kcz4RQm EjPkkXliI2qyEPtYjr5EEvXmR4xI0CtB9RylWngBNUh0HJyIVQ0+MrFRyYXxxUZycwW3 V/vw== X-Forwarded-Encrypted: i=1; AJvYcCW6X12Vd7ZTMMXyiGz3ZN1j0JA83E0dAqLP8Ti801c/BozafuWt3fT8TgJ69rYJa1fA32CDrP+kxQrkKAuJkbPs8yFklFE= X-Gm-Message-State: AOJu0YzjIm8KNL1AgIAPhvuTdCCS6IM3k9c6UA+qoEyKuPGnyP55/+8w 7DcDByyLzH8ZyDgEETrAcsHTDRc5wqIIkfF6hNlh8yXX31Grw+Co X-Google-Smtp-Source: AGHT+IFKgA4IsGqpAq00t225ywscFSac3tH8ZgwXmUlKR1YGsA8pAGXiAGOR52uSpzQ2p30CtQQlVg== X-Received: by 2002:a17:90b:4a90:b0:2cb:58e1:abc8 with SMTP id 98e67ed59e1d1-2d3e45f6f63mr12066279a91.21.1723998927499; Sun, 18 Aug 2024 09:35:27 -0700 (PDT) Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id 98e67ed59e1d1-2d3f3b90337sm5123474a91.0.2024.08.18.09.35.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Aug 2024 09:35:26 -0700 (PDT) Message-ID: Date: Sun, 18 Aug 2024 09:35:28 -0700 MIME-Version: 1.0 Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width Content-Language: en-US To: David Ponce References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> From: Jim Porter In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72689 Cc: Eli Zaretskii , 72689@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 8/18/2024 12:36 AM, David Ponce via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > On 18/08/2024 8:12 AM, Jim Porter wrote: >> I'm not sure how much this matters, but I always get a bit nervous >> about a function changing something about one of its arguments when >> it's not obvious. > > My implementation proposal does not change the behavior of the > function. It is just an attempt to improve its performance. My mistake; I misread the code and thought the 'remove-text-properties' call was being applied to the string argument. (It's applied to the buffer, of course.) From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 19 04:49:52 2024 Received: (at 72689) by debbugs.gnu.org; 19 Aug 2024 08:49:52 +0000 Received: from localhost ([127.0.0.1]:57642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfy5I-00050z-0Q for submit@debbugs.gnu.org; Mon, 19 Aug 2024 04:49:52 -0400 Received: from smtp-25.smtpout.orange.fr ([80.12.242.25]:53605 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sfy5F-00050o-Hq for 72689@debbugs.gnu.org; Mon, 19 Aug 2024 04:49:50 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id fy4Xs0oCauuNAfy4XsCy0w; Mon, 19 Aug 2024 10:49:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724057346; bh=LyORy519p2YRKWB8nm15/Vtn+f2lT0QbYNalRbPfax4=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Ssjd+gfyYrRk8zy3+a+wgVN+ZiYE5/SX+Xa9oBNCj/VWCOLl+q4nnyyU1Is07MjWB 32o86yChdHcnES8QjIvs/MTw8IIS9DQ/Q1Rgp0mKp67/AUF7iKokFdc+8+SPyipN1g /AIw9EJMA5sWFtkZo9Rt59t+OARC8Af22HfiqUV+mB5U+1HXBVJOx89CqcJUynXi8K /dWYooj8g/a7dD2ys1vnjGVKGieknLWL0YqOebX1vcCDuITEIjzPV7H1PUR2l+/jMy rz4WzCIE/yTaLa25Wu1HGKhSCboyUcoPWeTdFbFHyYpNFLJdccycIEVuAFfPMhbQ3P KQaJWM0J9LMxA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 19 Aug 2024 10:49:06 +0200 X-ME-IP: 2.7.225.247 Content-Type: multipart/mixed; boundary="------------mXmucp7oBVioNV9840LnjaKw" Message-ID: Date: Mon, 19 Aug 2024 10:49:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <8634n219b1.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72689 Cc: 72689@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 (-) This is a multi-part message in MIME format. --------------mXmucp7oBVioNV9840LnjaKw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 18/08/2024 11:15 AM, Eli Zaretskii wrote: [...]> I think you understood the issue, and just creating a new buffer if > the "normal" one is "taken" should be good enough. I don't expect > this situation to be a frequent one, so creating too many buffers > should not be a danger. Thanks! Please, find attached a revised V01 patch that implements your suggestion. I finally opted to keep only one function, because setting a few buffer-local variables on each call has not a significant impact on performance. --------------mXmucp7oBVioNV9840LnjaKw Content-Type: text/x-patch; charset=UTF-8; name="improve-string-pixel-width-V01.patch" Content-Disposition: attachment; filename="improve-string-pixel-width-V01.patch" Content-Transfer-Encoding: base64 MjAyNC0wOC0xOSAgRGF2aWQgUG9uY2UgIDxkYV92aWRAb3JhbmdlLmZyPgoKCVR3ZWFrIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiBzdHJpbmctcGl4ZWwtd2lkdGggdG8gcnVuIGZhc3RlciBh bmQKCXVzZSBsZXNzIG1lbW9yeS4gIEFsc28gY2F0ZXIgZm9yIHRoZSBjYXNlIHdoZXJlIG1v cmUgdGhhbiBvbmUKCWV4ZWN1dGlvbiB0aHJlYWQgY2FsbHMgdGhlIGZ1bmN0aW9uIChidWcj NzI2ODkpLgoKCSogc3Vici14LmVsIChzdHJpbmctLXBpeGVsLXdpZHRoLWJ1ZmZlcik6IE5l dyB2YXJpYWJsZS4KCShzdHJpbmctLXBpeGVsLXdpZHRoKTogVXNlIGl0LiAgQ3JlYXRlIGEg bmV3IHdvcmtpbmcgYnVmZmVyIHdoZW4KCXBhcmFsbGVsIHJ1biBpcyBkZXRlY3RlZC4gIFBy ZWZlciBgcmVtb3ZlLXRleHQtcHJvcGVydGllcycgdG8KCWBwcm9wZXJ0aXplJyB0byBhdm9p ZCBjcmVhdGluZyBhIG5ldyBzdHJpbmcgb24gZWFjaCBjYWxsLgoKZGlmZiAtLWdpdCBhL2xp c3AvZW1hY3MtbGlzcC9zdWJyLXguZWwgYi9saXNwL2VtYWNzLWxpc3Avc3Vici14LmVsCmlu ZGV4IDA1OGMwNmJjNWY2Li5iNjg4ZDE3OWRhNCAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1s aXNwL3N1YnIteC5lbAorKysgYi9saXNwL2VtYWNzLWxpc3Avc3Vici14LmVsCkBAIC0zMzYs NiArMzM2LDggQEAgbmFtZWQtbGV0CiAgICAgICAoY2wtbGFiZWxzICgoLG5hbWUgLGZhcmdz IC4gLGJvZHkpKSAjJyxuYW1lKQogICAgICAgLiAsYWFyZ3MpKSkKIAorKGRlZnZhciBzdHJp bmctLXBpeGVsLXdpZHRoLWJ1ZmZlciBuaWwpCisKIDs7OyMjI2F1dG9sb2FkCiAoZGVmdW4g c3RyaW5nLXBpeGVsLXdpZHRoIChzdHJpbmcgJm9wdGlvbmFsIGJ1ZmZlcikKICAgIlJldHVy biB0aGUgd2lkdGggb2YgU1RSSU5HIGluIHBpeGVscy4KQEAgLTM0NiwyMSArMzQ4LDQ1IEBA IHN0cmluZy1waXhlbC13aWR0aAogICAgICAgMAogICAgIDs7IEtlZXBpbmcgYSB3b3JrIGJ1 ZmZlciBhcm91bmQgaXMgbW9yZSBlZmZpY2llbnQgdGhhbiBjcmVhdGluZyBhCiAgICAgOzsg bmV3IHRlbXBvcmFyeSBidWZmZXIuCi0gICAgKHdpdGgtY3VycmVudC1idWZmZXIgKGdldC1i dWZmZXItY3JlYXRlICIgKnN0cmluZy1waXhlbC13aWR0aCoiKQotICAgICAgOzsgSWYgYGRp c3BsYXktbGluZS1udW1iZXJzJyBpcyBlbmFibGVkIGluIGludGVybmFsIGJ1ZmZlcnMKLSAg ICAgIDs7IChlLmcuIGdsb2JhbGx5KSwgaXQgYnJlYWtzIHdpZHRoIGNhbGN1bGF0aW9uIChi dWcjNTkzMTEpCi0gICAgICAoc2V0cS1sb2NhbCBkaXNwbGF5LWxpbmUtbnVtYmVycyBuaWwp Ci0gICAgICAoZGVsZXRlLXJlZ2lvbiAocG9pbnQtbWluKSAocG9pbnQtbWF4KSkKLSAgICAg IDs7IERpc2FibGUgbGluZS1wcmVmaXggYW5kIHdyYXAtcHJlZml4LCBmb3IgdGhlIHNhbWUg cmVhc29uLgotICAgICAgKHNldHEgbGluZS1wcmVmaXggbmlsCi0JICAgIHdyYXAtcHJlZml4 IG5pbCkKLSAgICAgIChpZiBidWZmZXIKLSAgICAgICAgICAoc2V0cS1sb2NhbCBmYWNlLXJl bWFwcGluZy1hbGlzdAotICAgICAgICAgICAgICAgICAgICAgICh3aXRoLWN1cnJlbnQtYnVm ZmVyIGJ1ZmZlcgotICAgICAgICAgICAgICAgICAgICAgICAgZmFjZS1yZW1hcHBpbmctYWxp c3QpKQotICAgICAgICAoa2lsbC1sb2NhbC12YXJpYWJsZSAnZmFjZS1yZW1hcHBpbmctYWxp c3QpKQotICAgICAgKGluc2VydCAocHJvcGVydGl6ZSBzdHJpbmcgJ2xpbmUtcHJlZml4IG5p bCAnd3JhcC1wcmVmaXggbmlsKSkKLSAgICAgIChjYXIgKGJ1ZmZlci10ZXh0LXBpeGVsLXNp emUgbmlsIG5pbCB0KSkpKSkKKyAgICAod2l0aC1jdXJyZW50LWJ1ZmZlcgorICAgICAgICAo b3IgKGlmIChidWZmZXItbGl2ZS1wIHN0cmluZy0tcGl4ZWwtd2lkdGgtYnVmZmVyKQorICAg ICAgICAgICAgICAgIDs7IENoZWNrIGlmIHdvcmsgYnVmZmVyIGlzIG5vdCB1c2VkIGJ5Cisg ICAgICAgICAgICAgICAgOzsgYW5vdGhlciBwYXJhbGxlbCBydW4gKGJ1ZyM3MjY4OSkuICBU aGF0CisgICAgICAgICAgICAgICAgOzsgaXMsIGlmIGBzdHJpbmctLXBpeGVsLXdpZHRoLWJ1 ZmZlcicgaGFzIG5vCisgICAgICAgICAgICAgICAgOzsgYnVmZmVyLWxvY2FsIHZhbHVlLCBp biB3aGljaCBjYXNlIHRoZSBmdW5jdGlvbgorICAgICAgICAgICAgICAgIDs7IGBidWZmZXIt bG9jYWwtdmFsdWUnIHJldHVybnMgaXRzIGdsb2JhbCB2YWx1ZSwKKyAgICAgICAgICAgICAg ICA7OyBlcXVhbCB0byB0aGUgd29yayBidWZmZXIuICBPdGhlcndpc2UsIHdoZW4gdGhlCisg ICAgICAgICAgICAgICAgOzsgd29yayBidWZmZXIgaXMgImJ1c3kiLCB0aGUgYnVmZmVyLWxv Y2FsIHZhbHVlIG9mCisgICAgICAgICAgICAgICAgOzsgYHN0cmluZy0tcGl4ZWwtd2lkdGgt YnVmZmVyJyBpcyBuaWwuCisgICAgICAgICAgICAgICAgKGJ1ZmZlci1sb2NhbC12YWx1ZSAn c3RyaW5nLS1waXhlbC13aWR0aC1idWZmZXIKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHN0cmluZy0tcGl4ZWwtd2lkdGgtYnVmZmVyKSkKKyAgICAgICAgICAgIDs7 IENyZWF0ZSBhIG5ldyB3b3JrIGJ1ZmZlciBpZiBjdXJyZW50IGlzICJidXN5Ii4KKyAgICAg ICAgICAgIChzZXRxIHN0cmluZy0tcGl4ZWwtd2lkdGgtYnVmZmVyCisgICAgICAgICAgICAg ICAgICAoZ2VuZXJhdGUtbmV3LWJ1ZmZlciAiICpzdHJpbmctcGl4ZWwtd2lkdGgqIiB0KSkp CisgICAgICA7OyBNYXJrIGJ1ZmZlciBhcyAiYnVzeSIuCisgICAgICAoc2V0cS1sb2NhbCBz dHJpbmctLXBpeGVsLXdpZHRoLWJ1ZmZlciBuaWwpCisgICAgICAodW53aW5kLXByb3RlY3QK KyAgICAgICAgICAocHJvZ24KKyAgICAgICAgICAgIDs7IElmIGBkaXNwbGF5LWxpbmUtbnVt YmVycycgaXMgZW5hYmxlZCBpbiBpbnRlcm5hbAorICAgICAgICAgICAgOzsgYnVmZmVycyAo ZS5nLiBnbG9iYWxseSksIGl0IGJyZWFrcyB3aWR0aCBjYWxjdWxhdGlvbgorICAgICAgICAg ICAgOzsgKGJ1ZyM1OTMxMSkuICBEaXNhYmxlIGBsaW5lLXByZWZpeCcgYW5kIGB3cmFwLXBy ZWZpeCcsCisgICAgICAgICAgICA7OyBmb3IgdGhlIHNhbWUgcmVhc29uLgorICAgICAgICAg ICAgKHNldHEgZGlzcGxheS1saW5lLW51bWJlcnMgbmlsCisgICAgICAgICAgICAgICAgICBs aW5lLXByZWZpeCBuaWwgd3JhcC1wcmVmaXggbmlsKQorICAgICAgICAgICAgKGlmIGJ1ZmZl cgorICAgICAgICAgICAgICAgIChzZXRxLWxvY2FsIGZhY2UtcmVtYXBwaW5nLWFsaXN0Cisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmZmVy CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYWNlLXJlbWFwcGluZy1hbGlzdCkp CisgICAgICAgICAgICAgIChraWxsLWxvY2FsLXZhcmlhYmxlICdmYWNlLXJlbWFwcGluZy1h bGlzdCkpCisgICAgICAgICAgICAoZXJhc2UtYnVmZmVyKQorICAgICAgICAgICAgKGluc2Vy dCBzdHJpbmcpCisgICAgICAgICAgICA7OyBQcmVmZXIgYHJlbW92ZS10ZXh0LXByb3BlcnRp ZXMnIHRvIGBwcm9wZXJ0aXplJyB0byBhdm9pZAorICAgICAgICAgICAgOzsgY3JlYXRpbmcg YSBuZXcgc3RyaW5nIG9uIGVhY2ggY2FsbC4KKyAgICAgICAgICAgIChyZW1vdmUtdGV4dC1w cm9wZXJ0aWVzCisgICAgICAgICAgICAgKHBvaW50LW1pbikgKHBvaW50LW1heCkgJyhsaW5l LXByZWZpeCBuaWwgd3JhcC1wcmVmaXggbmlsKSkKKyAgICAgICAgICAgIChjYXIgKGJ1ZmZl ci10ZXh0LXBpeGVsLXNpemUgbmlsIG5pbCB0KSkpCisgICAgICAgIDs7IE1hcmsgYnVmZmVy IGFzIGZyZWUgdG8gdXNlLgorICAgICAgICAoa2lsbC1sb2NhbC12YXJpYWJsZSAnc3RyaW5n LS1waXhlbC13aWR0aC1idWZmZXIpKSkpKQogCiA7OzsjIyNhdXRvbG9hZAogKGRlZnVuIHN0 cmluZy1nbHlwaC1zcGxpdCAoc3RyaW5nKQo= --------------mXmucp7oBVioNV9840LnjaKw-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 20 11:13:36 2024 Received: (at 72689) by debbugs.gnu.org; 20 Aug 2024 15:13:37 +0000 Received: from localhost ([127.0.0.1]:33564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgQYC-0005Sq-6K for submit@debbugs.gnu.org; Tue, 20 Aug 2024 11:13:36 -0400 Received: from smtp-18.smtpout.orange.fr ([80.12.242.18]:51712 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgQY8-0005Se-UW for 72689@debbugs.gnu.org; Tue, 20 Aug 2024 11:13:34 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id gQXNs1ov4oIRNgQXNsRZnT; Tue, 20 Aug 2024 17:12:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724166768; bh=BqLNqPIrkwrZYSjlUyf216nIG0vtUFrGsnIqYMCL0zY=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Jg5iWvOQ1ncqg8R40G4XCN+q2ulZA6pr8RtSmT+w9XBJRR7PC/zZNbM8vtM5TNjcp b7E1qhXW4O5DK2xeDhTAoOBEQ00MDn4hVQA5qhXorfYggRDwZ3R7UCLbBZ+ovWpt9V 0BGfG4CwaqNYSPIZWbvwxyoIGZHbndd3yH/Dkou8E8FZY5p2vH713Bgfw+7hsVEQh0 uRIJ+ulaK0PrfGQgbvBuiTc9+1tBzFHwhBR3qCzmRASY29wNvnjLeaLqAdY9uwOX45 32PamESSV/2DeoWiq9JiBViVzm0gthjyKrWo5zocbxhrFGbaP+Koh632nBxyEpUcVm EoUrnKMC6jK/A== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Tue, 20 Aug 2024 17:12:48 +0200 X-ME-IP: 2.7.225.247 Message-ID: <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> Date: Tue, 20 Aug 2024 17:12:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <8634n219b1.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: 72689 Cc: 72689@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 18/08/2024 11:15 AM, Eli Zaretskii wrote: [...] >>> Thanks. The idea SGTM, but I think the implementation needs to cater >>> for the case where more than one execution thread performs this job >>> "in parallel" (however improbable this could sound), so we need to be >>> able to detect when this buffer is "busy". The simplest way is to use >>> some boolean buffer-local variable, which will be set non-nil when the >>> function starts using the buffer and reset to nil when the function is >>> done with its job. I've been thinking more about the parallelism issue when a function reuses a temporary buffer for its activity, and I wonder if we could use a simple API like the one below to safely get an exclusive working buffer without having to create a new one on each call? ;; --------------------------------------------------------------- (defvar work-buffer--list nil) (defvar work-buffer--lock (make-mutex)) (defsubst work-buffer--get () "Get a work buffer." (let ((buffer (with-mutex work-buffer--lock (pop work-buffer--list)))) (if (buffer-live-p buffer) buffer (generate-new-buffer " *work*" t)))) (defsubst work-buffer--release (buffer) "Release work BUFFER." (if (buffer-live-p buffer) (with-current-buffer buffer ;; Flush BUFFER before making it available again, i.e. clear ;; its contents, remove all overlays and buffer-local ;; variables. Is it enough to safely reuse the buffer? (erase-buffer) (delete-all-overlays) (let (change-major-mode-hook) (kill-all-local-variables t)) ;; Make the buffer available again. (with-mutex work-buffer--lock (push buffer work-buffer--list))))) ;;;###autoload (defmacro with-work-buffer (&rest body) "Create a work buffer, and evaluate BODY there like `progn'. Like `with-temp-buffer', but reuse an already created temporary buffer when possible, instead of creating a new one on each call." (declare (indent 0) (debug t)) (let ((work-buffer (make-symbol "work-buffer"))) `(let ((,work-buffer (work-buffer--get))) (with-current-buffer ,work-buffer (unwind-protect (progn ,@body) (work-buffer--release ,work-buffer)))))) ;; --------------------------------------------------------------- Here is how string-pixel-width could be implemented to use the above API: (defun string-pixel-W (string &optional buffer) "Return the width of STRING in pixels. If BUFFER is non-nil, use the face remappings from that buffer when determining the width." (declare (important-return-value t)) (if (zerop (length string)) 0 ;; Keeping a work buffer around is more efficient than creating a ;; new temporary buffer. (with-work-buffer ;; If `display-line-numbers' is enabled in internal ;; buffers (e.g. globally), it breaks width calculation ;; (bug#59311). Disable `line-prefix' and `wrap-prefix', ;; for the same reason. (setq display-line-numbers nil line-prefix nil wrap-prefix nil) (if buffer (setq-local face-remapping-alist (with-current-buffer buffer face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (erase-buffer) (insert string) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties (point-min) (point-max) '(line-prefix nil wrap-prefix nil)) (car (buffer-text-pixel-size nil nil t))))) ;; Quick benchmarck (let* ((text1 (make-string 1000 ?x)) (text2 (propertize text1 'line-prefix "XXXX ")) (runs 1000)) (list (progn (garbage-collect) (benchmark-run runs (string-pixel-width text2))) (progn (garbage-collect) (benchmark-run runs (string-pixel-W text2))) )) Compared to my previous proposal the quick benchmark above shows similar results for both performance and memory usage, but the new implementation is simpler, and the API might be useful in other similar cases. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 09:18:09 2024 Received: (at 72689) by debbugs.gnu.org; 21 Aug 2024 13:18:09 +0000 Received: from localhost ([127.0.0.1]:35168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sglE0-0002QN-KM for submit@debbugs.gnu.org; Wed, 21 Aug 2024 09:18:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sglDy-0002Pn-2l for 72689@debbugs.gnu.org; Wed, 21 Aug 2024 09:18:07 -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 1sglD9-0000O3-QH; Wed, 21 Aug 2024 09:17:15 -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=T6PXNMJ3lhHqt44Qo1jUrxX2CFWLR6xTw2vvRg7+wIg=; b=h6fr9XgqRQqV nAHSyDVlzCKa5qsPhHhThdFu8K9y1co41+gzSkVVKpcTIeb+KQmicYWIS3zYPdT/0cKfXnB1r0mt0 VUojossqi1yLKb1If9gwTHplwLoPAl5p2c8g3l9L5FCznDXBxUBS5Vv5vDIy6vU0stzjvYUH9PzBx PUwvBuWf1qJ2eImWJC0TXM/U/Rz0P6PSsScZBd0E6xffHZXPITpsV7EHZE0OrmanJKzRKsKPZ13cZ 7bcC8rhs7e8ZSAYDl1RuKJLk1aAGDCJCSW2BB2PokG+Ry8nygXg2oLDco4vyd8/P0PRgG6zgJCVsL Wyd5RATyBRyGkfsilVJyGQ==; Date: Wed, 21 Aug 2024 16:17:12 +0300 Message-Id: <86jzgauiav.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> (message from David Ponce on Tue, 20 Aug 2024 17:12:45 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Tue, 20 Aug 2024 17:12:45 +0200 > Cc: 72689@debbugs.gnu.org > From: David Ponce > > On 18/08/2024 11:15 AM, Eli Zaretskii wrote: > [...] > >>> Thanks. The idea SGTM, but I think the implementation needs to cater > >>> for the case where more than one execution thread performs this job > >>> "in parallel" (however improbable this could sound), so we need to be > >>> able to detect when this buffer is "busy". The simplest way is to use > >>> some boolean buffer-local variable, which will be set non-nil when the > >>> function starts using the buffer and reset to nil when the function is > >>> done with its job. > > I've been thinking more about the parallelism issue when a function > reuses a temporary buffer for its activity, and I wonder if we could > use a simple API like the one below to safely get an exclusive working > buffer without having to create a new one on each call? Thanks, but using a mutex is overkill: there could be no race between two or more threads in this case in accessing the buffer-local variable, because only one Lisp thread can be running at any given time. So the simpler method of testing the "busy" flag should be sufficient. > Compared to my previous proposal the quick benchmark above shows > similar results for both performance and memory usage, but the new > implementation is simpler, and the API might be useful in other > similar cases. Simpler implementation is OK, but I think it will be simpler yet if you remove the mutex, which is not needed. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 16:44:01 2024 Received: (at 72689) by debbugs.gnu.org; 21 Aug 2024 20:44:01 +0000 Received: from localhost ([127.0.0.1]:36410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgsBU-0007gx-Lp for submit@debbugs.gnu.org; Wed, 21 Aug 2024 16:44:01 -0400 Received: from smtp-75.smtpout.orange.fr ([80.12.242.75]:53887 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgsBS-0007gm-0s for 72689@debbugs.gnu.org; Wed, 21 Aug 2024 16:43:59 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id gsAfsbHFKjDE7gsAfs6Af4; Wed, 21 Aug 2024 22:43:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724272991; bh=AMMsb+3SFBTVR5ek4WWQcrUT+hKc9tQwlIJ4zs7pK6Y=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=UBDGcobjpDicjv7co3TgvJd3QYcIg3fMVSYiqRIeSEvk4S25/hwKbuby1dgdIp4LL QeYa/Vg4rA8b22JgcPbuBdcogse7dsFY8T5ojzy7dun0YvQMLsA52VH8wXrQdSvOH1 ilWGiJMo4Q8goBPkU9rTNYP0wNkpz22N5jeotT0IjPzz+enHHHEdFkxDHeUF0DEC0v I/ies6yNhZC8sf2QCAwBDORdfPxrxLCVHzzsP9APF9PIdCe+mPxhyulgBPjZdQYy/L wlhutzxvXGYXoAjrHoubsqC+DHAae3S9rmdh6uDpCTGjh6pR7uQ5QgoqH+yCFOYuAq UEGbXEa9telsA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 21 Aug 2024 22:43:11 +0200 X-ME-IP: 2.7.225.247 Message-ID: <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> Date: Wed, 21 Aug 2024 22:43:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <86jzgauiav.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: 72689 Cc: 72689@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 21/08/2024 3:17 PM, Eli Zaretskii wrote: [...] >> >> I've been thinking more about the parallelism issue when a function >> reuses a temporary buffer for its activity, and I wonder if we could >> use a simple API like the one below to safely get an exclusive working >> buffer without having to create a new one on each call? > > Thanks, but using a mutex is overkill: there could be no race between > two or more threads in this case in accessing the buffer-local > variable, because only one Lisp thread can be running at any given > time. So the simpler method of testing the "busy" flag should be > sufficient. I used a mutex to protect the global variable `work-buffer--list' (which holds the list buffers available to be reused) against concurrent accesses during the very simple update operations: pop an available buffer, push a released buffer to make it available. Of course, if you guarantee that only one Lisp thread can be running at any given time, protecting `work-buffer--list' against concurrent accesses is not necessary and mutex can be removed. >> Compared to my previous proposal the quick benchmark above shows >> similar results for both performance and memory usage, but the new >> implementation is simpler, and the API might be useful in other >> similar cases. > > Simpler implementation is OK, but I think it will be simpler yet if > you remove the mutex, which is not needed. Here is the new version without mutex (no significant impact on performance compared to the version with mutex): (defvar work-buffer--list nil) (defsubst work-buffer--get () "Get a work buffer." (let ((buffer (pop work-buffer--list))) (if (buffer-live-p buffer) buffer (generate-new-buffer " *work*" t)))) (defsubst work-buffer--release (buffer) "Release work BUFFER." (if (buffer-live-p buffer) (with-current-buffer buffer ;; Flush BUFFER before making it available again, i.e. clear ;; its contents, remove all overlays and buffer-local ;; variables. Is it enough to safely reuse the buffer? (erase-buffer) (delete-all-overlays) (let (change-major-mode-hook) (kill-all-local-variables t)) ;; Make the buffer available again. (push buffer work-buffer--list)))) ;;;###autoload (defmacro with-work-buffer (&rest body) "Create a work buffer, and evaluate BODY there like `progn'. Like `with-temp-buffer', but reuse an already created temporary buffer when possible, instead of creating a new one on each call." (declare (indent 0) (debug t)) (let ((work-buffer (make-symbol "work-buffer"))) `(let ((,work-buffer (work-buffer--get))) (with-current-buffer ,work-buffer (unwind-protect (progn ,@body) (work-buffer--release ,work-buffer)))))) ;;; Apply the work-buffer API to `string-pixel-width'. ;; (defun string-pixel-width (string &optional buffer) "Return the width of STRING in pixels. If BUFFER is non-nil, use the face remappings from that buffer when determining the width." (declare (important-return-value t)) (if (zerop (length string)) 0 ;; Keeping a work buffer around is more efficient than creating a ;; new temporary buffer. (with-work-buffer ;; If `display-line-numbers' is enabled in internal ;; buffers (e.g. globally), it breaks width calculation ;; (bug#59311). Disable `line-prefix' and `wrap-prefix', ;; for the same reason. (setq display-line-numbers nil line-prefix nil wrap-prefix nil) (if buffer (setq-local face-remapping-alist (with-current-buffer buffer face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) (erase-buffer) (insert string) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. (remove-text-properties (point-min) (point-max) '(line-prefix nil wrap-prefix nil)) (car (buffer-text-pixel-size nil nil t))))) Should I prepare a patch of subr-x.el to include both the proposed `work-buffer' API, and an implementation of `string-pixel-width' using it? Thanks! From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 21 23:44:35 2024 Received: (at 72689) by debbugs.gnu.org; 22 Aug 2024 03:44:36 +0000 Received: from localhost ([127.0.0.1]:36543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgykV-0002bJ-Hu for submit@debbugs.gnu.org; Wed, 21 Aug 2024 23:44:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sgykT-0002b5-A6 for 72689@debbugs.gnu.org; Wed, 21 Aug 2024 23:44:34 -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 1sgyje-0005mC-1x; Wed, 21 Aug 2024 23:43:42 -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=ojmgelX/weNOTgJwRg9IcxpE8gQ+L+lOoiieHySbpCg=; b=Khox7rl0S/v1 l5oNiuV7RvLJj9eHZP3K6VIASMrvVz4XLEDAi9sGjez7jayNmoDqPX/SstZKo7PbLLjjeLYIAhA5a GmXLgr0eBoZShNqk0ZKON8r8M9HAG4GEpaIm2LqJblF30Kkf6QWIEDWcL58hgOIZLbMSuX9Ym2tR1 /CfVUJUKvJIw3qGIhv53bPtjTmIcKI0c56ocEEtbjA5QzeubzmbeDh522CSbShWiuThkd5cXwlZwc ueFE4klfJlAuQZuzJ7OSzABMMJGEKFzlIFBngUgvDjJRcd5yHuMioLIjvJMA8Nc5XOqV2E/KCUA51 0DIxvDmY5WCtr1WkcFWruw==; Date: Thu, 22 Aug 2024 06:43:40 +0300 Message-Id: <86seuxte6r.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> (message from David Ponce on Wed, 21 Aug 2024 22:43:08 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Wed, 21 Aug 2024 22:43:08 +0200 > Cc: 72689@debbugs.gnu.org > From: David Ponce > > On 21/08/2024 3:17 PM, Eli Zaretskii wrote: > > Thanks, but using a mutex is overkill: there could be no race between > > two or more threads in this case in accessing the buffer-local > > variable, because only one Lisp thread can be running at any given > > time. So the simpler method of testing the "busy" flag should be > > sufficient. > > I used a mutex to protect the global variable `work-buffer--list' > (which holds the list buffers available to be reused) against > concurrent accesses during the very simple update operations: pop an > available buffer, push a released buffer to make it available. > > Of course, if you guarantee that only one Lisp thread can be running > at any given time, protecting `work-buffer--list' against concurrent > accesses is not necessary and mutex can be removed. Yes, I think so. > Here is the new version without mutex (no significant impact on > performance compared to the version with mutex): Thanks, LGTM. > Should I prepare a patch of subr-x.el to include both the proposed > `work-buffer' API, and an implementation of `string-pixel-width' using > it? Yes, please. And the macro itself needs a NEWS entry, I think. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 22 05:49:42 2024 Received: (at 72689) by debbugs.gnu.org; 22 Aug 2024 09:49:42 +0000 Received: from localhost ([127.0.0.1]:36742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh4Rp-0004G6-JE for submit@debbugs.gnu.org; Thu, 22 Aug 2024 05:49:42 -0400 Received: from smtp-22.smtpout.orange.fr ([80.12.242.22]:54219 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh4Rm-0004Fv-Pc for 72689@debbugs.gnu.org; Thu, 22 Aug 2024 05:49:40 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id h4QysL5yXQaX2h4QzscWqk; Thu, 22 Aug 2024 11:48:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724320131; bh=wetzgYxxO2nIpxD5grWmCB7ts/B2Xir5236n3SwLRnI=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=ibYbNXOScTXnQ2WMRuOmkzs/UyZSNkecskJkiR73NlZuHSyi5t3EXkBEiGc3Jm3u8 o5+Wjv8DjyrPDiYoI4l1rywi/0m6zsqXKW09GRHZgAFgy7oXjfJAKM0JFGVMvbEp89 2AaVWFxVBGG8B1dWqjY3VLzkidJD1m0mhbwX1MXVm/8wby/cunU11ccBZU5YCPsfvH mFgPLYPVZ+N41v4NRM3A8RG0BzRSN3I3GXyncKlLX6jNgrMy8cox6roYEniTY0TGIU KG8SnLgrRnEdAvjeWDq1Z+cjps9ksBqSb3lDUpbJs0oYfhLfeASDumKEciwQGXusmX PYeTKTugN8SnQ== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Thu, 22 Aug 2024 11:48:51 +0200 X-ME-IP: 2.7.225.247 Message-ID: Date: Thu, 22 Aug 2024 11:48:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <86seuxte6r.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: 72689 Cc: 72689@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 22/08/2024 5:43 AM, Eli Zaretskii wrote: >> Date: Wed, 21 Aug 2024 22:43:08 +0200 >> Cc: 72689@debbugs.gnu.org >> From: David Ponce >> >> On 21/08/2024 3:17 PM, Eli Zaretskii wrote: >>> Thanks, but using a mutex is overkill: there could be no race between >>> two or more threads in this case in accessing the buffer-local >>> variable, because only one Lisp thread can be running at any given >>> time. So the simpler method of testing the "busy" flag should be >>> sufficient. >> >> I used a mutex to protect the global variable `work-buffer--list' >> (which holds the list buffers available to be reused) against >> concurrent accesses during the very simple update operations: pop an >> available buffer, push a released buffer to make it available. >> >> Of course, if you guarantee that only one Lisp thread can be running >> at any given time, protecting `work-buffer--list' against concurrent >> accesses is not necessary and mutex can be removed. > > Yes, I think so. > >> Here is the new version without mutex (no significant impact on >> performance compared to the version with mutex): > > Thanks, LGTM. > >> Should I prepare a patch of subr-x.el to include both the proposed >> `work-buffer' API, and an implementation of `string-pixel-width' using >> it? > > Yes, please. And the macro itself needs a NEWS entry, I think. Thanks. I will prepare a patch and a NEWS entry for the new `with-work-buffer' macro ASAP. Could you please review this last version of the work-buffer API, which introduce the variable `work-buffer-limit' to limit the number of work buffers? Such a limit minimizes the risk of keeping a large number of work buffers throughout the entire Emacs session when, for example, `with-work-buffer' is called recursively, as illustrated by this very poorly written function: ;; Example of a poorly written function that could produce a big number ;; of work buffers! (defun bad-make-string (char &optional count) (or (natnump count) (setq count 0)) (with-work-buffer (insert-char char) (if (> count 1) (insert (bad-make-string char (1- count)))) (buffer-string))) For now, `work-buffer-limit' is a simple variable that can be let-bound to temporarily increase the limit if needed. I'm not sure a customizable user option is useful. The default limit of 10 can also be changed if you think it is not enough or on the contrary is too much. Below is the new code. The benchmarks result are still similar. (defvar work-buffer--list nil) (defvar work-buffer-limit 10 "Maximum number of reusable work buffers. When this limit is exceeded, newly allocated work buffers are automatically killed, which means that in a such case `with-work-buffer' becomes equivalent to `with-temp-buffer'.") (defsubst work-buffer--get () "Get a work buffer." (let ((buffer (pop work-buffer--list))) (if (buffer-live-p buffer) buffer (generate-new-buffer " *work*" t)))) (defun work-buffer--release (buffer) "Release work BUFFER." (if (buffer-live-p buffer) (with-current-buffer buffer ;; Flush BUFFER before making it available again, i.e. clear ;; its contents, remove all overlays and buffer-local ;; variables. Is it enough to safely reuse the buffer? (erase-buffer) (delete-all-overlays) (let (change-major-mode-hook) (kill-all-local-variables t)) ;; Make the buffer available again. (push buffer work-buffer--list))) ;; If the maximum number of reusable work buffers is exceeded, kill ;; work buffer in excess, taking into account that the limit could ;; have been let-bound to temporarily increase its value. (when (> (length work-buffer--list) work-buffer-limit) (mapc #'kill-buffer (nthcdr work-buffer-limit work-buffer--list)) (setq work-buffer--list (ntake work-buffer-limit work-buffer--list)))) ;;;###autoload (defmacro with-work-buffer (&rest body) "Create a work buffer, and evaluate BODY there like `progn'. Like `with-temp-buffer', but reuse an already created temporary buffer when possible, instead of creating a new one on each call." (declare (indent 0) (debug t)) (let ((work-buffer (make-symbol "work-buffer"))) `(let ((,work-buffer (work-buffer--get))) (with-current-buffer ,work-buffer (unwind-protect (progn ,@body) (work-buffer--release ,work-buffer)))))) From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 22 07:00:02 2024 Received: (at 72689) by debbugs.gnu.org; 22 Aug 2024 11:00:03 +0000 Received: from localhost ([127.0.0.1]:36853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh5Xu-0006Lv-3w for submit@debbugs.gnu.org; Thu, 22 Aug 2024 07:00:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh5Xs-0006L6-0B for 72689@debbugs.gnu.org; Thu, 22 Aug 2024 07:00:00 -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 1sh5X1-0003Jp-Mo; Thu, 22 Aug 2024 06:59:07 -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=WK7akwb8gbOFCBYYQPnuGUTGjdt00kj6UnfMpVJftwQ=; b=QLiZozKkSw8c d+UfwEQint1RznJv/2mdoINOTZJLRc0wGzQ0dRzpFvf9Tzjc2jNSj8f/tQJmwjTCk4Ch3fsRF9R4r kVh8s5jcOVOkV6coPKrMj3QCbjq6potR7T5Wipdg7WvQX+6aSOt+MQpNsM01Y60uP5iKuj7HJw6xo 1AYwX54Aw01ADW5b3+MDhnEAjK6SJHU2VDIebojm2Uh+qqZavqQp8cQ8NfAsGDNGdJ0IbnPGTBCHu 6oSgqYoHbia6nTRv1FR9lknwrMbtsbBM46V0EPn+hnWQbB0N3h63kQ2lZF0nqD9aOWERZOE3OSeUc Au9K6KkjC29Ntb1fyrsyJg==; Date: Thu, 22 Aug 2024 13:59:04 +0300 Message-Id: <867cc8u8lj.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: (message from David Ponce on Thu, 22 Aug 2024 11:48:48 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Thu, 22 Aug 2024 11:48:48 +0200 > Cc: 72689@debbugs.gnu.org > From: David Ponce > > > Thanks, LGTM. > > > >> Should I prepare a patch of subr-x.el to include both the proposed > >> `work-buffer' API, and an implementation of `string-pixel-width' using > >> it? > > > > Yes, please. And the macro itself needs a NEWS entry, I think. > > Thanks. I will prepare a patch and a NEWS entry for the new > `with-work-buffer' macro ASAP. > > Could you please review this last version of the work-buffer API, > which introduce the variable `work-buffer-limit' to limit the number > of work buffers? LGTM, thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 22 10:57:04 2024 Received: (at 72689) by debbugs.gnu.org; 22 Aug 2024 14:57:04 +0000 Received: from localhost ([127.0.0.1]:38222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh9FI-00054L-8Y for submit@debbugs.gnu.org; Thu, 22 Aug 2024 10:57:04 -0400 Received: from out-69.smtpout.orange.fr ([193.252.22.69]:59059 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sh9FG-00053t-38 for 72689@debbugs.gnu.org; Thu, 22 Aug 2024 10:57:03 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id h9ESsIYOgy802h9ESsZQQT; Thu, 22 Aug 2024 16:56:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724338574; bh=Vl4sb49o4UR1agkoThudJ2Mx3rlB9SNXcugfdIpBUEo=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=TLy88D8jDN+peZXaGIh1nM7Wia4Ci/GbG6sG/30kd7ewH8k9EgemZSQKAzp/xQ0DN TptZnULFvgdeaM5gj5IuIM5S2Cakm/NG2fhHEdxDtEavOXPGK1XkxDKs/fgB4/Kdj+ YlP4rq9y7CWHE1nAHjfPnPUoaH70oOOMmMs0xpN1yQVOxpZM6CBJ/yK6Ay6Qivg27S wcc3N2q7g0RmE1nHQ/Lt30K17wKCR/x/M1vpqOIUVO78GENSDmAX07XndHu0W51nIW zbBuwcgaR4mzPschdg6Whaq1RfDUFzR8wkI4z3l0ShUc8hMAzkU8xLbJmDyk+CyayU 0mOmos9c+RUoA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Thu, 22 Aug 2024 16:56:14 +0200 X-ME-IP: 2.7.225.247 Content-Type: multipart/mixed; boundary="------------hohy4vh2JsEehRUqCKGegKOj" Message-ID: Date: Thu, 22 Aug 2024 16:56:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <867cc8u8lj.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 72689 Cc: 72689@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 (-) This is a multi-part message in MIME format. --------------hohy4vh2JsEehRUqCKGegKOj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22/08/2024 12:59 PM, Eli Zaretskii wrote: >> Date: Thu, 22 Aug 2024 11:48:48 +0200 >> Cc: 72689@debbugs.gnu.org >> From: David Ponce >> >>> Thanks, LGTM. >>> >>>> Should I prepare a patch of subr-x.el to include both the proposed >>>> `work-buffer' API, and an implementation of `string-pixel-width' using >>>> it? >>> >>> Yes, please. And the macro itself needs a NEWS entry, I think. >> >> Thanks. I will prepare a patch and a NEWS entry for the new >> `with-work-buffer' macro ASAP. >> >> Could you please review this last version of the work-buffer API, >> which introduce the variable `work-buffer-limit' to limit the number >> of work buffers? > > LGTM, thanks. Thanks. Please find attached 2 patches: 1. with-work-buffer.patch to introduce the new macro with-work-buffer. 2. string-pixel-width.patch to improve `string-pixel-width'. --------------hohy4vh2JsEehRUqCKGegKOj Content-Type: text/x-patch; charset=UTF-8; name="with-work-buffer.patch" Content-Disposition: attachment; filename="with-work-buffer.patch" Content-Transfer-Encoding: base64 MjAyNC0wOC0yMiAgRGF2aWQgUG9uY2UgIDxkYV92aWRAb3JhbmdlLmZyPgoKCU5ldyBtYWNy byBgd2l0aC13b3JrLWJ1ZmZlcicuCgoJKiBldGMvTkVXUzogQW5ub3VuY2UgJ3dpdGgtd29y ay1idWZmZXInLgoKCSogbGlzcC9lbWFjcy1saXNwL3N1YnIteC5lbCAod29yay1idWZmZXIt LWxpc3QpCgkod29yay1idWZmZXItbGltaXQpOiBOZXcgdmFyaWFibGVzLgoJKHdvcmstYnVm ZmVyLS1nZXQsIHdvcmstYnVmZmVyLS1yZWxlYXNlKTogTmV3IGZ1bmN0aW9uLgoJKHdpdGgt d29yay1idWZmZXIpOiBOZXcgbWFjcm8uCgpkaWZmIC0tZ2l0IGEvZXRjL05FV1MgYi9ldGMv TkVXUwppbmRleCA4Y2QyMWY1ZmI3NC4uZDY0NDA1NDBiNDUgMTAwNjQ0Ci0tLSBhL2V0Yy9O RVdTCisrKyBiL2V0Yy9ORVdTCkBAIC0yNTcsNiArMjU3LDE0IEBAIGxhbmd1YWdlIEEuCiBJ ZiBzdXBwbGllZCwgJ3N0cmluZy1waXhlbC13aWR0aCcgd2lsbCB1c2UgYW55IGZhY2UgcmVt YXBwaW5ncyBmcm9tCiBCVUZGRVIgd2hlbiBjb21wdXRpbmcgdGhlIHN0cmluZydzIHdpZHRo LgogCistLS0KKyoqKiBOZXcgbWFjcm8gJ3dpdGgtd29yay1idWZmZXInLgorVGhpcyBtYWNy byBpcyBzaW1pbGFyIHRvIHRoZSBhbHJlYWR5IGV4aXN0aW5nIG1hY3JvIGB3aXRoLXRlbXAt YnVmZmVyJy4KK0hvd2V2ZXIsIGNvbnRyYXJ5IHRvIHRoZSBsYXR0ZXIsIGB3aXRoLXdvcmst YnVmZmVyJyBkb2VzIG5vdCBhbGxvY2F0ZSBhCituZXcgdGVtcG9yYXJ5IGJ1ZmZlciBvbiBl YWNoIGNhbGwsIGJ1dCB0cnkgdG8gcmV1c2UgdGhvc2UgcHJldmlvdXNseQorYWxsb2NhdGVk ICh1cCB0byBhIG51bWJlciBkZWZpbmVkIGJ5IHRoZSB2YXJpYWJsZSBgd29yay1idWZmZXIt bGltaXQnCit3aGljaCBkZWZhdWx0cyB0byAxMCkuCisKICsrKwogKiogJ2RhdGUtdG8tdGlt ZScgbm93IGRlZmF1bHRzIHRvIGxvY2FsIHRpbWUuCiBUaGUgZnVuY3Rpb24gbm93IGFzc3Vt ZXMgbG9jYWwgdGltZSBpbnN0ZWFkIG9mIFVuaXZlcnNhbCBUaW1lIHdoZW4KZGlmZiAtLWdp dCBhL2xpc3AvZW1hY3MtbGlzcC9zdWJyLXguZWwgYi9saXNwL2VtYWNzLWxpc3Avc3Vici14 LmVsCmluZGV4IDA1OGMwNmJjNWY2Li4zMzQ3YzgwMmY2OCAxMDA2NDQKLS0tIGEvbGlzcC9l bWFjcy1saXNwL3N1YnIteC5lbAorKysgYi9saXNwL2VtYWNzLWxpc3Avc3Vici14LmVsCkBA IC0zMzYsNiArMzM2LDUzIEBAIG5hbWVkLWxldAogICAgICAgKGNsLWxhYmVscyAoKCxuYW1l ICxmYXJncyAuICxib2R5KSkgIycsbmFtZSkKICAgICAgIC4gLGFhcmdzKSkpCiAKKyhkZWZ2 YXIgd29yay1idWZmZXItLWxpc3QgbmlsKQorKGRlZnZhciB3b3JrLWJ1ZmZlci1saW1pdCAx MAorICAiTWF4aW11bSBudW1iZXIgb2YgcmV1c2FibGUgd29yayBidWZmZXJzLgorV2hlbiB0 aGlzIGxpbWl0IGlzIGV4Y2VlZGVkLCBuZXdseSBhbGxvY2F0ZWQgd29yayBidWZmZXJzIGFy ZQorYXV0b21hdGljYWxseSBraWxsZWQsIHdoaWNoIG1lYW5zIHRoYXQgaW4gYSBzdWNoIGNh c2UKK2B3aXRoLXdvcmstYnVmZmVyJyBiZWNvbWVzIGVxdWl2YWxlbnQgdG8gYHdpdGgtdGVt cC1idWZmZXInLiIpCisKKyhkZWZzdWJzdCB3b3JrLWJ1ZmZlci0tZ2V0ICgpCisgICJHZXQg YSB3b3JrIGJ1ZmZlci4iCisgIChsZXQgKChidWZmZXIgKHBvcCB3b3JrLWJ1ZmZlci0tbGlz dCkpKQorICAgIChpZiAoYnVmZmVyLWxpdmUtcCBidWZmZXIpCisgICAgICAgIGJ1ZmZlcgor ICAgICAgKGdlbmVyYXRlLW5ldy1idWZmZXIgIiAqd29yayoiIHQpKSkpCisKKyhkZWZ1biB3 b3JrLWJ1ZmZlci0tcmVsZWFzZSAoYnVmZmVyKQorICAiUmVsZWFzZSB3b3JrIEJVRkZFUi4i CisgIChpZiAoYnVmZmVyLWxpdmUtcCBidWZmZXIpCisgICAgICAod2l0aC1jdXJyZW50LWJ1 ZmZlciBidWZmZXIKKyAgICAgICAgOzsgRmx1c2ggQlVGRkVSIGJlZm9yZSBtYWtpbmcgaXQg YXZhaWxhYmxlIGFnYWluLCBpLmUuIGNsZWFyCisgICAgICAgIDs7IGl0cyBjb250ZW50cywg cmVtb3ZlIGFsbCBvdmVybGF5cyBhbmQgYnVmZmVyLWxvY2FsCisgICAgICAgIDs7IHZhcmlh Ymxlcy4gIElzIGl0IGVub3VnaCB0byBzYWZlbHkgcmV1c2UgdGhlIGJ1ZmZlcj8KKyAgICAg ICAgKGVyYXNlLWJ1ZmZlcikKKyAgICAgICAgKGRlbGV0ZS1hbGwtb3ZlcmxheXMpCisgICAg ICAgIChsZXQgKGNoYW5nZS1tYWpvci1tb2RlLWhvb2spCisgICAgICAgICAgKGtpbGwtYWxs LWxvY2FsLXZhcmlhYmxlcyB0KSkKKyAgICAgICAgOzsgTWFrZSB0aGUgYnVmZmVyIGF2YWls YWJsZSBhZ2Fpbi4KKyAgICAgICAgKHB1c2ggYnVmZmVyIHdvcmstYnVmZmVyLS1saXN0KSkp CisgIDs7IElmIHRoZSBtYXhpbXVtIG51bWJlciBvZiByZXVzYWJsZSB3b3JrIGJ1ZmZlcnMg aXMgZXhjZWVkZWQsIGtpbGwKKyAgOzsgd29yayBidWZmZXIgaW4gZXhjZXNzLCB0YWtpbmcg aW50byBhY2NvdW50IHRoYXQgdGhlIGxpbWl0IGNvdWxkCisgIDs7IGhhdmUgYmVlbiBsZXQt Ym91bmQgdG8gdGVtcG9yYXJpbHkgaW5jcmVhc2UgaXRzIHZhbHVlLgorICAod2hlbiAoPiAo bGVuZ3RoIHdvcmstYnVmZmVyLS1saXN0KSB3b3JrLWJ1ZmZlci1saW1pdCkKKyAgICAobWFw YyAjJ2tpbGwtYnVmZmVyIChudGhjZHIgd29yay1idWZmZXItbGltaXQgd29yay1idWZmZXIt LWxpc3QpKQorICAgIChzZXRxIHdvcmstYnVmZmVyLS1saXN0IChudGFrZSB3b3JrLWJ1ZmZl ci1saW1pdCB3b3JrLWJ1ZmZlci0tbGlzdCkpKSkKKworOzs7IyMjYXV0b2xvYWQKKyhkZWZt YWNybyB3aXRoLXdvcmstYnVmZmVyICgmcmVzdCBib2R5KQorICAiQ3JlYXRlIGEgd29yayBi dWZmZXIsIGFuZCBldmFsdWF0ZSBCT0RZIHRoZXJlIGxpa2UgYHByb2duJy4KK0xpa2UgYHdp dGgtdGVtcC1idWZmZXInLCBidXQgcmV1c2UgYW4gYWxyZWFkeSBjcmVhdGVkIHRlbXBvcmFy eQorYnVmZmVyIHdoZW4gcG9zc2libGUsIGluc3RlYWQgb2YgY3JlYXRpbmcgYSBuZXcgb25l IG9uIGVhY2ggY2FsbC4iCisgIChkZWNsYXJlIChpbmRlbnQgMCkgKGRlYnVnIHQpKQorICAo bGV0ICgod29yay1idWZmZXIgKG1ha2Utc3ltYm9sICJ3b3JrLWJ1ZmZlciIpKSkKKyAgICBg KGxldCAoKCx3b3JrLWJ1ZmZlciAod29yay1idWZmZXItLWdldCkpKQorICAgICAgICh3aXRo LWN1cnJlbnQtYnVmZmVyICx3b3JrLWJ1ZmZlcgorICAgICAgICAgKHVud2luZC1wcm90ZWN0 CisgICAgICAgICAgICAgKHByb2duICxAYm9keSkKKyAgICAgICAgICAgKHdvcmstYnVmZmVy LS1yZWxlYXNlICx3b3JrLWJ1ZmZlcikpKSkpKQorCiA7OzsjIyNhdXRvbG9hZAogKGRlZnVu IHN0cmluZy1waXhlbC13aWR0aCAoc3RyaW5nICZvcHRpb25hbCBidWZmZXIpCiAgICJSZXR1 cm4gdGhlIHdpZHRoIG9mIFNUUklORyBpbiBwaXhlbHMuCg== --------------hohy4vh2JsEehRUqCKGegKOj Content-Type: text/x-patch; charset=UTF-8; name="string-pixel-width.patch" Content-Disposition: attachment; filename="string-pixel-width.patch" Content-Transfer-Encoding: base64 MjAyNC0wOC0yMiAgRGF2aWQgUG9uY2UgIDxkYV92aWRAb3JhbmdlLmZyPgoKCVR3ZWFrIHRo ZSBpbXBsZW1lbnRhdGlvbiBvZiBzdHJpbmctcGl4ZWwtd2lkdGggdG8gcnVuIGZhc3RlciBh bmQKCXVzZSBsZXNzIG1lbW9yeS4gIEFsc28gY2F0ZXIgZm9yIHRoZSBjYXNlIHdoZXJlIHRo aXMgZnVuY3Rpb24gaXMKCWNhbGxlZCBpbiBwYXJhbGxlbCAoYnVnIzcyNjg5KS4KCgkqIGxp c3AvZW1hY3MtbGlzcC9zdWJyLXguZWwgKHN0cmluZy1waXhlbC13aWR0aCk6IFVzZQoJYHdp dGgtd29yay1tYWNybycuICBQcmVmZXIgYHJlbW92ZS10ZXh0LXByb3BlcnRpZXMnIHRvCglg cHJvcGVydGl6ZScgdG8gYXZvaWQgY3JlYXRpbmcgYSBuZXcgc3RyaW5nIG9uIGVhY2ggY2Fs bC4KCmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3Avc3Vici14LmVsIGIvbGlzcC9lbWFj cy1saXNwL3N1YnIteC5lbAppbmRleCAzMzQ3YzgwMmY2OC4uODM1MjhmNWM1ZGQgMTAwNjQ0 Ci0tLSBhL2xpc3AvZW1hY3MtbGlzcC9zdWJyLXguZWwKKysrIGIvbGlzcC9lbWFjcy1saXNw L3N1YnIteC5lbApAQCAtMzkzLDIwICszOTMsMjQgQEAgc3RyaW5nLXBpeGVsLXdpZHRoCiAg ICAgICAwCiAgICAgOzsgS2VlcGluZyBhIHdvcmsgYnVmZmVyIGFyb3VuZCBpcyBtb3JlIGVm ZmljaWVudCB0aGFuIGNyZWF0aW5nIGEKICAgICA7OyBuZXcgdGVtcG9yYXJ5IGJ1ZmZlci4K LSAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciAoZ2V0LWJ1ZmZlci1jcmVhdGUgIiAqc3RyaW5n LXBpeGVsLXdpZHRoKiIpCi0gICAgICA7OyBJZiBgZGlzcGxheS1saW5lLW51bWJlcnMnIGlz IGVuYWJsZWQgaW4gaW50ZXJuYWwgYnVmZmVycwotICAgICAgOzsgKGUuZy4gZ2xvYmFsbHkp LCBpdCBicmVha3Mgd2lkdGggY2FsY3VsYXRpb24gKGJ1ZyM1OTMxMSkKLSAgICAgIChzZXRx LWxvY2FsIGRpc3BsYXktbGluZS1udW1iZXJzIG5pbCkKLSAgICAgIChkZWxldGUtcmVnaW9u IChwb2ludC1taW4pIChwb2ludC1tYXgpKQotICAgICAgOzsgRGlzYWJsZSBsaW5lLXByZWZp eCBhbmQgd3JhcC1wcmVmaXgsIGZvciB0aGUgc2FtZSByZWFzb24uCi0gICAgICAoc2V0cSBs aW5lLXByZWZpeCBuaWwKLQkgICAgd3JhcC1wcmVmaXggbmlsKQorICAgICh3aXRoLXdvcmst YnVmZmVyCisgICAgICA7OyBJZiBgZGlzcGxheS1saW5lLW51bWJlcnMnIGlzIGVuYWJsZWQg aW4gaW50ZXJuYWwKKyAgICAgIDs7IGJ1ZmZlcnMgKGUuZy4gZ2xvYmFsbHkpLCBpdCBicmVh a3Mgd2lkdGggY2FsY3VsYXRpb24KKyAgICAgIDs7IChidWcjNTkzMTEpLiAgRGlzYWJsZSBg bGluZS1wcmVmaXgnIGFuZCBgd3JhcC1wcmVmaXgnLAorICAgICAgOzsgZm9yIHRoZSBzYW1l IHJlYXNvbi4KKyAgICAgIChzZXRxIGRpc3BsYXktbGluZS1udW1iZXJzIG5pbAorICAgICAg ICAgICAgbGluZS1wcmVmaXggbmlsIHdyYXAtcHJlZml4IG5pbCkKICAgICAgIChpZiBidWZm ZXIKICAgICAgICAgICAoc2V0cS1sb2NhbCBmYWNlLXJlbWFwcGluZy1hbGlzdAogICAgICAg ICAgICAgICAgICAgICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyIGJ1ZmZlcgogICAgICAgICAg ICAgICAgICAgICAgICAgZmFjZS1yZW1hcHBpbmctYWxpc3QpKQogICAgICAgICAoa2lsbC1s b2NhbC12YXJpYWJsZSAnZmFjZS1yZW1hcHBpbmctYWxpc3QpKQotICAgICAgKGluc2VydCAo cHJvcGVydGl6ZSBzdHJpbmcgJ2xpbmUtcHJlZml4IG5pbCAnd3JhcC1wcmVmaXggbmlsKSkK KyAgICAgIChlcmFzZS1idWZmZXIpCisgICAgICAoaW5zZXJ0IHN0cmluZykKKyAgICAgIDs7 IFByZWZlciBgcmVtb3ZlLXRleHQtcHJvcGVydGllcycgdG8gYHByb3BlcnRpemUnIHRvIGF2 b2lkCisgICAgICA7OyBjcmVhdGluZyBhIG5ldyBzdHJpbmcgb24gZWFjaCBjYWxsLgorICAg ICAgKHJlbW92ZS10ZXh0LXByb3BlcnRpZXMKKyAgICAgICAocG9pbnQtbWluKSAocG9pbnQt bWF4KSAnKGxpbmUtcHJlZml4IG5pbCB3cmFwLXByZWZpeCBuaWwpKQogICAgICAgKGNhciAo YnVmZmVyLXRleHQtcGl4ZWwtc2l6ZSBuaWwgbmlsIHQpKSkpKQogCiA7OzsjIyNhdXRvbG9h ZAo= --------------hohy4vh2JsEehRUqCKGegKOj-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 02:30:44 2024 Received: (at 72689) by debbugs.gnu.org; 23 Aug 2024 06:30:44 +0000 Received: from localhost ([127.0.0.1]:38711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shNoq-0005My-1J for submit@debbugs.gnu.org; Fri, 23 Aug 2024 02:30:44 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:37085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shNol-0005Mc-K9 for 72689@debbugs.gnu.org; Fri, 23 Aug 2024 02:30:42 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 573511C0005; Fri, 23 Aug 2024 06:29:44 +0000 (UTC) From: Juri Linkov To: David Ponce Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width In-Reply-To: (David Ponce via's message of "Thu, 22 Aug 2024 16:56:11 +0200") Organization: LINKOV.NET References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> Date: Fri, 23 Aug 2024 09:20:07 +0300 Message-ID: <86cylz22ip.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72689 Cc: Eli Zaretskii , 72689@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 (-) > +*** New macro 'with-work-buffer'. > +This macro is similar to the already existing macro `with-temp-buffer'. Another variant for the name that emphasizes its opposite nature to `with-temp-buffer' would be `with-permanent-buffer' or `with-perm-buffer'. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 02:50:50 2024 Received: (at 72689) by debbugs.gnu.org; 23 Aug 2024 06:50:50 +0000 Received: from localhost ([127.0.0.1]:38790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shO8I-0005u7-7n for submit@debbugs.gnu.org; Fri, 23 Aug 2024 02:50:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shO8G-0005tr-4I for 72689@debbugs.gnu.org; Fri, 23 Aug 2024 02:50:48 -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 1shO7O-0000G9-E3; Fri, 23 Aug 2024 02:49:54 -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=QBWhHvGm71FQjDtFfy8juQCC54r+4x3qT51YdfEQU5w=; b=Pc2L4UUZi+4P 1GVk/LW+f7nyWsM1xeB1SvWaIxsiBuR85SXKwAflB5/7v1ympnko6KJtYXB6TzLeYKAyxbePKadyJ 7jBbIdVQbK91tbthPyYk3NFvVRVTtPjl4QIRMucAlkaMfgKnpEBm6MRY/q3tfD1WhIWtSwxt6353b ADu+1KCfQ3nO73PvxhP0XBvUr8sNO/eIeym9MyuJkCv5TNtYcgztXljCRc6SiCkf8irNe/XQPTlIr lsm/75dPUGyRUTVmatw2RluWnB8Z9gW2VtHsHz6c1ZlHC14mbcjL+SgD2AJIc/9RnJe8Rr5fNmj3g t2gLZihw7E7CXcr6vQ8NYA==; Date: Fri, 23 Aug 2024 09:49:51 +0300 Message-Id: <86msl3rawg.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86cylz22ip.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 23 Aug 2024 09:20:07 +0300) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> <86cylz22ip.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: da_vid@orange.fr, 72689@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: Juri Linkov > Cc: Eli Zaretskii , 72689@debbugs.gnu.org > Date: Fri, 23 Aug 2024 09:20:07 +0300 > > > +*** New macro 'with-work-buffer'. > > +This macro is similar to the already existing macro `with-temp-buffer'. > > Another variant for the name that emphasizes its opposite nature > to `with-temp-buffer' would be `with-permanent-buffer' > or `with-perm-buffer'. FWIW, I like with-work-buffer better. But that doesn't mean there couldn't be proposals for better names. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 23 03:24:21 2024 Received: (at 72689) by debbugs.gnu.org; 23 Aug 2024 07:24:22 +0000 Received: from localhost ([127.0.0.1]:38904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shOej-0006qX-JI for submit@debbugs.gnu.org; Fri, 23 Aug 2024 03:24:21 -0400 Received: from smtp-72.smtpout.orange.fr ([80.12.242.72]:59889 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shOeg-0006qL-MN for 72689@debbugs.gnu.org; Fri, 23 Aug 2024 03:24:19 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id hOdrs5KFylL4ChOdrsl5x9; Fri, 23 Aug 2024 09:23:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1724397810; bh=krU84FwP6CI0ElxnuIxOMDAjyVMRuMXc3qNZEK1hjLc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=jkaEeFtzOgM/64n4LJeNThbFPCVadI5Zs5UcjdChfm4vF/CF6+rbjqru9CHPqR373 I+DDeBSZChoaxinGgT8g5Obl3L/LqkO2Aq+rrI978E8fHiz7AWtdNMPlz/ki+e1ca/ YXBtdCQcE0AzsyUHjtbOxnEK2NR7zVBkqNpp2G3PH4+k0EkbnZbDgCRDtvqfus+wxN bY89hFHGqTOAQrxybZGjzVgcecdMKlcH9RfyC590z5krE3Ay3FQD/Ij9ShjEYb7fEk FQjx82WhAZVERdrmRfcVCXb2Oce/iTPYJbJMZ0MaRSfacdtB6Qr5XwsLIDSEirvwuT 4LZC5byqiD1LA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Fri, 23 Aug 2024 09:23:30 +0200 X-ME-IP: 2.7.225.247 Message-ID: Date: Fri, 23 Aug 2024 09:23:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii , Juri Linkov References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> <86cylz22ip.fsf@mail.linkov.net> <86msl3rawg.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <86msl3rawg.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: 72689 Cc: 72689@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 23/08/2024 8:49 AM, Eli Zaretskii wrote: >> From: Juri Linkov >> Cc: Eli Zaretskii , 72689@debbugs.gnu.org >> Date: Fri, 23 Aug 2024 09:20:07 +0300 >> >>> +*** New macro 'with-work-buffer'. >>> +This macro is similar to the already existing macro `with-temp-buffer'. >> >> Another variant for the name that emphasizes its opposite nature >> to `with-temp-buffer' would be `with-permanent-buffer' >> or `with-perm-buffer'. > > FWIW, I like with-work-buffer better. But that doesn't mean there > couldn't be proposals for better names. Same for me. The name `with-work-buffer' clearly stay that you are using a work buffer, which is actually a temp buffer, excepted that the implementation try to minimize the number of new allocated buffer. `with-work-buffer' could be safely replaced by `with-temp-buffer' and probably `with-temp-buffer' by `with-work-buffer' in many cases. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 31 04:28:09 2024 Received: (at 72689-done) by debbugs.gnu.org; 31 Aug 2024 08:28:09 +0000 Received: from localhost ([127.0.0.1]:53911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skJSq-00071Q-Mr for submit@debbugs.gnu.org; Sat, 31 Aug 2024 04:28:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skJSo-00070u-Cj for 72689-done@debbugs.gnu.org; Sat, 31 Aug 2024 04:28:07 -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 1skJRm-0000eM-IQ; Sat, 31 Aug 2024 04:27:02 -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=xE6sowrlsazAjjXx/4ljWEZgIIwZUj0zlx0konfUgUA=; b=Daauv7EJDt18 N7YbUTZdtEpJyppYUvKs3416OunokJb76KLEGeSyKGyY17jUhcqYZHoOrS43MX9K9hEw6S6k5zx3G NhvfnZP8pxZgjhOlUpUkJY20IrNHnE1+Yqd0ao77to/GOMjw29/yd6H+ke292HZ9C1l8K5sYDGe2U FVCjvXgOKWQ9b1pDjJCVFqM/UGQYz7uYogpMvgGSWa4o28+SDLQkjdUgmeLAvkGR90xC3Dg5gFb1h DEVhcVZhb7ouM7q2N2dxYjJBqxixFdf7xQ+deO1evw/wwoQgJ3E8WPffkWATVT5hj7w33w6UmkqfR zjA3s5d3yGBbF6oSSH2gbg==; Date: Sat, 31 Aug 2024 11:26:59 +0300 Message-Id: <86ed65cd2k.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: (message from David Ponce on Thu, 22 Aug 2024 16:56:11 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689-done Cc: 72689-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: Thu, 22 Aug 2024 16:56:11 +0200 > Cc: 72689@debbugs.gnu.org > From: David Ponce > > > LGTM, thanks. > > Thanks. Please find attached 2 patches: > > 1. with-work-buffer.patch to introduce the new macro with-work-buffer. > > 2. string-pixel-width.patch to improve `string-pixel-width'. Thanks, installed on the master branch, and closing the bug. Please in the future try to submit patches using "git format-patch", as that makes the patches easier to apply. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 31 06:52:57 2024 Received: (at 72689-done) by debbugs.gnu.org; 31 Aug 2024 10:52:57 +0000 Received: from localhost ([127.0.0.1]:54048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skLiz-0002l9-E9 for submit@debbugs.gnu.org; Sat, 31 Aug 2024 06:52:57 -0400 Received: from msa-216.smtpout.orange.fr ([193.252.23.216]:60638 helo=msa.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skLiw-0002l0-Gi for 72689-done@debbugs.gnu.org; Sat, 31 Aug 2024 06:52:55 -0400 Received: from [192.168.1.21] ([2.7.225.247]) by smtp.orange.fr with ESMTPA id kLhwsTosiQaX2kLhws90pY; Sat, 31 Aug 2024 12:51:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1725101515; bh=LiaR7f9qRXW9oWmgEiTZStxIA7begSIiuEMX3VClVNg=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=NV0fbzuU5LUz3nUcPcHhsGeWaYzHfmxAfu+Dgh97vrKEb2KNDfyHwU0PY2EdL7SEF kSpYfoWr4A9ETnPi+IEdgCS8gqpECQA5dktsg1F6nJKpAGk7Du6sBvtO+GCVk3AKC/ HsBgwc9DuCcoDaJ636lhc7mriQrhG9DuaoUSgGaUh33VIP0rnYORT4PKUEixhCVT/P yBHQO9tiR0drA616H6Kskt7LftGi0OIZv9Xl9paGuSRytGjtdZWleXy4c99bWD3FZR 1p+ZCvKHnSvYh8nnmuxyO2HuCpCVpqoMezxYvTWDz9pmdWjtyu0y25pJNh+JNNEHFp 75K66BnI8qghA== X-ME-Helo: [192.168.1.21] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Sat, 31 Aug 2024 12:51:55 +0200 X-ME-IP: 2.7.225.247 Message-ID: <3a66affe-a0b6-47a9-8b76-271da619df85@orange.fr> Date: Sat, 31 Aug 2024 12:51:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width To: Eli Zaretskii References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> <86ed65cd2k.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <86ed65cd2k.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: 72689-done Cc: 72689-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: -1.0 (-) On 31/08/2024 10:26 AM, Eli Zaretskii wrote: >> Date: Thu, 22 Aug 2024 16:56:11 +0200 >> Cc: 72689@debbugs.gnu.org >> From: David Ponce >> >>> LGTM, thanks. >> >> Thanks. Please find attached 2 patches: >> >> 1. with-work-buffer.patch to introduce the new macro with-work-buffer. >> >> 2. string-pixel-width.patch to improve `string-pixel-width'. > > Thanks, installed on the master branch, and closing the bug. Many thanks! Looking at the new version of string-pixel-width, I realized that I left a call to erase-buffer that is not necessary. Leaving it is not a problem, but it would save a function call to remove it. diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 83528f5c5dd..4cdb065feeb 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -405,7 +405,6 @@ string-pixel-width (with-current-buffer buffer face-remapping-alist)) (kill-local-variable 'face-remapping-alist)) - (erase-buffer) (insert string) ;; Prefer `remove-text-properties' to `propertize' to avoid ;; creating a new string on each call. > > Please in the future try to submit patches using "git format-patch", > as that makes the patches easier to apply. Ok, I will have study this command. I'm afraid I only use git in a very basic way. Many thanks for your help! From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 31 08:01:39 2024 Received: (at 72689) by debbugs.gnu.org; 31 Aug 2024 12:01:39 +0000 Received: from localhost ([127.0.0.1]:54209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skMnS-0004oZ-PG for submit@debbugs.gnu.org; Sat, 31 Aug 2024 08:01:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skMnQ-0004oJ-VE for 72689@debbugs.gnu.org; Sat, 31 Aug 2024 08:01:37 -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 1skMmP-0004Np-BI; Sat, 31 Aug 2024 08:00:33 -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=wTkdE8JMpSSA0WW0sBUG/6wDOyf/ckvxlkpXG0VpGT4=; b=nBcZSMTR0swc gNKgxqavsQ7ZCiIn6MNg/V/eGbBCds0V3qBJJLNhQJO733jJGhN07YB+mC7r+0pGkRmikuyLc6Rds 3i1SRVeK7ZyS0d9AUfFz9JUUsGlG0Fy6o32SkQ48hbSu1KEeu+Yw28si/XpZtFxDGqSjGkLhFjnBL 4NpGmpw3caR+YYiuRnCT4g1Bz6vSD3pHyll4SHdHDDUabw8FEfY2KppNbelD75KWVM7kKEU5/XOOK NfULhjgbj/dwpLHUdQ2aaU7UkY66QjPWFRXuXblJveBjQORXWm1VbGH/qLPULWqRJZHnrqIyBUxxI 3ZNDvhI7qxEbwXTf4/e/UA==; Date: Sat, 31 Aug 2024 15:00:31 +0300 Message-Id: <86h6b0c36o.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <3a66affe-a0b6-47a9-8b76-271da619df85@orange.fr> (message from David Ponce on Sat, 31 Aug 2024 12:51:52 +0200) Subject: Re: bug#72689: 31.0.50; Proposal to improve string-pixel-width References: <54d1d667-55d0-41fc-9eec-38b3881d799b@orange.fr> <86bk1q1m0l.fsf@gnu.org> <8634n219b1.fsf@gnu.org> <35119d55-c582-4f4b-b80d-d94fc6b8886c@orange.fr> <86jzgauiav.fsf@gnu.org> <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> <86seuxte6r.fsf@gnu.org> <867cc8u8lj.fsf@gnu.org> <86ed65cd2k.fsf@gnu.org> <3a66affe-a0b6-47a9-8b76-271da619df85@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 72689 Cc: 72689@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: Sat, 31 Aug 2024 12:51:52 +0200 > Cc: 72689-done@debbugs.gnu.org > From: David Ponce > > > Thanks, installed on the master branch, and closing the bug. > > Many thanks! > > Looking at the new version of string-pixel-width, I realized that I left > a call to erase-buffer that is not necessary. Leaving it is not a problem, > but it would save a function call to remove it. Thanks, done. From unknown Fri Jun 20 07:27:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 29 Sep 2024 11:24:17 +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