From unknown Sat Aug 09 13:01:35 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#64535 <64535@debbugs.gnu.org> To: bug#64535 <64535@debbugs.gnu.org> Subject: Status: 30.0.50; Spurious newlines in `prin1` output Reply-To: bug#64535 <64535@debbugs.gnu.org> Date: Sat, 09 Aug 2025 20:01:35 +0000 retitle 64535 30.0.50; Spurious newlines in `prin1` output reassign 64535 emacs submitter 64535 Stefan Monnier severity 64535 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 15:19:38 2023 Received: (at submit) by debbugs.gnu.org; 8 Jul 2023 19:19:38 +0000 Received: from localhost ([127.0.0.1]:45224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIDT0-000338-1M for submit@debbugs.gnu.org; Sat, 08 Jul 2023 15:19:38 -0400 Received: from lists.gnu.org ([209.51.188.17]:56898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIDSx-000330-LF for submit@debbugs.gnu.org; Sat, 08 Jul 2023 15:19:36 -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 1qIDSx-0006pu-F2 for bug-gnu-emacs@gnu.org; Sat, 08 Jul 2023 15:19:35 -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 1qIDSv-0003T3-Rm for bug-gnu-emacs@gnu.org; Sat, 08 Jul 2023 15:19:35 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 36C171000C4 for ; Sat, 8 Jul 2023 15:19:31 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0EBF91000B9 for ; Sat, 8 Jul 2023 15:19:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1688843966; bh=VGaA7D8cmH9MwHnjg9Bz0qtsg3Ej7Yojz+vhzDTOXqQ=; h=From:To:Subject:Date:From; b=UD/IGFAvwoncEvbK1DaN92y8tlHHrIHPtajKcjK8Vdd8Ob/ev/oF2SjscauhQT867 qTRm0qkg3UcEDBNX8Ag1L+XHbu8sy5UZJPP+uyuCnf/BOZOjdhRBNc1QKcVWtG84jQ J9EX1WJj2G0Gy0rQfQKUIp/+S65ZRht0ERhWCn8+Xi6JWJk2OncjDOYbUyUxGc7Ly5 LG5hTq4yzGdnrezWqEdPfdKhsIeL9q5VNTd2J2A5d1bSkkBCGcZgVHmOJ9hHVDVsEh m1YUe9Am0mTC28UqI0uShUv1tDyteL6iDw4euwk9CWIidTnqf+oMaZGvqVvMAPRytg 4UZuGLDaeUhRQ== Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA27912033B for ; Sat, 8 Jul 2023 15:19:25 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Spurious newlines in `prin1` output Date: Sat, 08 Jul 2023 15:19:13 -0400 Message-ID: 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 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 (--) Package: Emacs Version: 30.0.50 `prin1` never inserts newlines unless they're within strings (and that can be controlled with `print-escape-newlines`), right? Right? Nope: it does insert newlines inside char-table when reaching the 3rd level of subtables. This was done to work around the long lines problem in redisplay (bug#2866), but it's far from the only case where `prin1` can emit a long line, and we've significantly improved our handling of long lines. Can we get rid of this quirk now, please? Stefan diff --git a/src/print.c b/src/print.c index 5c95aeb9a20..aae998692fb 100644 --- a/src/print.c +++ b/src/print.c @@ -2544,11 +2544,6 @@ print_object (Lisp_Object obj, Lisp_Object printcharfun, bool escapeflag) } case PVEC_SUB_CHAR_TABLE: { - /* Make each lowest sub_char_table start a new line. - Otherwise we'll make a line extremely long, which - results in slow redisplay. */ - if (XSUB_CHAR_TABLE (obj)->depth == 3) - printchar ('\n', printcharfun); print_c_string ("#^^[", printcharfun); int n = sprintf (buf, "%d %d", XSUB_CHAR_TABLE (obj)->depth, From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 09 01:09:54 2023 Received: (at 64535) by debbugs.gnu.org; 9 Jul 2023 05:09:54 +0000 Received: from localhost ([127.0.0.1]:45542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIMgC-0004m8-Eu for submit@debbugs.gnu.org; Sun, 09 Jul 2023 01:09:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIMg9-0004ls-Gy for 64535@debbugs.gnu.org; Sun, 09 Jul 2023 01:09: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 1qIMg3-0002FJ-Fk; Sun, 09 Jul 2023 01:09:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wHPpbL+/ppAXa1G8MssEneUjJRWN0k7auAC0FlOae3E=; b=fUuFpw2dEu/P M2MR08gHgtZhGxjt/p80AbjjlkJlzyxu6W1E8roJYeZKq32iEW7hXvgu0PgVuyNhzqbUnZkjia0zm pXuXf+R6QDa0NWzwXlS0ivPv7vPagtivzrNrmRFZAsva4uosCOYAfEF1So1AIjiZHEeEKoFY908Sk 71raVF+9vuA80hCl581Oy42kyNXGC3PRZFo4rbcuLXVP9Cjwd8BKWEmK7hpz9WAhDIf040Q2kbym2 gWrdcw8zJMXua/hDYwXT03pDhrGaSzBvXMjsb5cbN/j6lEuaCUUSgV7cnMVndOHVidCbxRhsWxLbR G/S9e4y467/wqV2DnS23Mw==; 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 1qIMg2-0003k2-Jp; Sun, 09 Jul 2023 01:09:43 -0400 Date: Sun, 09 Jul 2023 08:09:49 +0300 Message-Id: <83v8etbrhe.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64535 Cc: 64535@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 08 Jul 2023 15:19:13 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > `prin1` never inserts newlines unless they're within strings (and that > can be controlled with `print-escape-newlines`), right? Right? > > Nope: it does insert newlines inside char-table when reaching the 3rd > level of subtables. This was done to work around the long lines problem > in redisplay (bug#2866), but it's far from the only case where `prin1` > can emit a long line, and we've significantly improved our handling of > long lines. > > Can we get rid of this quirk now, please? I'm okay with getting rid of it, with two conditions: . removing newline insertion in the scenario of bug#2866 leaves Emacs sufficiently performant, even in the unoptimized build, and . we will still insert a newline if long-line-threshold is nil IOW, I don't want us to bring back regressions as result of this cleanup. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 19:12:06 2023 Received: (at 64535-done) by debbugs.gnu.org; 13 Jul 2023 23:12:06 +0000 Received: from localhost ([127.0.0.1]:41046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK5Th-0001tL-Vh for submit@debbugs.gnu.org; Thu, 13 Jul 2023 19:12:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK5Tc-0001sn-Kd for 64535-done@debbugs.gnu.org; Thu, 13 Jul 2023 19:12:03 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5FC5A80575; Thu, 13 Jul 2023 19:11:55 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5D44C8026A; Thu, 13 Jul 2023 19:11:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689289909; bh=vEE9m+gcbjJZOMo9c5lPFf9kPKt2YJegqDM9egSq8HI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PE2K2JhdfCWXTKmaWbl/1BqSOaUkVKvhJcxXVn1D6hIoVj0X3397ThysLrJ/WUxI7 t1dfsIxpjWwEgEBcDk+O01GsXjx9MI0636ioFd71AA7P49qvjI9Jll5yrAsesWi5ru Fea+f9bb2UCXD5b0dqKtiDWqR+Yav2M98sWz9//W9tKv+lQTYgE1nQ4lqDbxFnXKMS 2LdCk2j1aE2BkRY0LTxR9oDPeM6mcOoRaL9xFGcOI8eY6EqmZYxyWxbs7vxDDTiWnN PozX5qUgZ5801cs8xi6mSC0tKjMrLMfRT2PQUUFJIdgh8btACL90ZzhebMEZTFMIf0 Qu/T65uOqofzw== Received: from pastel (unknown [104.247.239.133]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B97E120278; Thu, 13 Jul 2023 19:11:49 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output In-Reply-To: <83v8etbrhe.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Jul 2023 08:09:49 +0300") Message-ID: References: <83v8etbrhe.fsf@gnu.org> Date: Thu, 13 Jul 2023 19:11:48 -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 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: -0.0 (/) X-Debbugs-Envelope-To: 64535-done Cc: 64535-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 (---) >> Can we get rid of this quirk now, please? > > I'm okay with getting rid of it, with two conditions: > > . removing newline insertion in the scenario of bug#2866 leaves > Emacs sufficiently performant, even in the unoptimized build, and > . we will still insert a newline if long-line-threshold is nil That means we'd keep the code and make it even larger. > IOW, I don't want us to bring back regressions as result of > this cleanup. That wouldn't be a cleanup, then. IOW you're asking me to make the quirk even bigger. I'd rather keep the quirk as-is, in that case. Thanks, closing, Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 09:38:03 2023 Received: (at 64535) by debbugs.gnu.org; 14 Jul 2023 13:38:03 +0000 Received: from localhost ([127.0.0.1]:41733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKIzj-00011B-4G for submit@debbugs.gnu.org; Fri, 14 Jul 2023 09:38:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKIze-000101-0Y for 64535@debbugs.gnu.org; Fri, 14 Jul 2023 09:37:59 -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 1qKIzX-0004UU-F5; Fri, 14 Jul 2023 09:37:51 -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=iq+bRgfa9LXXR4biUfduKtP6Koe4oxRiLP11ZS2VmO8=; b=kxJi0XNr4wsj JJYY/ttZ34CWhS77/3UmNAaJeTRHVUMFijktBAsloRojaMu6qcxdjALYOvh5hnabDqqRJ8hLYGxJz doc+DGubNFKEsQ1YQF9fASq0oejZnvi6s4Sf8v69K8uQKHG125mR3TbmqfjLGdstWj6obllrA0vBo dFmWVdimAAeZG7+5aMOFqsAn4rLsNUty3wr6IfRdcUyq/wrUYFFjDZVwk5I7KeoIAMjICRNokh9VM xZ7AIa0j+ax1atbyJE702dswVcywyxKzuHJ2JvJg4yFiko3ObHSWVKnjoPAS2G1l7L5jZxVL+LiAm h6sC5UEo63/Px9dNJXWTpQ==; 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 1qKIzW-0006j2-Ro; Fri, 14 Jul 2023 09:37:51 -0400 Date: Fri, 14 Jul 2023 16:38:08 +0300 Message-Id: <83cz0ufwan.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 13 Jul 2023 19:11:48 -0400) Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output References: <83v8etbrhe.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64535 Cc: 64535@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: 64535-done@debbugs.gnu.org > Date: Thu, 13 Jul 2023 19:11:48 -0400 > > >> Can we get rid of this quirk now, please? > > > > I'm okay with getting rid of it, with two conditions: > > > > . removing newline insertion in the scenario of bug#2866 leaves > > Emacs sufficiently performant, even in the unoptimized build, and > > . we will still insert a newline if long-line-threshold is nil > > That means we'd keep the code and make it even larger. The second item, maybe. What about the first -- is bug#2866 solved by long-line handling in Emacs 29? > > IOW, I don't want us to bring back regressions as result of > > this cleanup. > > That wouldn't be a cleanup, then. IOW you're asking me to make the > quirk even bigger. I'd rather keep the quirk as-is, in that case. Sorry, I don't understand: what was the reason for you to start this discussion? IOW, why is it good to get rid of the code which inserts those newlines? I don't suppose you wanted to bring back the bug which was the reason for adding that code, did you? I can suggest another solution: remove that code, but make sure long-line-threshold is reset to its default value locally in the buffer where prin1 is producing its output? Would that be more acceptable? From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 10:46:44 2023 Received: (at 64535) by debbugs.gnu.org; 14 Jul 2023 14:46:44 +0000 Received: from localhost ([127.0.0.1]:43193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKK45-0003co-Nf for submit@debbugs.gnu.org; Fri, 14 Jul 2023 10:46:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKK43-0003ca-LE for 64535@debbugs.gnu.org; Fri, 14 Jul 2023 10:46:36 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 60566806BB; Fri, 14 Jul 2023 10:46:30 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 142C58065C; Fri, 14 Jul 2023 10:46:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689345989; bh=kJPlR7J5LQ054TaWV/auP//zlQGx7KK9ODkK2BEDvk4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LTHUhcgtsNnRUgOW1xwt7VkL37HOJLK2PESL3VYd8LHe5KYoOO0cNejCKbdlufLJ5 gjyjJnw9pM3LjhKlynLMLx79zz6y09kZ8fkT94suDci8mwabzeFKnJsspQbMVR4ZGY ZukK2nZhF7TjwT8ps+GtGym+ks0UjzkWBf7Kk55f/9jUqkrWW7WlbGbcFxJ+okMVTL 6pPRbzlc44aVy0TV6SIK2qIqUjQFqoPd0pL/v5cUrsoIHVAaCTcK8JIr2KrMKvek9o TF8XV8xM4YdfUaJ7I/G4jYOybaMBF0NYNz4R+0LnL4Mbt6f10dSMAIWN1D6GX89MLi vY5zUCzCoKQ0Q== Received: from pastel (unknown [104.247.239.133]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E21F01201F0; Fri, 14 Jul 2023 10:46:28 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output In-Reply-To: <83cz0ufwan.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 16:38:08 +0300") Message-ID: References: <83v8etbrhe.fsf@gnu.org> <83cz0ufwan.fsf@gnu.org> Date: Fri, 14 Jul 2023 10:46:28 -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 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: 64535 Cc: 64535@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 (---) >> That means we'd keep the code and make it even larger. > The second item, maybe. What about the first -- is bug#2866 solved by > long-line handling in Emacs 29? In my tests, yes. >> > IOW, I don't want us to bring back regressions as result of >> > this cleanup. >> That wouldn't be a cleanup, then. IOW you're asking me to make the >> quirk even bigger. I'd rather keep the quirk as-is, in that case. > Sorry, I don't understand: what was the reason for you to start this > discussion? IOW, why is it good to get rid of the code which inserts > those newlines? Because it's a wart. > I can suggest another solution: remove that code, but make sure > long-line-threshold is reset to its default value locally in the > buffer where prin1 is producing its output? Would that be more > acceptable? Bug#2866 fundamentally had nothing to do with `prin1`. It was just another instance of "Emacs freezes when encountering a long line". The patch installed back then fixed the problem for one particular (and quite uncommon) way to end up with a long line. There are millions more ways to get that result, as you know, many of them much more common. The only thing special about Bug#2866 is that it happened to be a case where the long line was generated by our own code and where Handa bothered to write a hack that kinda worked around the problem, leaving all the many other ways to walk into that problem just as opened as before. We now have a general way to solve the problem. I don't think it's always absolutely perfect, but it's definitely good enough that we can get rid of this odd hack. And those user who set `long-line-threshold` to nil *and* happen to reproduce just the recipe in Bug#2866 would get what they ask for, IMO. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 03:29:41 2023 Received: (at 64535) by debbugs.gnu.org; 15 Jul 2023 07:29:41 +0000 Received: from localhost ([127.0.0.1]:43950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKZim-0000rQ-Ic for submit@debbugs.gnu.org; Sat, 15 Jul 2023 03:29:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKZil-0000rC-3c for 64535@debbugs.gnu.org; Sat, 15 Jul 2023 03:29:40 -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 1qKZif-0008Cc-Gh; Sat, 15 Jul 2023 03:29:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xffDoLF2BGN8a19tEGuW7tal+FaUzPzPQwUycGe8ydM=; b=jwiPqek/hQV6 rW2jHub3sMkYcz+U3w2/HFz4yxKdx9NeE7s0AnQlfpQY0qQrExQGZekx1uJ9ETzAw/xMFj5YVipmP 432Ag6pEk6e3lwlsbT4aeUGeM84RV+6hWNWQ5A/utuahfPTdPQD7xiFaD7TgsETinp5WCMhLa9fvU vB+wjdBPQPRWdemYqoEZewU1hjIi3TmbWFLiZmNsPGt2Nbxa43UTJL1gTAgzy+c3QTx83B/dCLW1+ LfYp98nbCboomYZir1x9zl7vrIrtMu2Hefq1o7ATeMxd+Xb8ybM1C/ToSHy1ZgnOVxfRLH5a7K5dx 85MXfsNZbsLiga3J3sCjJQ==; 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 1qKZif-000383-0R; Sat, 15 Jul 2023 03:29:33 -0400 Date: Sat, 15 Jul 2023 10:29:54 +0300 Message-Id: <835y6leiod.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Fri, 14 Jul 2023 10:46:28 -0400) Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output References: <83v8etbrhe.fsf@gnu.org> <83cz0ufwan.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64535 Cc: 64535@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: 64535@debbugs.gnu.org > Date: Fri, 14 Jul 2023 10:46:28 -0400 > > > I can suggest another solution: remove that code, but make sure > > long-line-threshold is reset to its default value locally in the > > buffer where prin1 is producing its output? Would that be more > > acceptable? > > Bug#2866 fundamentally had nothing to do with `prin1`. It was just > another instance of "Emacs freezes when encountering a long line". > > The patch installed back then fixed the problem for one particular (and > quite uncommon) way to end up with a long line. There are millions more > ways to get that result, as you know, many of them much more common. > > The only thing special about Bug#2866 is that it happened to be a case > where the long line was generated by our own code and where Handa > bothered to write a hack that kinda worked around the problem, leaving > all the many other ways to walk into that problem just as opened > as before. > > We now have a general way to solve the problem. I don't think it's > always absolutely perfect, but it's definitely good enough that we can > get rid of this odd hack. And those user who set `long-line-threshold` > to nil *and* happen to reproduce just the recipe in Bug#2866 would get > what they ask for, IMO. Is that a "no" to my proposal above? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 11:21:02 2023 Received: (at 64535) by debbugs.gnu.org; 15 Jul 2023 15:21:02 +0000 Received: from localhost ([127.0.0.1]:45797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKh4w-00030M-AM for submit@debbugs.gnu.org; Sat, 15 Jul 2023 11:21:02 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKh4s-0002zk-1s for 64535@debbugs.gnu.org; Sat, 15 Jul 2023 11:21:01 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C03B980712; Sat, 15 Jul 2023 11:20:52 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9AB9D8062B; Sat, 15 Jul 2023 11:20:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689434451; bh=MilcXp+Pk0ExYc1WqOCWVEcH+0g7n3vy8FvH+Sg0/JU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=agOrpwJYVqhMEyuJIS6szFzF7iz1wEPvXD4fANsqdnJ5jxXteY1VGjlLLR4gIcbTS d69uQeh85Vs5pRlxmwRAUYGIxpeHcVMfgD6H1bEbHkUorZ+1fowdyEY1AXhmb1Mbko w5owJ2ANw1DZxLwRVt7X3hbNmv9Ln+m4bAHYM81EzBerarV8EPIS5b+jRxhNVswRet zDTtfgQotNvZqDEpZo96fKCriYZgxDJLcjCb/nJCy/0bhqMZHzrx9YOPhEGlEs7eNn DyujbmJcVIbdFufv/iqBmujHXMNTgXY85Ne/e+VLJ7QV9jY3+5zzNvy6UmLIhsNlSC lI2WcwJiAAsVg== Received: from pastel (unknown [108.175.230.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7635812024D; Sat, 15 Jul 2023 11:20:51 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output In-Reply-To: <835y6leiod.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Jul 2023 10:29:54 +0300") Message-ID: References: <83v8etbrhe.fsf@gnu.org> <83cz0ufwan.fsf@gnu.org> <835y6leiod.fsf@gnu.org> Date: Sat, 15 Jul 2023 11:20:50 -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.125 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: 64535 Cc: 64535@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 can suggest another solution: remove that code, but make sure >> > long-line-threshold is reset to its default value locally in the >> > buffer where prin1 is producing its output? Would that be more >> > acceptable? >> >> Bug#2866 fundamentally had nothing to do with `prin1`. It was just >> another instance of "Emacs freezes when encountering a long line". >> >> The patch installed back then fixed the problem for one particular (and >> quite uncommon) way to end up with a long line. There are millions more >> ways to get that result, as you know, many of them much more common. >> >> The only thing special about Bug#2866 is that it happened to be a case >> where the long line was generated by our own code and where Handa >> bothered to write a hack that kinda worked around the problem, leaving >> all the many other ways to walk into that problem just as opened >> as before. >> >> We now have a general way to solve the problem. I don't think it's >> always absolutely perfect, but it's definitely good enough that we can >> get rid of this odd hack. And those user who set `long-line-threshold` >> to nil *and* happen to reproduce just the recipe in Bug#2866 would get >> what they ask for, IMO. > > Is that a "no" to my proposal above? It's saying that your proposal is to replace the current hack with another hack, so indeed: not interested. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 12:00:43 2023 Received: (at 64535) by debbugs.gnu.org; 10 Aug 2023 16:00:43 +0000 Received: from localhost ([127.0.0.1]:43891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU85b-0000Tl-0v for submit@debbugs.gnu.org; Thu, 10 Aug 2023 12:00:43 -0400 Received: from heytings.org ([95.142.160.155]:32776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU85Z-0000Tc-5F for 64535@debbugs.gnu.org; Thu, 10 Aug 2023 12:00:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1691683240; bh=NmP4R0IKWO1fukgkwHmsb04y+4DAItOC2IrF/6oQcEA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=7N5LvOgbZ32vemeYCyi0VxST8pk8XZ1lw+Z3jTuGl7cw5ha8ui3mSQFHOzslYMTxU 7ySjzHvK/qa+WqILT+RHWNUR1eEAd65unt/E4yHIGusud63g/sgbkC5j5BW/iVmNQV tVkZO1nNrmZ0FISdxVE2QiAReGpV5Ng4kIX+gWe3udYwTiorl+I0RF2OpBm09fWFkW l/nP/y+gLa1XqmmRnM5/i8AoXUMJsh2vUjfKI7nkiHQYTo1yUPZAz97japtjFMPSDE y909w433uj0V32Q4ZHFAbgBvD/lARYtvtyV8sKdNf/RrhDO+HehXKMndGd71PUPz1r l74/UV1T8onsA== Date: Thu, 10 Aug 2023 16:00:39 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output In-Reply-To: Message-ID: <3283828c97f247a07062@heytings.org> References: <83v8etbrhe.fsf@gnu.org> <83cz0ufwan.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64535 Cc: 64535@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 (-) > > We now have a general way to solve the problem. I don't think it's > always absolutely perfect, but it's definitely good enough that we can > get rid of this odd hack. And those user who set `long-line-threshold` > to nil *and* happen to reproduce just the recipe in Bug#2866 would get > what they ask for, IMO. > FWIW, I agree with Stefan here. long-line-threshold is a fire escape, and users are advised to not change its value: "There is no reason to change that value except for debugging purposes." So his proposed fix, which removes a workaround installed by Mattias in May 2022, is safe. From unknown Sat Aug 09 13:01:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 08 Sep 2023 11:24:07 +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