From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 64535@debbugs.gnu.org
Subject: bug#64535: 30.0.50; Spurious newlines in `prin1` output
Date: Sat, 15 Jul 2023 10:29:54 +0300 [thread overview]
Message-ID: <835y6leiod.fsf@gnu.org> (raw)
In-Reply-To: <jwva5vyef22.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 14 Jul 2023 10:46:28 -0400)
> 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?
next prev parent reply other threads:[~2023-07-15 7:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-08 19:19 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
2023-07-09 5:09 ` Eli Zaretskii
2023-07-13 23:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-14 13:38 ` Eli Zaretskii
2023-07-14 14:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-15 7:29 ` Eli Zaretskii [this message]
2023-07-15 15:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-10 16:00 ` Gregory Heytings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=835y6leiod.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=64535@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.