Move the entry about 'format' into Incompatible Lisp Changes

* etc/NEWS: Move the entry about 'format' refraining from allocating
new strings into Incompatible Lisp Changes.  (Bug#28625)

diff --git a/etc/NEWS b/etc/NEWS
index 7f89ef92ec436d96e4ad5d76567206f71b94e521..2b8ef4da1d78c9cd2e5bb5cbc3734277f8ba5f5e 100644 (file)
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1361,6 +1361,15 @@ non-nil, but the code returned the list in the increasing order of
 priority instead.  Now the code does what the documentation says it
 should do.
 
++++
+** 'format' now avoids allocating a new string in more cases.
+'format' was previously documented to return a newly-allocated string,
+but this documentation was not correct, as (eq x (format x)) returned
+t when x was the empty string.  'format' is no longer documented to
+return a newly-allocated string, and the implementation now takes
+advantage of the doc change to avoid making copies of strings in
+common cases like (format "foo") and (format "%s" "foo").
+
 ---
 ** The function 'eldoc-message' now accepts a single argument.
 Programs that called it with multiple arguments before should pass
@@ -1556,13 +1565,6 @@ Emacs integers with %e, %f, or %g conversions.  For example, on these
 hosts (eql N (string-to-number (format "%.0f" N))) now returns t for
 all Emacs integers N.
 
-+++
-** 'format' is no longer documented to return a newly-allocated string.
-This documentation was not correct, as (eq x (format x)) returned t
-when x was the empty string.  'format' now takes advantage of the doc
-change to avoid making copies of strings in common cases like (format
-"foo") and (format "%s" "foo").
-
 ---
 ** Calls that accept floating-point integers (for use on hosts with
 limited integer range) now signal an error if arguments are not