bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67180: 30.0.50; 'pp-to-string' emits extra newline


From: Stefan Monnier
Subject: bug#67180: 30.0.50; 'pp-to-string' emits extra newline
Date: Thu, 16 Nov 2023 09:16:02 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Eshel Yaron [2023-11-15 14:10:39] wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> On Emacs 29 and earlier, with `-Q`, we have:
>>>> 
>>>> (pp-to-string "foo")
>>>>   => "\"foo\""
>>>> 
>>>> On master with `-Q`, we get an extra newline at the end of the string:
>>>> 
>>>> (pp-to-string "foo")
>>>>   => "\"foo\"
>>>> "
>>
>> Is that a problem?
>
> FWIW, I think that this change is for the better, but it is
> incompatible, and sadly it broke `agda2-mode`.  (In some sense this
> probably Agda's "fault", because I don't really understand why they're
> using `pp-to-string` the way they do.)  My suggestion was simply to
> explicitly mention this new behavior in NEWS or some such.

Like this?

    diff --git a/etc/NEWS b/etc/NEWS
    index 23f4a8b5311..2dcb2f5664e 100644
    --- a/etc/NEWS
    +++ b/etc/NEWS
    @@ -1099,6 +1099,9 @@ showcases all their customization options.
     
     * Incompatible Lisp Changes in Emacs 30.1
     
    +** 'pp' and 'pp-to-string' now always include a terminating newline.
    +In the past they included a terminating newline in most cases but not all.
    +
     ** 'buffer-match-p' and 'match-buffers' take '&rest args'.
     They used to take a single '&optional arg' and were documented to use
     an unreliable hack to try and support condition predicates that


-- Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]