bug#64535: 30.0.50; Spurious newlines in `prin1` output

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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,

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Eli Zaretskii]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Eli Zaretskii]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Eli Zaretskii]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#64535: 30.0.50; Spurious newlines in `prin1` output

[Gregory Heytings]

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