From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: Brahimi Saifullah Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 05:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 51995@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16373846771658 (code B ref -1); Sat, 20 Nov 2021 05:05:02 +0000 Received: (at submit) by debbugs.gnu.org; 20 Nov 2021 05:04:37 +0000 Received: from localhost ([127.0.0.1]:41316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moIYH-0000Qg-8v for submit@debbugs.gnu.org; Sat, 20 Nov 2021 00:04:37 -0500 Received: from lists.gnu.org ([209.51.188.17]:52142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moIYF-0000QW-8n for submit@debbugs.gnu.org; Sat, 20 Nov 2021 00:04:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moIYE-00068d-W9 for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 00:04:35 -0500 Received: from [2607:f8b0:4864:20::836] (port=38707 helo=mail-qt1-x836.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1moIYC-0000ph-Qq for bug-gnu-emacs@gnu.org; Sat, 20 Nov 2021 00:04:34 -0500 Received: by mail-qt1-x836.google.com with SMTP id 8so11507725qtx.5 for ; Fri, 19 Nov 2021 21:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=09p81VldLPhoOE4htDq3aCWGfh3cCUPgM7pAbfE++is=; b=A6MRXX+ZG6S4geHJK+bikY6vXa3INX2aIH88JMCWcJG2eqith+ZZyLsw0axcN+Co3r NC5oWlOKw3c41PmZKsQx2m+QyEexEk3CVPTeWi6c/eQeqohOFmknAWY/FORS1415ndk5 qYA8V5g4rGsae9LphuEehqb90iVZWJ8f1pIKYDpMWYiwvmOzF62orPWbJmUWEiRTDAmk GYMfajLZ8SWVZKh7ejbW68Hx1j192/lZ/0hDUquvdOtRpR3BHBqOnHUvPFrF3x9bZ8SS 2EAxRRTmDDq4D1aWDuw5rGHjC0V/nNeZNjbCObL8NnH/B1RNibtpdvbWEhT3e0TDFWB2 8GzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=09p81VldLPhoOE4htDq3aCWGfh3cCUPgM7pAbfE++is=; b=LL9xtBEJTQih8d0iN31R/hfXscvrEMs3fTAuO2ido2+robVgJPg72p1VW2BYzxXGBH zwC+m+UNOKojuWGl2SFlT3DB1eSqjrwW7iuPoQsPB6K/H4CqVZaPDIczTKF8WZBFLwlE m1G7325TXTtb9XsuYqoVJx4bccQhaBC4DJcBzFzUMDjmqDuhUW4+VxfvrUlrzytNm427 8iXYtWCLD8IxTtkvk05k4bsQpI+owQgcAzfuV5Am50vRyv305P66pFZbCk8/hQrHvrg/ 5x821iKJa2kDhBt0TBcg17QQhnuITPSsHrwmMF3NjVBeXLSraeiN6VjPxKg8NlLcum1P 9v9w== X-Gm-Message-State: AOAM533meti0GIN8Iw1cuVpbNpHBupAsi/TkD/U6Fyy8cfr5tGXBykBi 6uZr57pALQiwBq053lc/deJDSxDoG+qeeiw8 X-Google-Smtp-Source: ABdhPJxSVy3m99ONkcY+mdY0nGaKXbJ1TiIuFw+ccsrT7ZNytGn9cJplL1dQE2as/dk8wPvW4FQVIg== X-Received: by 2002:ac8:4e4f:: with SMTP id e15mr12276482qtw.168.1637384671335; Fri, 19 Nov 2021 21:04:31 -0800 (PST) Received: from COMPUTADOR ([2804:14d:90bc:8726:6928:8009:bb3:aa5f]) by smtp.googlemail.com with ESMTPSA id e17sm1021869qtw.18.2021.11.19.21.04.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Nov 2021 21:04:31 -0800 (PST) From: Brahimi Saifullah Date: Sat, 20 Nov 2021 02:04:14 -0300 Message-ID: <84czmvbepd.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::836 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::836; envelope-from=brahimi.saifullah@gmail.com; helo=mail-qt1-x836.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) 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 (--) emacs -Q (string-pixel-width "foo") =3D> 24 (string-pixel-width "fooooooooooooooooooooooooooooooooooooooooooooooooooooo= ooooooooooooooooooooooooooooooooooooooo") =3D> 744 C-x 3 (or reduce the size of the current window some other way) (string-pixel-width "fooooooooooooooooooooooooooooooooooooooooooooooooooooo= ooooooooooooooooooooooooooooooooooooooo") =3D> 481 C-x 3 (string-pixel-width "fooooooooooooooooooooooooooooooooooooooooooooooooooooo= ooooooooooooooooooooooooooooooooooooooo") =3D> 225 And so on. The exact values might vary per system. The problem is that, when the string's width is larger than the windows' wi= dth, the windows' width is returned, and not the string's. This can be traced back to `window-text-pixel-size', specifically: | The optional argument X-LIMIT, if non-nil, specifies the maximum X | coordinate beyond which the text should be ignored. It is therefore | also the maximum width that the function can return. X-LIMIT nil or | omitted means to use the pixel-width of WINDOW=E2=80=99s body. This defa= ult | means text of truncated lines wider than the window will be ignored; | specify a large value for X-LIMIT if lines are truncated and you need | to account for the truncated text. Use nil for X-LIMIT if you want to | know how high WINDOW should become in order to fit all of its buffer=E2= =80=99s | text with the width of WINDOW unaltered. Use the maximum width WINDOW | may assume if you intend to change WINDOW=E2=80=99s width. Since calcula= ting | the width of long lines can take some time, it=E2=80=99s always a good id= ea to | make this argument as small as possible; in particular, if the buffer | contains long lines that shall be truncated anyway. In `string-pixel-width', X-LIMIT is nil. I think the best solution is to modify `window-text-pixel-size' so that X-LIMIT may be specified as having "no limit". Y-LIMIT already offers this possibility: when it is nil, the entirety of the buffer is considered (in reality, it seems to be simply set to INT_MAX, and that does the job). ---------------------------------------------------------------------------= ----- I'm experience some different problems with this function, and I'm pretty s= ure it don't stem from this same issue, but from WINDOW being buffer. Should I open a new bug report? Or expand upon the issue on this same threa= d? In GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2021-11-19 built on COMPUTADOR Repository revision: 956f21b6b916f8d87a7b872e02f668883c17b8ba Repository branch: master Windowing system distributor 'Microsoft Corp.', version 10.0.19041 System Description: Microsoft Windows 10 Enterprise (v10.0.2004.19041.1348) Configured using: 'configure --with-native-compilation --with-json --with-imagemagick --without-pop' Configured features: ACL DBUS GIF GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XPM ZLIB Important settings: value of $LC_CTYPE: pt_BR.UTF-8 value of $LANG: PTB locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search seq byte-opt bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils gv time-date subr-x help-mode cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify dbusbind w32 lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 72646 4855) (symbols 48 6899 0) (strings 32 21630 1558) (string-bytes 1 703288) (vectors 16 14099) (vector-slots 8 298463 13452) (floats 8 26 261) (intervals 56 234 3) (buffers 992 10)) From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 07:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Brahimi Saifullah Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163739285617298 (code B ref 51995); Sat, 20 Nov 2021 07:21:02 +0000 Received: (at 51995) by debbugs.gnu.org; 20 Nov 2021 07:20:56 +0000 Received: from localhost ([127.0.0.1]:41462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moKgC-0004Uw-Jt for submit@debbugs.gnu.org; Sat, 20 Nov 2021 02:20:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moKgB-0004Uj-HI for 51995@debbugs.gnu.org; Sat, 20 Nov 2021 02:20:55 -0500 Received: from [2001:470:142:3::e] (port=58468 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moKg6-0008Oi-Aq; Sat, 20 Nov 2021 02:20:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4dYZE6r3OQTAYO+MjCme1zJIQgR79mV+Fc0PlETmVGo=; b=KFtI+RUHm4ag C2YlMJUa96nvQh5OphN9O/1vCwC4wLmr/a9PLkJKKL5hZjEmCMXxoSBaJtsP7V0nz7Chv8cfdajrb fRUMXRutFLw42wR3AVE62CABC/haVpgZKzSwYCJBy61cyNBnpa7dFXhgG3eJrGPQpUQcRUKm8GjGU Pyuq9g/H9is/w8ptBqbkO2YZBIgo+athV7qVj7eh8mwvVnDXFglthwJekDpQv33SFmO9oL/jI78mG R7DiUbD6QBC6PdEkdDABR8oqv1WAAqFCznY/Wtan1aDCiPCxV/XSXsQ5CZBwSf+2JtAIg1u6n5t3d LB3ExWh1V+4WjFEXH7Ar8w==; Received: from [87.69.77.57] (port=2641 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moKg5-0005iX-TK; Sat, 20 Nov 2021 02:20:50 -0500 Date: Sat, 20 Nov 2021 09:20:51 +0200 Message-Id: <83o86fthrg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <84czmvbepd.fsf@gmail.com> (message from Brahimi Saifullah on Sat, 20 Nov 2021 02:04:14 -0300) References: <84czmvbepd.fsf@gmail.com> X-Spam-Score: -2.3 (--) 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: Brahimi Saifullah > Date: Sat, 20 Nov 2021 02:04:14 -0300 > > > emacs -Q > (string-pixel-width "foo") > => 24 > (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo") > => 744 > C-x 3 (or reduce the size of the current window some other way) > (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo") > => 481 > C-x 3 > (string-pixel-width "foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo") > => 225 > And so on. The exact values might vary per system. > > The problem is that, when the string's width is larger than the windows' width, > the windows' width is returned, and not the string's. Why is it useful to measure width of a string that is wider than the window? Isn't it enough to know that the string is wider than the window in that case? (This part is not currently documented, but documenting it is easy.) What is the actual real-life situation where this is needed? From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 08:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Brahimi Saifullah , 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163739813228395 (code B ref 51995); Sat, 20 Nov 2021 08:49:02 +0000 Received: (at 51995) by debbugs.gnu.org; 20 Nov 2021 08:48:52 +0000 Received: from localhost ([127.0.0.1]:41633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moM3H-0007Nu-KJ for submit@debbugs.gnu.org; Sat, 20 Nov 2021 03:48:51 -0500 Received: from mout.gmx.net ([212.227.17.21]:46891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moM3E-0007Ng-66 for 51995@debbugs.gnu.org; Sat, 20 Nov 2021 03:48:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637398121; bh=6xkaV7AdEais6M3S1odrJjjJcMxEcdgWjBS++I+s/ro=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=VZA35OZ4lFINzch6oYXYSq0gPYiKe6nUaPgQp2nOaeUsMJfKgyXkweX7llShcZoJr w4DI/0CDCsijooiUcJq2RZDl14Vk8oAU5pAYWfH0jhMNRWdmL9QfokddNleUszHB3Y DOdZR4hyxUa9Qm1mck56uKMYWo2HC/IAPnDphOE0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.5]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMofc-1n77M50QK4-00IhPC; Sat, 20 Nov 2021 09:48:41 +0100 References: <84czmvbepd.fsf@gmail.com> From: martin rudalics Message-ID: <4abf6240-6cb0-fda0-b264-e2b1a5078f92@gmx.at> Date: Sat, 20 Nov 2021 09:48:39 +0100 MIME-Version: 1.0 In-Reply-To: <84czmvbepd.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:mxJtnbVowocJEBSA5eYiyXZbb0W0y4pqxhcjypDTYqx9QTRDVnH S5dC22bVkYQElZ3d3NqgluspMgXzjb8vre6mRsVVBOf3/BgmlZ9+qvQubvgoR2beqWbfL9s T3ztgw9Z3SsQTWCowYFKhd/fqdxjfyy5W4IYoXf5k1pOnPAfxEeB9jWnSYK+0kGHp1iUlW5 q+I/SG4TTCNsJUgbD7fGA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:LyB6qiygdzo=:Kb8hUaDus9u4B8uXp4fbk0 ozdoOlmCwER2TAF8bwZGQjF3TME4pz3IoRgqRUvMDkjUySpAzd3HX6dBAYB7IOLD0VWTmC+Yh 8cinp1vj9yFSE32xXNhnunmNnCJQhr8uSs8ND91b37XfLHNui1qTAgyjTqnohx3NH/vzaKp7+ ZJwC64WmLP1t9gnb1va8Ku0TflH0uy8Wyyj1i9WkniKGMpk1YPYzbG6gb1uOR3SngMi3maQqc pffR6EW6V72XcrtO8mLyDipL4enK3QH+bTSU/UBC/Vd0WH1n0rdvC6aflqYR2v4McpQaVTKDu Swv+EmiddIje7LgouSJMAM2pwPcpPOZ1GJIUe/7WaYaKF0MlA6YMm1zbvsdiwTzr3pmOWMLpN iGTbEXGNfXIDV+/mDmBIigT1JHJdzOeaQiHHhsGFpUB1eSTdj6tbXEl0ESP/EfOnpP0FDTJ1s ROCccCoWhFFtH6iqAsqZTX+BzzhFdOPXKrnA6SOQGngam8beEV7ebYBOa2xr8Zvn2e0KTIHSC PTi//3whhxBi+CEfi0Xt9NxlSWZe4cMmD9aKXL33F4qn5u/+P9cFHAiXpUijnSX1sSybayPEI Ke5ugqBZJ+IsZxI2GiYk2IqTjsKt4q2z/+gavp+ZMQ5fwC1ys8ABcFY7oSqhylpeA0vV6Hkxi kh9rN/N5ErJUN75SKlTLQZaPd4i9JZ9j1zOvlSDgMTkjvpfYyN0zb+KuN4UKykD6YhvdKWLU6 efWE1vbXTZhLlt5LRi92y3fca+9iRgzs1qTBy0aukrU+MsIgBoRa+NzefFntpXttwnjZVIAm9 Bz/CsY5KKv3SZ+h6TiLMZ5Ul0LE/4iHp30obMW6WG1cUWK6G8zjcmn+euP8CkCDdqtqgpMUhT YL6bH6tmSvRUidvGmSG2VSFED6bA8Hy68OxWK2NXdnaBD95iYroIoqvRs7//39Zt9CypDGh1B YEjpN5fEpgTTpA/EplgwykHx136/DYntkR5cHQ87+P4KnnEHLZnEGwmmDCg5ivq33ogkMpRXq PfdwFjFhQR1aYnO7HdQK8hPmBER+nXQJYgzsQOa3/FFi0xYctQP8idjafHcL9NTOLCIjN2rhx Pp1NjQOiZoX24A= X-Spam-Score: 0.0 (/) 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 (-) > I think the best solution is to modify `window-text-pixel-size' so that > X-LIMIT may be specified as having "no limit". Y-LIMIT already offers > this possibility: when it is nil, the entirety of the buffer is considered > (in reality, it seems to be simply set to INT_MAX, and that does the job). Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is not a good idea to set X-LIMIT or Y-LIMIT to very large values. The doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT that Since calculating the width of long lines can take some time, it's always a good idea to make this argument as small as possible; in particular, if the buffer contains long lines that shall be truncated anyway. and about Y-LIMIT that Since calculating the text height of a large buffer can take some time, it makes sense to specify this argument if the size of the buffer is large or unknown. So any such fix has to be made in 'string-pixel-width' itself. > I'm experience some different problems with this function, and I'm pretty sure > it don't stem from this same issue, but from WINDOW being buffer. > Should I open a new bug report? Or expand upon the issue on this same thread? 'string-pixel-width' and the accompanying change of 'window-text-pixel-size' are broken in many ways, see also https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg00339.html If you see a problem that is not mentioned there, please tell us. I hopefully fixed most of the issues here but cannot send you a patch at the moment to test because my local copy is completely out of synch with master. So please bear with me. martin From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 51995@debbugs.gnu.org, Brahimi Saifullah Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.16374009721208 (code B ref 51995); Sat, 20 Nov 2021 09:37:02 +0000 Received: (at 51995) by debbugs.gnu.org; 20 Nov 2021 09:36:12 +0000 Received: from localhost ([127.0.0.1]:41686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moMn6-0000JQ-FO for submit@debbugs.gnu.org; Sat, 20 Nov 2021 04:36:12 -0500 Received: from quimby.gnus.org ([95.216.78.240]:41560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moMn2-0000Ij-6E for 51995@debbugs.gnu.org; Sat, 20 Nov 2021 04:36:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jmL7HHi0rTuMVM2WKJ1bYuWHQ/YTSuV3uqRlXvQLr4Y=; b=IYUkbU2MoWrDxdJf+M8CWxV6EC ZWVXfe95e9YS1+Ojlsn/uGtoVoOwAaYvoU41THqh3U7mWznQqHLSomF1ygJZkH40VmFM9sb8iU1jQ cM6qNtYEEqwVh5yJAb+aCX/UDVlNhZ8t1cXUc2D1dhZkfPuUFRG7p7ztMWlKoZL5WME4=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1moMms-0001qj-AF; Sat, 20 Nov 2021 10:36:01 +0100 From: Lars Ingebrigtsen References: <84czmvbepd.fsf@gmail.com> <4abf6240-6cb0-fda0-b264-e2b1a5078f92@gmx.at> X-Now-Playing: June Tabor's _Ashore_: "Finisterre" Date: Sat, 20 Nov 2021 10:35:56 +0100 In-Reply-To: <4abf6240-6cb0-fda0-b264-e2b1a5078f92@gmx.at> (martin rudalics's message of "Sat, 20 Nov 2021 09:48:39 +0100") Message-ID: <87wnl3qidf.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: martin rudalics writes: > Since calculating the text height of a large buffer can take some time, > it makes sense to specify this argument if the size of the buffer is > large or unknown. > > So any such fix has to be made [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) 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 (---) martin rudalics writes: > Since calculating the text height of a large buffer can take some time, > it makes sense to specify this argument if the size of the buffer is > large or unknown. > > So any such fix has to be made in 'string-pixel-width' itself. Yup. Finding an appropriate limit to use here isn't trivial, though. But I guess we could just use something very large, or add an optional parameter to 'string-pixel-width' to allow the caller to control it... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width References: <84czmvbepd.fsf@gmail.com> In-Reply-To: <84czmvbepd.fsf@gmail.com> Resent-From: Brahimi Saifullah Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 21:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.16374442221804 (code B ref 51995); Sat, 20 Nov 2021 21:38:02 +0000 Received: (at 51995) by debbugs.gnu.org; 20 Nov 2021 21:37:02 +0000 Received: from localhost ([127.0.0.1]:43768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moY2g-0000Sx-2P for submit@debbugs.gnu.org; Sat, 20 Nov 2021 16:37:02 -0500 Received: from mail-ua1-f47.google.com ([209.85.222.47]:39781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moY2e-0000SW-2s for 51995@debbugs.gnu.org; Sat, 20 Nov 2021 16:37:00 -0500 Received: by mail-ua1-f47.google.com with SMTP id i6so28469414uae.6 for <51995@debbugs.gnu.org>; Sat, 20 Nov 2021 13:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:from:to:cc:subject; bh=DChnpdwESNxZHL16yWs1d8cKY4/giGctacUh6mLpveQ=; b=Bnwds7frt2i0Km7O+QsfZ9tXVv+q7NyYei3u4DVUxrJHNW38qOjBtOZR1YO580RSRM 7gjPnsJqN4lquLMrYDJ9TfU0Utr9TPTKKoNF1Vw0ICJHK3k1Y7+ehXdG/gtZwQ/PsHc9 b2RDd9Ruddpk83DjB/zuYkYSUfM7j99qyBbE53gFRRAnoE0oCYgdmrhX5PB0nVSdkyqL RVV26luFd9krLdzFeDtq0m5huEmu9W/ocOJSqUeVuRjDvi+opE8avjmnlMC9aOjl56x2 NJx9M3bPSaeVe0WjtRMl/pCmnVhONaPj6WYUn4+o913bPnayOMVKyzFO4dAtgZF/RTc2 w1LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:from:to:cc:subject; bh=DChnpdwESNxZHL16yWs1d8cKY4/giGctacUh6mLpveQ=; b=0Yczsx0nAUYbzIWrnW3A7vdarvJPeJTA+zPSXBLHg59Wee0yxaRJFlWOyicR1uUs8s /FPlVQeCX/T4Yv0SEPm1lb7PVDi5VG91DrhNFnmn5cVJPCR0PnDxKyOoQuBKkG0qg4+n HeJ/sVY3SH0iedfgVxg9NvG9djzoncO8LzYeFwCKoVirk/KXXVX1PqaNjTpPJEu0r8zt Hu2xlrXZpLu6+nQwlVUpwc4Q7X2/NDe9wBA6YgV+0y4zkM18gdzFW0jTYuHRIR8mv4FD 7Tn9D/y9Hv2Y3CcUetD6npzr6UP/CgKUUMZPUgVjxxeQbbB3XMfIb1p7I0Y/4lWdf4rv OrYg== X-Gm-Message-State: AOAM532hNFYxKG0KlLB0MGan8zXVGQ3xfza/H2aEjTDMPP4rz78BiqHs rfyP2Iv+7pIcoeFGJ81ipTE78cqQulzKCnBj X-Google-Smtp-Source: ABdhPJxGzQEEwZf7+IkqM/drmrxfrRkc3JWcoMLopmxZXXLAcGr9e4xlmesxUrWiQ757V+cY6VL6KQ== X-Received: by 2002:a05:6102:3ec3:: with SMTP id n3mr112360241vsv.48.1637444214316; Sat, 20 Nov 2021 13:36:54 -0800 (PST) Received: from COMPUTADOR ([2804:14d:90bc:8726:6928:8009:bb3:aa5f]) by smtp.googlemail.com with ESMTPSA id g28sm1934121vkl.16.2021.11.20.13.36.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Nov 2021 13:36:53 -0800 (PST) Date: Sat, 20 Nov 2021 18:36:46 -0300 Message-Id: <84ilwm7bm9.fsf@gmail.com> From: Brahimi Saifullah X-Spam-Score: 0.0 (/) 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 (-) >What is the actual real-life situation where >this is needed? Mainly when a window with delicated alignment is resized. Indeed, in most situations it likely won't be an issue, but I can think of times when it most definitely will: For example, in the package I'm working on, I want certain text to always be centered, even if the user resizes the window. (By centered I mean having the same amount of space on both sides). This is a mockup of the code I use: (let* ((string "Hello World, Hello World, Hello world") (width (string-pixel-width string))) (insert (propertize " " 'display `(space :align-to (- center (,(/ width 2))))) string)) If you evaluate this code in a window that is bigger or equal to the size of the string, it will be properly aligned even if you resize it later. But if you evaluate it in a small window, it will be grossly misaligned when you increase the window size. From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width References: <84czmvbepd.fsf@gmail.com> In-Reply-To: <84czmvbepd.fsf@gmail.com> Resent-From: Brahimi Saifullah Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Nov 2021 21:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.16374445322326 (code B ref 51995); Sat, 20 Nov 2021 21:43:02 +0000 Received: (at 51995) by debbugs.gnu.org; 20 Nov 2021 21:42:12 +0000 Received: from localhost ([127.0.0.1]:43772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moY7f-0000bS-Q0 for submit@debbugs.gnu.org; Sat, 20 Nov 2021 16:42:12 -0500 Received: from mail-ua1-f54.google.com ([209.85.222.54]:39743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moY7e-0000bE-AK for 51995@debbugs.gnu.org; Sat, 20 Nov 2021 16:42:10 -0500 Received: by mail-ua1-f54.google.com with SMTP id i6so28484110uae.6 for <51995@debbugs.gnu.org>; Sat, 20 Nov 2021 13:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:from:to:cc:subject; bh=+8KhxvcFTxz8Ht2vklNZS1L0iYm6PgvaBo3Konmbm5k=; b=EF8EwZo+BoS7dciDZ1CzYeibrhJe/ECjoLYis6Z3D6L+cIpIGoe4WmaNl9GoFl2yo/ PIC094XJcqi1x+XJXYOcuYhEdyyLrdBOVA9pO6HiQe7DtOdFIL0g1NxqQOxwxx5kjnvv 9S0QY4G/aKQenXiM50ANK9ErxDFrsJItyLaOPpUICkT8pfQgpkW+zr8Qz1bQD8wrWBX1 nbvyd4y+k9xyjlQuodUQyUU1E2so9dQLaZ+vYz3pL1cwTI209cAjvM58weQ/wuv4qpzk 7YQdMmUITW4X23pIoUOs1JrHAvAVYejSCQ+3uq1gxMDLE+kBPYVXJUiJe1SnnDdlUz1M o0WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:from:to:cc:subject; bh=+8KhxvcFTxz8Ht2vklNZS1L0iYm6PgvaBo3Konmbm5k=; b=aAb1AKAQn8REJa/9Su6qjvgIwbgJ89jBfK51JsHMoNugMk1Sv6QbYjB/+NEoYrYRvc zSsapvzGrS1hf+hYuJeA4fAZ1m/Q/L5fONcoqbk8rfletIw8Y5nEpuLmyTleN8i1v8YU qBTzJ1xxYJ6mVIcDdaA3nHl+rbGJEG41e11xmCNy/3vaUFe+I+nC/ExEm6ZkXnUea6fh k1tVY2FTgt7AOWDag4uNrPWdfnObx9JPvwD94+/m/dO7YBjFnNSpasJDr6WyT0uv5Vg4 wEy0TsTuCSKy4ggKyk0eKc43Gel1mOkAmLGVsPzy1wkq7Zyq0EMtEC8U5vPZqtqxzSI2 1m/A== X-Gm-Message-State: AOAM533ZEP+speLgR670Rt7uxzD/OpRJNLZnzFaEkmULTI4WRziCXR+8 gIdZDEM/2aialxtGQC1i+JiTbtYGvyyDxqLO X-Google-Smtp-Source: ABdhPJzZHSOdb9A8iSkof8Odd2nacUj1aiT+RljT6gzL8jZpZLPBt5xHWJ/BvYmwDYDMdsPEWN/1Aw== X-Received: by 2002:ab0:4301:: with SMTP id k1mr65275381uak.75.1637444524537; Sat, 20 Nov 2021 13:42:04 -0800 (PST) Received: from COMPUTADOR ([2804:14d:90bc:8726:6928:8009:bb3:aa5f]) by smtp.googlemail.com with ESMTPSA id u125sm2223836vsb.4.2021.11.20.13.42.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Nov 2021 13:42:04 -0800 (PST) Date: Sat, 20 Nov 2021 18:42:01 -0300 Message-Id: <84h7c67bdi.fsf@gmail.com> From: Brahimi Saifullah X-Spam-Score: 0.0 (/) 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 (-) >Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is >not a good idea to set X-LIMIT or Y-LIMIT to very large values. The >doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT >that > > Since calculating the width of long lines can take some time, it's > always a good idea to make this argument as small as possible; in > particular, if the buffer contains long lines that shall be truncated > anyway. I saw the warnings, but I'm unsure of their validity. Here are some benchmarks that I did. Each form was run on a fresh emacs -Q. Apologies in advance if there is something wrong about them: ;;; X-LIMIT nil (window width is the limit) (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "foo") (car (window-text-pixel-size nil (point-min) (point)))))) ;; (15.551981 588 8.272839) (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size nil (point-min) (point)))))) ;; (17.975419000000002 588 8.30243) ;;; X-LIMIT is equal to the width of the string plus 1 (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "foo") (car (window-text-pixel-size nil (point-min) (point) 25))))) ;; (15.489861 587 8.267005000000001) (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size nil (point-min) (point) 873))))) ;; (17.98802 587 8.421413) ;;; X-LIMIT is unreasonably large (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "foo") (car (window-text-pixel-size nil (point-min) (point) 1000000))))) ;; (15.508047000000001 587 8.281872) (benchmark-run 100000 (save-window-excursion (with-temp-buffer (set-window-buffer nil (current-buffer)) (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size nil (point-min) (point) 1000000))))) ;; (18.031506 588 8.440261) The limit actually seems to be rather irrelevant. Long strings take expectedly longer, but it doesn't seem related to how big or how small X-LIMIT is. The following use a buffer as WINDOW, as `string-pixel-width' currently does: (benchmark-run 100000 (with-temp-buffer (insert "foo") (car (window-text-pixel-size (current-buffer) (point-min) (point))))) ;; (5.935459 164 2.328032) (benchmark-run 100000 (with-temp-buffer (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size (current-buffer) (point-min) (point))))) ;; (8.362771 168 2.349145) (benchmark-run 100000 (with-temp-buffer (insert "foo") (car (window-text-pixel-size (current-buffer) (point-min) (point) 25)))) ;; (5.922218 164 2.350169) (benchmark-run 100000 (with-temp-buffer (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size (current-buffer) (point-min) (point) 873)))) ;; (7.989145 164 2.2566439999999997) (benchmark-run 100000 (with-temp-buffer (insert "foo") (car (window-text-pixel-size (current-buffer) (point-min) (point) 1000000)))) ;; (5.933362 168 2.378873) (benchmark-run 100000 (with-temp-buffer (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") (car (window-text-pixel-size (current-buffer) (point-min) (point) 1000000)))) ;; (8.006855 167 2.318854) It's a lot more efficient to use a buffer, but the difference between the limits themselves continue to be insignificant. -------------------------------------------------------------------------------- >'string-pixel-width' and the accompanying change of >'window-text-pixel-size' are broken in many ways, see also > > https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg00339.html > >If you see a problem that is not mentioned there, please tell us. Yes, those seem to be the exact problems I was experiencing. >I hopefully fixed most of the issues here but cannot send you a patch at >the moment to test because my local copy is completely out of synch with >master. So please bear with me. Take your time :) From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Nov 2021 06:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Brahimi Saifullah Cc: rudalics@gmx.at, 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163747647723866 (code B ref 51995); Sun, 21 Nov 2021 06:35:01 +0000 Received: (at 51995) by debbugs.gnu.org; 21 Nov 2021 06:34:37 +0000 Received: from localhost ([127.0.0.1]:44003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mogQv-0006Cq-99 for submit@debbugs.gnu.org; Sun, 21 Nov 2021 01:34:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mogQt-0006Cc-3M for 51995@debbugs.gnu.org; Sun, 21 Nov 2021 01:34:35 -0500 Received: from [2001:470:142:3::e] (port=43014 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mogQn-0007tp-Nk; Sun, 21 Nov 2021 01:34:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0HQJ1iEcd5LDx5wo9GxWb8fshJYzS9yGaLJXKoQErzA=; b=RyC8fDMiKAl2 NuPvho2/Y4Ci03VXeDaawg1lFWw/ITKmUURuT1/yjYqENGj6VEzybHqvCihatfBvAJhySMvGK0iGE Soe1dkk02dbGtAfE9/gwYXImIFMGlmAKOy+GRwRUnJKMcvvphu0XboV8spc7g//byBO86dsigItCU WOKPy4h29GxWuOifsacLbn7n6IKSoDuerH5vLv2KSKw3bLypj+JV4DlK9g43+Jr1vDpdOjqbv07MH xVN4BMXZWUA0+SjqlMNQrtvnZW54qylkY3LVAQrQ0OSyDkwSow0gPR6VS7S5vVqPE8R/rUY34ntWX nGp2RbHstBcllt642RD50Q==; Received: from [87.69.77.57] (port=1088 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mogQn-00046p-DJ; Sun, 21 Nov 2021 01:34:29 -0500 Date: Sun, 21 Nov 2021 08:34:34 +0200 Message-Id: <83ee7arp8l.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <84h7c67bdi.fsf@gmail.com> (message from Brahimi Saifullah on Sat, 20 Nov 2021 18:42:01 -0300) References: <84czmvbepd.fsf@gmail.com> <84h7c67bdi.fsf@gmail.com> X-Spam-Score: -2.3 (--) 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, 20 Nov 2021 18:42:01 -0300 > From: Brahimi Saifullah > Cc: 51995@debbugs.gnu.org > > >Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is > >not a good idea to set X-LIMIT or Y-LIMIT to very large values. The > >doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT > >that > > > > Since calculating the width of long lines can take some time, it's > > always a good idea to make this argument as small as possible; in > > particular, if the buffer contains long lines that shall be truncated > > anyway. > > I saw the warnings, but I'm unsure of their validity. > Here are some benchmarks that I did. Each form was run on a fresh emacs -Q. > Apologies in advance if there is something wrong about them: > > ;;; X-LIMIT nil (window width is the limit) > (benchmark-run 100000 > (save-window-excursion > (with-temp-buffer > (set-window-buffer nil (current-buffer)) > (insert "foo") ^^^ He mean a REALLY long line. Like thousands of characters. From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Nov 2021 09:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Brahimi Saifullah Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.16374859732860 (code B ref 51995); Sun, 21 Nov 2021 09:13:02 +0000 Received: (at 51995) by debbugs.gnu.org; 21 Nov 2021 09:12:53 +0000 Received: from localhost ([127.0.0.1]:44250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moiu4-0000k3-Fs for submit@debbugs.gnu.org; Sun, 21 Nov 2021 04:12:53 -0500 Received: from mout.gmx.net ([212.227.17.20]:53803) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moiu0-0000jZ-1M for 51995@debbugs.gnu.org; Sun, 21 Nov 2021 04:12:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637485962; bh=++p7UR97rUd+2cK/DP5yI+dbOYBLIEX8GnT0g88PmIs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Lp8H/1jwGW+6RcUp2USKYZnKT+r7hGIgKvs33jmDsEPjEdSfgymCpdG3dfUac2MQm bSZg4056UJbAyiFcZYSn23PSv4TmYrexcs1o52QiMIR0SHiiKwIimOkXR0Aghvrajj CrBQiIEpnXSc2JkR+o6gMipkxDjl190KxRu3ub28= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([213.142.96.19]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8XPt-1mc3Vw30Ov-014T3Q; Sun, 21 Nov 2021 10:12:41 +0100 References: <84h7c67bdi.fsf@gmail.com> From: martin rudalics Message-ID: <1e235f66-126f-96b6-2193-ce4642badb80@gmx.at> Date: Sun, 21 Nov 2021 10:12:40 +0100 MIME-Version: 1.0 In-Reply-To: <84h7c67bdi.fsf@gmail.com> Content-Type: multipart/mixed; boundary="------------D4640899B678C361160E0F37" Content-Language: en-US X-Provags-ID: V03:K1:5Z+GPAgg/72H/aszm9ztEyXptFDvMQ9EFaBcVijFcT9yTAMhbGy 50hzN8O7eYyM4BNnFSJ7cz/bnNS24gl5Krpv2EdXnIhUWUjzuI7lU9IVllDDHb67hFyDtbl 6AbSPymR01Yphk4S9KYjma/tzS/JP/116Ax8Lu3yVl3u4Wl6t3jYTYFb/O5np7enG9meuni GaIM+Vj1d1DxCyLWsd15A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:onNvHfAFEPw=:tT9VneR1v0otvItkzdUhtM TemHtQ8hWzGjNGnaV+2TfEIzXwUsClwLAXSqi5JArhEuKtZVlSE9VQDydS4HcgFrmhkXAa6s2 hm5UCLL3BVOP8CtjdpZ0F0OQjTp1ZKGTtgwfLlV7F6xFloK4QjQZJJT3KQ35s8jxQ1qupW8Ir ry9MnxNoDrcRoEp30aZbQdTtjCKXNOKKyPuo9n3HY1tiU4KiuHrOUcj4CAMbcwSZPh3UBe09f 4o3vJ0s2YNQ4jtG6MqtWahd9vMye+1wPDjVwqvZYguT6TD/a7CMBytzhebjXkxlThIWZnE1/x QY2sq5uNYZgc/VuPr0CaVCJ0oZQl7RTqmUEjDiHwFLkPQy6gFUGpA9piEjLzQAEImfBGE76FI piazyVrd/a5T8dbImKCA9JgLUBxVv336svWj3h6LYV90fes0LsH5knvUEB8X94hK0lEOJWhl4 0s74Hg6f5kZtlr3eOSr4c7Wm+fZrSVfvifuDuvuzymU5QJIyU0rOEBqfmmVVWK2Swa3qnufrA LnEX/6roO2rA0vD7HiqaWGF6cJb/cIDSjCghS6TW+8Cp5DjJ06z8oXw40dhdSt2do3qLoiheh 0ndheI69apeJnO8QfFvStjVfgGpy6yZNR0p+5CtENH/wXbk3hyAlJd099A3Qd3RpyKP/EHqcn Ko0Ubo/d+SGgMMEIgCaG57mCTuzdh0fQUs6fZ6qBjhx7kGaH5NfkvfutTQ1k0glCMyHwEi1KI J0x5sBMudJ4Jbpy4BPNIXv99g9H+8ZiIBjL0ZOBclpr0c39e2Wa4W5ZENPnzDWymshI0wcfcP VkXDND7kvYFcIqmickjEnPphgRKpiG+X/tQ8dJIvOdETWJBaBS+STkD938PHdUA7TiBbt2+9o VjHdXtQSIeilJISR8LVoWWbqWux0EDn/KqtyYe2wr0LQFs+jPVSpTtgEXSHAzaiHH6PGAEcm/ x1mw19JwHOuZGoRYhlIigkoyyFviMYdRI1aGx8swLD1Jk2NWTPYSpcxM/0dsVI+wO14e3/1B+ l1mvzfOg6RwJrCMan4knkYKk1z2Yc+vlfqNWAvLQEDWfCEvyy47tujWylKvQNAZrZTXBityel 3FvWxB6lFxoiG8= X-Spam-Score: 0.0 (/) 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. --------------D4640899B678C361160E0F37 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > I saw the warnings, but I'm unsure of their validity. > Here are some benchmarks that I did. Each form was run on a fresh emacs -Q. > Apologies in advance if there is something wrong about them: [...] > (benchmark-run 100000 > (with-temp-buffer > (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore") > (car (window-text-pixel-size > (current-buffer) (point-min) (point) 1000000)))) > ;; (8.006855 167 2.318854) > > It's a lot more efficient to use a buffer, but the difference > between the limits themselves continue to be insignificant. These examples are harmless. Please try to test (1) with a large buffer that has no newline characters and (2) with 'truncate-lines' non-nil. 'window-text-pixel-size' must be able to handle these cases gracefully even if it's not geared to them. Any clients of 'window-text-pixel-size' like 'string-pixel-width' can easily set X-LIMIT to some sufficiently large value without affecting the basic functionality of 'window-text-pixel-size'. >> I hopefully fixed most of the issues here but cannot send you a patch at >> the moment to test because my local copy is completely out of synch with >> master. So please bear with me. Please try the attached patch (if it doesn't apply, I'll send you the affected functions separately so you can apply the changes manually). Thanks, martin --------------D4640899B678C361160E0F37 Content-Type: text/x-patch; name="buffer-text-pixel-size.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="buffer-text-pixel-size.diff" diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 00668d4743..a9d0d1b11f 100644 =2D-- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -446,8 +446,7 @@ string-pixel-width "Return the width of STRING in pixels." (with-temp-buffer (insert string) - (car (window-text-pixel-size - (current-buffer) (point-min) (point))))) + (car (buffer-text-pixel-size nil nil (buffer-size))))) (provide 'subr-x) diff --git a/src/xdisp.c b/src/xdisp.c index aa01db210b..0f3b407a30 100644 =2D-- a/src/xdisp.c +++ b/src/xdisp.c @@ -10626,77 +10626,21 @@ in_display_vector_p (struct it *it) && it->dpvec + it->current.dpvec_index !=3D it->dpend); } -DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pi= xel_size, 0, 6, 0, - doc: /* Return the size of the text of WINDOW's buffer in pixels. -WINDOW can be any live window and defaults to the selected one. The -return value is a cons of the maximum pixel-width of any text line -and the pixel-height of all the text lines in the accessible portion -of buffer text. -WINDOW can also be a buffer, in which case the selected window is used, -and the function behaves as if that window was displaying this buffer. - -This function exists to allow Lisp programs to adjust the dimensions -of WINDOW to the buffer text it needs to display. - -The optional argument FROM, if non-nil, specifies the first text -position to consider, and defaults to the minimum accessible position -of the buffer. If FROM is t, it stands for the minimum accessible -position that starts a non-empty line. TO, if non-nil, specifies the -last text position and defaults to the maximum accessible position of -the buffer. If TO is t, it stands for the maximum accessible position -that ends a non-empty line. - -The optional argument X-LIMIT, if non-nil, specifies the maximum X -coordinate beyond which the text should be ignored. It is therefore -also the maximum width that the function can return. X-LIMIT nil or -omitted means to use the pixel-width of WINDOW's body. This default -means text of truncated lines wider than the window will be ignored; -specify a large value for X-LIMIT if lines are truncated and you need -to account for the truncated text. Use nil for X-LIMIT if you want to -know how high WINDOW should become in order to fit all of its buffer's -text with the width of WINDOW unaltered. Use the maximum width WINDOW -may assume if you intend to change WINDOW's width. Since calculating -the width of long lines can take some time, it's always a good idea to -make this argument as small as possible; in particular, if the buffer -contains long lines that shall be truncated anyway. - -The optional argument Y-LIMIT, if non-nil, specifies the maximum Y -coordinate beyond which the text is to be ignored; it is therefore -also the maximum height that the function can return (excluding the -height of the mode- or header-line, if any). Y-LIMIT nil or omitted -means consider all of the accessible portion of buffer text up to the -position specified by TO. Since calculating the text height of a -large buffer can take some time, it makes sense to specify this -argument if the size of the buffer is large or unknown. - -Optional argument MODE-LINES nil or omitted means do not include the -height of the mode-, tab- or header-line of WINDOW in the return value. -If it is the symbol `mode-line', 'tab-line' or `header-line', include -only the height of that line, if present, in the return value. If t, -include the height of any of these, if present, in the return value. */) - (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_li= mit, - Lisp_Object y_limit, Lisp_Object mode_lines) +/* This is like Fwindow_text_pixel_size but assumes that WINDOW's buffer + is the current buffer. Fbuffer_text_pixel_size calls it after it has + set WINDOW's buffer to the buffer specified by its BUFFER_OR_NAME + argument. */ +static Lisp_Object +window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object= to, Lisp_Object x_limit, + Lisp_Object y_limit, Lisp_Object mode_lines) { - struct window *w =3D BUFFERP (window) ? XWINDOW (selected_window) - : decode_live_window (window); - Lisp_Object buffer =3D BUFFERP (window) ? window : w->contents; - struct buffer *b; + struct window *w =3D decode_live_window (window); struct it it; - struct buffer *old_b =3D NULL; ptrdiff_t start, end, bpos; struct text_pos startp; void *itdata =3D NULL; int c, max_x =3D 0, max_y =3D 0, x =3D 0, y =3D 0; - CHECK_BUFFER (buffer); - b =3D XBUFFER (buffer); - - if (b !=3D current_buffer) - { - old_b =3D current_buffer; - set_buffer_internal (b); - } - if (NILP (from)) { start =3D BEGV; @@ -10889,12 +10833,126 @@ DEFUN ("window-text-pixel-size", Fwindow_text_p= ixel_size, Swindow_text_pixel_siz bidi_unshelve_cache (itdata, false); + return Fcons (make_fixnum (x - start_x), make_fixnum (y)); +} + +DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pi= xel_size, 0, 6, 0, + doc: /* Return the size of the text of WINDOW's buffer in pixels. +WINDOW must be a live window and defaults to the selected one. The +return value is a cons of the maximum pixel-width of any text line +and the pixel-height of all the text lines in the accessible portion +of buffer text. + +This function exists to allow Lisp programs to adjust the dimensions +of WINDOW to the buffer text it needs to display. + +The optional argument FROM, if non-nil, specifies the first text +position to consider, and defaults to the minimum accessible position +of the buffer. If FROM is t, it stands for the minimum accessible +position that starts a non-empty line. TO, if non-nil, specifies the +last text position and defaults to the maximum accessible position of +the buffer. If TO is t, it stands for the maximum accessible position +that ends a non-empty line. + +The optional argument X-LIMIT, if non-nil, specifies the maximum X +coordinate beyond which the text should be ignored. It is therefore +also the maximum width that the function can return. X-LIMIT nil or +omitted means to use the pixel-width of WINDOW's body. This default +means text of truncated lines wider than the window will be ignored; +specify a large value for X-LIMIT if lines are truncated and you need +to account for the truncated text. Use nil for X-LIMIT if you want to +know how high WINDOW should become in order to fit all of its buffer's +text with the width of WINDOW unaltered. Use the maximum width WINDOW +may assume if you intend to change WINDOW's width. Since calculating +the width of long lines can take some time, it's always a good idea to +make this argument as small as possible; in particular, if the buffer +contains long lines that shall be truncated anyway. + +The optional argument Y-LIMIT, if non-nil, specifies the maximum Y +coordinate beyond which the text is to be ignored; it is therefore +also the maximum height that the function can return (excluding the +height of the mode- or header-line, if any). Y-LIMIT nil or omitted +means consider all of the accessible portion of buffer text up to the +position specified by TO. Since calculating the text height of a +large buffer can take some time, it makes sense to specify this +argument if the size of the buffer is large or unknown. + +Optional argument MODE-LINES nil or omitted means do not include the +height of the mode-, tab- or header-line of WINDOW in the return value. +If it is the symbol `mode-line', 'tab-line' or `header-line', include +only the height of that line, if present, in the return value. If t, +include the height of any of these, if present, in the return value. */) + (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_li= mit, + Lisp_Object y_limit, Lisp_Object mode_lines) +{ + struct window *w =3D decode_live_window (window); + struct buffer *b =3D XBUFFER (w->contents); + struct buffer *old_b =3D NULL; + Lisp_Object value; + + if (b !=3D current_buffer) + { + old_b =3D current_buffer; + set_buffer_internal_1 (b); + } + + value =3D window_text_pixel_size (window, from, to, x_limit, y_limit, m= ode_lines); + if (old_b) - set_buffer_internal (old_b); + set_buffer_internal_1 (old_b); + + return value; +} + +DEFUN ("buffer-text-pixel-size", Fbuffer_text_pixel_size, Sbuffer_text_pi= xel_size, 0, 4, 0, + doc: /* Return size of whole text of BUFFER_OR_NAME in WINDOW. +BUFFER-OR-NAME must specify a live buffer or the name of a live buffer +and defaults to the current buffer. WINDOW must be a live window and +defaults to the selected one. The return value is a cons of the maximum +pixel-width of any text line and the pixel-height of all the text lines +of the buffer specified by BUFFER-OR-NAME. + +The optional arguments X-LIMIT and Y-LIMIT have the same meaning as with +`window-text-pixel-size'. + +Do not use this function if the buffer specified by BUFFER_OR_NAME is +already displayed in WINDOW. `window-text-pixel-size' is cheaper in +that case because it does not have to temporarily show that buffer in +WINDOW. */) + (Lisp_Object buffer_or_name, Lisp_Object window, Lisp_Object x_limit, + Lisp_Object y_limit) +{ + struct window *w =3D decode_live_window (window); + struct buffer *b =3D (NILP (buffer_or_name) + ? current_buffer + : XBUFFER (Fget_buffer (buffer_or_name))); + Lisp_Object buffer, value; + ptrdiff_t count =3D SPECPDL_INDEX (); - return Fcons (make_fixnum (x - start_x), make_fixnum (y)); + XSETBUFFER (buffer, b); + + /* The unwind form of with_echo_area_buffer is what we need here to + make WINDOW temporarily show our buffer. */ + record_unwind_protect (unwind_with_echo_area_buffer, + with_echo_area_buffer_unwind_data (w)); + + set_buffer_internal_1 (b); + + if (!EQ (buffer, w->contents)) + { + wset_buffer (w, buffer); + set_marker_both (w->pointm, buffer, BEG, BEG_BYTE); + set_marker_both (w->old_pointm, buffer, BEG, BEG_BYTE); + } + + value =3D window_text_pixel_size (window, Qnil, Qnil, x_limit, y_limit,= Qnil); + + unbind_to (count, Qnil); + + return value; } + DEFUN ("display--line-is-continued-p", Fdisplay__line_is_continued_p, Sdisplay__line_is_continued_p, 0, 0, 0, doc: /* Return non-nil if the current screen line is continued on = display. */) @@ -35023,6 +35081,7 @@ syms_of_xdisp (void) defsubr (&Sinvisible_p); defsubr (&Scurrent_bidi_paragraph_direction); defsubr (&Swindow_text_pixel_size); + defsubr (&Sbuffer_text_pixel_size); defsubr (&Smove_point_visually); defsubr (&Sbidi_find_overridden_directionality); defsubr (&Sdisplay__line_is_continued_p); --------------D4640899B678C361160E0F37-- From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width References: <84czmvbepd.fsf@gmail.com> In-Reply-To: <84czmvbepd.fsf@gmail.com> Resent-From: Brahimi Saifullah Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Nov 2021 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , martin rudalics Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163751989812727 (code B ref 51995); Sun, 21 Nov 2021 18:39:02 +0000 Received: (at 51995) by debbugs.gnu.org; 21 Nov 2021 18:38:18 +0000 Received: from localhost ([127.0.0.1]:46002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1morjG-0003JD-Ga for submit@debbugs.gnu.org; Sun, 21 Nov 2021 13:38:18 -0500 Received: from mail-ua1-f49.google.com ([209.85.222.49]:44762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1morjF-0003J0-Vd for 51995@debbugs.gnu.org; Sun, 21 Nov 2021 13:38:18 -0500 Received: by mail-ua1-f49.google.com with SMTP id p2so32013053uad.11 for <51995@debbugs.gnu.org>; Sun, 21 Nov 2021 10:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:from:to:cc:subject; bh=m4zzSKzqC9JI2XCsPpNYKCR6e0VJg/7OO3PWL4b3Y5k=; b=FudlXPqkUZKY53KXhmMcSdI4qEoyH8m/TYc0YM5TStTjgIot0tmU2tvXeaF8GU8wKG mcjmGqN6MbIvLYkYirwa73tvRdKfJAMdHI45mt901znZNcq+9RMSBmf4B2uaLkmRnc8l LmcJMoeVpfjyaN7idS1hhUabspk5Ew5I70dBUIdPhXKf4Bwc+tCRvoRo9GjKQl5/M/BM MTtG+Ze8S3vMLb+Hvw92yu7Wyg40ASrnE4eIaolipRLNDvq9B+ufMDniKJdZgNl52KXd Nt8oAgAtku1HRRI4fnqsgSNfz34W37/mQLi+y/sWlgyV+jrLNSCn+70VGH8vYnCSBqf2 SDmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:from:to:cc:subject; bh=m4zzSKzqC9JI2XCsPpNYKCR6e0VJg/7OO3PWL4b3Y5k=; b=zH+K/H58kivch3Y4+kBW8ZvE2D1igr0aVAFrW9y2ybZ8OqNI0WAQ0juNJ6PvzPrDr+ Dy5VqIjgjwiLN6m08UHL1zJJsFMOPGXfDjYmzU4y/7v4K4LwXdWYOZUlc9hrJVb0XrqC KkUe0SUch2GOwZrgHf13sSNNqUC5d7E0zyAswCa46Lx1BY5p7KV+AURaR5BqBRvirduw juNpfa/2qPWbwxjqZA8NDxJ9OfqG7JDjWo5jORx8mZHnVj9+GI+a959zYV34bnyyNGHy oO7gHmUEJj5CdKVXBu7lijlW/3sK1bBYeQeabgKhu0j3OmOAvc/iurMZp7YQdgCozzy+ w7WQ== X-Gm-Message-State: AOAM531fsKOLN4LLsAG/JU5cyyEHJyNmiyUQhST+HQXGh5wHnpgmkdCf 6j3nqWYpA2bZEiYQrHRx0UAmUUKh7/WPmQPk X-Google-Smtp-Source: ABdhPJynh06tVgYhVmmJftGtgsjRYvXXVfcgz13GGnh+0ITwPoma2NBlXZqg9rqrnqeCpf0OMzxwYw== X-Received: by 2002:ab0:3886:: with SMTP id z6mr41296049uav.79.1637519892210; Sun, 21 Nov 2021 10:38:12 -0800 (PST) Received: from COMPUTADOR ([2804:14d:90bc:8726:4c9c:5960:c709:1997]) by smtp.googlemail.com with ESMTPSA id q9sm3249092vkn.44.2021.11.21.10.38.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Nov 2021 10:38:11 -0800 (PST) Date: Sun, 21 Nov 2021 15:38:05 -0300 Message-Id: <84ee79xsky.fsf@gmail.com> From: Brahimi Saifullah X-Spam-Score: 0.0 (/) 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 (-) >He mean a REALLY long line. Like thousands of characters. >These examples are harmless. Please try to test (1) with a large buffer >that has no newline characters and (2) with 'truncate-lines' non-nil. >'window-text-pixel-size' must be able to handle these cases gracefully >even if it's not geared to them. I think there's a misunderstading. I meant that a facility should be added to `window-text-pixel-size' so that callers like `string-pixel-width' can ask for having no (X) limit without specifying a large number themselves. Basically I want to use: (window-text-pixel-size window (point-min) (point) t) ^^^ (or some other value that `window-text-pixel-size' should understand as meaning "no limit" for X-LIMIT) instead of: (window-text-pixel-size window (point-min) (point) 123456789) The default behavior of the function should stay the same. >Any clients of 'window-text-pixel-size' like 'string-pixel-width' can >easily set X-LIMIT to some sufficiently large value without affecting >the basic functionality of 'window-text-pixel-size'. Yes, that's the simplest solution, but I find passing a random magic number instead of providing a simple interface to say "I don't want to use a limit" (like Y-LIMIT already allows, as I previously mentioned) rather inelegant :) >Please try the attached patch (if it doesn't apply, I'll send you the >affected functions separately so you can apply the changes manually). Can you explain how you are supposed to apply it? I tried: git apply buffer-text-pixel-size.diff But all it says is: error: corrupt patch at line 12 I did apply the changes manually by looking at the .diff file, and it's seemingly working for me. Minus one glaring issue: `string-pixel-width' is using `buffer-size' as the X-LIMIT, but that function returns the amount of characters in the buffer. This means that instead of returning the pixel width, it merely returns the amount of characters in a string. If I change that, everything else seems to be in good order. From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width References: <84czmvbepd.fsf@gmail.com> In-Reply-To: <84czmvbepd.fsf@gmail.com> Resent-From: Brahimi Saifullah Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Nov 2021 00:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163754243317215 (code B ref 51995); Mon, 22 Nov 2021 00:54:02 +0000 Received: (at 51995) by debbugs.gnu.org; 22 Nov 2021 00:53:53 +0000 Received: from localhost ([127.0.0.1]:46381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moxaj-0004TZ-C8 for submit@debbugs.gnu.org; Sun, 21 Nov 2021 19:53:53 -0500 Received: from mail-ua1-f53.google.com ([209.85.222.53]:41846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1moxaS-0004T8-LZ for 51995@debbugs.gnu.org; Sun, 21 Nov 2021 19:53:51 -0500 Received: by mail-ua1-f53.google.com with SMTP id p37so33180990uae.8 for <51995@debbugs.gnu.org>; Sun, 21 Nov 2021 16:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:from:to:cc:subject; bh=vFq94K64W1PA6OYZN70QT3XXXgNBAfH1HfNZhoTDbnE=; b=EgIWCBrxmoJ8ZVL5KEhCfANkfBb1+I4Q5YnB4MTlL1SKoYZSshZToHkMC5XjJygg4I KmRL1X1VXJTd0QZ4vJgbRbGFq/USnzQ0nirlT50p+ijSN08/nY5PHsfBCZBdHCjeOxLg 3Q68esRztZjMSow0/5A3HkIt/E9TAa0jP/bYk86rwDXfibExOgh4suSMCj3KR/GuIIX+ 9KAcgq7zt1P3mLs/+BCqlR1FRFf0RRLwENtpQQmVkhRYQfysUlH47vLsRevda46pCYNz w6PI7k/SXRPHXnkJ9sunWXw1pfPuclWE3YeW65QEAwfSl8yqA5eYXPMNIeiWMUCS4/IG Tqdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:from:to:cc:subject; bh=vFq94K64W1PA6OYZN70QT3XXXgNBAfH1HfNZhoTDbnE=; b=jVlOKd9p0r9gUMdz4TdZN3u6JqFvVCpoL0wzHjLIPXb7julcb1mO6YF8PGIbnT5jje RoeFoNAhNfhTVEZL89vy7cj+1ZiiXo20EeKi2EpljcQhPpsMkmLs4c3w1qPOkTnXmHcZ vtZaYl4N9PvltsOuhrf0LXnZbDlvNQz3VG6AHCJlMOlPWs9L6EeC1mGsW3yHN1lFD5AT YzIz07Kkrp1CHJneF/49RE8P3pjI2n8SN0jrQkpfOKGDSIrb2lDCbsi1m6XoX105SENP 0bNbPiLWmrmdhFq+xmP34Ma0W6YwMNtIiqVTezXGfpopkbLbt9UuFmUml2NAfp9BcBQ5 pXnQ== X-Gm-Message-State: AOAM533ndmU7iPnGEmbFXxsK83Ju12wGp24SeJ4Yxe8iN8zt2lB1YAoV rDdiqvNOdicGEYmW7OITTlFdMiqdB6B/Nh0d X-Google-Smtp-Source: ABdhPJzmIqbdH5tZhvvxTLIDO/vaLy/z1eCDi7gCEvCvyHTJe7G/aapY9ojfkEWKKR0kg3t9PtQ7aA== X-Received: by 2002:a05:6102:e0f:: with SMTP id o15mr123460089vst.51.1637542410857; Sun, 21 Nov 2021 16:53:30 -0800 (PST) Received: from COMPUTADOR ([2804:14d:90bc:8726:4c9c:5960:c709:1997]) by smtp.googlemail.com with ESMTPSA id t132sm3650389vkb.19.2021.11.21.16.53.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Nov 2021 16:53:30 -0800 (PST) Date: Sun, 21 Nov 2021 21:53:27 -0300 Message-Id: <84a6hxdn94.fsf@gmail.com> From: Brahimi Saifullah X-Spam-Score: 0.0 (/) 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 (-) >Can you explain how you are supposed to apply it? > >I tried: > > git apply buffer-text-pixel-size.diff > >But all it says is: > > error: corrupt patch at line 12 My bad, it seems the file got corrupted on my end. I downloaded it from debbugs.gnu.org and the patch is recognized as valid, yet it does not apply: Checking patch lisp/emacs-lisp/subr-x.el... error: while searching for: "Return the width of STRING in pixels." (with-temp-buffer (insert string) (car (window-text-pixel-size (current-buffer) (point-min) (point))))) (provide 'subr-x) error: patch failed: lisp/emacs-lisp/subr-x.el:446 error: lisp/emacs-lisp/subr-x.el: patch does not apply (The only problem is that a new function was added at the end of subr-x, the xdisp.c part does apply fine.) I've also tested the patch further, using `buffer-text-size' on my package's implementation of `string-pixel-width', and everything is is working, including my tests. Thanks. From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Nov 2021 09:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Brahimi Saifullah , Eli Zaretskii Cc: 51995@debbugs.gnu.org Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.163757334329584 (code B ref 51995); Mon, 22 Nov 2021 09:30:02 +0000 Received: (at 51995) by debbugs.gnu.org; 22 Nov 2021 09:29:03 +0000 Received: from localhost ([127.0.0.1]:46918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp5dG-0007gs-0p for submit@debbugs.gnu.org; Mon, 22 Nov 2021 04:29:03 -0500 Received: from mout.gmx.net ([212.227.15.15]:54871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp5dB-0007gU-A3 for 51995@debbugs.gnu.org; Mon, 22 Nov 2021 04:29:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637573330; bh=wRTUU+IsfUjpDXymvOjYn7tUWhqGkhD/fXCrtgmLoVE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=j2N56cTF2d5WQW1S32masMvHzD3Q1ObsIUgyAEadoDN+lwG7N4MwDCiH3fgO6lgwV sxN1LImX7QhgeeHUjeGdTz5sr6YkcaxncWTkoTdVgOJW9PYtbhsjIgs9yVqdFp9Ayv nhYj0ze+RKnDM4u+L7qlVEXB+YQ7MgQWXB8hs5yI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([212.95.5.236]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mk0JW-1mMbRi2DdI-00kQda; Mon, 22 Nov 2021 10:28:50 +0100 References: <84ee79xsky.fsf@gmail.com> From: martin rudalics Message-ID: Date: Mon, 22 Nov 2021 10:28:48 +0100 MIME-Version: 1.0 In-Reply-To: <84ee79xsky.fsf@gmail.com> Content-Type: multipart/mixed; boundary="------------4EDA1BC832D70D2A9BC9707F" Content-Language: en-US X-Provags-ID: V03:K1:oJVcrrW5HLkdeDVb6P3nkyaKb0xf/TcykcaQfYIm4pmZfMnzLlX qwRfPQwvIH91alsf/Ko9+1ciyg+hWffqhSDyvom3LPLj9XE12/yJax7dLyKUhEVMIP9t78g jiZFMIeYMd2gvYwAiQU+KSaA4F3/xVjfO9SrkPhg0SQgxVW/KoFoDbVR2S1KJ6LN5vsyS/V SgEZGWNz4y6COebWVxPoQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+u20LAROSeE=:fGpy7ByUkBqsBcLn1YJ6zb MHSi5PcB/FT5RR1lGVhuy4i8rhJeo0DvaJ1FhmxPRc9Zs0GUXaJDtxslmjK7chDMjwVv66EL1 m185KXOqoXsCsLxdi9QdKYAfAD9FNRXPTJFFsyVdBI4b6mUKGh4n5dFE/QQaZfy7T1VfU4vtY rFnBUmXmUqXfimJzTr6KlPY9tImv7FdhZKDuG7D8Jee6yo+IIkydB6cchQ1oEIsgKJL6YzMHb 2YpgyZb8ITlundjS/6OO8UngUTh6Br+5g9YgVKq56aHVdkQaav/ZlYdJUcCYsTKLTObTpxjN3 rrPS/ScbwUzOqfbwGgxS4CDhM/ZijSwE8+paEh76o4kP9vkg56GfUR3hwnrG3ttJXmbtoEq1t ez0d8UjFykNY0Sr6qJdgwnsdhbvH0JM/HwF2H9nTH/2msT6TKXtVAkiNtBSGwgWfeU2YPTPBP yzQdhoCLGacwKlpSzCUnauJNyqD7pgIFLUPuv3Xcvh1j6CBitdwOg9wAzzlJIbJPSr3iBOAWw bUxH7VaOsjdWmP/jn8ATH/B/0MGKyO9maAxAk2LE6A2tM0ipLJwDhfVd1jgd6RD1LxzaDsZvl ho/aYz7Ze1YL7Meq5Ig7a84D+D1oIlKSGYS58OZkvmBZjTpSPaYMyxGnB6de85ojctRIwEETa xH3jtJ8FcISasDwVdR7h9SDzOiW7j1ptGZO2FkASSZWtlrZdXct0wUo56lBiy6+ksZ9SXCZTB yBsi97/O8xtRTeJj4tBxwHRqJdclQ58k4FF/LbMp9QplW7/t67mcuUZGmT0Vj7Kpot5OIR13Y Cq+AZ5J6tfEH/eihUmciSs9DGorgFhbzwebl5gtqB22mimJRBECBrBY/cKWyfrAeQPjQDHZIa HHi7+eJ+LRaQcslOxdxWXcxrqA7OSFXholewxz1UL3jNqSzAgOJQSHzma9OwhYS2CkNz27LQI j/fUap0MvisQKOP4W2ZShlsmaCWGO9OS+0nMYK65/Vo3PaQkWjQhYG3jKJacu4Q28w0iWP+Pz W0psdK26+nAtfP96F0YTi8H5bO/BfZJKhgER82bM5zpHHYKncYE7XPy1RKe3IMNS4D0m2mtZS +9e9vVew0jObzc= X-Spam-Score: -0.7 (/) 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 (-) This is a multi-part message in MIME format. --------------4EDA1BC832D70D2A9BC9707F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > I meant that a facility should be added to `window-text-pixel-size' so > that callers like `string-pixel-width' can ask for having no (X) limit > without specifying a large number themselves. Basically I want to use: > > (window-text-pixel-size window (point-min) (point) t) > ^^^ > (or some other value that `window-text-pixel-size' > should understand as meaning "no limit" for X-LIMIT) > > instead of: > > (window-text-pixel-size window (point-min) (point) 123456789) > > The default behavior of the function should stay the same. OK. >> Any clients of 'window-text-pixel-size' like 'string-pixel-width' can >> easily set X-LIMIT to some sufficiently large value without affecting >> the basic functionality of 'window-text-pixel-size'. > > Yes, that's the simplest solution, but I find passing a random magic number > instead of providing a simple interface to say "I don't want to use a limit" > (like Y-LIMIT already allows, as I previously mentioned) rather inelegant :) Agreed (also because 'most-positive-fixnum' and anything beyond INT_MAX as argument don't work at the moment which is confusing). > Minus one glaring issue: > `string-pixel-width' is using `buffer-size' as the X-LIMIT, but > that function returns the amount of characters in the buffer. > This means that instead of returning the pixel width, it merely > returns the amount of characters in a string. If I change that, > everything else seems to be in good order. Yes. This wasn't a very bright idea. The function will now be (defun string-pixel-width (string) "Return the width of STRING in pixels." (with-temp-buffer (insert string) (car (buffer-text-pixel-size nil nil t)))) as you suggested. The xdisp.c change is attached. Apply the 'string-pixel-width' change manually. Thanks, martin --------------4EDA1BC832D70D2A9BC9707F Content-Type: text/x-patch; name="buffer-text-pixel-size.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="buffer-text-pixel-size.diff" diff --git a/src/xdisp.c b/src/xdisp.c index aa01db210b..03659d0dda 100644 =2D-- a/src/xdisp.c +++ b/src/xdisp.c @@ -10626,77 +10626,21 @@ in_display_vector_p (struct it *it) && it->dpvec + it->current.dpvec_index !=3D it->dpend); } -DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pi= xel_size, 0, 6, 0, - doc: /* Return the size of the text of WINDOW's buffer in pixels. -WINDOW can be any live window and defaults to the selected one. The -return value is a cons of the maximum pixel-width of any text line -and the pixel-height of all the text lines in the accessible portion -of buffer text. -WINDOW can also be a buffer, in which case the selected window is used, -and the function behaves as if that window was displaying this buffer. - -This function exists to allow Lisp programs to adjust the dimensions -of WINDOW to the buffer text it needs to display. - -The optional argument FROM, if non-nil, specifies the first text -position to consider, and defaults to the minimum accessible position -of the buffer. If FROM is t, it stands for the minimum accessible -position that starts a non-empty line. TO, if non-nil, specifies the -last text position and defaults to the maximum accessible position of -the buffer. If TO is t, it stands for the maximum accessible position -that ends a non-empty line. - -The optional argument X-LIMIT, if non-nil, specifies the maximum X -coordinate beyond which the text should be ignored. It is therefore -also the maximum width that the function can return. X-LIMIT nil or -omitted means to use the pixel-width of WINDOW's body. This default -means text of truncated lines wider than the window will be ignored; -specify a large value for X-LIMIT if lines are truncated and you need -to account for the truncated text. Use nil for X-LIMIT if you want to -know how high WINDOW should become in order to fit all of its buffer's -text with the width of WINDOW unaltered. Use the maximum width WINDOW -may assume if you intend to change WINDOW's width. Since calculating -the width of long lines can take some time, it's always a good idea to -make this argument as small as possible; in particular, if the buffer -contains long lines that shall be truncated anyway. - -The optional argument Y-LIMIT, if non-nil, specifies the maximum Y -coordinate beyond which the text is to be ignored; it is therefore -also the maximum height that the function can return (excluding the -height of the mode- or header-line, if any). Y-LIMIT nil or omitted -means consider all of the accessible portion of buffer text up to the -position specified by TO. Since calculating the text height of a -large buffer can take some time, it makes sense to specify this -argument if the size of the buffer is large or unknown. - -Optional argument MODE-LINES nil or omitted means do not include the -height of the mode-, tab- or header-line of WINDOW in the return value. -If it is the symbol `mode-line', 'tab-line' or `header-line', include -only the height of that line, if present, in the return value. If t, -include the height of any of these, if present, in the return value. */) - (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_li= mit, - Lisp_Object y_limit, Lisp_Object mode_lines) +/* This is like Fwindow_text_pixel_size but assumes that WINDOW's buffer + is the current buffer. Fbuffer_text_pixel_size calls it after it has + set WINDOW's buffer to the buffer specified by its BUFFER_OR_NAME + argument. */ +static Lisp_Object +window_text_pixel_size (Lisp_Object window, Lisp_Object from, Lisp_Object= to, Lisp_Object x_limit, + Lisp_Object y_limit, Lisp_Object mode_lines) { - struct window *w =3D BUFFERP (window) ? XWINDOW (selected_window) - : decode_live_window (window); - Lisp_Object buffer =3D BUFFERP (window) ? window : w->contents; - struct buffer *b; + struct window *w =3D decode_live_window (window); struct it it; - struct buffer *old_b =3D NULL; ptrdiff_t start, end, bpos; struct text_pos startp; void *itdata =3D NULL; int c, max_x =3D 0, max_y =3D 0, x =3D 0, y =3D 0; - CHECK_BUFFER (buffer); - b =3D XBUFFER (buffer); - - if (b !=3D current_buffer) - { - old_b =3D current_buffer; - set_buffer_internal (b); - } - if (NILP (from)) { start =3D BEGV; @@ -10755,8 +10699,10 @@ DEFUN ("window-text-pixel-size", Fwindow_text_pix= el_size, Swindow_text_pixel_siz else end =3D clip_to_bounds (start, fix_position (to), ZV); - if (!NILP (x_limit) && RANGED_FIXNUMP (0, x_limit, INT_MAX)) + if (RANGED_FIXNUMP (0, x_limit, INT_MAX)) max_x =3D XFIXNUM (x_limit); + else if (!NILP (x_limit)) + max_x =3D INT_MAX; if (NILP (y_limit)) max_y =3D INT_MAX; @@ -10889,12 +10835,128 @@ DEFUN ("window-text-pixel-size", Fwindow_text_p= ixel_size, Swindow_text_pixel_siz bidi_unshelve_cache (itdata, false); + return Fcons (make_fixnum (x - start_x), make_fixnum (y)); +} + +DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_pi= xel_size, 0, 6, 0, + doc: /* Return the size of the text of WINDOW's buffer in pixels. +WINDOW must be a live window and defaults to the selected one. The +return value is a cons of the maximum pixel-width of any text line +and the pixel-height of all the text lines in the accessible portion +of buffer text. + +This function exists to allow Lisp programs to adjust the dimensions +of WINDOW to the buffer text it needs to display. + +The optional argument FROM, if non-nil, specifies the first text +position to consider, and defaults to the minimum accessible position +of the buffer. If FROM is t, it stands for the minimum accessible +position that starts a non-empty line. TO, if non-nil, specifies the +last text position and defaults to the maximum accessible position of +the buffer. If TO is t, it stands for the maximum accessible position +that ends a non-empty line. + +The optional argument X-LIMIT, if non-nil, specifies the maximum X +coordinate beyond which the text should be ignored. It is therefore +also the maximum width that the function can return. X-LIMIT nil or +omitted means to use the pixel-width of WINDOW's body. This default +means text of truncated lines wider than the window will be ignored; +specify a non-nil value for X-LIMIT if lines are truncated and you need +to account for the truncated text. + +Use nil for X-LIMIT if you want to know how high WINDOW should become in +order to fit all of its buffer's text with the width of WINDOW +unaltered. Use the maximum width WINDOW may assume if you intend to +change WINDOW's width. Use t for the maximum possible value. Since +calculating the width of long lines can take some time, it's always a +good idea to make this argument as small as possible; in particular, if +the buffer contains long lines that shall be truncated anyway. + +The optional argument Y-LIMIT, if non-nil, specifies the maximum Y +coordinate beyond which the text is to be ignored; it is therefore +also the maximum height that the function can return (excluding the +height of the mode- or header-line, if any). Y-LIMIT nil or omitted +means consider all of the accessible portion of buffer text up to the +position specified by TO. Since calculating the text height of a +large buffer can take some time, it makes sense to specify this +argument if the size of the buffer is large or unknown. + +Optional argument MODE-LINES nil or omitted means do not include the +height of the mode-, tab- or header-line of WINDOW in the return value. +If it is the symbol `mode-line', 'tab-line' or `header-line', include +only the height of that line, if present, in the return value. If t, +include the height of any of these, if present, in the return value. */) + (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_li= mit, + Lisp_Object y_limit, Lisp_Object mode_lines) +{ + struct window *w =3D decode_live_window (window); + struct buffer *b =3D XBUFFER (w->contents); + struct buffer *old_b =3D NULL; + Lisp_Object value; + + if (b !=3D current_buffer) + { + old_b =3D current_buffer; + set_buffer_internal_1 (b); + } + + value =3D window_text_pixel_size (window, from, to, x_limit, y_limit, m= ode_lines); + if (old_b) - set_buffer_internal (old_b); + set_buffer_internal_1 (old_b); + + return value; +} + +DEFUN ("buffer-text-pixel-size", Fbuffer_text_pixel_size, Sbuffer_text_pi= xel_size, 0, 4, 0, + doc: /* Return size of whole text of BUFFER_OR_NAME in WINDOW. +BUFFER-OR-NAME must specify a live buffer or the name of a live buffer +and defaults to the current buffer. WINDOW must be a live window and +defaults to the selected one. The return value is a cons of the maximum +pixel-width of any text line and the pixel-height of all the text lines +of the buffer specified by BUFFER-OR-NAME. + +The optional arguments X-LIMIT and Y-LIMIT have the same meaning as with +`window-text-pixel-size'. + +Do not use this function if the buffer specified by BUFFER_OR_NAME is +already displayed in WINDOW. `window-text-pixel-size' is cheaper in +that case because it does not have to temporarily show that buffer in +WINDOW. */) + (Lisp_Object buffer_or_name, Lisp_Object window, Lisp_Object x_limit, + Lisp_Object y_limit) +{ + struct window *w =3D decode_live_window (window); + struct buffer *b =3D (NILP (buffer_or_name) + ? current_buffer + : XBUFFER (Fget_buffer (buffer_or_name))); + Lisp_Object buffer, value; + ptrdiff_t count =3D SPECPDL_INDEX (); - return Fcons (make_fixnum (x - start_x), make_fixnum (y)); + XSETBUFFER (buffer, b); + + /* The unwind form of with_echo_area_buffer is what we need here to + make WINDOW temporarily show our buffer. */ + record_unwind_protect (unwind_with_echo_area_buffer, + with_echo_area_buffer_unwind_data (w)); + + set_buffer_internal_1 (b); + + if (!EQ (buffer, w->contents)) + { + wset_buffer (w, buffer); + set_marker_both (w->pointm, buffer, BEG, BEG_BYTE); + set_marker_both (w->old_pointm, buffer, BEG, BEG_BYTE); + } + + value =3D window_text_pixel_size (window, Qnil, Qnil, x_limit, y_limit,= Qnil); + + unbind_to (count, Qnil); + + return value; } + DEFUN ("display--line-is-continued-p", Fdisplay__line_is_continued_p, Sdisplay__line_is_continued_p, 0, 0, 0, doc: /* Return non-nil if the current screen line is continued on = display. */) @@ -35023,6 +35085,7 @@ syms_of_xdisp (void) defsubr (&Sinvisible_p); defsubr (&Scurrent_bidi_paragraph_direction); defsubr (&Swindow_text_pixel_size); + defsubr (&Sbuffer_text_pixel_size); defsubr (&Smove_point_visually); defsubr (&Sbidi_find_overridden_directionality); defsubr (&Sdisplay__line_is_continued_p); --------------4EDA1BC832D70D2A9BC9707F-- From unknown Sun Jun 15 08:40:11 2025 X-Loop: help-debbugs@gnu.org Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Nov 2021 11:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51995 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: 51995@debbugs.gnu.org, Eli Zaretskii , Brahimi Saifullah Received: via spool by 51995-submit@debbugs.gnu.org id=B51995.16375790957640 (code B ref 51995); Mon, 22 Nov 2021 11:05:02 +0000 Received: (at 51995) by debbugs.gnu.org; 22 Nov 2021 11:04:55 +0000 Received: from localhost ([127.0.0.1]:47103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp783-0001zA-FR for submit@debbugs.gnu.org; Mon, 22 Nov 2021 06:04:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp77x-0001yq-Ql for 51995@debbugs.gnu.org; Mon, 22 Nov 2021 06:04:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=taus2WaYfqUlOSZBU1yqB7OXCRNdNx6IvC3QMWud8eg=; b=eOfMuUpd7umYk1XjBPBgSF4VrB nKBXqF8JkUxGVu4SaATXh4w6rfGQcmkF/XqdSp4XKWOcAFobTAIZzLkKmeBLY3ME8n1KpQX075rI0 51FR3sGWecuNPGArHhWXIyZDNFBOz4dv69ziKruPLk1V9dRl7qu6g41DzVYbprmeGwm0=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mp77o-0006Nn-1n; Mon, 22 Nov 2021 12:04:43 +0100 From: Lars Ingebrigtsen References: <84ee79xsky.fsf@gmail.com> Date: Mon, 22 Nov 2021 12:04:35 +0100 In-Reply-To: (martin rudalics's message of "Mon, 22 Nov 2021 10:28:48 +0100") Message-ID: <878rxgh2nw.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: martin rudalics writes: > Yes. This wasn't a very bright idea. The function will now be > > (defun string-pixel-width (string) > "Return the width of STRING in pixels." > (with-temp-buffer > (insert string) > (car (buffer-te [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) 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 (---) martin rudalics writes: > Yes. This wasn't a very bright idea. The function will now be > > (defun string-pixel-width (string) > "Return the width of STRING in pixels." > (with-temp-buffer > (insert string) > (car (buffer-text-pixel-size nil nil t)))) > > as you suggested. The xdisp.c change is attached. Apply the > 'string-pixel-width' change manually. Thanks; I've now applied the patch and adjusted the function, and it seems to work as advertised now. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 22 06:05:02 2021 Received: (at control) by debbugs.gnu.org; 22 Nov 2021 11:05:03 +0000 Received: from localhost ([127.0.0.1]:47107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp78A-0001zn-NS for submit@debbugs.gnu.org; Mon, 22 Nov 2021 06:05:02 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mp789-0001zJ-Dx for control@debbugs.gnu.org; Mon, 22 Nov 2021 06:05:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fp7+SbBwPFJz62bNxyLvGzC0gInMM+LfRT0hfURRpOA=; b=uH+3Drfrnct43+YiG1yn3DitYE kpc4azpo/TiAYHHMjZcyYmOWEPY/kzP65/tn3ceAQ9MrmsGMM2mHdA9xMF985AZU1aFuR/8xJeXGq CttJCKaIrtNyxLit1OalXr+tiWt+I1JiBTnaW0Trh1AOvlTZVAVuTipFIuteEQdm1hJ0=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mp781-0006Nz-Fo for control@debbugs.gnu.org; Mon, 22 Nov 2021 12:04:55 +0100 Date: Mon, 22 Nov 2021 12:04:51 +0100 Message-Id: <877dd0h2ng.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #51995 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 51995 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) close 51995 29.1 quit