From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Ponce via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72689: 31.0.50; Proposal to improve string-pixel-width Date: Wed, 21 Aug 2024 22:43:08 +0200 Message-ID: <358cf360-aa39-4551-aa8f-46543df07eda@orange.fr> 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> Reply-To: David Ponce Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17308"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 72689@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 21 22:43:48 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sgsBI-0004Lq-6s for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Aug 2024 22:43:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sgsAp-00019H-NW; Wed, 21 Aug 2024 16:43:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sgsAo-000198-AR for bug-gnu-emacs@gnu.org; Wed, 21 Aug 2024 16:43:18 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sgsAn-0007L4-Sl for bug-gnu-emacs@gnu.org; Wed, 21 Aug 2024 16:43:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=AMMsb+3SFBTVR5ek4WWQcrUT+hKc9tQwlIJ4zs7pK6Y=; b=OgUV2pDUZshasA8N55GqzsQ3qJXhDr4V6N374bwidHEURidJzMKu5z9Pyg+NDrn47Egk33JLCerJnL6oO5h0L8pbfYRbTNAlDU+dz/43f49HhIxD6T3oze/ZHYwc4LyFEOLYVJ13DqBGTgIYI5+0Wnh72nUGFFPPZiTqZ5yYUHLjt4FRkEXw1m2fm4CQco1LkAbmXYeond1QWziVuobp5Lx/4oaCXZIgEGbp6cUShEhBQUIyrJZUKik/vddpfxDKa2jshVeSc/PQKoS/L/UumBxYDoxGeDD3ClAjji1qtdjt6DBKEFTt4bcAJ6yY65Ng927ZZ+q3HhwDoFAYX7Bdcw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sgsBW-0007hM-I7 for bug-gnu-emacs@gnu.org; Wed, 21 Aug 2024 16:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Ponce Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Aug 2024 20:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72689 X-GNU-PR-Package: emacs Original-Received: via spool by 72689-submit@debbugs.gnu.org id=B72689.172427304129576 (code B ref 72689); Wed, 21 Aug 2024 20:44:02 +0000 Original-Received: (at 72689) by debbugs.gnu.org; 21 Aug 2024 20:44:01 +0000 Original-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 Original-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 Original-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 Content-Language: fr, en-US In-Reply-To: <86jzgauiav.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:290503 Archived-At: 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!