From: Eli Zaretskii Date: Sat, 7 Oct 2017 11:32:12 +0000 (+0300) Subject: Move the entry about 'format' into Incompatible Lisp Changes X-Git-Tag: emacs-26.0.90~45^2~6 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=dc6ae15a8d3b68ba2e12c71abc830b06dcc424a0;p=emacs.git 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 7f89ef92ec4..2b8ef4da1d7 100644 --- 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