GNU bug report logs - #64535
30.0.50; Spurious newlines in `prin1` output

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64535 in the body.
You can then email your comments to 64535 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Spurious newlines in `prin1` output
Date: Sat, 08 Jul 2023 15:19:13 -0400

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,

Message #8 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Sun, 09 Jul 2023 08:09:49 +0300

> 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" <bug-gnu-emacs <at> gnu.org>
> 
> `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.

Message #13 received at 64535-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64535-done <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
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.

> 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

Message #16 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Fri, 14 Jul 2023 16:38:08 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 64535-done <at> 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?

Message #19 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Fri, 14 Jul 2023 10:46:28 -0400

>> 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

Message #22 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Sat, 15 Jul 2023 10:29:54 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 64535 <at> 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?

Message #25 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64535 <at> debbugs.gnu.org
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Sat, 15 Jul 2023 11:20:50 -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?

It's saying that your proposal is to replace the current hack with
another hack, so indeed: not interested.


        Stefan

Message #28 received at 64535 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64535 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Thu, 10 Aug 2023 16:00:39 +0000

>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.