From unknown Fri Aug 15 12:48:31 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#63861 <63861@debbugs.gnu.org> To: bug#63861 <63861@debbugs.gnu.org> Subject: Status: [PATCH] pp.el: New "pretty printing" code Reply-To: bug#63861 <63861@debbugs.gnu.org> Date: Fri, 15 Aug 2025 19:48:31 +0000 retitle 63861 [PATCH] pp.el: New "pretty printing" code reassign 63861 emacs submitter 63861 Stefan Monnier severity 63861 normal tag 63861 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 18:51:22 2023 Received: (at submit) by debbugs.gnu.org; 2 Jun 2023 22:51:23 +0000 Received: from localhost ([127.0.0.1]:40996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5DcA-0002F3-5Q for submit@debbugs.gnu.org; Fri, 02 Jun 2023 18:51:22 -0400 Received: from lists.gnu.org ([209.51.188.17]:58746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Dc5-0002Eq-CE for submit@debbugs.gnu.org; Fri, 02 Jun 2023 18:51:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Dc5-00029d-55 for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 18:51:17 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Dc2-0007EX-Bz for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 18:51:16 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6325F44109D for ; Fri, 2 Jun 2023 18:51:12 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7FDD344105D for ; Fri, 2 Jun 2023 18:51:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1685746269; bh=sxdHbJ65dSKDWDZ9YOQE6JJoMBCokSFgb3m5fwGXwLs=; h=From:To:Subject:Date:From; b=cG1aK65yftgiUQY3aRCs3/YKB9MlnGxHl7Ao5NtEixlKOc7cPUYIlzbMnWrTe+UxV HQ+iHOMGH4ZcHa8fXnvGXFiUNJxh3CjKVSvqoXOtJVySfmj+Qr9wKnEjXiXInOqBs8 EP53ej/l8q7EVVEJaeOTNavw0g/w7pl3p6pPyL+rZoVbrCLMCluP3Wk1sR2Ref6XuV woc1iy3AeF+4Mo95GOv7yRcxGMQnVV+XUgGUy/pJlWMAI5H1hsK9jtATezJ1d5HNX/ O5/6/7hNIXrCi6ORhMf6PZUsUSyAaR09ae70GxIKmOq8vnaxqPCVoJf2k7zwUhLWID 43X7a2BfvHYHw== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65A291202BC for ; Fri, 2 Jun 2023 18:51:09 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: [PATCH] pp.el: New "pretty printing" code Date: Fri, 02 Jun 2023 18:50:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.032 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Tags: patch I've often been annoyed by the way `ielm` "pretty prints" data, so I wrote my own pretty printer, which has evolved over the years. I believe it has finally reached a state which may be acceptable to more than just myself. The new code is in a new function `pp-region`. The old code redirects to the new code if `pp-buffer-use-pp-region` is non-nil, tho I'm not sure we want to bother users with such a config var. Hopefully, the new code should be good enough that users don't need to choose. Maybe I should make it a `defvar` and have it default to t, so new users will complain if it's not good enough? Stefan In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2023-05-24 built on pastel Repository revision: 41b6b907d4cf2f8c302647dc63c5d9c94f9f01d6 Repository branch: work Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Debian GNU/Linux 11 (bullseye) Configured using: 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign' PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-pp.el-New-pretty-printing-code.patch >From f26455b6b36f02fcb0954d5a440e8e97a0070b26 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 2 Jun 2023 18:42:55 -0400 Subject: [PATCH] pp.el: New "pretty printing" code Provide a new pretty printing code which tries to generate code a bit more like what humans tend to write. The new code is driven by the assumption that we want the output to fit within `fill-column` (which clearly works poorly with deeply indented code which just can't fit within `fill-column`). * lisp/emacs-lisp/pp.el (pp--within-fill-column-p, pp-region): New funs. (pp-buffer-use-pp-region): New custom var. (pp-buffer): Use it. --- lisp/emacs-lisp/pp.el | 94 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 93 insertions(+), 1 deletion(-) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index e6e3cd6c6f4..3f9f4a5fbba 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -74,11 +74,103 @@ pp-to-string (pp-buffer) (buffer-string)))) +(defun pp--within-fill-column-p () + "Return non-nil if point is within `fill-column'." + ;; Try and make it O(fill-column) rather than O(current-column), + ;; so as to avoid major slowdowns on long lines. + ;; FIXME: This doesn't account for invisible text or `display' properties :-( + (and (save-excursion + (re-search-backward + "^\\|\n" (max (point-min) (- (point) fill-column)) t)) + (<= (current-column) fill-column))) + +(defun pp-region (beg end) + "Insert newlines in BEG..END to try and fit within `fill-column'. +Presumes the current buffer contains Lisp code and has indentation properly +configured for that. +Designed under the assumption that the region occupies a single line, +tho it should also work if that's not the case." + (interactive "r") + (goto-char beg) + (let ((end (copy-marker end t))) + (while (< (point) end) + (forward-comment (point-max)) + (let ((beg (point)) + ;; Whether we're in front of an element with paired delimiters. + ;; Can be something funky like #'(lambda ..) or ,'#s(...). + (paired (when (looking-at "['`,#]*[[:alpha:]]*\\([({[\"]\\)") + (match-beginning 1)))) + ;; Go to the end of the sexp. + (goto-char (or (scan-sexps (or paired (point)) 1) end)) + (unless + (and + ;; The sexp is all on a single line. + (save-excursion (not (search-backward "\n" beg t))) + ;; And its end is within `fill-column'. + (or (pp--within-fill-column-p) + ;; If the end of the sexp is beyond `fill-column', + ;; try to move the sexp to its own line. + (and + (save-excursion + (goto-char beg) + (if (save-excursion (skip-chars-backward " \t({[',") (bolp)) + ;; The sexp was already on its own line. + nil + (skip-chars-backward " \t") + (setq beg (copy-marker beg t)) + (if paired (setq paired (copy-marker paired t))) + ;; We could try to undo this insertion if it + ;; doesn't reduce the indentation depth, but I'm + ;; not sure it's worth the trouble. + (insert "\n") (indent-according-to-mode) + t)) + ;; Check again if we moved the whole exp to a new line. + (pp--within-fill-column-p)))) + ;; The sexp is spread over several lines, and/or its end is + ;; (still) beyond `fill-column'. + (when (and paired (not (eq ?\" (char-after paired)))) + ;; The sexp has sub-parts, so let's try and spread + ;; them over several lines. + (save-excursion + (goto-char beg) + (when (looking-at "(\\([^][()\" \t\n]+\\)") + ;; Inside an expression of the form (SYM ARG1 + ;; ARG2 ... ARGn) where SYM has a `lisp-indent-function' + ;; property that's a number, insert a newline after + ;; the corresponding ARGi, because it tends to lead to + ;; more natural and less indented code. + (let* ((sym (intern-soft (match-string 1))) + (lif (and sym (get sym 'lisp-indent-function)))) + (when (natnump lif) + (goto-char (match-end 0)) + (forward-sexp lif) + (insert "\n") + (indent-according-to-mode))))) + (save-excursion + (pp-region (1+ paired) (1- (point))))) + ;; Now the sexp either ends beyond `fill-column' or is + ;; spread over several lines (or both). Either way, the rest of the + ;; line should be moved to its own line. + (skip-chars-forward ")]}") + (unless (eolp) (insert "\n") (indent-according-to-mode))))))) + +(defcustom pp-buffer-use-pp-region nil + "If non-nil, `pp-buffer' uses the new `pp-region' code." + :type 'boolean) + ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp object." (interactive) (goto-char (point-min)) + (if pp-buffer-use-pp-region + (with-syntax-table emacs-lisp-mode-syntax-table + (let ((fill-column (max fill-column 70)) + (indent-line-function + (if (local-variable-p 'indent-line-function) + indent-line-function + #'lisp-indent-line))) + (pp-region (point-min) (point-max)))) (while (not (eobp)) (cond ((ignore-errors (down-list 1) t) @@ -98,7 +190,7 @@ pp-buffer (insert ?\n)) (t (goto-char (point-max))))) (goto-char (point-min)) - (indent-sexp)) + (indent-sexp))) ;;;###autoload (defun pp (object &optional stream) -- 2.30.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 01:52:58 2023 Received: (at 63861) by debbugs.gnu.org; 3 Jun 2023 05:52:59 +0000 Received: from localhost ([127.0.0.1]:41406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KCA-0001tO-J2 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 01:52:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KC8-0001tA-LR for 63861@debbugs.gnu.org; Sat, 03 Jun 2023 01:52:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5KC2-0000Mr-Rc; Sat, 03 Jun 2023 01:52:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ROdT8QHL2rTNR5r1l/g5vLc4rvSSxh7Ow2uxtxfjIks=; b=kUxl451vEGiV tNB03QS/TUorySQHAXxLUq3WZOzuymRZq3aA78jnONc58WmCKo5FDKr8NDfOMfGrErO6Wqwnsa2dK SD6lklvUG5ZVT0gP+qfEYVNIWG5/IKSq6MUrqJtLxsM8U53LeZY90Dfwgqapj/jGJkewHEQjOeAsZ wukE9Tv4sVToyhmk3achYiYWDOacfFzc9/RjytmBKLV4vpPxUjZBTEIrYEyDDB7wVlLp0yyefRaBG bWZRvW+jX6Q6P9JN33alaoT4NjvO6GApzC0qLGXP9tJObaDcHHz+KEx92Pgz9MNxR8uAsPalxXnOI 0lsxQpVkxG45FYLiv3jRtA==; Received: from [87.69.77.57] (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 1q5KC2-00071C-Bg; Sat, 03 Jun 2023 01:52:50 -0400 Date: Sat, 03 Jun 2023 08:53:41 +0300 Message-Id: <83fs799jmi.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 02 Jun 2023 18:50:57 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > I've often been annoyed by the way `ielm` "pretty prints" data, > so I wrote my own pretty printer, which has evolved over the years. > I believe it has finally reached a state which may be acceptable > to more than just myself. > > The new code is in a new function `pp-region`. > The old code redirects to the new code if `pp-buffer-use-pp-region` is > non-nil, tho I'm not sure we want to bother users with such > a config var. Hopefully, the new code should be good enough that users > don't need to choose. Maybe I should make it a `defvar` and have it > default to t, so new users will complain if it's not good enough? Thanks. I almost never use IELM, so I have no significant comments to this, only minor ones. > +(defun pp-region (beg end) > + "Insert newlines in BEG..END to try and fit within `fill-column'. > +Presumes the current buffer contains Lisp code and has indentation properly > +configured for that. > +Designed under the assumption that the region occupies a single line, > +tho it should also work if that's not the case." The first line should say what this command does. Also, I think this warrants a NEWS entry and should be documented in the ELisp manual. > +(defcustom pp-buffer-use-pp-region nil > + "If non-nil, `pp-buffer' uses the new `pp-region' code." > + :type 'boolean) Please add :version. Also, "the new code" should be rephrased to not use "new" (which doesn't stand the time test). And the new defcustom should probably be mentioned in the manual, perhaps where we mention IELM. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 14:18:48 2023 Received: (at 63861) by debbugs.gnu.org; 3 Jun 2023 18:18:48 +0000 Received: from localhost ([127.0.0.1]:44270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Vpv-0001Vc-H5 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 14:18:47 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Vps-0001VL-GX for 63861@debbugs.gnu.org; Sat, 03 Jun 2023 14:18:45 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DFDB880781; Sat, 3 Jun 2023 14:18:38 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 76BE080058; Sat, 3 Jun 2023 14:18:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1685816317; bh=1N2QNavXwWxHIke28SKjqrCeKuRWoXBOs6USGboMp+M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aFuLSClDVvVkJqDtqCiclWH72i91Fy38eCpPJUlGjRi3CPFOPL+MXbsL2sWo2IUcm UROg+DQIEXaBrqTfFfecj69YK+s/cJhn2lFUGRMMk4btsj+uteamCGRiMNIXmCq1c4 v81z0ixnbhCoCSNiO041zio40IBKqgFfMt6dsz9rn49NkL7XHakmEJV5vhfkTxLq5r rcbFxLzTc7fCeDxtKRhPZAJgSZnfIU0eU44Oe7OU4uGrosaU+qvlukkau04R12Jnol 8JXSwnDhr6avxKlAChwaTtsJXmJcG3S8BlXtJTtpVyewADbIszF/chKK/H5tRZnPn5 aEqPru6liGUjg== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 37EAD12031E; Sat, 3 Jun 2023 14:18:37 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <83fs799jmi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 08:53:41 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> Date: Sat, 03 Jun 2023 14:18:36 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.085 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I've often been annoyed by the way `ielm` "pretty prints" data, >> so I wrote my own pretty printer, which has evolved over the years. >> I believe it has finally reached a state which may be acceptable >> to more than just myself. >> >> The new code is in a new function `pp-region`. >> The old code redirects to the new code if `pp-buffer-use-pp-region` is >> non-nil, tho I'm not sure we want to bother users with such >> a config var. Hopefully, the new code should be good enough that users >> don't need to choose. Maybe I should make it a `defvar` and have it >> default to t, so new users will complain if it's not good enough? > > Thanks. I almost never use IELM, so I have no significant comments to > this, only minor ones. FWIW, the change affects other functionality that uses `pp`, such as `C-h v`. While working on (previous versions of) this code, I've had performance problems show up during the generation of `emoji-labels.el`. >> +(defun pp-region (beg end) >> + "Insert newlines in BEG..END to try and fit within `fill-column'. >> +Presumes the current buffer contains Lisp code and has indentation properly >> +configured for that. >> +Designed under the assumption that the region occupies a single line, >> +tho it should also work if that's not the case." > > The first line should say what this command does. How 'bout: Insert line-breaks in Lisp code so it fits within `fill-column`. ? > Also, I think this warrants a NEWS entry and should be documented in > the ELisp manual. Definitely for NEWS, yes. For the ELisp manual, currently we don't document `pp-buffer`, the closest I see is `indent-pp-sexp` (in `programs.texi`). I'm not sure what to put in there. nor where to put it. >> +(defcustom pp-buffer-use-pp-region nil >> + "If non-nil, `pp-buffer' uses the new `pp-region' code." >> + :type 'boolean) > Please add :version. Hmm... so you think it should stay as a `defcustom` and we should thus plan to keep both kinds of pretty-printing in the long term? I mostly intended it to be a temporary knob for people to be able to try the new code and easily compare with the old (or revert to the old when bumping into a problem with the new). If so, we should probably think of better names to distinguish the two pp styles than `pp-buffer` vs `pp-region`. Maybe `pp-fill` for the new code since arguably the main difference is that the new code pays attention to `fill-column`? I don't have a good idea for a name for the old code, OTOH (and I think it would make sense to keep `pp-buffer` as a dispatch between the two options, so it would be good to have a separate name for the old style). Another difference might be that the new style is maybe aimed more at pp'ing code than data, whereas the old style might be a bit more "agnostic" to the definition. Yet another difference is that the old code tends to use more lines (because it doesn't try to fill the line upto `fill-column`) and occasionally outputs very long lines because it only breaks lines near parentheses. Maybe that info can inspire someone to come up with a good name for this "old style"? > Also, "the new code" should be rephrased to not use "new" (which > doesn't stand the time test). :-) > And the new defcustom should probably be mentioned in the manual, > perhaps where we mention IELM. If it stays as a `defcustom`, agreed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 14:57:21 2023 Received: (at 63861) by debbugs.gnu.org; 3 Jun 2023 18:57:21 +0000 Received: from localhost ([127.0.0.1]:44311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5WRE-0002WQ-R5 for submit@debbugs.gnu.org; Sat, 03 Jun 2023 14:57:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5WRB-0002W9-M7 for 63861@debbugs.gnu.org; Sat, 03 Jun 2023 14:57:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5WR5-0007kP-Q4; Sat, 03 Jun 2023 14:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5Vrb6KWJfP8kxRRXPwnZlMhzyS5w52nNMGSExoMc1x8=; b=MtkDUAGCN73E /5aw/lSc9ZdGRv8+lYDRZW9DAWXWDmRsxRNl7gShrcEOrj9SMBI9ItRTVAFrKyn2kcYMxbNyehFOv vGmc33Ufy/L+/g3xsUjIQs+xzKAv4tfdoM7xcSQV7PVROR4ZJKXr+SjJNw/sgw6TvKl+CGaFw0/Pz XHtHNFT1F825CM4jWgE84IYzxkAKdK1zGxFvgTb1Ep/L/kEBa0aLxVum6Ki55vxbG6L6SrFrD90jZ LWXzucVPlePvAGroSTwJfT25mZw+xdU4Ko7vu8m8Q1owIxflGBluygA0W3bT2e+khLexNbyavKBkp cLKKLCnLlsINZesycOmYYg==; Received: from [87.69.77.57] (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 1q5WR5-0007Os-9T; Sat, 03 Jun 2023 14:57:11 -0400 Date: Sat, 03 Jun 2023 21:58:03 +0300 Message-Id: <83r0qs74qs.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 03 Jun 2023 14:18:36 -0400) Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: <83fs799jmi.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 63861@debbugs.gnu.org > Date: Sat, 03 Jun 2023 14:18:36 -0400 > > >> +(defun pp-region (beg end) > >> + "Insert newlines in BEG..END to try and fit within `fill-column'. > >> +Presumes the current buffer contains Lisp code and has indentation properly > >> +configured for that. > >> +Designed under the assumption that the region occupies a single line, > >> +tho it should also work if that's not the case." > > > > The first line should say what this command does. > > How 'bout: > > Insert line-breaks in Lisp code so it fits within `fill-column`. > > ? Yes, but let's also mention BEG and END: Break lines in Lisp code between BEG and END so it fits within `fill-column'. > > Also, I think this warrants a NEWS entry and should be documented in > > the ELisp manual. > > Definitely for NEWS, yes. For the ELisp manual, currently we don't > document `pp-buffer`, the closest I see is `indent-pp-sexp` (in > `programs.texi`). > I'm not sure what to put in there. nor where to put it. We document "pp" in "Output Functions". Maybe there? > >> +(defcustom pp-buffer-use-pp-region nil > >> + "If non-nil, `pp-buffer' uses the new `pp-region' code." > >> + :type 'boolean) > > Please add :version. > > Hmm... so you think it should stay as a `defcustom` and we should thus > plan to keep both kinds of pretty-printing in the long term? No, I just said that _if_ we keep it as a defcustom, _then_ it should have a :version tag. I have no idea how many users will want to customize this. > I mostly intended it to be a temporary knob for people to be able to try > the new code and easily compare with the old (or revert to the old when > bumping into a problem with the new). > > If so, we should probably think of better names to distinguish the two > pp styles than `pp-buffer` vs `pp-region`. Maybe `pp-fill` for the new > code since arguably the main difference is that the new code pays > attention to `fill-column`? I don't have a good idea for a name for the > old code, OTOH (and I think it would make sense to keep `pp-buffer` as > a dispatch between the two options, so it would be good to have > a separate name for the old style). > > Another difference might be that the new style is maybe aimed more at > pp'ing code than data, whereas the old style might be a bit more > "agnostic" to the definition. Yet another difference is that the old > code tends to use more lines (because it doesn't try to fill the line > upto `fill-column`) and occasionally outputs very long lines because it > only breaks lines near parentheses. > > Maybe that info can inspire someone to come up with a good name for this > "old style"? Maybe we should leave it as a variable for now, and see if there's enough demand for both flavors. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 23:25:43 2023 Received: (at 63861) by debbugs.gnu.org; 4 Jun 2023 03:25:43 +0000 Received: from localhost ([127.0.0.1]:44592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5eND-0007l6-1a for submit@debbugs.gnu.org; Sat, 03 Jun 2023 23:25:43 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:58642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5eN8-0007kk-8H for 63861@debbugs.gnu.org; Sat, 03 Jun 2023 23:25:41 -0400 Received: by mail-pf1-f193.google.com with SMTP id d2e1a72fcca58-65299178ac5so2942982b3a.1 for <63861@debbugs.gnu.org>; Sat, 03 Jun 2023 20:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685849132; x=1688441132; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=x0G98lNJMOPAaEylLGxqWp7ZBiNZdZ4xF+Cwpa46Mdo=; b=VEnUf3lFaP6WRx7SasN8+Xx2DMCQMB/B0UhEV40G6Sp/kUoBopqCxbYwoR4g1JgxD2 o2gA/v0gnvuW/SMXCxF+Lqx7XfLkf3pTf0AON1B93FekatjgE7jWLkOLXtFy+xjYSZMa zysmBd9D7tBuvkuNqX2JZW0OonyTR051pQyMCBfzT2OCOeYLsXhn+6Wvabb5OdyDXqE1 160p+Xa1t5PxbT+G00mLnW6LVX1Hvp0cwsI2Fw3frDd+xSDMTY4rlTSB0bF05dHIVhts mOLv2a5niTqgq1dfH+n48bulFSyAArWhKPLE8zdz/DNkdyNfxyH0H4Q3c/OeGZTu7nZQ lu5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685849132; x=1688441132; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=x0G98lNJMOPAaEylLGxqWp7ZBiNZdZ4xF+Cwpa46Mdo=; b=NjoG80mG8QBcM82aRDRnoETiqvI/QZCtXV2yamje+osN98BXIMk7Vvk3/ykTEtO/9u rzjO3H2q/+KDp/T1kC1L36yN/dYN56GPJie6br/y4F0qN/BIlQ+Egt+/SchsEf+FXgIs JREcfoPiSkVqO94k1qWKZ46OedGddmFgKJe3JyXrwMWtpu5BBlVH/7UIPtU+jFJ2/SRZ VKUQQ1y2Iwx9itq+Yb0wMx45zKjnisjy2l49gBcPq7m+E9TCG6D3ia2LoOJn7aWQ1Vfa IdDDFuRdxnnCBkfHKaIb65vnXcABP8075JzGwiR/uw6a5q6o9lFZNZ4MJnZVmWr8L0HF f+pg== X-Gm-Message-State: AC+VfDy9mFr2zhkxWBxZlPhZcMWq0UZlahLZkrQBfow21Zq22kHdzQIV Hdz0ZE7jICkQPggrPILc0Ew= X-Google-Smtp-Source: ACHHUZ5rXfqqW5y2EN865Zjiw7h8D6JP3LMux60LcE4GOFwt6Mixrw6Q+8wTrPjVkZHJSo/oGtN+Vg== X-Received: by 2002:a05:6a20:a204:b0:101:4e04:cef1 with SMTP id u4-20020a056a20a20400b001014e04cef1mr2730263pzk.27.1685849131840; Sat, 03 Jun 2023 20:25:31 -0700 (PDT) Received: from localhost ([49.204.116.165]) by smtp.gmail.com with ESMTPSA id y14-20020a655b4e000000b0053b9bb98331sm3173543pgr.20.2023.06.03.20.25.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 03 Jun 2023 20:25:31 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier via's message of "Sat, 03 Jun 2023 14:18:36 -0400") References: <83fs799jmi.fsf@gnu.org> Date: Sun, 04 Jun 2023 08:55:29 +0530 Message-ID: <871qirdi3a.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=9C=E0=AF=82=E0=AE=A9=E0=AF=8D 03, 2023]= Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of tex= t editors" wrote: > Hmm... so you think it should stay as a `defcustom` and we should thus > plan to keep both kinds of pretty-printing in the long term? > I mostly intended it to be a temporary knob for people to be able to try > the new code and easily compare with the old (or revert to the old when > bumping into a problem with the new). > > If so, we should probably think of better names to distinguish the two > pp styles than `pp-buffer` vs `pp-region`. Maybe `pp-fill` for the new > code since arguably the main difference is that the new code pays > attention to `fill-column`? I don't have a good idea for a name for the > old code, OTOH (and I think it would make sense to keep `pp-buffer` as > a dispatch between the two options, so it would be good to have > a separate name for the old style). > > Another difference might be that the new style is maybe aimed more at > pp'ing code than data, whereas the old style might be a bit more > "agnostic" to the definition. Yet another difference is that the old > code tends to use more lines (because it doesn't try to fill the line > upto `fill-column`) and occasionally outputs very long lines because it > only breaks lines near parentheses. BTW, how does this compare to the newly added `pp-emacs-lisp-code'? It was still rough around the edges the last time I set `pp-use-max-width' non-nil. It is also quite a lot slower than the old path. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 05 12:40:04 2023 Received: (at submit) by debbugs.gnu.org; 5 Jun 2023 16:40:04 +0000 Received: from localhost ([127.0.0.1]:50265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6DFT-0004pc-Rl for submit@debbugs.gnu.org; Mon, 05 Jun 2023 12:40:04 -0400 Received: from lists.gnu.org ([209.51.188.17]:46730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6DFS-0004oy-6K for submit@debbugs.gnu.org; Mon, 05 Jun 2023 12:40:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6DFR-0004UB-US for bug-gnu-emacs@gnu.org; Mon, 05 Jun 2023 12:40:01 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6DFQ-00045S-CV; Mon, 05 Jun 2023 12:40:01 -0400 X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net Received: by mail.gandi.net (Postfix) with ESMTPSA id 210FBE000B; Mon, 5 Jun 2023 16:39:55 +0000 (UTC) From: Juri Linkov To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier via's message of "Sat, 03 Jun 2023 14:18:36 -0400") Organization: LINKOV.NET References: <83fs799jmi.fsf@gnu.org> Date: Mon, 05 Jun 2023 19:12:49 +0300 Message-ID: <86r0qqnjce.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:4b98:dc4:8::224; envelope-from=juri@linkov.net; helo=relay4-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , 63861@debbugs.gnu.org, Stefan Monnier 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.6 (--) > FWIW, the change affects other functionality that uses `pp`, such as > `C-h v`. While working on (previous versions of) this code, I've had > performance problems show up during the generation of `emoji-labels.el`. When tried on emoji-labels.el, at the end it failed with (scan-error "Containing expression ends prematurely" 255866 255867) >> Also, I think this warrants a NEWS entry and should be documented in >> the ELisp manual. > > Definitely for NEWS, yes. For the ELisp manual, currently we don't > document `pp-buffer`, the closest I see is `indent-pp-sexp` (in > `programs.texi`). For indent-pp-sexp with a prefix arg used on defuns, the new version is much better - it makes code more readable. It has only one snag: it inserts an empty line between the defun line and the docstring. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 10:10:42 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 14:10:42 +0000 Received: from localhost ([127.0.0.1]:54461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6ts2-0002l9-1W for submit@debbugs.gnu.org; Wed, 07 Jun 2023 10:10:42 -0400 Received: from lists.gnu.org ([209.51.188.17]:54882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6ts0-0002kw-DT for submit@debbugs.gnu.org; Wed, 07 Jun 2023 10:10:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6ts0-0007u0-54 for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 10:10:40 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6trx-0001yP-RP for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 10:10:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 66ED024002A for ; Wed, 7 Jun 2023 16:10:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686147034; bh=DpDLfIdDiVbDjZTvK6GG31VMNZfkeQQfiKzxAnS2Mv0=; h=From:MIME-Version:To:Cc:Subject:Date:Message-ID:Autocrypt:OpenPGP: From; b=Q3HsHYcz+8zL9M7vKnURHeJXnNH+zj9o/DxlZfmuFkc+8cQN8JN2S1gD9LssfDPyg 9QqFW5f9iX46pTbWABMOpUvTXT8pE7N1yUbljAzf1wMI3V9rQjKCtdFXrykV7BhpS2 YuV9xSuphjNxBvF28mFUXgQG+gLBY0wuEfxlV7wiWlezXU53Cv1pI01fOXMoGx37LD 0H3N2maTSSqT45liflvXiiv19bLqH53/iK8Yhxinhv8h5Tk+yR2pJeuPBazFIZyBAQ pPt9BMaCpojq7IXBevz0TQn4sSZ/N0p8H2vFwC+prJ8AQw+j/MfqQqYGkDdjSM3K49 o9ooItLnZJyew== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qbq4T1M7bz6tvp; Wed, 7 Jun 2023 16:10:32 +0200 (CEST) From: Thierry Volpiatto MIME-Version: 1.0 Content-Type: text/plain To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: Date: Wed, 07 Jun 2023 14:10:22 +0000 In-Reply-To: (Stefan Monnier via's message of "Fri, 02 Jun 2023 18:50:57 -0400") Message-ID: <87edmnics1.fsf@posteo.net> Autocrypt: addr=thievol@posteo.net; prefer-encrypt=mutual; keydata=xsDNBF8ylcIBDADG+hy+zR6L4/vbdDDZuSaMmSrU3A5QZJpeBCvxTr7MpzzruZbhLPW1K3R6N2MAedi8Y+C8o27FVRIjpdbaKMGu9je7JV/TbUQYo3SOwCK1vM4LUn4V6ZLzSYkuiEt4eyMoiDdyvN0pkcK6P9x9DCetcEVszXzQg+yzCVrQ2hXWDXWT4M18EC3wtO7RHPouMqGiwBFhBAYErCqFWFxQHkfbtG/4yGyJ58rglb65O3qijjMWvYwcWZun9/7qm8Z4/4mHopmo2zgU+OrptnLSZfkZGz3Y7Uf452xQGVq0Fv75NPvQru7y+DYVhuVXXyAmGxt+vf4rIiixMBbhKEPjcxEPAa2LTzex2IsTZR+QVG9uDnqCWcgaOEQ58fzXNvNhtwwF/Rgio2XWAJVdmFWS59/k9W58CIUSNKBMZh2XeGdEmtHvDtCxW3z6FJha36RzOM3fMNNiAGdFZJA84gcdloJR+sHCDTTPT3784fjr+V8An7sI581NGFzkRQqPvEQCZbUAEQEAAc0SdGhpZXZvbEBwb3N0ZW8ubmV0wsEOBBMBCgA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmL3HCoACgkQDsVtFB0W75OVEAv/f6XxmtIFz08fUb8hBp/zJP6IC4/rhhh+0GMRIRzLN8DK0jV8JCzYdFHiRJOy2lNIOpmrrCmjRRxferc2G42+ePFIsslxhU46VSz1Z83NwIG3mpdYNV5WUTUdgzxExHTNTFCd7NKv0nlHKQaAtdXm5bYnSHsnL7cx8z7lukA/EsJocE+GD7QXnsrdlicvdobI0TEN4l73221a72oCvHfYLCVsB6YsNJ5ZGkA1zSjzln5uLAgZ/2r/aqlao/AlSZkAk6+hvK0 RyAZ/YR4YRZxO8Fsd0gWgFkanRfKfufJ1V0OHZg7yszi3q/hRzS+rZtJ0OuzDlh/dyQkxVkZb9vis/+HnGDJrBE5MsmJLcy2Sy3uUnio0fq8q9CrZbudvd1DajlZxPzTm0csPeUk45QEgbhEU7MfyAX/mkKxjHajz2cMcHKIap1BqEgJl4BKFeLMcBZ4O1p9ivwtf1Ht2JTp5lOi0ItPfhQ4DP8LZ1ZIkN5Kg9v0cyw9meRzAuuR0V2GtzsDNBF8ylcIBDADnIDHEkmk4lUwTlOhwb2yjUfmGPnpH3MCCHkjM9H/P1gTHxFWtwFVPcNMCwXWvKSBTF2dZXKERD0yzG06zT53ZMN7EIIeuY6m4R8IcMvpohciisWxbFoB4ZY117tVSeqjo946itgbpdeESKl9a8dpn7ytZMyYxPdojlQAqxeAJ8444raESh1oTKXb64hlk4l2pSRlrLgjpJBo8asAfZndaxIUKhw68tV8sqeZh9P6cGtHbUELKVJqefNV7V7jF5wf3xvRG6Ces3kSKXalLfs+vrVaoOjQeWrc0AtwFWHmt9JLfKrqF+Q2Q7jUidboWmazQM56ESJFPpPHmWq8k6DHspsFHOforLouTHJL1556IPne7IV2BGfWc0+xLxalZ8F5F+vnPF/OkrC1CD5iCKTjXKa2iZbcYdYQAiL6P8Ac8CgN6EkhpbxRtzrEgChuNGevdi/G/GHG4Zqrh6YFwIa/NHq2aVaFq5C1yNTMJd1FRjRzs5JPPlJKpYDnNx+MSp7UAEQEAAcLA9gQYAQoAIAIbDBYhBCPbcH0Te6954oP8cA7FbRQdFu+TBQJi9x1ZAAoJEA7FbRQdFu+To6QMAIcvUSiFwCIggxkmYy3ZY0QAMLmIPga8DNPMXbfSOBDb2KLGBd+FAA8p2GExpul4r6kOYnGogtojByHmVgrd30/3ZURTM8Vj51wwD05viMZccQHlWd9J/qZIvhBJlJWYnwVxh+2Kg4/h kx7SGc7JJS5GS37+PFQOJHPGMxc+fe4Ty2FdjIOVf3P1Hov9K6yBI7Af66qqcL3aKJ4jJidRYN8sMaKOqEu4rcSpTxp8/3Ddbs9HezUgXeUzOLJMcEYFlvCyC8ZSl/QDZmpobKbxZ1JAqZM8lnmcZYSV7OsWnxJIYDV1gH5LTLj7bGswXaB4B+qkckihWkRZixu8q1IK0c/xwUzyF092uFRM/sQKrSmnwA1+hQiiIuEl4XVz5li0/TmMta3ijUM7GNbl2IjioTRxWWecwad1mNHvKTcXPsKDAbHFdLvQzurnroBHQV0jSPNLTP5Suo7RnLbehfg5INpGjToCUlrd2qQqgXW7h5qZTgUq5UmBc7YZ0JYWQgPTbQ== OpenPGP: url=https://posteo.de/keys/thievol@posteo.net.asc; preference=encrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: 63861@debbugs.gnu.org, Stefan Monnier 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 (--) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Tags: patch > > I've often been annoyed by the way `ielm` "pretty prints" data, > so I wrote my own pretty printer, which has evolved over the years. > I believe it has finally reached a state which may be acceptable > to more than just myself. > > The new code is in a new function `pp-region`. > The old code redirects to the new code if `pp-buffer-use-pp-region` is > non-nil, tho I'm not sure we want to bother users with such > a config var. Hopefully, the new code should be good enough that users > don't need to choose. Maybe I should make it a `defvar` and have it > default to t, so new users will complain if it's not good enough? I tried your code and it looks very slow (but looks nice once printed). Testing on my bookmark-alist printed in some buffer. Here with a slightly modified version of pp-buffer (not much faster than the original one): (benchmark-run-compiled 1 (pp-buffer)) => (6.942135047 0 0.0) And here with your version (using pp-region): (benchmark-run-compiled 1 (pp-buffer)) => (46.141411097 0 0.0) For describe variable I use a modified version of `pp` which is very fast (nearly instant to pretty print value above) but maybe unsafe with some vars, didn't have any problems though, see https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-variable.el. > > Stefan > > > In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo > version 1.16.0, Xaw3d scroll bars) of 2023-05-24 built on pastel > Repository revision: 41b6b907d4cf2f8c302647dc63c5d9c94f9f01d6 > Repository branch: work > Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 > System Description: Debian GNU/Linux 11 (bullseye) > > Configured using: > 'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable > 'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign' > PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig' > > -- Thierry From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 11:21:36 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 15:21:37 +0000 Received: from localhost ([127.0.0.1]:54516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6uye-0004jD-Jc for submit@debbugs.gnu.org; Wed, 07 Jun 2023 11:21:36 -0400 Received: from lists.gnu.org ([209.51.188.17]:46334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6uyc-0004j0-Nl for submit@debbugs.gnu.org; Wed, 07 Jun 2023 11:21:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6uyc-0007TV-Gl for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 11:21:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6uya-0006hk-Qq; Wed, 07 Jun 2023 11:21:34 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 69DA3441553; Wed, 7 Jun 2023 11:21:30 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AB40344155D; Wed, 7 Jun 2023 11:21:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686151284; bh=FVNZ6oFSDc2WFENjozGXe/vlamLI/zmVGhX91/SCCEk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=S56QMUZHjAx6J05KONi+/6kOmCEFu8zeYLpBcX2nIZVl0xMj16+Uk/w6dj/9wahWP EM8pbGV6fzcjkBstIGdJtuxTS86W2KK6pDZU4PMG0YoUzg1ARJYf6MMpaN4s8MeJlJ Nw2QKq1wq+MPEGTF22hbsvBRng1eQLutYV3txtAleEf4D7WRVb89PNcQhdurju8Au+ S7uFtebugsNAykZuwHBRRWRQBBbtQeoY+V122V5e7042dUO8Mo/hv8TPei3w7BOANl rD6Hh2sEBQkZOPyPOmWWMEHIUoO2Bp0nrCP/uYY5ZYys3vghyti1veion3vLyZ3u1I yW8SkHqW630iA== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 939C512077F; Wed, 7 Jun 2023 11:21:24 -0400 (EDT) From: Stefan Monnier To: Juri Linkov Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <86r0qqnjce.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 05 Jun 2023 19:12:49 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <86r0qqnjce.fsf@mail.linkov.net> Date: Wed, 07 Jun 2023 11:21:23 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.156 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org, Eli Zaretskii 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 (--) >> FWIW, the change affects other functionality that uses `pp`, such as >> `C-h v`. While working on (previous versions of) this code, I've had >> performance problems show up during the generation of `emoji-labels.el`. > > When tried on emoji-labels.el, at the end it failed with > > (scan-error "Containing expression ends prematurely" 255866 255867) Hmm... when I do rm lisp/international/emoji-labels.el make the file is rebuilt correctly. Could you give more details about how you got the above? >>> Also, I think this warrants a NEWS entry and should be documented in >>> the ELisp manual. >> Definitely for NEWS, yes. For the ELisp manual, currently we don't >> document `pp-buffer`, the closest I see is `indent-pp-sexp` (in >> `programs.texi`). > For indent-pp-sexp with a prefix arg used on defuns, the new version > is much better - it makes code more readable. It has only one snag: > it inserts an empty line between the defun line and the docstring. Oh, indeed, I'm not careful to check before I insert the `\n` in this case (I always use it on code that starts as a single line). I'll fix it in the next round, thanks. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 11:27:43 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 15:27:43 +0000 Received: from localhost ([127.0.0.1]:54526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6v4Y-0004sg-Os for submit@debbugs.gnu.org; Wed, 07 Jun 2023 11:27:43 -0400 Received: from lists.gnu.org ([209.51.188.17]:58430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6v4W-0004sX-Ma for submit@debbugs.gnu.org; Wed, 07 Jun 2023 11:27:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6v4W-0000hv-BO for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 11:27:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6v4U-0007k5-IL for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 11:27:40 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 30D3180504; Wed, 7 Jun 2023 11:27:37 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ED547804F6; Wed, 7 Jun 2023 11:27:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686151656; bh=5jZ6luSq4tjv/AHsp8bV8kbUZF0uBnjbcXdkfi6NNvU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JNjeXEMsp/hbqAb+v7KnwZ0Cuzdp1tJQ3QiY751pr6rjjQ9ulTXvRWZVzAGxQ4XBf 5MWV3XvtBFGlk0RPCnxSuW+dzVP3E1LS/1OKH7dXxP7HlOfLIfD8zkRzgH0ElCqKjI MUIG2rOd3S62B9Y+HVNC0PDJS9RdX+Q1dcSAhQcJfkxohoY+5ma4GCht4f3M49Zejp 3h1Dv2+18qcMxBQl3XnooCPyujlGKv9yzYLDtN6WKqJ1qv9Rd6yRIKx+MVXfxu9Yn2 DBm9/zHTPRMqvpyodol3WFDCqJ7u2wpJJNK4j+xuaLtqIzEe651LVeYKZk/u/yiNuh n/verMXwU97vA== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DC2E9120508; Wed, 7 Jun 2023 11:27:35 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <87edmnics1.fsf@posteo.net> (Thierry Volpiatto's message of "Wed, 07 Jun 2023 14:10:22 +0000") Message-ID: References: <87edmnics1.fsf@posteo.net> Date: Wed, 07 Jun 2023 11:27:35 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.055 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > I tried your code and it looks very slow (but looks nice once printed). > Testing on my bookmark-alist printed in some buffer. > Here with a slightly modified version of pp-buffer (not much faster than > the original one): > > (benchmark-run-compiled 1 (pp-buffer)) > =3D> (6.942135047 0 0.0) > And here with your version (using pp-region): > (benchmark-run-compiled 1 (pp-buffer)) > =3D> (46.141411097 0 0.0) > > For describe variable I use a modified version of `pp` which is very > fast (nearly instant to pretty print value above) but maybe unsafe with > some vars, didn't have any problems though, see > https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-varia= ble.el. Beside the actual way we choose when to insert \n, the main difference w.r.t performance tends to come from the fact that the new code relies on `lisp-indent-line` rather than `lisp-indent-region`. In many cases it doesn't make much difference performancewise, but indeed there are cases where the difference is significant (more specifically where it makes the code O(N=B2) rather than O(N)). I've been using the patch below for a while and I should probably include it the `pp-region` patch. Can you check whether it helps for your case? Stefan diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index d44c9d6e23d..9914ededb85 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -876,7 +876,7 @@ lisp-ppss 2 (counting from 0). This is important for Lisp indentation." (unless pos (setq pos (point))) (let ((pss (syntax-ppss pos))) - (if (nth 9 pss) + (if (and (not (nth 2 pss)) (nth 9 pss)) (let ((sexp-start (car (last (nth 9 pss))))) (parse-partial-sexp sexp-start pos nil nil (syntax-ppss sexp-sta= rt))) pss))) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 11:48:41 2023 Received: (at 63861) by debbugs.gnu.org; 7 Jun 2023 15:48:41 +0000 Received: from localhost ([127.0.0.1]:54572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6vOr-0005VC-J5 for submit@debbugs.gnu.org; Wed, 07 Jun 2023 11:48:41 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6vOp-0005Uo-Uf for 63861@debbugs.gnu.org; Wed, 07 Jun 2023 11:48:40 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A4C501000C3; Wed, 7 Jun 2023 11:48:34 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9B65610002F; Wed, 7 Jun 2023 11:48:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686152913; bh=zWc3UxkpG27Vw1j5ec3WMcgGfbiQMjTvdxOkV4Z9hRY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Fa9xQBfAx6ssp/WdJRb52reel6AJp2fmiG5HiZ/o13Rr8AFMaB/9wKTT36tofgWQp /0UAZE0SmchlguCBF8w8K0VKrg4SE0BhoOBE/SDrAXos6wto1liEozuhP9Qg/CIuw9 7fjejIUlazwKNzCHEhiY9tYVGDZ49Y32bB/yWBeRlNO2StvxIo9w0x0Hln7e9w8Ycv nlyawbH4i5+jaFu4C6m/8611TxH8NFwC5ArMCoRsdaLnhmCi+LHcSCTjoALj+Njyi+ HTHeHs9nJCf+z144CEXizkcEUfjJlWhsE8GV74Os3nR3dhYq2keSrz3UDsGpeN8k0m idKvD5Ha692jA== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 609C812029C; Wed, 7 Jun 2023 11:48:33 -0400 (EDT) From: Stefan Monnier To: Visuwesh Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <871qirdi3a.fsf@gmail.com> (Visuwesh's message of "Sun, 04 Jun 2023 08:55:29 +0530") Message-ID: References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> Date: Wed, 07 Jun 2023 11:48:32 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.076 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > BTW, how does this compare to the newly added `pp-emacs-lisp-code`? Very good question. I had completely missed that (and its `pp-use-max-width`). This points to a host of integration issues between my code and the existing code. I'll have to take a deeper look. > It was still rough around the edges the last time I set > `pp-use-max-width' non-nil. It is also quite a lot slower than the > old path. My new code is expected to be slower than the "normal" pretty-printer, but barring performance bugs in `lisp-indent-line` (such as the one fixed by the patch I just sent to Thierry) it should be approximately a constant factor slower. AFAICT the performance of `pp-emacs-lisp-code` can be more problematic. Beside performance, I guess the behavior of the two should be somewhat similar, tho I also see that `pp-emacs-lisp-code` pays attention to the Edebug and `doc-string-elt` info, so it may give slightly more refined info. Another difference is that `pp-emacs-lisp-code` starts with an S-exp object, whereas my code starts with a region (i.e. an sexp that's already been printed). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 12:24:48 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 16:24:48 +0000 Received: from localhost ([127.0.0.1]:54592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6vxn-0006SO-LF for submit@debbugs.gnu.org; Wed, 07 Jun 2023 12:24:48 -0400 Received: from lists.gnu.org ([209.51.188.17]:59974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6vxl-0006S8-33 for submit@debbugs.gnu.org; Wed, 07 Jun 2023 12:24:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6vxk-000078-TF for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 12:24:44 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6vxi-0006jE-LE for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 12:24:44 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 987C9240027 for ; Wed, 7 Jun 2023 18:24:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686155080; bh=zSAxuZL1zaM9LfBN7PD/uPQ1qxQh/x/jOf/clHFMHn0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=UkBZW+fSqxJGYf7Rdxi1oE+iyxSRWZCTM+pFGVKUTIJIYVJ20M61AJ4pV9BdvUDlc DlOD6CMOnL412rT+HL333MbY2X9cGAHuE2Y06/yxQpeRWp5FNJp3ZY2k2MjdD+4kqR fSKz+Vezh4a7Ait1h8Bc5ua37Zs7vYAwnTQItSJ43UMSQKUM8cD5AIH4hMWdgZhlvl U2MwpzrQ8Sx7/5TGMhR6GR+DU0aZA7P68vR9HUDcvSPCE9gGw4/5ct95g2tyOB2kaC IPdW83dhtQka4C+RhYC5KvFzo+w4IWg0CQj3M4pTBfAHwZMjtbBAaRbLnzRASjA+Cc lvh8cvWbVJu9Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qbt3C43Rcz9rxG; Wed, 7 Jun 2023 18:24:39 +0200 (CEST) References: <87edmnics1.fsf@posteo.net> From: Thierry Volpiatto To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code Date: Wed, 07 Jun 2023 16:19:38 +0000 In-reply-to: Message-ID: <871qinme9q.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: >> I tried your code and it looks very slow (but looks nice once printed). >> Testing on my bookmark-alist printed in some buffer. >> Here with a slightly modified version of pp-buffer (not much faster than >> the original one): >> >> (benchmark-run-compiled 1 (pp-buffer)) >> =3D> (6.942135047 0 0.0) >> And here with your version (using pp-region): >> (benchmark-run-compiled 1 (pp-buffer)) >> =3D> (46.141411097 0 0.0) >> >> For describe variable I use a modified version of `pp` which is very >> fast (nearly instant to pretty print value above) but maybe unsafe with >> some vars, didn't have any problems though, see >> https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-vari= able.el. > > Beside the actual way we choose when to insert \n, the main difference > w.r.t performance tends to come from the fact that the new code relies > on `lisp-indent-line` rather than `lisp-indent-region`. > > In many cases it doesn't make much difference performancewise, but > indeed there are cases where the difference is significant (more > specifically where it makes the code O(N=C2=B2) rather than O(N)). > I've been using the patch below for a while and I should probably > include it the `pp-region` patch. > > Can you check whether it helps for your case? No, more or less the same: (benchmark-run-compiled 1 (pp-buffer)) =3D> (48.501764747 0 0.0) I have modified my code so that it can be used outside help, you can test it with tv/pp-region. Here with always the same test buffer: (benchmark-run-compiled 1 (tv/pp-region (point-min) (point-max))) =3D> (0.259444169 0 0.0) =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmSAr0ETHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvkwp+C/wOxit5p0nawhL5sNdfj+v35T7KlKKh BuOxnG36W5q6IqApKN9VsRTEirFmWA7nyHAvlmN/VBPRIt1aZRdbsZX3tqQwWRYs taIU7EPxejnQs+rbdeRuTK5IvibjqHmPyg4bIbKV2WVgXbtJj7KXRBAZZrfDqq5u LhQv6Uqg46QQYfooZ1vW1jxaFb4wYTaSEeLHys3nmjQKEOQsdvgHz/rPn+TR6JEU 1LOAYHs52fxecgkuUt4Iu2FPpcyEcEbS/yFu9PEwTHl8jPAeB+IuJF0rcDkCF1E5 S1jcQ+AnmAYoQO2yxAHYihk+OSa2GTbFN1IsAEQyDSVwuL/5PBI1oHf81zAKAGMa nTCw0q62l6BMCGLNPrSf8Z9EgIqUMaWUzucQyVLlI3WQbCqRNNG2z31TuqWPgq/o wKVOMETJ+6HX6++DW0jzNR8Ek1btWxX2Kb6oC9GfmPBylvrZv3i5Z99d/2McCsq0 0noiry4Ic4HA8187gbW+R2W4AUGprZCnrJY= =h9Ln -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 14:14:45 2023 Received: (at 63861) by debbugs.gnu.org; 7 Jun 2023 18:14:45 +0000 Received: from localhost ([127.0.0.1]:54702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6xgC-00010n-T0 for submit@debbugs.gnu.org; Wed, 07 Jun 2023 14:14:45 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:54563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6xgA-00010X-Fc for 63861@debbugs.gnu.org; Wed, 07 Jun 2023 14:14:43 -0400 X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net Received: by mail.gandi.net (Postfix) with ESMTPSA id 3065D20004; Wed, 7 Jun 2023 18:14:34 +0000 (UTC) From: Juri Linkov To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier's message of "Wed, 07 Jun 2023 11:21:23 -0400") Organization: LINKOV.NET References: <83fs799jmi.fsf@gnu.org> <86r0qqnjce.fsf@mail.linkov.net> Date: Wed, 07 Jun 2023 21:12:00 +0300 Message-ID: <867csf3zwv.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> When tried on emoji-labels.el, at the end it failed with >> >> (scan-error "Containing expression ends prematurely" 255866 255867) > > Hmm... when I do > > rm lisp/international/emoji-labels.el > make > > the file is rebuilt correctly. > Could you give more details about how you got the above? With (setq debug-on-error t) when point is at the beginning of this line: (defconst emoji--labels '(("Smileys" typing 'C-u C-M-q' gives the error: Debugger entered--Lisp error: (scan-error "Containing expression ends prematurely" 9739 9740) pp-region(522 9447) pp-region(521 9448) pp-buffer() indent-pp-sexp((4)) funcall-interactively(indent-pp-sexp (4)) command-execute(indent-pp-sexp) I can send the file, but all its parens are balanced. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 15:43:26 2023 Received: (at 63861) by debbugs.gnu.org; 7 Jun 2023 19:43:26 +0000 Received: from localhost ([127.0.0.1]:54842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6z42-0003PA-Bt for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:43:26 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6z3z-0003Os-7u for 63861@debbugs.gnu.org; Wed, 07 Jun 2023 15:43:24 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 58EDF1000C3; Wed, 7 Jun 2023 15:43:17 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 48D6D10002F; Wed, 7 Jun 2023 15:43:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686166996; bh=GsQopnNi3sn//DVmNLgKMobUdoPceHOxHvRTEhKaSeY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Pf1xNeoyTTtzPZOIgyEas0F8BLQhh7WFq3TbK5ZA8BP45JhPgMRbLNUuM8ssSQHq/ b29qzN6yZOTqnqMqZHO8le7NL836TNd5ZCm8yqu/M0Q5wEWtJd9qbBDH1ndW2rgG2p yQl0d7e/eXDZcSUHEF1IIyhK7J/Mp4c+9DC4KUfE3btpna4X+5WPrZdQRRhLODg6cH ZtJloFLLrygAzF5W2hmd+XVSf3e3A8j6sg1gZTM0HNPmpO5UvG41PbjIZO0WF6dsH8 auqj0EdTaljMCvvGsjg3NfOeRUy9EHrLtk6V19FOa0LKBE3mzIK9z+bjuV4SzaeRCs aHokyzAhhWoRA== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27F9312031E; Wed, 7 Jun 2023 15:43:16 -0400 (EDT) From: Stefan Monnier To: Juri Linkov Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <867csf3zwv.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 07 Jun 2023 21:12:00 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <86r0qqnjce.fsf@mail.linkov.net> <867csf3zwv.fsf@mail.linkov.net> Date: Wed, 07 Jun 2023 15:43:15 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.028 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > With (setq debug-on-error t) when point is at the beginning of this line: > > (defconst emoji--labels '(("Smileys" > > typing 'C-u C-M-q' gives the error: > > Debugger entered--Lisp error: (scan-error "Containing expression ends prematurely" 9739 9740) Thanks, I can reproduce it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 17:18:10 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 21:18:10 +0000 Received: from localhost ([127.0.0.1]:54937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q70Xi-0005sh-G8 for submit@debbugs.gnu.org; Wed, 07 Jun 2023 17:18:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:45962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q70Xf-0005sS-0F for submit@debbugs.gnu.org; Wed, 07 Jun 2023 17:18:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q70Xe-0003CH-Po for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 17:18:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q70Xc-0005iH-Pc for bug-gnu-emacs@gnu.org; Wed, 07 Jun 2023 17:18:06 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7D0D580502; Wed, 7 Jun 2023 17:18:02 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 50BBB8001C; Wed, 7 Jun 2023 17:18:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686172681; bh=elUZIe8bA3eJwTLoijuUzL2IHHWk3q478+ebDGmo+I0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TWzVpx3WLDxzUQS9d1Sgbtz6pUbkyAn0Fjd0qLjXbqFaF/BURxNO8DLKXad/DWn3e dsn+973xFyxHrmUxZoDGbYoeZrbu11P1YNJoxJWMZtKTgMGK+GcWGlXZ7DAw4+nSge 7cualGFr5c092bWy5k6+xWVku4zeu48H9SXe2F2cmXf7b1x5HSeVJhehL9j1vQ4dCT 42mcf1BUCHtBOsgAtMatwt/QjleEZAqVjI8uGEG88UcHAlyVXKOfyEsn6ZsvvyAza/ 8UiNZmQOZf9ZoBvq25cs7bKQxNDCKaOTAl69SxL4zSMQoihmhdQwFfhtn3ZT3YwuI5 QHCqqH/1THZ8w== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2E8A51205D9; Wed, 7 Jun 2023 17:18:01 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <871qinme9q.fsf@posteo.net> (Thierry Volpiatto's message of "Wed, 07 Jun 2023 16:19:38 +0000") Message-ID: References: <87edmnics1.fsf@posteo.net> <871qinme9q.fsf@posteo.net> Date: Wed, 07 Jun 2023 17:18:00 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.079 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > No, more or less the same: :-( > (benchmark-run-compiled 1 (pp-buffer)) > => (48.501764747 0 0.0) > > I have modified my code so that it can be used outside help, you can > test it with tv/pp-region. Here with always the same test buffer: > > (benchmark-run-compiled 1 (tv/pp-region (point-min) (point-max))) > => (0.259444169 0 0.0) Hmm... I think this depends on the data you're printing. Any hope you can share the data you're using for your tests? [ I understand it's personal, so it can be problematic. Maybe you can anonymize with a search&replace of, say `[[:alpha:]]` to `x`? ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 12:16:09 2023 Received: (at submit) by debbugs.gnu.org; 8 Jun 2023 16:16:09 +0000 Received: from localhost ([127.0.0.1]:57332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7IIy-0006n8-J6 for submit@debbugs.gnu.org; Thu, 08 Jun 2023 12:16:09 -0400 Received: from lists.gnu.org ([209.51.188.17]:54684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7IIv-0006mz-TV for submit@debbugs.gnu.org; Thu, 08 Jun 2023 12:16:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7IIs-00008e-Pg for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 12:16:04 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7IIo-0004DS-BM for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 12:16:02 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6F48E44273B; Thu, 8 Jun 2023 12:15:54 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 03FA44426F9; Thu, 8 Jun 2023 12:15:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686240952; bh=Q99fEJPiE/gKpF6fktOZZqp+JvCW+yGJzCF0GdJ1B5o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pozCBrPVbhUD0Mk/YaN/wZMWjXrFIP95NLInXTAKH4WtgPCwcC70gigXqCnWDBxf4 GKXnCJOkgHmVc1ZTUJ/8JH0J7+gk7phpzueoYRxJt11OrZGeQ6qBQwPP/YxxjX43vS hEYItyuTDc6gUh5RudFi1kmCsY8Sn8bnAWUWu4tdR1SC8OAZwf6YXWYtTSNvJiUaPv Er3O/Vxo3gJpO9MVOjYdnvEmKdjDcjK3YVTFcI9KFQ1rRkCciMZxinPG+dbsIDX3ZV aKv00zQeAyWvzXdfEvDgGJyYTLVSWR544l6YcbOsasckf9491z3R0wtzTKiOlUjKa4 E27CGht8glwtQ== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CC4251200D7; Thu, 8 Jun 2023 12:15:51 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <87edmnics1.fsf@posteo.net> (Thierry Volpiatto's message of "Wed, 07 Jun 2023 14:10:22 +0000") Message-ID: References: <87edmnics1.fsf@posteo.net> Date: Thu, 08 Jun 2023 12:15:47 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.155 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >> The new code is in a new function `pp-region`. >> The old code redirects to the new code if `pp-buffer-use-pp-region` is >> non-nil, tho I'm not sure we want to bother users with such >> a config var. Hopefully, the new code should be good enough that users >> don't need to choose. Maybe I should make it a `defvar` and have it >> default to t, so new users will complain if it's not good enough? > > I tried your code and it looks very slow (but looks nice once printed). > Testing on my bookmark-alist printed in some buffer. > Here with a slightly modified version of pp-buffer (not much faster than > the original one): > > (benchmark-run-compiled 1 (pp-buffer)) > => (6.942135047 0 0.0) > And here with your version (using pp-region): > (benchmark-run-compiled 1 (pp-buffer)) > => (46.141411097 0 0.0) Hmm... that's weird. With the bookmark-alist.el file you sent me, I get pretty much the reverse result: % for f in foo.el test-load-history.el test-bookmark-alist.el; do \ for v in nil t; do \ time src/emacs -Q --batch "$f" -l pp \ --eval "(progn (setq pp-buffer-use-pp-region $v) \ (message \"%s %s %S\" (file-name-nondirectory buffer-file-name) \ pp-buffer-use-pp-region \ (benchmark-run (pp-buffer))))"; \ done; done foo.el nil (0.210123295 1 0.057426385) src/emacs -Q --batch "$f" -l pp --eval 0.34s user 0.04s system 99% cpu 0.382 total foo.el t (0.07107641199999999 0 0.0) src/emacs -Q --batch "$f" -l pp --eval 0.19s user 0.03s system 99% cpu 0.222 total test-load-history.el nil (156.07942386099998 17 1.432754161) src/emacs -Q --batch "$f" -l pp --eval 156.04s user 0.20s system 99% cpu 2:36.26 total test-load-history.el t (96.480110987 24 1.9799413479999999) src/emacs -Q --batch "$f" -l pp --eval 96.40s user 0.27s system 99% cpu 1:36.69 total test-bookmark-alist.el nil (51.211047973 8 0.6690439610000001) src/emacs -Q --batch "$f" -l pp --eval 51.29s user 0.11s system 99% cpu 51.401 total test-bookmark-alist.el t (5.110458941 6 0.468187075) src/emacs -Q --batch "$f" -l pp --eval 5.21s user 0.09s system 99% cpu 5.302 total % This is comparing "the old pp-buffer" with "the new `pp-region`", using the patch below. This is not using your `tv/pp-region` code. I find these results (mine) quite odd: they suggest that my `pp-region` is *faster* than the old `pp-buffer` for `load-history` and `bookmark-alist` data, which I definitely did not expect (and don't know how to explain either). These tests were run on a machine whose CPU's speed can vary quite drastically depending on the load, so take those numbers with a grain of salt, but the dynamic frequency fluctuations shouldn't cause more than a factor of 2 difference (and according to my CPU frequency monitor widget, the frequency was reasonably stable during the test). > For describe variable I use a modified version of `pp` which is very > fast (nearly instant to pretty print value above) but maybe unsafe with > some vars, didn't have any problems though, see > https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-variable.el. So, IIUC the numbers you cite above compare my `pp-region` to your `tv/pp-region`, right? And do I understand correctly that `tv/pp-region` does not indent its output? What was the reason for this choice? Stefan PS: BTW, looking at the output of `pp` on the bookmark-data, it's not a test where `pp-region` shines: the old pp uses up more lines, but is more regular and arguably more readable :-( diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index d44c9d6e23d..9914ededb85 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -876,7 +876,7 @@ lisp-ppss 2 (counting from 0). This is important for Lisp indentation." (unless pos (setq pos (point))) (let ((pss (syntax-ppss pos))) - (if (nth 9 pss) + (if (and (not (nth 2 pss)) (nth 9 pss)) (let ((sexp-start (car (last (nth 9 pss))))) (parse-partial-sexp sexp-start pos nil nil (syntax-ppss sexp-start))) pss))) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index e6e3cd6c6f4..89d7325a491 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -74,31 +74,127 @@ pp-to-string (pp-buffer) (buffer-string)))) +(defun pp--within-fill-column-p () + "Return non-nil if point is within `fill-column'." + ;; Try and make it O(fill-column) rather than O(current-column), + ;; so as to avoid major slowdowns on long lines. + ;; FIXME: This doesn't account for invisible text or `display' properties :-( + (and (save-excursion + (re-search-backward + "^\\|\n" (max (point-min) (- (point) fill-column)) t)) + (<= (current-column) fill-column))) + +(defun pp-region (beg end) + "Insert newlines in BEG..END to try and fit within `fill-column'. +Presumes the current buffer contains Lisp code and has indentation properly +configured for that. +Designed under the assumption that the region occupies a single line, +tho it should also work if that's not the case." + (interactive "r") + (goto-char beg) + (let ((end (copy-marker end t)) + (newline (lambda () + (skip-chars-forward ")]}") + (unless (save-excursion (skip-chars-forward " \t") (eolp)) + (insert "\n") + (indent-according-to-mode))))) + (while (progn (forward-comment (point-max)) + (< (point) end)) + (let ((beg (point)) + ;; Whether we're in front of an element with paired delimiters. + ;; Can be something funky like #'(lambda ..) or ,'#s(...). + (paired (when (looking-at "['`,#]*[[:alpha:]]*\\([({[\"]\\)") + (match-beginning 1)))) + ;; Go to the end of the sexp. + (goto-char (or (scan-sexps (or paired (point)) 1) end)) + (unless + (and + ;; The sexp is all on a single line. + (save-excursion (not (search-backward "\n" beg t))) + ;; And its end is within `fill-column'. + (or (pp--within-fill-column-p) + ;; If the end of the sexp is beyond `fill-column', + ;; try to move the sexp to its own line. + (and + (save-excursion + (goto-char beg) + (if (save-excursion (skip-chars-backward " \t({[',") (bolp)) + ;; The sexp was already on its own line. + nil + (skip-chars-backward " \t") + (setq beg (copy-marker beg t)) + (if paired (setq paired (copy-marker paired t))) + ;; We could try to undo this insertion if it + ;; doesn't reduce the indentation depth, but I'm + ;; not sure it's worth the trouble. + (insert "\n") (indent-according-to-mode) + t)) + ;; Check again if we moved the whole exp to a new line. + (pp--within-fill-column-p)))) + ;; The sexp is spread over several lines, and/or its end is + ;; (still) beyond `fill-column'. + (when (and paired (not (eq ?\" (char-after paired)))) + ;; The sexp has sub-parts, so let's try and spread + ;; them over several lines. + (save-excursion + (goto-char beg) + (when (looking-at "(\\([^][()\" \t\n;']+\\)") + ;; Inside an expression of the form (SYM ARG1 + ;; ARG2 ... ARGn) where SYM has a `lisp-indent-function' + ;; property that's a number, insert a newline after + ;; the corresponding ARGi, because it tends to lead to + ;; more natural and less indented code. + (let* ((sym (intern-soft (match-string 1))) + (lif (and sym (get sym 'lisp-indent-function)))) + (if (eq lif 'defun) (setq lif 2)) + (when (natnump lif) + (goto-char (match-end 0)) + (forward-sexp lif) + (funcall newline))))) + (save-excursion + (pp-region (1+ paired) (1- (point))))) + ;; Now the sexp either ends beyond `fill-column' or is + ;; spread over several lines (or both). Either way, the rest of the + ;; line should be moved to its own line. + (funcall newline)))))) + +(defcustom pp-buffer-use-pp-region t + "If non-nil, `pp-buffer' uses the new `pp-region' code." + :type 'boolean) + ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp object." (interactive) (goto-char (point-min)) - (while (not (eobp)) - (cond - ((ignore-errors (down-list 1) t) - (save-excursion - (backward-char 1) - (skip-chars-backward "'`#^") - (when (and (not (bobp)) (memq (char-before) '(?\s ?\t ?\n))) - (delete-region - (point) - (progn (skip-chars-backward " \t\n") (point))) - (insert "\n")))) - ((ignore-errors (up-list 1) t) - (skip-syntax-forward ")") - (delete-region - (point) - (progn (skip-chars-forward " \t\n") (point))) - (insert ?\n)) - (t (goto-char (point-max))))) - (goto-char (point-min)) - (indent-sexp)) + (if pp-buffer-use-pp-region + (with-syntax-table emacs-lisp-mode-syntax-table + (let ((fill-column (max fill-column 70)) + (indent-line-function + (if (local-variable-p 'indent-line-function) + indent-line-function + #'lisp-indent-line))) + (pp-region (point-min) (point-max)))) + (while (not (eobp)) + (cond + ((ignore-errors (down-list 1) t) + (save-excursion + (backward-char 1) + (skip-chars-backward "'`#^") + (when (and (not (bobp)) (memq (char-before) '(?\s ?\t ?\n))) + (delete-region + (point) + (progn (skip-chars-backward " \t\n") (point))) + (insert "\n")))) + ((ignore-errors (up-list 1) t) + (skip-syntax-forward ")") + (delete-region + (point) + (progn (skip-chars-forward " \t\n") (point))) + (insert ?\n)) + (t (goto-char (point-max))))) + (goto-char (point-min)) + (indent-sexp))) ;;;###autoload (defun pp (object &optional stream) From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 14:35:45 2023 Received: (at submit) by debbugs.gnu.org; 8 Jun 2023 18:35:45 +0000 Received: from localhost ([127.0.0.1]:57541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7KU5-00025E-0h for submit@debbugs.gnu.org; Thu, 08 Jun 2023 14:35:45 -0400 Received: from lists.gnu.org ([209.51.188.17]:47750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7KTz-00024r-Id for submit@debbugs.gnu.org; Thu, 08 Jun 2023 14:35:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7KTx-0004ve-OR for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 14:35:39 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7KTu-0007t6-Tq for bug-gnu-emacs@gnu.org; Thu, 08 Jun 2023 14:35:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D3733240027 for ; Thu, 8 Jun 2023 20:35:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686249330; bh=bn0HBf9ch96YnPIDc7xLGnbCg6b3a/Ooa0haqxrCnaE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=CS3uW4tr9CWhADjJuJih+DYi2ikVcUnu+cn5uZ+Fn6zcaoQDXJgYONJKnkPmVme/A tBdxm51gNxtWWI1cR1Q7ruFc0M1uNr8BHnK+bS2c/pVeaBAxoTzYPUFG/oU79JOvm9 sze3etGVBiESmFciaYTcJCOwsoy6iNRQLwUxbMp/RfWqeLlr0hWtOwi/hGBDlHdxxM WY208HLMRdM+Yu0b35cAynCkqrNgWd06mNtTH8QaIBLBxwtTiHuOtYCBSESGClKwQE TD5/VbfOA0KaS8mKh9GX55KbgzBr+QmwDxtUgQXpIBaxMSc46sp37m8YYpuz/ZtVbq 5D4030XiDtzlw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QcXvj525xz9rxV; Thu, 8 Jun 2023 20:35:29 +0200 (CEST) References: <87edmnics1.fsf@posteo.net> From: Thierry Volpiatto To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code Date: Thu, 08 Jun 2023 18:08:18 +0000 In-reply-to: Message-ID: <87bkhpvm35.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: > This is comparing "the old pp-buffer" with "the new `pp-region`", using > the patch below. This is not using your `tv/pp-region` code. > > I find these results (mine) quite odd: they suggest that my `pp-region` > is *faster* than the old `pp-buffer` for `load-history` and `bookmark-ali= st` > data, which I definitely did not expect (and don't know how to explain > either). Hmm, don't know, I ran pp-buffer with M-: from the test-load-history.el or = the test-bookmark-alist.el buffer. May be using emacs --batch makes a difference? is the data really printed in such case? More or less the code using pp-region takes between 42 to 48s and the one with old pp-buffer around 6s. Also sorry about your last patch I tested it too fast, it is indeed slightly faster, but not much: 42 vs 46s. > These tests were run on a machine whose CPU's speed can vary quite > drastically depending on the load, so take those numbers with a grain of > salt, but the dynamic frequency fluctuations shouldn't cause more than > a factor of 2 difference (and according to my CPU frequency monitor > widget, the frequency was reasonably stable during the test). Yes, sure, more or less it is the same. >> For describe variable I use a modified version of `pp` which is very >> fast (nearly instant to pretty print value above) but maybe unsafe with >> some vars, didn't have any problems though, see >> https://github.com/thierryvolpiatto/emacs-config/blob/main/describe-vari= able.el. > > So, IIUC the numbers you cite above compare my `pp-region` to your > `tv/pp-region`, right? Not in the first mail, but after yes. > And do I understand correctly that `tv/pp-region` does not indent its > output? No, it does indent, see function tv/pp which use pp-to-string which use pp-= buffer and pp-buffer indent the whole sexp at the end. > What was the reason for this choice? Because indentation is done at the end by pp-buffer. PS (unrelated to pp-region): About the old pp-buffer, there is a difficult = to find bug where the same operation is running twice (newline is added, then removed, then added again and then the loop continue) You can see it by edebugging pp-buffer on a simple alist like this: (defvar bar '((1 . "un") (2 . "deux") (3 . "trois") (4 . "quatre") (5 . "ci= nq") (6 . "six"))) =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmSCH24THHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvkw+fC/sFPgkM9RlaUeWC3RkW5rGlE8l+ebPb stAyBMFL4kON1t6p/htBv/9ljl2nBmMK0dszhFvM/m0UkWByBtmupQNBL3zke5Je cgqu4MMRqqKejXdAzAolF2uEQwTB2leb7AYTWzzRFjyAryfONaQcq4pGYJvsaqCC O1rwCkmzU8fnZR2Gc0eb8wJxBDoBExhAQVMU8JNJ4K5oTLAKrO/n3PVg6GrZ19Ni uKTJsV33udqPTIqFsjDdRN5cNQiDc63g2aaMobJ7Zahh9LPS5oFeRSCIOms/tDR1 BRj3FCziJP1IJvXTyeVfTskZ2626mTyLBilJkqtTedRbV9l3lfnKyBZpgfrWYUKH Grkt5hGWLPSyj6boyGr6LGpZw3e4xs/aFkcCoxRBCW9pTflW/z6Wzg4THz9xm4Il hTv/ZHxNT4xP3N0oArA/UiDdNH7Cu7CUAOi4jd4lFZs4XRlNUVWwfW+QD7bpftzV 2CRK08x3FiYjqrrK7dcvD86xYIdwk/onylE= =KTPc -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 18:35:20 2023 Received: (at 63861) by debbugs.gnu.org; 8 Jun 2023 22:35:20 +0000 Received: from localhost ([127.0.0.1]:57857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ODv-0008Mk-UN for submit@debbugs.gnu.org; Thu, 08 Jun 2023 18:35:20 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ODr-0008MU-Ku for 63861@debbugs.gnu.org; Thu, 08 Jun 2023 18:35:18 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CC3A2442828; Thu, 8 Jun 2023 18:35:09 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6DE1B442822; Thu, 8 Jun 2023 18:35:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686263707; bh=bCsQ14NO62KPSbj1VPVjQkBTZ1PvVa0r27Y3NTb+Ruk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mEUhdpXMMnPWp9oqjctZ2BrLpE+Dq4/UF1QlucWzCiY6tBgi7qLoIbwIxaAK9EWzy crAydcLdilc3x9l4cF+TbfOEr2bzwkr+CyXxYsYR87LINqkF/1OaAqTjdnzDZNB35N 6AvmAbUKFYJ2Efk0PEM2MpTTsi5uIcUjGPML0WgocWhXHk9b8bnDcwM2eawo5FFGZZ 9Zn/rPM8yJDtMFnfwp/pHKucWOxbpH+0mipfZSqjOeN71OJWD+5bYxpWCWjKnmznVZ HPLU1IcMj0GP+EaY8yDhKAAX3F2UEhtD133DtVKd2Z3F8mbhnJQwzmRIkYnM+BTeHD ah+kGIBW3xV7w== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4E2581207FF; Thu, 8 Jun 2023 18:35:07 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <87bkhpvm35.fsf@posteo.net> (Thierry Volpiatto's message of "Thu, 08 Jun 2023 18:08:18 +0000") Message-ID: References: <87edmnics1.fsf@posteo.net> <87bkhpvm35.fsf@posteo.net> Date: Thu, 08 Jun 2023 18:35:05 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.154 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I find these results (mine) quite odd: they suggest that my `pp-region` >> is *faster* than the old `pp-buffer` for `load-history` and `bookmark-alist` >> data, which I definitely did not expect (and don't know how to explain >> either). I've just redone my tests a bit differently, added `pp-emacs-lisp-code`, and also introduced a var to control whether to activate the `lisp-ppss` patch or not. I also fixed my `foo.el` file: its content was accidentally already pretty printed rather than being on a single line, which totally changes the behavior of `pp-region` and `pp-buffer`). For reference: % (cd ~/tmp; l foo.el test*.el) -rw------- 1 monnier monnier 1125154 8 jun 11:20 test-load-history.el -rw------- 1 monnier monnier 163258 8 jun 11:20 test-bookmark-alist.el -rw-r--r-- 1 monnier monnier 77101 8 jun 17:20 foo.el % Here's the code I used to run the test: for f in ~/tmp/foo.el ~/tmp/test-bookmark-alist.el ~/tmp/test-load-history.el; do for ppss in nil t; do for v in '(pp-buffer)' '(pp-region (point-min) (point-max))' '(tv/pp-region (point-min) (point-max))' '(let ((s (read (current-buffer)))) (erase-buffer) (pp-emacs-lisp-code s))'; do src/emacs -Q --batch -l ~/tmp/describe-variable --eval "(with-temp-buffer (emacs-lisp-mode) (insert-file-contents \"$f\") (setq pp-buffer-use-pp-region nil lisp--faster-ppss $ppss) (message \"%S %S %S %S\" (file-name-nondirectory \"$f\") (benchmark-run $v) '$v '$ppss))"&; done; done; done So, by file, from fastest to slowest: foo.el (0.859482743 0 0.0) (pp-buffer) t foo.el (0.890402623 0 0.0) (pp-buffer) nil foo.el (4.62344853 4 1.7225397670000002) (tv/pp-region (point-min) (point-max)) t foo.el (4.687414465 4 1.7116580980000002) (tv/pp-region (point-min) (point-max)) nil foo.el (7.932661181 1 0.3435169600000001) (pp-region (point-min) (point-max)) t foo.el (196.183345212 1 0.618591124) (pp-region (point-min) (point-max)) nil foo.el (2997.739238575 505 105.82851685700001) (let ((s (read (current-buffer)))) (erase-buffer) (pp-emacs-lisp-code s)) t Here we see that my `pp-region` code is slower than `pp-buffer` by a factor ~10x: I'm not very happy about it, but this `foo.el` file was selected because it was the worst case I had come across (tho that was before I found the `lisp-ppss` patch). The last element in each line is whether we activated the `lisp-ppss` patch. As we can see here, the `lisp-ppss` patch makes an enormous difference (~24x) for my code, but not for `pp-buffer` (because it relies on `lisp-indent-region` rather than `lisp-indent-line`) and not for `tv/pp-region` either (because it doesn't indent at all). We also see that `pp-emacs-lisp-code` is *much* slower. I don't include other results for this function in this email because they're still running :-) test-bookmark-alist.el (13.237991019999999 6 2.403892035) (tv/pp-region (point-min) (point-max)) nil test-bookmark-alist.el (14.853056353 6 2.705511935) (tv/pp-region (point-min) (point-max)) t test-bookmark-alist.el (28.059658418 5 2.005039257) (pp-region (point-min) (point-max)) t test-bookmark-alist.el (180.390204026 5 2.1182066760000002) (pp-region (point-min) (point-max)) nil test-bookmark-alist.el (265.95429676599997 10 4.445954908) (pp-buffer) t test-bookmark-alist.el (268.975666886 10 3.6774180120000004) (pp-buffer) nil Here we see that my `pp-region` code can be faster (even significantly so) than `pp-buffer`. I'm not sure why, but I'll take the win :-) We also see that the faster `lisp-ppss` again makes an important difference in the performance of `pp-region` (~8x), tho the effect is not as drastic as in the case of `foo.el`. test-load-history.el (235.134082197 8 4.440112806999999) (tv/pp-region (point-min) (point-max)) nil test-load-history.el (235.873981253 8 4.416064476) (tv/pp-region (point-min) (point-max)) t test-load-history.el (506.770548196 31 9.706665932) (pp-region (point-min) (point-max)) t test-load-history.el (701.991875274 43 12.390212449) (pp-buffer) t test-load-history.el (710.843618646 43 12.156289354) (pp-buffer) nil test-load-history.el (1419.268184021 36 9.260999640000001) (pp-region (point-min) (point-max)) nil Here again, we see that `pp-region` is competitive with `pp-buffer` and the `lisp-ppss` patch speeds it up significantly (~3x). Another thing we see in those tests is that `pp-region` (with the `lisp-ppss` patch) is ~2x slower than `tv/pp-region`, whereas the performance differential with `pp-buffer` varies a lot more. Also if we compare the time it takes to the size of the file, we see: 77101B / 7.932661181s = 9719 B/s 163258B / 28.059658418s = 5818 B/s 1125154B / 506.770548196s = 2220 B/s `pp-region`s performance is not quite linear in the size of the file :-( Interestingly, the same holds for `tv/pp-region`: 77101B / 4.62344853s = 16676 B/s 163258B / 13.237991019s = 12332 B/s 1125154B / 235.134082197s = 4785 B/s even though it works in a fundamentally very different way (which, to my naive eye should result in a linear performance), so maybe the slowdown here is due to something external (such as the fact that various operations on buffers get slower as the buffer gets bigger). > hmm, don't know, I ran pp-buffer with M-: from the test-load-history.el or the > test-bookmark-alist.el buffer. May be using emacs --batch makes a > difference? I don't see any significant performance difference between batch and non-batch :-( > is the data really printed in such case? Yes, definitely. > More or less the code using pp-region takes between 42 to 48s and the one > with old pp-buffer around 6s. I wonder why we see such wildly different performance. In my tests on your `test-bookmark-alist.el` I basically see the reverse ratio! > Also sorry about your last patch I tested it too fast, it is indeed > slightly faster, but not much: 42 vs 46s. This is also perplexing. In my tests, the patch has a very significant impact on the performance of `pp-region`. Are you sure the patch is used (`lisp-mode.el` is preloaded, so you need to re-dump Emacs, or otherwise manually force-reload `lisp-mode.elc` into your Emacs session)? FWIW, I'm running my tests on Emacs's `master` branch with the native ELisp compiler enabled (tho I don't see much difference in performance on these tests when running my other Emacs build without the native compiler) on an i386 Debian testing system. >> And do I understand correctly that `tv/pp-region` does not indent its >> output? > No, it does indent, see function tv/pp which use pp-to-string which use pp-buffer > and pp-buffer indent the whole sexp at the end. AFAICT `tv/pp` uses `pp-to-string` only on "atomic" values (i.e. not lists, vectors, or hash-tables), so there's usually not much to indent in there. What I see in the output after calling `tv/pp-region` are non-indented lists. >> What was the reason for this choice? > Because indentation is done at the end by pp-buffer. When I use `describe-variable` with your code, the printed value is indeed indented, but that code uses only `pp-buffer` and not `tv/pp-region` (i.e. `tv/describe-variable` does not call `tv/pp-region`, neither directly nor indirectly). > PS (unrelated to pp-region): About the old pp-buffer, there is > a difficult to find bug where the same operation is running twice > (newline is added, then removed, then added again and then the loop > continue) > > You can see it by edebugging pp-buffer on a simple alist like this: > > (defvar bar '((1 . "un") (2 . "deux") (3 . "trois") (4 . "quatre") (5 . "cinq") (6 . "six"))) That might be part of the poor performance we see on `test-bookmark-alist.el`? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 20:07:40 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 00:07:40 +0000 Received: from localhost ([127.0.0.1]:57892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7PfI-0002Hs-48 for submit@debbugs.gnu.org; Thu, 08 Jun 2023 20:07:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7PfD-0002Hb-CT for 63861@debbugs.gnu.org; Thu, 08 Jun 2023 20:07:39 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BF3E9100054; Thu, 8 Jun 2023 20:07:29 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AD16E10001C; Thu, 8 Jun 2023 20:07:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686269248; bh=AVrIAWJUiv+D0xOgiWywKasZjqoAeGGQPPKR+zlP41s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h7jhQUE4vAk/HaSLEC5+JsOBk+zsfS8kRwtdINobdTyS9qJZNBeNmyIPSzj3q916j Cu3QAa0eoxl5Sx52HrmDvt+Hn9ZFIaFrlxg+E3ICSR94btgkbB5MyRJZf4tN7zCLAp li9gO2RRa48l8r1IDFD7Bf8nprK+gjtcrPhk6wz30yp7Y6gHww6N59+PvopkYkoPPd 5Cy0XhJgGI0XG7t0yAitMEe+R1iBzX+EbDdL8eIKIhtFlr0qgKErJgZEJnouoYkzfb FW3lf1eOdWswCKuVou3kBCXJN7LbBeHitrlTWdeV8ZGQx46fVnTFAZ30jVW3jldIvG rnxF+HHs5A2zQ== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C8071200D7; Thu, 8 Jun 2023 20:07:28 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier's message of "Thu, 08 Jun 2023 18:35:05 -0400") Message-ID: References: <87edmnics1.fsf@posteo.net> <87bkhpvm35.fsf@posteo.net> Date: Thu, 08 Jun 2023 20:07:26 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > `pp-region`s performance is not quite linear in the size of the file :-( > Interestingly, the same holds for `tv/pp-region`: > > 77101B / 4.62344853s = 16676 B/s > 163258B / 13.237991019s = 12332 B/s > 1125154B / 235.134082197s = 4785 B/s > > even though it works in a fundamentally very different way (which, to > my naive eye should result in a linear performance), so maybe the > slowdown here is due to something external (such as the fact that > various operations on buffers get slower as the buffer gets bigger). I think I figured it out: the larger files happen to have relatively more (smaller) "objects". So it is more or less linear, just not in the size in bytes but in the size in number of objects. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 23:21:51 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 03:21:51 +0000 Received: from localhost ([127.0.0.1]:57975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ShD-0007S8-19 for submit@debbugs.gnu.org; Thu, 08 Jun 2023 23:21:51 -0400 Received: from mail-oo1-f67.google.com ([209.85.161.67]:48264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ShA-0007Rt-Jf for 63861@debbugs.gnu.org; Thu, 08 Jun 2023 23:21:49 -0400 Received: by mail-oo1-f67.google.com with SMTP id 006d021491bc7-55b5472ab85so113590eaf.0 for <63861@debbugs.gnu.org>; Thu, 08 Jun 2023 20:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686280903; x=1688872903; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zBSTVL46bUMnxqaP4/MKs6coaXTphlVEWj1YwxFEPDk=; b=AETVqjqJrhoIqsVrcPYR9mmtrYSd/mC5RQHU+LQiF9EZGDKu9q5VYl846HBz0ulc6a 3XwQY4RWvY+tW+ne4+xiktLg8SFB+uEmqmqljoZurhNpTQpdJLw4mfhg7pg+opKVNcbe DmRQnkUj4vVo70qxEVf4sMIiHjYBtCGvkowBwLuQuhsTtIaQXOSjfmZo7ca3CZWR6Ow0 MXlvKjUcLuipTF3DY1+Gq1KSLfQ2zxtZT0RPUzmXaiqhRs4pBCbIdSpK/DGP515tamcJ 3HkeqzUq4zl7STseotlZnWOpNV1OVcjgXQaoei7oSQKduLabd+yEkwwMOR9nXhT1uOse S8cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686280903; x=1688872903; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zBSTVL46bUMnxqaP4/MKs6coaXTphlVEWj1YwxFEPDk=; b=Gxx40RDIIyTjPBw1LHH4E9eHOJKJDkQ1DKWCI4wC1oEwtNHh4mt2i62pmTP4w9eRhq DWI7zaMsx0/KmLIi6je5axcqhBXWwPxpFVPbxqr4aw9YuzwujzwkftVHVMQYGR7NC3V/ 4qlBTO22Z+MB2qVDelix9kQsYti+f6wPrASJu39mSGmuo9AemttOxXhOoX1Iny0T783j g5/fNCWceniGgVaOakCVmQfYGyzd17kRKeVAMQKuyDgGDqiX2YXMJ491AUroCblq/fwL tqqjmjB/Jeo4YCCB9c/3fR2F85fxUQMUioyHMVVzuWq/KI4BP74MiGB93IzQ+Hx+w8Ix nqcA== X-Gm-Message-State: AC+VfDzRDpHoMgMNKNeCmPULCIZkCLPRenEwnUScBuraucdMvmL8/ePe Ux9hMgBRim3NYlyk0fgb8xk= X-Google-Smtp-Source: ACHHUZ6vI5SRjcqEjySSh5ceMVfKDceZ3qlGTbBqmxcZ1P06a57m6eTuoCS3aqhx6UGzqtMpbHVwvw== X-Received: by 2002:a05:6359:a26:b0:129:c25e:1cb0 with SMTP id el38-20020a0563590a2600b00129c25e1cb0mr166389rwb.30.1686280902701; Thu, 08 Jun 2023 20:21:42 -0700 (PDT) Received: from localhost ([49.205.80.56]) by smtp.gmail.com with ESMTPSA id z24-20020a63c058000000b0051ba9d772f9sm1919176pgi.59.2023.06.08.20.21.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jun 2023 20:21:42 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier via's message of "Wed, 07 Jun 2023 11:48:32 -0400") References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> Date: Fri, 09 Jun 2023 08:51:39 +0530 Message-ID: <87cz25b9rw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=AA=E0=AF=81=E0=AE=A4=E0=AE=A9=E0=AF=8D =E0=AE=9C=E0=AF=82=E0=AE=A9= =E0=AF=8D 07, 2023] Stefan Monnier via "Bug reports for GNU Emacs, the Swis= s army knife of text editors" wrote: >> BTW, how does this compare to the newly added `pp-emacs-lisp-code`? > > Very good question. I had completely missed that (and its `pp-use-max-wi= dth`). > This points to a host of integration issues between my code and the > existing code. I'll have to take a deeper look. >From what I remember, pp simply switches to use pp-emacs-lisp-code when the relevant user option is set. The poor performance of pp-emacs-lisp-code made me wish pp-use-max-width was only obeyed by user facing commands like pp-eval-expression & friends. >> It was still rough around the edges the last time I set >> `pp-use-max-width' non-nil. It is also quite a lot slower than the >> old path. > > My new code is expected to be slower than the "normal" pretty-printer, > but barring performance bugs in `lisp-indent-line` (such as the one > fixed by the patch I just sent to Thierry) it should be approximately > a constant factor slower. > > AFAICT the performance of `pp-emacs-lisp-code` can be more problematic. Hopefully, the constant factor is quite small. pp-emacs-lisp-code took a lot of time to print my modest bookmark alist (28 entries) and for the longest time I thought some other code in Emacs has gone awry. > Beside performance, I guess the behavior of the two should be > somewhat similar, tho I also see that `pp-emacs-lisp-code` pays > attention to the Edebug and `doc-string-elt` info, so it may give > slightly more refined info. I haven't tested your pretty printer but pp-emacs-lisp-code could give some really bizarre results for lisp data. Unfortunately, I don't have any examples handy to illustrate what I mean by bizarre though.=20 > Another difference is that `pp-emacs-lisp-code` starts with an S-exp > object, whereas my code starts with a region (i.e. an sexp that's > already been printed). > > > Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 01:50:28 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 05:50:28 +0000 Received: from localhost ([127.0.0.1]:58180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7V11-0003S6-MA for submit@debbugs.gnu.org; Fri, 09 Jun 2023 01:50:28 -0400 Received: from mout01.posteo.de ([185.67.36.65]:59149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7V0v-0003Rf-DX for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 01:50:25 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B9297240027 for <63861@debbugs.gnu.org>; Fri, 9 Jun 2023 07:50:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686289813; bh=33UgKrqOPZMLxRVGjw4vLWW3hvTpCGHol0iUUYNEghI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=qyrgmEpBhc1wkerCLU9R/GhzRjgLZSXR4PUia+Fftg0DhMfQ4l4u3GASZkcq/Jidt l0U2uIVLcIpUSSJEe8U8To5gKe2hGlfLwW6KAU20nzslT7+h8NHW9rpN4nt8jXbJKR HI3Cxm+pj33p9+jClDzwnx+V6nvkEDEP9geyXEFFil9oR0vXCUsnGX8cPEHRNDPgMU XUjHPgipSYn8zTrnWnVTp93hL7kgYfHzH3Hh8aO+paF3s1+MeKNGOfZFQF91vX/cUG xxyT7130/8AgXNn5LTBy/ZN6OVE7z+jcpj1twKsNuPpXp/w/fqvZGhNJMj8N8wB8Gp 8hQrqEzOiEE0w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QcqtD52cnz6tsf; Fri, 9 Jun 2023 07:50:12 +0200 (CEST) References: <87edmnics1.fsf@posteo.net> <87bkhpvm35.fsf@posteo.net> From: Thierry Volpiatto To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code Date: Fri, 09 Jun 2023 05:22:31 +0000 In-reply-to: Message-ID: <878rctkwvh.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Stefan Monnier writes: >>> I find these results (mine) quite odd: they suggest that my `pp-region` >>> is *faster* than the old `pp-buffer` for `load-history` and `bookmark-a= list` >>> data, which I definitely did not expect (and don't know how to explain >>> either). > > I've just redone my tests a bit differently, added `pp-emacs-lisp-code`, > and also introduced a var to control whether to activate the `lisp-ppss` > patch or not. I also fixed my `foo.el` file: its content was > accidentally already pretty printed rather than being on a single line, > which totally changes the behavior of `pp-region` and `pp-buffer`). > > For reference: > > % (cd ~/tmp; l foo.el test*.el) > -rw------- 1 monnier monnier 1125154 8 jun 11:20 test-load-history.el > -rw------- 1 monnier monnier 163258 8 jun 11:20 test-bookmark-alist= .el > -rw-r--r-- 1 monnier monnier 77101 8 jun 17:20 foo.el > % > > Here's the code I used to run the test: > > for f in ~/tmp/foo.el ~/tmp/test-bookmark-alist.el ~/tmp/test-load-hi= story.el; do for ppss in nil t; do for v in '(pp-buffer)' '(pp-region (poin= t-min) (point-max))' '(tv/pp-region (point-min) (point-max))' '(let ((s (re= ad (current-buffer)))) (erase-buffer) (pp-emacs-lisp-code s))'; do src/emac= s -Q --batch -l ~/tmp/describe-variable --eval "(with-temp-buffer (emacs-li= sp-mode) (insert-file-contents \"$f\") (setq pp-buffer-use-pp-region nil li= sp--faster-ppss $ppss) (message \"%S %S %S %S\" (file-name-nondirectory \"$= f\") (benchmark-run $v) '$v '$ppss))"&; done; done; done > > So, by file, from fastest to slowest: > > foo.el (0.859482743 0 0.0) (pp-buffer) t > foo.el (0.890402623 0 0.0) (pp-buffer) nil > foo.el (4.62344853 4 1.7225397670000002) (tv/pp-region (point-min) (p= oint-max)) t > foo.el (4.687414465 4 1.7116580980000002) (tv/pp-region (point-min) (= point-max)) nil > foo.el (7.932661181 1 0.3435169600000001) (pp-region (point-min) (poi= nt-max)) t > foo.el (196.183345212 1 0.618591124) (pp-region (point-min) (point-ma= x)) nil > foo.el (2997.739238575 505 105.82851685700001) (let ((s (read (curren= t-buffer)))) (erase-buffer) (pp-emacs-lisp-code s)) t > > Here we see that my `pp-region` code is slower than `pp-buffer` by > a factor ~10x: I'm not very happy about it, but this `foo.el` file was > selected because it was the worst case I had come across (tho that was > before I found the `lisp-ppss` patch). > > The last element in each line is whether we activated the `lisp-ppss` > patch. As we can see here, the `lisp-ppss` patch makes an enormous > difference (~24x) for my code, but not for `pp-buffer` (because it > relies on `lisp-indent-region` rather than `lisp-indent-line`) and not > for `tv/pp-region` either (because it doesn't indent at all). > > We also see that `pp-emacs-lisp-code` is *much* slower. I don't include > other results for this function in this email because they're still > running :-) > > test-bookmark-alist.el (13.237991019999999 6 2.403892035) (tv/pp-regi= on (point-min) (point-max)) nil > test-bookmark-alist.el (14.853056353 6 2.705511935) (tv/pp-region (po= int-min) (point-max)) t > test-bookmark-alist.el (28.059658418 5 2.005039257) (pp-region (point= -min) (point-max)) t > test-bookmark-alist.el (180.390204026 5 2.1182066760000002) (pp-regio= n (point-min) (point-max)) nil > test-bookmark-alist.el (265.95429676599997 10 4.445954908) (pp-buffer= ) t > test-bookmark-alist.el (268.975666886 10 3.6774180120000004) (pp-buff= er) nil > > Here we see that my `pp-region` code can be faster (even significantly > so) than `pp-buffer`. I'm not sure why, but I'll take the win :-) > We also see that the faster `lisp-ppss` again makes an important > difference in the performance of `pp-region` (~8x), tho the effect is > not as drastic as in the case of `foo.el`. > > test-load-history.el (235.134082197 8 4.440112806999999) (tv/pp-regio= n (point-min) (point-max)) nil > test-load-history.el (235.873981253 8 4.416064476) (tv/pp-region (poi= nt-min) (point-max)) t > test-load-history.el (506.770548196 31 9.706665932) (pp-region (point= -min) (point-max)) t > test-load-history.el (701.991875274 43 12.390212449) (pp-buffer) t > test-load-history.el (710.843618646 43 12.156289354) (pp-buffer) nil > test-load-history.el (1419.268184021 36 9.260999640000001) (pp-region= (point-min) (point-max)) nil > > Here again, we see that `pp-region` is competitive with `pp-buffer` and > the `lisp-ppss` patch speeds it up significantly (~3x). > > Another thing we see in those tests is that `pp-region` (with the > `lisp-ppss` patch) is ~2x slower than `tv/pp-region`, whereas the > performance differential with `pp-buffer` varies a lot more. Also if we > compare the time it takes to the size of the file, we see: > > 77101B / 7.932661181s =3D 9719 B/s > 163258B / 28.059658418s =3D 5818 B/s > 1125154B / 506.770548196s =3D 2220 B/s > > `pp-region`s performance is not quite linear in the size of the file :-( > Interestingly, the same holds for `tv/pp-region`: > > 77101B / 4.62344853s =3D 16676 B/s > 163258B / 13.237991019s =3D 12332 B/s > 1125154B / 235.134082197s =3D 4785 B/s > > even though it works in a fundamentally very different way (which, to > my naive eye should result in a linear performance), so maybe the > slowdown here is due to something external (such as the fact that > various operations on buffers get slower as the buffer gets bigger). > >> hmm, don't know, I ran pp-buffer with M-: from the test-load-history.el = or the >> test-bookmark-alist.el buffer. May be using emacs --batch makes a >> difference? > > I don't see any significant performance difference between batch and > non-batch :-( > >> is the data really printed in such case? > > Yes, definitely. > >> More or less the code using pp-region takes between 42 to 48s and the one >> with old pp-buffer around 6s. > > I wonder why we see such wildly different performance. In my tests on > your `test-bookmark-alist.el` I basically see the reverse ratio! > >> Also sorry about your last patch I tested it too fast, it is indeed >> slightly faster, but not much: 42 vs 46s. > > This is also perplexing. In my tests, the patch has a very significant > impact on the performance of `pp-region`. > Are you sure the patch is used (`lisp-mode.el` is preloaded, so you need > to re-dump Emacs, or otherwise manually force-reload `lisp-mode.elc` > into your Emacs session)? No, I just C-M-x lisp-ppss, I will try today to recompile an emacs with your patchs applied and see if it makes a difference. I also use emacs-28, will try with 30. > FWIW, I'm running my tests on Emacs's `master` branch with the native > ELisp compiler enabled (tho I don't see much difference in performance > on these tests when running my other Emacs build without the native > compiler) on an i386 Debian testing system. I don't use native compilation. >>> And do I understand correctly that `tv/pp-region` does not indent its >>> output? >> No, it does indent, see function tv/pp which use pp-to-string which use = pp-buffer >> and pp-buffer indent the whole sexp at the end. > > AFAICT `tv/pp` uses `pp-to-string` only on "atomic" values (i.e. not > lists, vectors, or hash-tables), so there's usually not much to indent in= there. > What I see in the output after calling `tv/pp-region` are non-indented li= sts. Hmm maybe, seems it was similar to pp-buffer but perhaps I didn't look carefully. >>> What was the reason for this choice? >> Because indentation is done at the end by pp-buffer. > > When I use `describe-variable` with your code, the printed value is > indeed indented, but that code uses only `pp-buffer` and not > `tv/pp-region` (i.e. `tv/describe-variable` does not call > `tv/pp-region`, neither directly nor indirectly). Yes you have to run manually tv/pp-value-in-help when you need to read the value of a variable (unless it is a small var). >> PS (unrelated to pp-region): About the old pp-buffer, there is >> a difficult to find bug where the same operation is running twice >> (newline is added, then removed, then added again and then the loop >> continue) >> >> You can see it by edebugging pp-buffer on a simple alist like this: >> >> (defvar bar '((1 . "un") (2 . "deux") (3 . "trois") (4 . "quatre") (5 . = "cinq") (6 . "six"))) > > That might be part of the poor performance we see on > `test-bookmark-alist.el`? Not sure it makes a big difference but for sure it is slower to defeat the operation done in previous turn and do it again. > > Stefan =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmSCvZITHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk1fjC/wKGtKtEctIoIOhvTh5fauCQymCkEu3 gvxDZPmEMTnhui1u77KHOdjR/lYQKzknNRLHz/i7iWtTHg01H2Je/QlFOjddnaja VbXq4ZMsPiyqkp/9GjHn9kz3Fmmg6Z8qx6AAeq17ZUH9eE1nKM9hyJDsru9G3/OZ ilagbYDjRIkTTbUsYj4h1emR+nRiiWykgeKvvcupXiizeiPeFvQZsyqmPxar8vW/ K7dBElSDGhN1SofSU+Q7z/cA6qvadd1Ms81tzvTSkfs0BaBpgLd4+SPonuuCLRVy MmeSSJehxGItsmmBJq8cZGXG0lk06gsZ0K3AlwUdesxhUyPoUSojcPKVtdO4jisB i1aWKFojbacesLbwVssUBbvVFGX0dv8t4M3L8XJbyjnbV+LVh3b2djNi7L9NW19n cxqy+S1E30jaoC1qu6azEET/7sHYshQYMnrfbH6+XtpW4iKvPwYgHJIDvf5nF0+f Br3qF4C7i8wRFHLmuNRxZuHAGjnuDsaY/FQ= =xvmp -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 10:59:29 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 14:59:29 +0000 Received: from localhost ([127.0.0.1]:60030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7daK-0004bi-Sc for submit@debbugs.gnu.org; Fri, 09 Jun 2023 10:59:29 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7daI-0004bS-FX for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 10:59:27 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E410A80292; Fri, 9 Jun 2023 10:59:20 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B0C0980262; Fri, 9 Jun 2023 10:59:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686322759; bh=CRT6RgnC1gVjSMgbNLGzv0dbIG8bo64coTSaoY8dafU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QY9JIRG4LHmasaETa1GrfMcib+V1wz788JdTKJD2A/USRATDBausUnXqaa6gtQJJ2 ZMzcf///ZNKcOl5mkpTVKgkg46EJ8m3whHSohfPxjSjrPS0a8MeffUdQ52MvJLfGr3 bRXSr0Y3uC39jRU9n3IzVCu6MWgZNiHAXI2sKM6gm10Icbq4vElomAtgaN0XzF1Sjp 1CuDZjirUpuI75y+ncKLxOFwbvUoIDH0ZfypXfRWT2q6K80SY1nNuhz0n0GO8pHbUE HDWRZ6lnmoRuniLeujEcr35egpX0OjaNjHWWKBX1cRWDWo40NKunkuh3XEpRsmRaQy 4OTJOJANRYSdw== Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 88B501204E7; Fri, 9 Jun 2023 10:59:19 -0400 (EDT) From: Stefan Monnier To: Visuwesh Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <87cz25b9rw.fsf@gmail.com> (Visuwesh's message of "Fri, 09 Jun 2023 08:51:39 +0530") Message-ID: References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> <87cz25b9rw.fsf@gmail.com> Date: Fri, 09 Jun 2023 10:59:18 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.071 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> BTW, how does this compare to the newly added `pp-emacs-lisp-code`? >> Very good question. I had completely missed that (and its `pp-use-max-width`). >> This points to a host of integration issues between my code and the >> existing code. I'll have to take a deeper look. > From what I remember, pp simply switches to use pp-emacs-lisp-code when > the relevant user option is set. Yup, similar to my patch, except my patch hooks into `pp-buffer`, i.e. a lower level which hence affects more uses. > The poor performance of pp-emacs-lisp-code made me wish > pp-use-max-width was only obeyed by user facing commands like > pp-eval-expression & friends. My tests yesterday suggest `pp-emacs-lisp-code` is simply too slow to be used except when we know beforehand that the sexp to be printed is small. And I can't think of a single piece of code where that's the case. I suspect part of the code can be improved to bring the computational complexity of the code closer to linear, but until someone does that, I think `pp-use-max-width` is just unusable. Instead we could/should provide ways for the user to interactively call a command to reformat something using `pp-emacs-lisp-code`. Or maybe change the code so `pp-emacs-lisp-code` is used only when the total printed size is below a certain threshold. >> My new code is expected to be slower than the "normal" pretty-printer, >> but barring performance bugs in `lisp-indent-line` (such as the one >> fixed by the patch I just sent to Thierry) it should be approximately >> a constant factor slower. >> AFAICT the performance of `pp-emacs-lisp-code` can be more problematic. > Hopefully, the constant factor is quite small. In my tests, 10x seems to be the "worst case slowdown" of `pp-region`. On some of the tests, it's actually faster, sometimes significantly so (presumably due to some non-linear complexity in some parts of `pp-buffer`). > pp-emacs-lisp-code took a lot of time to print my modest bookmark > alist (28 entries) and for the longest time I thought some other code > in Emacs has gone awry. AFAICT it suffers from a pretty bad complexity. > I haven't tested your pretty printer but pp-emacs-lisp-code could give > some really bizarre results for lisp data. I haven't seen "really bizarre results" with `pp-region` yet, but I wouldn't be surprised if that can happen: I've been playing with various pretty-printing alternatives over the years and they all seem to suffer from weird behaviors occasionally, except for those that insert too many line breaks. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 11:04:38 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 15:04:38 +0000 Received: from localhost ([127.0.0.1]:60073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7dfK-0004nk-6u for submit@debbugs.gnu.org; Fri, 09 Jun 2023 11:04:38 -0400 Received: from mout01.posteo.de ([185.67.36.65]:40735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7dfH-0004nW-8x for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 11:04:36 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9B0CA240029 for <63861@debbugs.gnu.org>; Fri, 9 Jun 2023 17:04:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1686323069; bh=PiUqxgsZ/6O5eyoUxecsa4+cYNANYqxopaSkDg+mq0c=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Iv3ZV52rEh6KX2xF3VJskWQoRaiu+k0QpCD9c2R5zva7nq3d41wO/FsUour/rCA+g TTRTVa00p+vNA+tHJa106ewYf+uRsMns8+O6k//T1qmZ3ZIx8N8UFDkTBHr5hnDpDk A1l8X1OajBr3gtsFOnWZX9pSLvjCb4djeQbmSHmC3bKe8L/XhtosyV1BG9YzXgPr/T BPhMZePRP9znYGmRTOEljj5wcD6RnfxTkHxqwlA18sRuOhF0rWiaBFFQcDSHgZhWvL z16VnKZH5uDDn4SLLJPsx8axN/JZsvqAwar4jzAaWz9w84ugGIHU8ctYPQVMxjT1ps pVfmOwcKSqjKg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qd49n0R0lz9rxG; Fri, 9 Jun 2023 17:04:28 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> <87cz25b9rw.fsf@gmail.com> Date: Fri, 09 Jun 2023 15:09:15 +0000 Message-ID: <871qikvfj8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org, Visuwesh 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 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > I haven't seen "really bizarre results" with `pp-region` yet, but > I wouldn't be surprised if that can happen: I've been playing with > various pretty-printing alternatives over the years and they all seem to > suffer from weird behaviors occasionally, except for those that insert > too many line breaks. If algorithms that insert "too many" line breaks can be reasonably fast, can they be executed first followed by merging the excessive lines back? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 11:26:26 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 15:26:26 +0000 Received: from localhost ([127.0.0.1]:60129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7e0Q-0005PG-6A for submit@debbugs.gnu.org; Fri, 09 Jun 2023 11:26:26 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7e0O-0005Oy-Kn for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 11:26:25 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5AC124428FD; Fri, 9 Jun 2023 11:26:19 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 20FC84428F3; Fri, 9 Jun 2023 11:26:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686324378; bh=eboyan05Pgx+u/6iiCgrksFBXF+3xQZw/zHY36kblWc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jqQYjSZ12Jm00pwyG5BXTRQzdwGWstVBowrwI3rNCs721HqJCPVdET0sSmTOylfoy NcLdc74SMkv7j83Xj2WAeBm8ItqwoMPFyyVYxFZ3AOSqPjDeqpRAoCvGINj/MFMVIc mc16zjS0RDtb87FlENnGLP/JNLnSPJ0xv7t7dESI1NQWBDUik1OBHBhWk4I94Y/zHL sOOkTWfoKf0nXAIi/8SWVlb+q5E7lyy+pVPO6r9TbyQG3iYX0Ce1UwPCvLYM4M2TL5 dTV4K0AorjpgKXPY7j4dKfKS4jAj4PisqH/MPmQ/JIeEc73QR2lUk0u4zO/R70k+0V XqP3N7BM1czuQ== Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EDFC1120513; Fri, 9 Jun 2023 11:26:17 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <871qikvfj8.fsf@localhost> (Ihor Radchenko's message of "Fri, 09 Jun 2023 15:09:15 +0000") Message-ID: References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> <87cz25b9rw.fsf@gmail.com> <871qikvfj8.fsf@localhost> Date: Fri, 09 Jun 2023 11:26:16 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.011 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org, Visuwesh 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 (---) >> I haven't seen "really bizarre results" with `pp-region` yet, but >> I wouldn't be surprised if that can happen: I've been playing with >> various pretty-printing alternatives over the years and they all seem to >> suffer from weird behaviors occasionally, except for those that insert >> too many line breaks. > If algorithms that insert "too many" line breaks can be reasonably fast, > can they be executed first followed by merging the excessive lines back? Speed is definitely an issue in general, but the "behavior" I was alluding to above was not the performance but the end result (and I think the same was true for Visuwesh's comment). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 11:59:28 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 15:59:28 +0000 Received: from localhost ([127.0.0.1]:60190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7eWN-0000NZ-T2 for submit@debbugs.gnu.org; Fri, 09 Jun 2023 11:59:28 -0400 Received: from mail-pj1-f65.google.com ([209.85.216.65]:58454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7eWM-0000NN-DL for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 11:59:26 -0400 Received: by mail-pj1-f65.google.com with SMTP id 98e67ed59e1d1-256531ad335so830976a91.0 for <63861@debbugs.gnu.org>; Fri, 09 Jun 2023 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686326360; x=1688918360; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hx0qmyxVdBJSMBiq578o2VxJuQo8CAncy8l8gWwCk3Q=; b=kta2HoWuAHGlF8mRWbvnhKndPdhvbXAZQ43j7cioS0YAZlrb7ihm+2cix0CvzpeqsM lbm6CjsmLFApFhuVcw7sJFf24Cfo4cYOK9hl7LnlP5rJo7vqd7HB3FzKZ9g5ITTkH9g9 mIehd+A0l9MFNYmE7SeypD6GgPLuar4/MbCNu/NwUKJidecP3POLttbodYvOYyA3wCP6 eTK9deB/YeWD6OK61m14drc7dUSw9bQPenj7DHOBHM5urGDWb6HzVQ8NEWJH9Y7rAphh 1FKt0q1sHyrjOx2f45FCIr91Zly6++DPaF4b4LJU5rWvLERuslcDp2GrnIVO4iBKtOw9 NMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686326360; x=1688918360; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hx0qmyxVdBJSMBiq578o2VxJuQo8CAncy8l8gWwCk3Q=; b=INxcQuJ0k5NVQ24MxJSJ4JUaV0ULSc8clDFFW+rM5lHbgHw50zp+BTwBvMeDqygVKB EnEV+fLLXvfggg7+Z2UpacOPZhHsGkiSOCDR+ReAxNEDy1eLWnCdApv87gCahyPo2/3S NnQrWD5ERqTByfxTRJAayn9cYLdXB9jheTpJx4LjBpuhfBb2n8KeuSsuuNjVX+32rS7+ tg9XDjhjKGU62tQ67RDF3MSmtiIMtheikhGqLZF9MUX4aX1RCc09xIq+F/4lY4iaQkOt SBmLkYIZGeeIAsxj58PaJESn4xzpy4wsTJkVtuYoA+9GU4kuNc5FAuHlnNx+iO6mZPey ctVw== X-Gm-Message-State: AC+VfDxSsnfEgsJ2xOey1DX3blHESGlGUXW1PZD1YA9pvn159zIswOMh 97/w+Nskhoa7tefzvRBi0Tg= X-Google-Smtp-Source: ACHHUZ4flz4pprfSeLVysZd2ih747iA16kjaj+MaOwbNvn/fHLBS3+jqkGvrhBcCw9oUPoSUx62YeQ== X-Received: by 2002:a17:90a:1999:b0:253:3a2c:df52 with SMTP id 25-20020a17090a199900b002533a2cdf52mr1620566pji.39.1686326360272; Fri, 09 Jun 2023 08:59:20 -0700 (PDT) Received: from localhost ([49.205.80.56]) by smtp.gmail.com with ESMTPSA id q66-20020a17090a1b4800b002533ce5b261sm5208595pjq.10.2023.06.09.08.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jun 2023 08:59:19 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier's message of "Fri, 09 Jun 2023 11:26:16 -0400") References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> <87cz25b9rw.fsf@gmail.com> <871qikvfj8.fsf@localhost> Date: Fri, 09 Jun 2023 21:29:18 +0530 Message-ID: <87ttvgaap5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63861 Cc: Ihor Radchenko , 63861@debbugs.gnu.org, Eli Zaretskii 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 (-) [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=9C=E0=AF=82= =E0=AE=A9=E0=AF=8D 09, 2023] Stefan Monnier wrote: > Speed is definitely an issue in general, but the "behavior" I was > alluding to above was not the performance but the end result (and > I think the same was true for Visuwesh's comment). Indeed, I was talking about the end result. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 09 12:04:54 2023 Received: (at 63861) by debbugs.gnu.org; 9 Jun 2023 16:04:54 +0000 Received: from localhost ([127.0.0.1]:60199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ebe-0000XE-1q for submit@debbugs.gnu.org; Fri, 09 Jun 2023 12:04:54 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:49558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7ebc-0000X1-2U for 63861@debbugs.gnu.org; Fri, 09 Jun 2023 12:04:52 -0400 Received: by mail-pf1-f196.google.com with SMTP id d2e1a72fcca58-652dd220d67so1973438b3a.3 for <63861@debbugs.gnu.org>; Fri, 09 Jun 2023 09:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686326686; x=1688918686; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=UInROBCCFFxlCiWtvsnC2ZrJKEzVMjEtnTcVtmGH/C0=; b=I6MhX+MkujZrybaLnHbWt+QfJ3INvOsDFNP1jfTFf/rZN67A1ePqahguvuGz7+1nYb Oyl+27Nl9KT8zHYdLzR4yLaDtTZa/gD9ZaBSSv9iR/oAPXy76JAAFnkBe/FyR1QQDqeD 3Cnj21pN/nTIf/wPMK7VNJZL3R8rQShcWwtH5HZS2f65L9+zzlfVculi2A07lkSRZUck C/eJK2v00eVFMTJ45mwOj0HQvGDIKAU4rZ6h9OcA7DNRdNDpALv+XulVAbKq8XbDWU0l ZTFMvmvRQ0/lwbp1P/ZjLEJpPCdz+isM+yyznN809CPfPM8TPUczq9AQ96GDCe6bbIIX IzgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686326686; x=1688918686; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UInROBCCFFxlCiWtvsnC2ZrJKEzVMjEtnTcVtmGH/C0=; b=mF6/gsLjKBjST82SnanEA8TKxFTuP1g52LyO+HVmWSnQedRHvPZD6sDMIsbEW4xvds w9vOzCLf2zDw4UxNfCLST+XnnIpQYBW+AcYjeZfF7inNhfCOo6RlOrc4VPX0ALRtjYdH /1psjNwazJJ/7CyxBccHkypH//AvmM5E/i0yWwS4Y8/YOu0arXd2Xz2UScZHabg9Q/Ak pkmnxWAI8aEfsL1rtoxa5M7gmZqVV759ulAidkAnGvaH/RqJEAA2WJvMXKr1n3/XFYUJ SbDy3Hpss2MfQx1CgSm8oNit/U2ygkOcAqeJGCBbsl8vXZCJh7Oq0RfYzrtSVYh57FiN Hzfw== X-Gm-Message-State: AC+VfDyo9wBTnZ4n/cz2qeE/WFkXgSbxeHYCNgpRuHFuKPFq150WIiPy 6YLHr9UC5dOfi44LLmrhKRs= X-Google-Smtp-Source: ACHHUZ5O85oqbiZdKZXgH1XwE56sP/BoExr4h5r20XtneaSNeOwLRDvjRDts/haSNJJjLcKkG+mK6w== X-Received: by 2002:a05:6a20:a987:b0:10c:80a:480c with SMTP id cc7-20020a056a20a98700b0010c080a480cmr1662211pzb.41.1686326686057; Fri, 09 Jun 2023 09:04:46 -0700 (PDT) Received: from localhost ([49.205.80.56]) by smtp.gmail.com with ESMTPSA id a14-20020a63e84e000000b0054a15146f53sm985323pgk.13.2023.06.09.09.04.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jun 2023 09:04:45 -0700 (PDT) From: Visuwesh To: Stefan Monnier Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier's message of "Fri, 09 Jun 2023 10:59:18 -0400") References: <83fs799jmi.fsf@gnu.org> <871qirdi3a.fsf@gmail.com> <87cz25b9rw.fsf@gmail.com> Date: Fri, 09 Jun 2023 21:34:43 +0530 Message-ID: <87pm64aag4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63861 Cc: Eli Zaretskii , 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=9C=E0=AF=82= =E0=AE=A9=E0=AF=8D 09, 2023] Stefan Monnier wrote: >>> My new code is expected to be slower than the "normal" pretty-printer, >>> but barring performance bugs in `lisp-indent-line` (such as the one >>> fixed by the patch I just sent to Thierry) it should be approximately >>> a constant factor slower. >>> AFAICT the performance of `pp-emacs-lisp-code` can be more problematic. >> Hopefully, the constant factor is quite small. > > In my tests, 10x seems to be the "worst case slowdown" of `pp-region`. > On some of the tests, it's actually faster, sometimes significantly so > (presumably due to some non-linear complexity in some parts of > `pp-buffer`). I cannot imagine how bad 10x really will be but if you are daily-driving this, I assume it is so not bad after all. Thanks for your answers! From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 12 16:22:14 2023 Received: (at 63861) by debbugs.gnu.org; 12 Jun 2023 20:22:14 +0000 Received: from localhost ([127.0.0.1]:40732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8o3G-0000HE-LG for submit@debbugs.gnu.org; Mon, 12 Jun 2023 16:22:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8o3B-0000Ge-30 for 63861@debbugs.gnu.org; Mon, 12 Jun 2023 16:22:09 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CE0161000C4; Mon, 12 Jun 2023 16:21:59 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7A96C10000A; Mon, 12 Jun 2023 16:21:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686601313; bh=RUsPdBs1NOtx6f29gtWjTh8lMnrU4l+BIrJTIMo8YKc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dKqx+u6smDN+vl8rwvog2l3Q2dpN1va8FB5QeJD5nG4TQ9uSjbX/D4NPQ+taa1pHE dpybp5Td1hTzyUkLDIIE4e9VHkGx+QGpD4mfViFTWAPxFIE1Pkwba3hKD+IdZCL8Oy qWW6T2bx/SKxEQBUY5iCQ2JD6iKDMc6jQOlDkH+OOgx2Ptzuu8fhPVD9Sle/R5l7bM aTGf0DtyXaDHjLwlhBVC5bZ7PrSix6if3LAjHC3a+34ALBe8XxoNZE6uL5NUUBeIF9 oeH8vYs8z/udJcLrWoBl9NFU9OyaRAMGw4zxL/VfyC3cjoo0WyEYZPgqRJUjnFhws/ bv1/oePV60bkQ== Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 49895120A09; Mon, 12 Jun 2023 16:21:53 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <83r0qs74qs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Jun 2023 21:58:03 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> Date: Mon, 12 Jun 2023 16:21:50 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.082 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain > Yes, but let's also mention BEG and END: > > Break lines in Lisp code between BEG and END so it fits within `fill-column'. Even better, thanks. >> > Also, I think this warrants a NEWS entry and should be documented in >> > the ELisp manual. >> >> Definitely for NEWS, yes. For the ELisp manual, currently we don't >> document `pp-buffer`, the closest I see is `indent-pp-sexp` (in >> `programs.texi`). >> I'm not sure what to put in there. nor where to put it. > > We document "pp" in "Output Functions". Maybe there? Haven't looked at that yet: I'm still trying to figure out how the functionality should be exposed. >> >> +(defcustom pp-buffer-use-pp-region nil >> >> + "If non-nil, `pp-buffer' uses the new `pp-region' code." >> >> + :type 'boolean) >> > Please add :version. >> Hmm... so you think it should stay as a `defcustom` and we should thus >> plan to keep both kinds of pretty-printing in the long term? > > No, I just said that _if_ we keep it as a defcustom, _then_ it should > have a :version tag. I have no idea how many users will want to > customize this. Since Emacs-29 already has a similar defcustom to use the `pp-emacs-lisp-code` algorithm (and since Thierry uses yet another algorithm), I guess there's enough evidence to convince me that we should have a defcustom. But I don't like the `pp-use-max-width` defcustom: its name doesn't say what it does since the fact that `pp-emacs-lisp-code` obeys `pp-max-width` is just one part of the difference with the default pp code. So I suggest "merging" that var with the new custom var that chooses which algorithm to use (I could make it an obsolete alias, but it seemed cleaner to use a new var and mark the old one obsolete). See below my new version of the patch. I renamed `pp-region` to `pp-fill`. The patch introduces a custom var `pp-default-function` which specifies which algorithm to use among: - `pp-emacs-lisp-code` (Lars' new-in-29 pretty-but-slow pretty printer). - `pp-fill` (my new pretty printer). - `pp-28` (the old pretty printer; suggestions for a better name welcome). - `pp-29` (dispatches according to `pp-use-max-width`, to either `pp-28` or `pp-emacs-lisp-code`, like we do in Emacs-29). - Thierry could plug his `tv/pp-region` in here. The patch also changes `pp` so you can call it with BEG..END and it will pretty-print that region, which makes `pp-buffer` obsolete (I have not yet updated the callers accordingly). If there's no objection, I'll adjust the doc, fix the obsolete uses of `pp-buffer`, and install. Stefan --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=pp-fill.patch Content-Transfer-Encoding: quoted-printable diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index d44c9d6e23d..9914ededb85 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -876,7 +876,7 @@ lisp-ppss 2 (counting from 0). This is important for Lisp indentation." (unless pos (setq pos (point))) (let ((pss (syntax-ppss pos))) - (if (nth 9 pss) + (if (and (not (nth 2 pss)) (nth 9 pss)) (let ((sexp-start (car (last (nth 9 pss))))) (parse-partial-sexp sexp-start pos nil nil (syntax-ppss sexp-sta= rt))) pss))) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index e6e3cd6c6f4..28620fd4bbd 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -52,32 +52,195 @@ large lists." :type 'boolean :version "29.1") +(make-obsolete-variable 'pp-use-max-width 'pp-default-function "30.1") + +(defcustom pp-default-function #'pp-fill + ;; FIXME: The best pretty printer to use depends on the use-case + ;; so maybe we should allow callers to specify what they want (maybe with + ;; options like `fast', `compact', `code', `data', ...) and these + ;; can then be mapped to actual pretty-printing algorithms. + ;; Then again, callers can just directly call the corresponding function. + "Function that `pp' should dispatch to for pretty printing. +That function can be called in one of two ways: +- with a single argument, which it should insert and pretty-print at point. +- with two arguments which delimit a region containing Lisp sexps + which should be pretty-printed. +In both cases, the function can presume that the buffer is setup for +Lisp syntax." + :type 'function + :options '(pp-28 pp-29 pp-fill pp-emacs-lisp-code) + :version "30.1") =20 (defvar pp--inhibit-function-formatting nil) =20 +;; There are basically two APIs for a pretty-printing function: +;; +;; - either the function takes an object (and prints it in addition to +;; prettifying it). +;; - or the function takes a region containing an already printed object +;; and prettifies its content. +;; +;; `pp--object' and `pp--region' are helper functions to convert one +;; API to the other. + + +(defun pp--object (object region-function) + "Pretty-print OBJECT at point. +The prettifying is done by REGION-FUNCTION which is +called with two positions as arguments and should fold lines +within that region. Returns the result as a string." + (let ((print-escape-newlines pp-escape-newlines) + (print-quoted t) + (beg (point))) + ;; FIXME: In many cases it would be preferable to use `cl-prin1' here. + (prin1 object (current-buffer)) + (funcall region-function beg (point)))) + +(defun pp--region (beg end object-function) + "Pretty-print the object(s) contained within BEG..END. +OBJECT-FUNCTION is called with a single object as argument +and should pretty print it at point into the current buffer." + (save-excursion + (with-restriction beg end + (goto-char (point-min)) + (while + (progn + ;; We'll throw away all the comments within objects, but let's + ;; try at least to preserve the comments between objects. + (forward-comment (point-max)) + (let ((beg (point)) + (object (ignore-error end-of-buffer + (list (read (current-buffer)))))) + (when (consp object) + (delete-region beg (point)) + (funcall object-function (car object)) + t))))))) + +(defun pp-29 (beg-or-sexp &optional end) + "Prettify the current region with printed representation of a Lisp objec= t. +Uses the pretty-printing algorithm that was standard in Emacs-29, +which, depending on `pp-use-max-width', will either use `pp-28' +or `pp-emacs-lisp-code'." + (if pp-use-max-width + (let ((pp--inhibit-function-formatting t)) ;FIXME: Why? + (pp-emacs-lisp-code beg-or-sexp end)) + (pp-28 beg-or-sexp end))) + ;;;###autoload -(defun pp-to-string (object) +(defun pp-to-string (object &optional pp-function) "Return a string containing the pretty-printed representation of OBJECT. OBJECT can be any Lisp object. Quoting characters are used as needed -to make output that `read' can handle, whenever this is possible." - (if pp-use-max-width - (let ((pp--inhibit-function-formatting t)) - (with-temp-buffer - (pp-emacs-lisp-code object) - (buffer-string))) +to make output that `read' can handle, whenever this is possible. +Optional argument PP-FUNCTION overrides `pp-default-function'." (with-temp-buffer (lisp-mode-variables nil) (set-syntax-table emacs-lisp-mode-syntax-table) - (let ((print-escape-newlines pp-escape-newlines) - (print-quoted t)) - (prin1 object (current-buffer))) - (pp-buffer) - (buffer-string)))) + (funcall (or pp-function pp-default-function) object) + (buffer-string))) + +(defun pp--within-fill-column-p () + "Return non-nil if point is within `fill-column'." + ;; Try and make it O(fill-column) rather than O(current-column), + ;; so as to avoid major slowdowns on long lines. + ;; FIXME: This doesn't account for invisible text or `display' propertie= s :-( + (and (save-excursion + (re-search-backward + "^\\|\n" (max (point-min) (- (point) fill-column)) t)) + (<=3D (current-column) fill-column))) + +(defun pp-fill (beg &optional end) + "Break lines in Lisp code between BEG and END so it fits within `fill-co= lumn'. +Presumes the current buffer has syntax and indentation properly +configured for that. +Designed under the assumption that the region occupies a single line, +tho it should also work if that's not the case. +Can also be called with a single argument, in which case +it inserts and pretty-prints that arg at point." + (interactive "r") + (if (null end) (pp--object beg #'pp-fill) + (goto-char beg) + (let ((end (copy-marker end t)) + (newline (lambda () + (skip-chars-forward ")]}") + (unless (save-excursion (skip-chars-forward " \t") (e= olp)) + (insert "\n") + (indent-according-to-mode))))) + (while (progn (forward-comment (point-max)) + (< (point) end)) + (let ((beg (point)) + ;; Whether we're in front of an element with paired delimite= rs. + ;; Can be something funky like #'(lambda ..) or ,'#s(...). + (paired (when (looking-at "['`,#]*[[:alpha:]]*\\([({[\"]\\)") + (match-beginning 1)))) + ;; Go to the end of the sexp. + (goto-char (or (scan-sexps (or paired (point)) 1) end)) + (unless + (and + ;; The sexp is all on a single line. + (save-excursion (not (search-backward "\n" beg t))) + ;; And its end is within `fill-column'. + (or (pp--within-fill-column-p) + ;; If the end of the sexp is beyond `fill-column', + ;; try to move the sexp to its own line. + (and + (save-excursion + (goto-char beg) + (if (save-excursion (skip-chars-backward " \t({[',") + (bolp)) + ;; The sexp was already on its own line. + nil + (skip-chars-backward " \t") + (setq beg (copy-marker beg t)) + (if paired (setq paired (copy-marker paired t))) + ;; We could try to undo this insertion if it + ;; doesn't reduce the indentation depth, but I'm + ;; not sure it's worth the trouble. + (insert "\n") (indent-according-to-mode) + t)) + ;; Check again if we moved the whole exp to a new line. + (pp--within-fill-column-p)))) + ;; The sexp is spread over several lines, and/or its end is + ;; (still) beyond `fill-column'. + (when (and paired (not (eq ?\" (char-after paired)))) + ;; The sexp has sub-parts, so let's try and spread + ;; them over several lines. + (save-excursion + (goto-char beg) + (when (looking-at "(\\([^][()\" \t\n;']+\\)") + ;; Inside an expression of the form (SYM ARG1 + ;; ARG2 ... ARGn) where SYM has a `lisp-indent-function' + ;; property that's a number, insert a newline after + ;; the corresponding ARGi, because it tends to lead to + ;; more natural and less indented code. + (let* ((sym (intern-soft (match-string 1))) + (lif (and sym (get sym 'lisp-indent-function)))) + (if (eq lif 'defun) (setq lif 2)) + (when (natnump lif) + (goto-char (match-end 0)) + (forward-sexp lif) + (funcall newline))))) + (save-excursion + (pp-fill (1+ paired) (1- (point))))) + ;; Now the sexp either ends beyond `fill-column' or is + ;; spread over several lines (or both). Either way, the + ;; rest of the line should be moved to its own line. + (funcall newline))))))) =20 ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp objec= t." + (declare (obsolete pp "30")) (interactive) + (pp (point-min) (point-max))) + +(defun pp-28 (beg &optional end) + "Prettify the current region with printed representation of a Lisp objec= t. +Uses the pretty-printing algorithm that was standard in Emacs=E2=89=A429. +Non-interactively can also be called with a single argument, in which +case that argument will be inserted pretty-printed at point." + (interactive "r") + (if (null end) (pp--object beg #'pp-29) + (save-restriction beg end (goto-char (point-min)) (while (not (eobp)) (cond @@ -98,7 +261,7 @@ (insert ?\n)) (t (goto-char (point-max))))) (goto-char (point-min)) - (indent-sexp)) + (indent-sexp)))) =20 ;;;###autoload (defun pp (object &optional stream) @@ -106,14 +106,22 @@ Quoting characters are printed as needed to make output that `read' can handle, whenever this is possible. =20 -This function does not apply special formatting rules for Emacs -Lisp code. See `pp-emacs-lisp-code' instead. +Uses the pretty-printing code specified in `pp-default-function'. =20 -By default, this function won't limit the line length of lists -and vectors. Bind `pp-use-max-width' to a non-nil value to do so. - -Output stream is STREAM, or value of `standard-output' (which see)." - (princ (pp-to-string object) (or stream standard-output))) +Output stream is STREAM, or value of `standard-output' (which see). +An alternative calling convention is to pass it two buffer positions, +in which case it will prettify that region's content." + (cond + ((and (integerp object) (integerp stream)) + (funcall pp-default-function object stream)) + ((and (eq (or stream standard-output) (current-buffer)) + ;; Make sure the current buffer is setup sanely. + (eq (syntax-table) emacs-lisp-mode-syntax-table) + (eq indent-line-function #'lisp-indent-line)) + ;; Skip the buffer->string->buffer middle man. + (funcall pp-default-function object)) + (t + (princ (pp-to-string object) (or stream standard-output))))) =20 ;;;###autoload (defun pp-display-expression (expression out-buffer-name &optional lisp) @@ -220,11 +220,14 @@ (pp-macroexpand-expression (pp-last-sexp)))) =20 ;;;###autoload -(defun pp-emacs-lisp-code (sexp) +(defun pp-emacs-lisp-code (sexp &optional end) "Insert SEXP into the current buffer, formatted as Emacs Lisp code. Use the `pp-max-width' variable to control the desired line length. -Note that this could be slow for large SEXPs." +Note that this could be slow for large SEXPs. +Can also be called with two arguments, in which case they're taken to be +the bounds of a region containing Lisp code to pretty-print." (require 'edebug) + (if end (pp--region sexp end #'pp-emacs-lisp-code) (let ((obuf (current-buffer))) (with-temp-buffer (emacs-lisp-mode) @@ -234,7 +237,7 @@ (indent-sexp) (while (re-search-forward " +$" nil t) (replace-match "")) - (insert-into-buffer obuf)))) + (insert-into-buffer obuf))))) =20 (defun pp--insert-lisp (sexp) (cl-case (type-of sexp) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 13 06:55:40 2023 Received: (at 63861) by debbugs.gnu.org; 13 Jun 2023 10:55:40 +0000 Received: from localhost ([127.0.0.1]:41439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q91ga-0006jl-7a for submit@debbugs.gnu.org; Tue, 13 Jun 2023 06:55:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q91gW-0006jV-1E for 63861@debbugs.gnu.org; Tue, 13 Jun 2023 06:55:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q91gQ-0001O7-Q9; Tue, 13 Jun 2023 06:55:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UeK39kkedwOcsWx0edCU13zZYwesJ/KDMaiCHv0om98=; b=a3ipZUupzu9g +AJMwK3mcavalqChwG1ushlMrZKuNCikX+mc3q+DEOddWUOhZuqqp33lG0+1GkTsREVO5/lOJ4LPD nq5Y2r0hyzxcEoX4KMD/c7geGFKDDGsukT10MxkxyoQEHneP4iLSvWVjjpmYCAycKJFk/4fmU4afJ RBe5zw+QZUFa5L/I7kf2PNiHdoeoy83ibnoC/Kz4b1Gvxb/tq7Vhfk5eZwaw6u72+srmnPVCt+Wae MMNF0mHXA61pNOX5I9KcLeS0wbahphLivxrNZsqYQDV6m3AOo+Vhb2VVQoFefq00QMovdhbdzf0eU tn9VthuaMeEQIdi4mQssGA==; Received: from [87.69.77.57] (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 1q91gC-0003BF-Ql; Tue, 13 Jun 2023 06:55:29 -0400 Date: Tue, 13 Jun 2023 13:55:14 +0300 Message-Id: <83pm5zws19.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 12 Jun 2023 16:21:50 -0400) Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 63861@debbugs.gnu.org > Date: Mon, 12 Jun 2023 16:21:50 -0400 > > > We document "pp" in "Output Functions". Maybe there? > > Haven't looked at that yet: I'm still trying to figure out how the > functionality should be exposed. Well, just don't forget that when you eventually install ;-) > +(defcustom pp-default-function #'pp-fill > + ;; FIXME: The best pretty printer to use depends on the use-case > + ;; so maybe we should allow callers to specify what they want (maybe with > + ;; options like `fast', `compact', `code', `data', ...) and these > + ;; can then be mapped to actual pretty-printing algorithms. > + ;; Then again, callers can just directly call the corresponding function. > + "Function that `pp' should dispatch to for pretty printing. > +That function can be called in one of two ways: > +- with a single argument, which it should insert and pretty-print at point. > +- with two arguments which delimit a region containing Lisp sexps > + which should be pretty-printed. > +In both cases, the function can presume that the buffer is setup for > +Lisp syntax." Perhaps say in the doc string something about when each algorithm is slower/faster? Otherwise LGTM, thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 14:27:11 2023 Received: (at 63861) by debbugs.gnu.org; 16 Jun 2023 18:27:11 +0000 Received: from localhost ([127.0.0.1]:50343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAEA9-0000oS-U7 for submit@debbugs.gnu.org; Fri, 16 Jun 2023 14:27:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAEA7-0000oE-Ni for 63861@debbugs.gnu.org; Fri, 16 Jun 2023 14:27:09 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 295671004AE; Fri, 16 Jun 2023 14:27:02 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 612BF100048; Fri, 16 Jun 2023 14:26:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686940015; bh=esjnikzyDPL9R3c2hai8U0PX15APhvyuyaKEyhkrvjc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bfMjOizC/qVhhslqght1beBbqPe+CLEkOLAX945mft3k4Wmjg/V0+pHLZZJkWZiR1 kXRVHO/FVBKt0u2k+L3IdM4VliMBrRIGKOj6OumvL1zOg6Bxx3FUh1aRk59WXj4AvL xM98LLQpCKMnPD7dsccOfwSAtYMvtsNUIURapsBaC2eH9ecYPK9fc5DckksUi4OIg/ l8JEcpazGCzdE134f/L2e88oKH05l5DwIhe33V9KzkHB6Tp7+GEtnvZ2e6O7jF41Fs hqMuqN7/jTAFmVxZgd/tp2grpJmrQc4HzuuOeFHYQnfTWKwijpDH0FQEuUtux6NFZu Kv1GxvkVXQ54A== Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18BD6120803; Fri, 16 Jun 2023 14:26:55 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <83pm5zws19.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jun 2023 13:55:14 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> <83pm5zws19.fsf@gnu.org> Date: Fri, 16 Jun 2023 14:26:54 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.207 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain KAM_LOTSOFHASH 0.25 Emails with lots of hash-like gibberish T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain > Otherwise LGTM, thanks. OK, I think I have it almost ready see the patches below. I just hit one snag when trying to fix the tests. We have for example the following test: (ert-deftest pp-print-quote () (should (string= (pp-to-string 'quote) "quote")) (should (string= (pp-to-string ''quote) "'quote")) (should (string= (pp-to-string '('a 'b)) "('a 'b)\n")) (should (string= (pp-to-string '(''quote 'quote)) "(''quote 'quote)\n")) This is how the old code behaved, i.e. the output sometimes ends with \n and sometimes not, depending on whether the object printed is a list or not. Currently, my new code behaves the same when using `pp-28` or `pp-29` but when using the new default (i.e. `pp-fill`) the output never ends in \n. This change was not intentional, but I think it makes sense because it's more consistent. I'm not completely sure how we should fix this. I think the old behavior of sometimes adding \n and sometimes not is not desirable, so I think we should change it (a backward incompatible change). We have two remaining choices: A) never add \n B) always add \n AFAICT, in practice the old behavior resulted in a \n added in most cases, so (B) should lead to less breakage, but OTOH I think (A) would be cleaner since it's easier for callers to add a \n when needed than for them to remove a \n. WDYT? A or B? Stefan --=-=-= Content-Type: text/x-diff; charset=iso-8859-1 Content-Disposition: inline; filename=0001-lisp-emacs-lisp-lisp-mode.el-lisp-ppss-Fix-performan.patch Content-Transfer-Encoding: quoted-printable >From 31bc44c81386f8db2aecfe1529d051fed1367df9 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 16 Jun 2023 13:14:27 -0400 Subject: [PATCH 1/5] * lisp/emacs-lisp/lisp-mode.el (lisp-ppss): Fix performance bug MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit (nth 2 ppss) can be absent but not incorrect, so don't recompute ppss for (nth 2 ppss) when (nth 2 ppss) is already provided. When calling `lisp-indent-line` on all the lines in a region, this sometimes introduced a gratuitous O(N=B2) complexity. --- lisp/emacs-lisp/lisp-mode.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index d44c9d6e23d..9914ededb85 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -876,7 +876,7 @@ lisp-ppss 2 (counting from 0). This is important for Lisp indentation." (unless pos (setq pos (point))) (let ((pss (syntax-ppss pos))) - (if (nth 9 pss) + (if (and (not (nth 2 pss)) (nth 9 pss)) (let ((sexp-start (car (last (nth 9 pss))))) (parse-partial-sexp sexp-start pos nil nil (syntax-ppss sexp-sta= rt))) pss))) --=20 2.39.2 --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=0002-pp.el-pp-default-function-New-custom-var.patch Content-Transfer-Encoding: quoted-printable >From 16c8fa5e209e5d13f86e87a84a678608de0d5341 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 16 Jun 2023 13:31:13 -0400 Subject: [PATCH 2/5] pp.el (pp-default-function): New custom var * lisp/emacs-lisp/pp.el (pp-use-max-width): Make obsolete. (pp-default-function): New custom var. (pp--object, pp--region): New helper functions. (pp-29): New function, extracted from `pp-to-string`. (pp-to-string): Add `pp-function` arg and obey `pp-default-function`. (pp-28): New function, extracted from `pp-buffer`. (pp-buffer): Rewrite, using `pp` so it obeys `pp-default-function`. (pp): Add new calling convention to apply it to a region, and obey `pp-default-function`. (pp-emacs-lisp-code): Add new calling convention to apply it to a region. --- lisp/emacs-lisp/pp.el | 198 ++++++++++++++++++++++++++++++------------ 1 file changed, 144 insertions(+), 54 deletions(-) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index e6e3cd6c6f4..0798e46f735 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -52,53 +52,132 @@ pp-use-max-width large lists." :type 'boolean :version "29.1") +(make-obsolete-variable 'pp-use-max-width 'pp-default-function "30.1") + +(defcustom pp-default-function #'pp-29 + ;; FIXME: The best pretty printer to use depends on the use-case + ;; so maybe we should allow callers to specify what they want (maybe with + ;; options like `fast', `compact', `code', `data', ...) and these + ;; can then be mapped to actual pretty-printing algorithms. + ;; Then again, callers can just directly call the corresponding function. + "Function that `pp' should dispatch to for pretty printing. +That function can be called in one of two ways: +- with a single argument, which it should insert and pretty-print at point. +- with two arguments which delimit a region containing Lisp sexps + which should be pretty-printed. +In both cases, the function can presume that the buffer is setup for +Lisp syntax." + :type '(choice + (const :tag "Emacs=E2=89=A428 algorithm, fast and good enough" p= p-28) + (const :tag "Work hard for code (slow on large inputs)" + pp-emacs-lisp-code) + (const :tag "`pp-emacs-lisp-code' if `pp-use-max-width' else `pp= -28'" + pp-29) + function) + :version "30.1") =20 (defvar pp--inhibit-function-formatting nil) =20 +;; There are basically two APIs for a pretty-printing function: +;; +;; - either the function takes an object (and prints it in addition to +;; prettifying it). +;; - or the function takes a region containing an already printed object +;; and prettifies its content. +;; +;; `pp--object' and `pp--region' are helper functions to convert one +;; API to the other. + + +(defun pp--object (object region-function) + "Pretty-print OBJECT at point. +The prettifying is done by REGION-FUNCTION which is +called with two positions as arguments and should fold lines +within that region. Returns the result as a string." + (let ((print-escape-newlines pp-escape-newlines) + (print-quoted t) + (beg (point))) + ;; FIXME: In many cases it would be preferable to use `cl-prin1' here. + (prin1 object (current-buffer)) + (funcall region-function beg (point)))) + +(defun pp--region (beg end object-function) + "Pretty-print the object(s) contained within BEG..END. +OBJECT-FUNCTION is called with a single object as argument +and should pretty print it at point into the current buffer." + (save-excursion + (with-restriction beg end + (goto-char (point-min)) + (while + (progn + ;; We'll throw away all the comments within objects, but let's + ;; try at least to preserve the comments between objects. + (forward-comment (point-max)) + (let ((beg (point)) + (object (ignore-error end-of-buffer + (list (read (current-buffer)))))) + (when (consp object) + (delete-region beg (point)) + (funcall object-function (car object)) + t))))))) + +(defun pp-29 (beg-or-sexp &optional end) ;FIXME: Better name? + "Prettify the current region with printed representation of a Lisp objec= t. +Uses the pretty-printing algorithm that was standard in Emacs-29, +which, depending on `pp-use-max-width', will either use `pp-28' +or `pp-emacs-lisp-code'." + (if pp-use-max-width + (let ((pp--inhibit-function-formatting t)) ;FIXME: Why? + (pp-emacs-lisp-code beg-or-sexp end)) + (pp-28 beg-or-sexp end))) + ;;;###autoload -(defun pp-to-string (object) +(defun pp-to-string (object &optional pp-function) "Return a string containing the pretty-printed representation of OBJECT. OBJECT can be any Lisp object. Quoting characters are used as needed -to make output that `read' can handle, whenever this is possible." - (if pp-use-max-width - (let ((pp--inhibit-function-formatting t)) - (with-temp-buffer - (pp-emacs-lisp-code object) - (buffer-string))) - (with-temp-buffer - (lisp-mode-variables nil) - (set-syntax-table emacs-lisp-mode-syntax-table) - (let ((print-escape-newlines pp-escape-newlines) - (print-quoted t)) - (prin1 object (current-buffer))) - (pp-buffer) - (buffer-string)))) +to make output that `read' can handle, whenever this is possible. +Optional argument PP-FUNCTION overrides `pp-default-function'." + (with-temp-buffer + (lisp-mode-variables nil) + (set-syntax-table emacs-lisp-mode-syntax-table) + (funcall (or pp-function pp-default-function) object) + (buffer-string))) =20 ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp objec= t." (interactive) - (goto-char (point-min)) - (while (not (eobp)) - (cond - ((ignore-errors (down-list 1) t) - (save-excursion - (backward-char 1) - (skip-chars-backward "'`#^") - (when (and (not (bobp)) (memq (char-before) '(?\s ?\t ?\n))) + (pp (point-min) (point-max))) + +(defun pp-28 (beg &optional end) ;FIXME: Better name? + "Prettify the current region with printed representation of a Lisp objec= t. +Uses the pretty-printing algorithm that was standard in Emacs=E2=89=A429. +Non-interactively can also be called with a single argument, in which +case that argument will be inserted pretty-printed at point." + (interactive "r") + (if (null end) (pp--object beg #'pp-29) + (save-restriction beg end + (goto-char (point-min)) + (while (not (eobp)) + (cond + ((ignore-errors (down-list 1) t) + (save-excursion + (backward-char 1) + (skip-chars-backward "'`#^") + (when (and (not (bobp)) (memq (char-before) '(?\s ?\t ?\n))) + (delete-region + (point) + (progn (skip-chars-backward " \t\n") (point))) + (insert "\n")))) + ((ignore-errors (up-list 1) t) + (skip-syntax-forward ")") (delete-region (point) - (progn (skip-chars-backward " \t\n") (point))) - (insert "\n")))) - ((ignore-errors (up-list 1) t) - (skip-syntax-forward ")") - (delete-region - (point) - (progn (skip-chars-forward " \t\n") (point))) - (insert ?\n)) - (t (goto-char (point-max))))) - (goto-char (point-min)) - (indent-sexp)) + (progn (skip-chars-forward " \t\n") (point))) + (insert ?\n)) + (t (goto-char (point-max))))) + (goto-char (point-min)) + (indent-sexp)))) =20 ;;;###autoload (defun pp (object &optional stream) @@ -106,14 +185,22 @@ pp Quoting characters are printed as needed to make output that `read' can handle, whenever this is possible. =20 -This function does not apply special formatting rules for Emacs -Lisp code. See `pp-emacs-lisp-code' instead. - -By default, this function won't limit the line length of lists -and vectors. Bind `pp-use-max-width' to a non-nil value to do so. - -Output stream is STREAM, or value of `standard-output' (which see)." - (princ (pp-to-string object) (or stream standard-output))) +Uses the pretty-printing code specified in `pp-default-function'. + +Output stream is STREAM, or value of `standard-output' (which see). +An alternative calling convention is to pass it two buffer positions, +in which case it will prettify that region's content." + (cond + ((and (integerp object) (integerp stream)) + (funcall pp-default-function object stream)) + ((and (eq (or stream standard-output) (current-buffer)) + ;; Make sure the current buffer is setup sanely. + (eq (syntax-table) emacs-lisp-mode-syntax-table) + (eq indent-line-function #'lisp-indent-line)) + ;; Skip the buffer->string->buffer middle man. + (funcall pp-default-function object)) + (t + (princ (pp-to-string object) (or stream standard-output))))) =20 ;;;###autoload (defun pp-display-expression (expression out-buffer-name &optional lisp) @@ -220,21 +307,24 @@ pp-macroexpand-last-sexp (pp-macroexpand-expression (pp-last-sexp)))) =20 ;;;###autoload -(defun pp-emacs-lisp-code (sexp) +(defun pp-emacs-lisp-code (sexp &optional end) "Insert SEXP into the current buffer, formatted as Emacs Lisp code. Use the `pp-max-width' variable to control the desired line length. -Note that this could be slow for large SEXPs." +Note that this could be slow for large SEXPs. +Can also be called with two arguments, in which case they're taken to be +the bounds of a region containing Lisp code to pretty-print." (require 'edebug) - (let ((obuf (current-buffer))) - (with-temp-buffer - (emacs-lisp-mode) - (pp--insert-lisp sexp) - (insert "\n") - (goto-char (point-min)) - (indent-sexp) - (while (re-search-forward " +$" nil t) - (replace-match "")) - (insert-into-buffer obuf)))) + (if end (pp--region sexp end #'pp-emacs-lisp-code) + (let ((obuf (current-buffer))) + (with-temp-buffer + (emacs-lisp-mode) + (pp--insert-lisp sexp) + (insert "\n") + (goto-char (point-min)) + (indent-sexp) + (while (re-search-forward " +$" nil t) + (replace-match "")) + (insert-into-buffer obuf))))) =20 (defun pp--insert-lisp (sexp) (cl-case (type-of sexp) --=20 2.39.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-pp.el-pp-buffer-Mark-as-obsolete.patch >From 2e10c9ef0b697fe55d6a5162312a217bc22133a1 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 16 Jun 2023 13:21:15 -0400 Subject: [PATCH 3/5] pp.el (pp-buffer): Mark as obsolete * lisp/emacs-lisp/pp.el (pp-buffer): Mark as obsolete * lisp/org/org-table.el (org-table-fedit-lisp-indent): * lisp/emacs-lisp/lisp-mode.el (indent-pp-sexp): * lisp/emacs-lisp/backtrace.el (backtrace--multi-line): * lisp/ielm.el (ielm-eval-input): * lisp/help-fns.el (describe-variable): Use the new `pp` calling convention instead of `pp-buffer`. (help-fns-edit-variable): Use `pp` instead of `prin1` + `pp-buffer`. Use the new `pp` --- lisp/emacs-lisp/backtrace.el | 2 +- lisp/emacs-lisp/lisp-mode.el | 2 +- lisp/emacs-lisp/pp.el | 1 + lisp/help-fns.el | 9 ++++----- lisp/ielm.el | 2 +- lisp/org/org-table.el | 5 ++++- 6 files changed, 12 insertions(+), 9 deletions(-) diff --git a/lisp/emacs-lisp/backtrace.el b/lisp/emacs-lisp/backtrace.el index 57912c854b0..81cfafa5738 100644 --- a/lisp/emacs-lisp/backtrace.el +++ b/lisp/emacs-lisp/backtrace.el @@ -556,7 +556,7 @@ backtrace-multi-line (defun backtrace--multi-line () "Pretty print the current buffer, then remove the trailing newline." (set-syntax-table emacs-lisp-mode-syntax-table) - (pp-buffer) + (pp (point-min) (point-max)) (goto-char (1- (point-max))) (delete-char 1)) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 9914ededb85..83b374551fc 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -1418,7 +1418,7 @@ indent-pp-sexp (save-excursion (save-restriction (narrow-to-region (point) (progn (forward-sexp 1) (point))) - (pp-buffer) + (pp (point-min) (point-max)) (goto-char (point-max)) (if (eq (char-before) ?\n) (delete-char -1))))) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index 0798e46f735..65325dea6f1 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -146,6 +146,7 @@ pp-to-string ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp object." + (declare (obsolete pp "30")) (interactive) (pp (point-min) (point-max))) diff --git a/lisp/help-fns.el b/lisp/help-fns.el index b9388b45397..79a2b9a495b 100644 --- a/lisp/help-fns.el +++ b/lisp/help-fns.el @@ -1341,7 +1341,7 @@ describe-variable (lisp-data-mode) (set-syntax-table emacs-lisp-mode-syntax-table) (insert print-rep) - (pp-buffer) + (pp (point-min) (point-max)) (font-lock-ensure) (let ((pp-buffer (current-buffer))) (with-current-buffer buf @@ -1368,7 +1368,7 @@ describe-variable (cl-prin1 origval)) (save-restriction (narrow-to-region from (point)) - (save-excursion (pp-buffer))) + (save-excursion (pp (point-min) (point-max)))) (help-fns--editable-variable from (point) variable origval buffer) (if (< (point) (+ from 20)) @@ -1399,7 +1399,7 @@ describe-variable (cl-prin1 global-val) (save-restriction (narrow-to-region from (point)) - (save-excursion (pp-buffer))) + (save-excursion (pp (point-min) (point-max)))) ;; See previous comment for this function. ;; (help-xref-on-pp from (point)) (if (< (point) (+ from 20)) @@ -1479,8 +1479,7 @@ help-fns-edit-variable (unless var (error "No variable under point")) (pop-to-buffer-same-window (format "*edit %s*" (nth 0 var))) - (prin1 (nth 1 var) (current-buffer)) - (pp-buffer) + (pp (nth 1 var) (current-buffer)) (goto-char (point-min)) (help-fns--edit-value-mode) (insert (format ";; Edit the `%s' variable.\n" (nth 0 var)) diff --git a/lisp/ielm.el b/lisp/ielm.el index 5c370733c05..f7984ea162c 100644 --- a/lisp/ielm.el +++ b/lisp/ielm.el @@ -436,7 +436,7 @@ ielm-eval-input ;; right buffer! (with-current-buffer ielmbuf (cl-prin1 result tmpbuf)) - (pp-buffer) + (pp (point-min) (point-max)) (concat (buffer-string) aux)))))) (error (setq error-type "IELM Error") diff --git a/lisp/org/org-table.el b/lisp/org/org-table.el index 42f234790c5..ecd17c76ec2 100644 --- a/lisp/org/org-table.el +++ b/lisp/org/org-table.el @@ -3717,7 +3717,10 @@ org-table-fedit-lisp-indent (setq this-command nil) (while (re-search-forward "[ \t]*\n[ \t]*" nil t) (replace-match " "))) - (pp-buffer) + (if (fboundp 'pp-buffer) ;Obsolete since Emacs-30 + (with-suppressed-warnings ((obsolete pp-buffer)) + (pp-buffer)) + (pp (point-min) (point-max))) (untabify (point-min) (point-max)) (goto-char (1+ (point-min))) (while (re-search-forward "^." nil t) -- 2.39.2 --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=0004-pp.el-pp-fill-New-default-pp-function.patch Content-Transfer-Encoding: quoted-printable >From cee9fb91a200afbaa9d3e7e52d8cd1533e150acc Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 16 Jun 2023 13:35:06 -0400 Subject: [PATCH 4/5] pp.el (pp-fill): New default pp function * lisp/emacs-lisp/pp.el (pp-default-function): Change default. (pp--within-fill-column-p): New helper function. (pp-fill): New function. --- lisp/emacs-lisp/pp.el | 91 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 90 insertions(+), 1 deletion(-) diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el index 65325dea6f1..2dc8f7cb65d 100644 --- a/lisp/emacs-lisp/pp.el +++ b/lisp/emacs-lisp/pp.el @@ -54,7 +54,7 @@ pp-use-max-width :version "29.1") (make-obsolete-variable 'pp-use-max-width 'pp-default-function "30.1") =20 -(defcustom pp-default-function #'pp-29 +(defcustom pp-default-function #'pp-fill ;; FIXME: The best pretty printer to use depends on the use-case ;; so maybe we should allow callers to specify what they want (maybe with ;; options like `fast', `compact', `code', `data', ...) and these @@ -68,6 +68,7 @@ pp-default-function In both cases, the function can presume that the buffer is setup for Lisp syntax." :type '(choice + (const :tag "Fit within `fill-column'" pp-fill) (const :tag "Emacs=E2=89=A428 algorithm, fast and good enough" p= p-28) (const :tag "Work hard for code (slow on large inputs)" pp-emacs-lisp-code) @@ -143,6 +144,94 @@ pp-to-string (funcall (or pp-function pp-default-function) object) (buffer-string))) =20 +(defun pp--within-fill-column-p () + "Return non-nil if point is within `fill-column'." + ;; Try and make it O(fill-column) rather than O(current-column), + ;; so as to avoid major slowdowns on long lines. + ;; FIXME: This doesn't account for invisible text or `display' propertie= s :-( + (and (save-excursion + (re-search-backward + "^\\|\n" (max (point-min) (- (point) fill-column)) t)) + (<=3D (current-column) fill-column))) + +(defun pp-fill (beg &optional end) + "Break lines in Lisp code between BEG and END so it fits within `fill-co= lumn'. +Presumes the current buffer has syntax and indentation properly +configured for that. +Designed under the assumption that the region occupies a single line, +tho it should also work if that's not the case. +Can also be called with a single argument, in which case +it inserts and pretty-prints that arg at point." + (interactive "r") + (if (null end) (pp--object beg #'pp-fill) + (goto-char beg) + (let ((end (copy-marker end t)) + (newline (lambda () + (skip-chars-forward ")]}") + (unless (save-excursion (skip-chars-forward " \t") (e= olp)) + (insert "\n") + (indent-according-to-mode))))) + (while (progn (forward-comment (point-max)) + (< (point) end)) + (let ((beg (point)) + ;; Whether we're in front of an element with paired delimite= rs. + ;; Can be something funky like #'(lambda ..) or ,'#s(...). + (paired (when (looking-at "['`,#]*[[:alpha:]]*\\([({[\"]\\)") + (match-beginning 1)))) + ;; Go to the end of the sexp. + (goto-char (or (scan-sexps (or paired (point)) 1) end)) + (unless + (and + ;; The sexp is all on a single line. + (save-excursion (not (search-backward "\n" beg t))) + ;; And its end is within `fill-column'. + (or (pp--within-fill-column-p) + ;; If the end of the sexp is beyond `fill-column', + ;; try to move the sexp to its own line. + (and + (save-excursion + (goto-char beg) + (if (save-excursion (skip-chars-backward " \t({[',") + (bolp)) + ;; The sexp was already on its own line. + nil + (skip-chars-backward " \t") + (setq beg (copy-marker beg t)) + (if paired (setq paired (copy-marker paired t))) + ;; We could try to undo this insertion if it + ;; doesn't reduce the indentation depth, but I'm + ;; not sure it's worth the trouble. + (insert "\n") (indent-according-to-mode) + t)) + ;; Check again if we moved the whole exp to a new line. + (pp--within-fill-column-p)))) + ;; The sexp is spread over several lines, and/or its end is + ;; (still) beyond `fill-column'. + (when (and paired (not (eq ?\" (char-after paired)))) + ;; The sexp has sub-parts, so let's try and spread + ;; them over several lines. + (save-excursion + (goto-char beg) + (when (looking-at "(\\([^][()\" \t\n;']+\\)") + ;; Inside an expression of the form (SYM ARG1 + ;; ARG2 ... ARGn) where SYM has a `lisp-indent-function' + ;; property that's a number, insert a newline after + ;; the corresponding ARGi, because it tends to lead to + ;; more natural and less indented code. + (let* ((sym (intern-soft (match-string 1))) + (lif (and sym (get sym 'lisp-indent-function)))) + (if (eq lif 'defun) (setq lif 2)) + (when (natnump lif) + (goto-char (match-end 0)) + (forward-sexp lif) + (funcall newline))))) + (save-excursion + (pp-fill (1+ paired) (1- (point))))) + ;; Now the sexp either ends beyond `fill-column' or is + ;; spread over several lines (or both). Either way, the + ;; rest of the line should be moved to its own line. + (funcall newline))))))) + ;;;###autoload (defun pp-buffer () "Prettify the current buffer with printed representation of a Lisp objec= t." --=20 2.39.2 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0005-lispref-streams.texi-Document-new-PP-functionality.patch >From f55500ef4033c5919783f391c079b9e5ec61fc0c Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Fri, 16 Jun 2023 13:35:36 -0400 Subject: [PATCH 5/5] lispref/streams.texi: Document new PP functionality * doc/lispref/streams.texi (Output Functions): Document new `pp` calling convention. (Output Variables): Document `pp-default-function`. --- doc/lispref/streams.texi | 24 ++++++++++++++++++++---- etc/NEWS | 10 ++++++++++ 2 files changed, 30 insertions(+), 4 deletions(-) diff --git a/doc/lispref/streams.texi b/doc/lispref/streams.texi index 89046a68249..2eb71b83f9c 100644 --- a/doc/lispref/streams.texi +++ b/doc/lispref/streams.texi @@ -755,10 +755,17 @@ Output Functions @end defmac @cindex pretty-printer -@defun pp object &optional stream -This function outputs @var{object} to @var{stream}, just like -@code{prin1}, but does it in a prettier way. That is, it'll -indent and fill the object to make it more readable for humans. +@defun pp object-or-beg &optional stream-or-end +This function indents and fills the printed representation of an +object (typically representing ELisp code) to make it more readable +for humans. + +It accepts two calling conventions: if called with two integers +@var{beg} and @var{end}, it indents and fills the corresponding +region, presumably containing the printed representation of one or +more objects, otherwise it takes a @var{object} and an optional +@var{stream}, and prints @var{object} like @code{prin1}, but does it +in a prettier way. @end defun If you need to use binary I/O in batch mode, e.g., use the functions @@ -981,6 +988,15 @@ Output Variables having their own escape syntax such as newline. @end defvar +@defopt pp-default-function +This user variable specifies the function used by @code{pp} to prettify +its output. By default it uses @code{pp-fill} which attempts to +strike a good balance between speed and generating natural looking output +that fits within @code{fill-column}. The previous default was +@code{pp-28}, which tends to be faster but generate output that looks +less natural and is less compact. +@end defopt + @node Output Overrides @section Overriding Output Variables @cindex overrides, in output functions diff --git a/etc/NEWS b/etc/NEWS index 61e6e161665..7aa387b3a5c 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -396,6 +396,16 @@ name as a string. The new function 'dictionary-completing-read-dictionary' can be used to prompt with completion based on dictionaries that the server supports. +** Pp +*** New 'pp-default-function' custom variable replaces 'pp-use-max-width'. + +*** New default pretty printing function, which tries to obey 'fill-column'. + +*** 'pp' can be applied to a region rather than an object. +As a consequence, 'pp-buffer' is now declared obsolete. + +*** 'pp-to-string' takes an additional 'pp-function' argument. +This arg specifies the prettifying algorithm to use. * New Modes and Packages in Emacs 30.1 -- 2.39.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 01:39:19 2023 Received: (at 63861) by debbugs.gnu.org; 17 Jun 2023 05:39:19 +0000 Received: from localhost ([127.0.0.1]:50712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAOed-0004St-7U for submit@debbugs.gnu.org; Sat, 17 Jun 2023 01:39:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAOea-0004SZ-1N for 63861@debbugs.gnu.org; Sat, 17 Jun 2023 01:39:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAOeT-0006ti-Sq; Sat, 17 Jun 2023 01:39:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=opKcxFRbwBOuYQ2ieKqDo8MqAzlo4x2W+PltHHbxL5w=; b=oaxTXNrQRjpSaIP76Os+ HcJ5J4gVijltqp4ISX6orJLGcEp2US6AQz1lDX9Zxowu38WUYWrW5XkwUqT5UTPLwQ/9XpO2UyB2M VCFb5ycTrCiSwKC+Z9EHttnr7T6rznGT4rpgP/u9K2dcG3UV87ECsHrmo8+OMcSVb/9cgcYbo4DuB 0YHRMxrgCxJMvUFcSy0x6nrnXuRLf/sySsYioeqbKsjVIm6GL4d8i+E3PN4qsrDcXlxGt06u+1vHs 22CWOPfWrB8cyN5apWWcJU++tyS0YB2A8AIzdFdLXf5p96yET9461WyniNQ4aJTVz1LE2GQBW5ujp wpJgP5FtKc2DAg==; Received: from [87.69.77.57] (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 1qAOeS-0006hg-WA; Sat, 17 Jun 2023 01:39:09 -0400 Date: Sat, 17 Jun 2023 08:39:07 +0300 Message-Id: <83h6r6sl50.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 16 Jun 2023 14:26:54 -0400) Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> <83pm5zws19.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 63861@debbugs.gnu.org > Date: Fri, 16 Jun 2023 14:26:54 -0400 > > +(defun pp-28 (beg &optional end) ;FIXME: Better name? > + "Prettify the current region with printed representation of a Lisp object. > +Uses the pretty-printing algorithm that was standard in Emacs≤29. ^^^^^^^^ Please avoid non-ASCII characters in doc strings: they could produce display problems on less-than-capable terminals. > +@defun pp object-or-beg &optional stream-or-end > +This function indents and fills the printed representation of an > +object (typically representing ELisp code) to make it more readable > +for humans. > + > +It accepts two calling conventions: if called with two integers > +@var{beg} and @var{end}, it indents and fills the corresponding > +region, presumably containing the printed representation of one or > +more objects, otherwise it takes a @var{object} and an optional > +@var{stream}, and prints @var{object} like @code{prin1}, but does it > +in a prettier way. This text references arguments like @var{object} that are named differently in the @defun line. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 12:14:05 2023 Received: (at 63861) by debbugs.gnu.org; 17 Jun 2023 16:14:05 +0000 Received: from localhost ([127.0.0.1]:52493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAYYv-0006xg-D8 for submit@debbugs.gnu.org; Sat, 17 Jun 2023 12:14:05 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAYYs-0006wX-1a for 63861@debbugs.gnu.org; Sat, 17 Jun 2023 12:14:03 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8BF901001FC; Sat, 17 Jun 2023 12:13:56 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 93E7E100083; Sat, 17 Jun 2023 12:13:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1687018435; bh=NO1TUCeNyUcPafTSLvzvfWJ/hKQkDVkkpyAHZ+719HY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CUaA3PIr3t0iunxIfnOy671lvGbe97N/Zm3BrjfIwJ1PCMIbrTkYHK+YZL3dC3rQp bNxT3Y3PSbQ5TWhOGTa1u49ECT1dZrYwYncd9WiJKNyBCzfONLSRAguNu9+NY/4rwz 46TmMFlV7aJFuZ+Q9qJxN4h1vtPni7bMh2orQE4/snTMHYdS5Z4FS6ytcKcaIzGKiu /ig6B/kOw7nU2CjjUgvSXbjMXKrdiDCpjGuvYp2mlvKE8BmKgx0Ymu5WoHsI1jjP1p aaq5hhKioNZkdKXksu5+bRx1Kn7EtLARiHy1mJHd+m3OVikFS3cQHMMPsS2skEwDX3 ZSwpeS7etdeMg== Received: from pastel (unknown [45.72.207.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 706AE12086B; Sat, 17 Jun 2023 12:13:55 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <83h6r6sl50.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Jun 2023 08:39:07 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> <83pm5zws19.fsf@gnu.org> <83h6r6sl50.fsf@gnu.org> Date: Sat, 17 Jun 2023 12:13:54 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.171 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> From: Stefan Monnier >> Cc: 63861@debbugs.gnu.org >> Date: Fri, 16 Jun 2023 14:26:54 -0400 >>=20 >> +(defun pp-28 (beg &optional end) ;FIXME: Better name? >> + "Prettify the current region with printed representation of a Lisp ob= ject. >> +Uses the pretty-printing algorithm that was standard in Emacs=E2=89=A42= 9. > ^^^^^^^^ > Please avoid non-ASCII characters in doc strings: they could produce > display problems on less-than-capable terminals. OK >> +@defun pp object-or-beg &optional stream-or-end >> +This function indents and fills the printed representation of an >> +object (typically representing ELisp code) to make it more readable >> +for humans. >> + >> +It accepts two calling conventions: if called with two integers >> +@var{beg} and @var{end}, it indents and fills the corresponding >> +region, presumably containing the printed representation of one or >> +more objects, otherwise it takes a @var{object} and an optional >> +@var{stream}, and prints @var{object} like @code{prin1}, but does it >> +in a prettier way. > > This text references arguments like @var{object} that are named > differently in the @defun line. Indeed. Assuming you understood what I meant to say, do you have a recommendation of how to write it? Or maybe, I should leave `pp` alone and add a new `pp-region` function instead instead of combining two different calling conventions on a single function? The reason I've done that is because it was difficult to avoid doing it for the "backend functions" (those that can be put on `pp-default-function`), but admittedly, that doesn't have to carry over to `pp`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 12:42:53 2023 Received: (at 63861) by debbugs.gnu.org; 17 Jun 2023 16:42:53 +0000 Received: from localhost ([127.0.0.1]:52539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAZ0n-0001qG-3L for submit@debbugs.gnu.org; Sat, 17 Jun 2023 12:42:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAZ0k-0001q3-Mi for 63861@debbugs.gnu.org; Sat, 17 Jun 2023 12:42:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAZ0e-0005l3-Rd; Sat, 17 Jun 2023 12:42:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=O81LDuZiaE4cy0YjwZEzVBeBFdmOWBJNdYEbXsz/IIA=; b=BVLr7hmQ6gFK /tS5YjflIoAbLJvPdrteY1QIRImkUqvv0qI3QDCXhDfI9cltigOGvX7FCVT8F1oObZL2jHKUIGASs tzzBvOE/bHDCoBw/izcjSjG/nrNP8mSkYz2NXB6mVUwsXghocyYCsKAytibFN79ZCxV69m81ppg4K IcyDlJaIVGsdabGleiOQXj03z25hMN09OtewRXPkCeUcDCBvGjHJ6mgAtQ5m6yot8G9aLDBjanbms r78RzgR91+OFeHKhcRylooFaml2lPnRrnKkbBeSLgpUGuKoANFN0fbzkof+nEENsUT7G51+qSi6Pz fIbpOC3ywhee+rZMQf51Kw==; Received: from [87.69.77.57] (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 1qAZ0e-00012u-Bi; Sat, 17 Jun 2023 12:42:44 -0400 Date: Sat, 17 Jun 2023 19:42:44 +0300 Message-Id: <83ttv6oxa3.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sat, 17 Jun 2023 12:13:54 -0400) Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> <83pm5zws19.fsf@gnu.org> <83h6r6sl50.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 63861@debbugs.gnu.org > Date: Sat, 17 Jun 2023 12:13:54 -0400 > > >> +@defun pp object-or-beg &optional stream-or-end > >> +This function indents and fills the printed representation of an > >> +object (typically representing ELisp code) to make it more readable > >> +for humans. > >> + > >> +It accepts two calling conventions: if called with two integers > >> +@var{beg} and @var{end}, it indents and fills the corresponding > >> +region, presumably containing the printed representation of one or > >> +more objects, otherwise it takes a @var{object} and an optional > >> +@var{stream}, and prints @var{object} like @code{prin1}, but does it > >> +in a prettier way. > > > > This text references arguments like @var{object} that are named > > differently in the @defun line. > > Indeed. Assuming you understood what I meant to say, do you have > a recommendation of how to write it? Something like this: The function can be called to pretty-print either a region of text, presumably containing the printed representation of one or more objects, or to pretty-print an object. In the first case, the function must be called with 2 arguments, @var{object-or-beg} and @var{stream-or-end}, which are integer buffer positions that define the region; in the second case, @var{object-or-beg} is the object to print and @var{stream-or-end} is the stream to which to print it, which defaults to @code{standard-output} if nil or omitted. > Or maybe, I should leave `pp` alone and add a new `pp-region` > function instead instead of combining two different calling conventions > on a single function? That might be better, indeed, both for documentation and for usage. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 18:08:44 2023 Received: (at 63861-done) by debbugs.gnu.org; 17 Jun 2023 22:08:44 +0000 Received: from localhost ([127.0.0.1]:52755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAe68-0004uL-9D for submit@debbugs.gnu.org; Sat, 17 Jun 2023 18:08:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAe64-0004u3-Ix for 63861-done@debbugs.gnu.org; Sat, 17 Jun 2023 18:08:43 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 401A81001FC; Sat, 17 Jun 2023 18:08:35 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 59804100083; Sat, 17 Jun 2023 18:08:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1687039714; bh=lcc1edJjUnDJWsQz7XBqQOz0GFgN7f0cAX6oHFz8d9Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eF/lCSuN816eKgMO0TevwL7llkwzWmO9HFJhqMQuqh21bJo1UdTAN06CbCYFg9OMr JqAs5Bfcj7F8U+HAeu640tmPcRarRnNYb/3oTuwXAbT4zJeFN4WFssCYZMOSuxAQJO aIjkAzRPbyEWyiQkqT0/VsAJwNib3Tpe1BP67bFhp9Jsxs1zc0uviTcdLZExTN9Jyj iDq62rr73XNOGTVzL9nHQYEuWiuojG6sZnzzFhj8Z29/cv9zKkmLObUqHPDXPdAs8W 8WprUxVmBB55Ce6sCuSaxCzZK7duNRcl/55BqsAWY/cFGASXmEeH/6H9BdbTRNMC7x z4rFve/vjdEsQ== Received: from pastel (unknown [45.72.207.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 396AE120910; Sat, 17 Jun 2023 18:08:34 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: <83ttv6oxa3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Jun 2023 19:42:44 +0300") Message-ID: References: <83fs799jmi.fsf@gnu.org> <83r0qs74qs.fsf@gnu.org> <83pm5zws19.fsf@gnu.org> <83h6r6sl50.fsf@gnu.org> <83ttv6oxa3.fsf@gnu.org> Date: Sat, 17 Jun 2023 18:08:33 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.169 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861-done Cc: 63861-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Or maybe, I should leave `pp` alone and add a new `pp-region` >> function instead instead of combining two different calling conventions >> on a single function? > > That might be better, indeed, both for documentation and for usage. Done. That also leads to fewer visible changes, so it's good (I just kept `pp-buffer` instead of adding `pp-region`). I pushed the result (after fixing the test problems with option B). Thanks, Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 20 16:56:43 2023 Received: (at 63861) by debbugs.gnu.org; 20 Jun 2023 20:56:43 +0000 Received: from localhost ([127.0.0.1]:59859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBiP4-00073a-PQ for submit@debbugs.gnu.org; Tue, 20 Jun 2023 16:56:43 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45335) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBiP3-00073O-8M for 63861@debbugs.gnu.org; Tue, 20 Jun 2023 16:56:41 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2AEC81001FC; Tue, 20 Jun 2023 16:56:35 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 15159100023; Tue, 20 Jun 2023 16:56:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1687294594; bh=Bas952RT09vm2ggQt8bwoGj6v8OsiFWlp1oYrW8Sncw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=S9eFVjIsCqeXHcsUCdX6H0GuBxzHA+dWWgFq9+bMRMG8nPXWwBTEeHCAJjq9Z96BY HYnPPTTbF7pvIxZSBfkvqxcXNw54RpjIm3eIPLlxNm46XxsMemoMdoZSiGZ+wSCam5 EU6St0hQ4ZbdHZxrS5meQk8NrfwVQhatt2pJIMDZhkouurXbyc0eruOJp+cVi0dPY5 xYD0dgOGgVEXCZc6igz/fQFeBqWTSeyfcg1a8fJIjOQSJa2Z3qamYczqBha9seWBxz qSVfACQoLu9eXC+9O4VoIvPl9KhaPTQLMmoQ3lQ9a7o+JhC/T4SszN23xMrBwET3Py QBW5fXrOk9YFA== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 037ED120147; Tue, 20 Jun 2023 16:56:34 -0400 (EDT) From: Stefan Monnier To: Thierry Volpiatto Subject: Re: bug#63861: [PATCH] pp.el: New "pretty printing" code In-Reply-To: (Stefan Monnier's message of "Thu, 08 Jun 2023 18:35:05 -0400") Message-ID: References: <87edmnics1.fsf@posteo.net> <87bkhpvm35.fsf@posteo.net> Date: Tue, 20 Jun 2023 16:56:33 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.075 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63861 Cc: 63861@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > So, by file, from fastest to slowest: > > foo.el (0.859482743 0 0.0) (pp-buffer) t > foo.el (0.890402623 0 0.0) (pp-buffer) nil > foo.el (4.62344853 4 1.7225397670000002) (tv/pp-region (point-min) (point-max)) t > foo.el (4.687414465 4 1.7116580980000002) (tv/pp-region (point-min) (point-max)) nil > foo.el (7.932661181 1 0.3435169600000001) (pp-region (point-min) (point-max)) t > foo.el (196.183345212 1 0.618591124) (pp-region (point-min) (point-max)) nil > foo.el (2997.739238575 505 105.82851685700001) (let ((s (read (current-buffer)))) (erase-buffer) (pp-emacs-lisp-code s)) t [...] > We also see that `pp-emacs-lisp-code` is *much* slower. I don't include > other results for this function in this email because they're still > running :-) OK, they're done running (well, I had to re-run them because of a power failure in between). The tests failed on `test-load-history.el` with: Error: wrong-type-argument (number-or-marker-p cl--defmethod-doc-pos) so it looks like it tickles a bug somewhere in `pp-emacs-lisp-code`. As for the performance: "foo.el" (3207.572643287 505 111.459754959) (... (pp-emacs-lisp-code s)) t "foo.el" (121171.97145393 692 103.67438615900001) (... (pp-emacs-lisp-code s)) nil "test-bookmark-alist.el" (102462.563603419 5456 921.614736375) (... (pp-emacs-lisp-code s)) t "test-bookmark-alist.el" (191188.84323175802 7493 847.82675889) (... (pp-emacs-lisp-code s)) nil So the `lisp-ppss` patch speeds up `pp-emacs-lisp-code` by a factor 37x on `foo.el` and a factor a bit less than 2x for `test-bookmark-alist.el`. We also see that `pp-emacs-lisp-code` (with the `lisp-ppss` patch) is more than 300x slower than the new `pp-fill` code on `foo.el` and more than 3000x slower than the new `pp-fill` code on `test-bookmark-alist.el`. Admittedly, these are not cases for which that code was designed (these files hold data rather than code). Stefan From unknown Fri Aug 15 12:48:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 19 Jul 2023 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator