bug#23394: generate-new-buffer-name behaviour changed

bug#23394: generate-new-buffer-name behaviour changed

[Chaitanya Koparkar]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

In GNU Emacs 25.1.50.1 (x86_64-apple-darwin15.3.0, NS appkit-1404.34 Version 10.11.3 (Build 15D21)) of 2016-04-17 built on Chaitanyas-Macbook-Pro.localRepository revision: 3de30674d7aa79c9f366f65c9f30aec2c8963b54Windowing system distributor 'Apple', version 10.3.1404Configured using: 'configure --with-ns'
Configured features:JPEG IMAGEMAGICK NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
Important settings:  value of $LANG: en_IN.UTF-8  locale-coding-system: utf-8-unix
Steps to reproduce:
* Start emacs and open a buffer named "*scratch*"
* Run `(generate-new-buffer-name "*scratch*")`
* The expected return value is "*scratch*<2>"   but instead it returns "*scratch*<1>"
I'm guessing, this commit introduced it, https://github.com/emacs-mirror/emacs/commit/b4c7869e5e1bb0bb33379b25ff830e721761a7bf.
Note the `++count` vs  just `count`.
This is just a guess however and it could be completely wrong.
Thanks,Chaitanya 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1714 bytes --]

bug#23394: generate-new-buffer-name behaviour changed

[Glenn Morris]

Chaitanya Koparkar wrote:

> Steps to reproduce:
> * Start emacs and open a buffer named "*scratch*"
> * Run `(generate-new-buffer-name "*scratch*")`
> * The expected return value is "*scratch*<2>" but instead it returns
> "*scratch*<1>"
> I'm guessing, this commit introduced it,
> https://github.com/emacs-mirror/emacs/commit/b4c7869e5e1bb0bb33379b25ff830e721761a7bf.
> Note the `++count` vs  just `count`.

Looks to me like you are right.
generate-new-buffer-name is documented to start from <2>, not <1>.

Paul, please could you take a look?

bug#23394: generate-new-buffer-name behaviour changed

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 78 bytes --]

Thanks for reporting the bug. I installed the attached patch to fix the typo.

[-- Attachment #2: 0001-Fix-generate-new-buffer-name-increment-typo.patch --]
[-- Type: text/x-diff, Size: 1075 bytes --]

From 9f2c5f395113abcfe556eabd3417e034df653ad4 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 30 Apr 2016 16:36:36 -0700
Subject: [PATCH] Fix generate-new-buffer-name increment typo

Problem reported by Chaitanya Koparkar (Bug#23394).
* src/buffer.c (Fgenerate_new_buffer_name): Increment count when
generating a new buffer.  This fixes a typo I introduced in
2014-04-05T00:04:58Z!eggert@cs.ucla.edu.
---
 src/buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/buffer.c b/src/buffer.c
index e0fbab6..06467d2 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1077,7 +1077,7 @@ is first appended to NAME, to speed up finding a non-existent buffer.  */)
     {
       char number[INT_BUFSIZE_BOUND (ptrdiff_t) + sizeof "<>"];
       AUTO_STRING_WITH_LEN (lnumber, number,
-			    sprintf (number, "<%"pD"d>", count));
+			    sprintf (number, "<%"pD"d>", ++count));
       Lisp_Object gentemp = concat2 (genbase, lnumber);
       if (!NILP (Fstring_equal (gentemp, ignore))
 	  || NILP (Fget_buffer (gentemp)))
-- 
2.5.5

bug#23394: generate-new-buffer-name behaviour changed

[Chaitanya Koparkar]

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

Awesome!Thanks :-)
> Thanks for reporting the bug. I installed the attached patch to fix the typo.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 370 bytes --]