GNU bug report logs - #77312
[PATCH] Add uniquify-get-unique-names

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 77312 <at> debbugs.gnu.org
Subject: bug#77312: [PATCH] Add uniquify-get-unique-names
Date: Fri, 20 Jun 2025 11:12:47 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 10/06/2025 18:05, Spencer Baugh wrote:
>>> In order to avoid them, we could only attach the property if the buffer
>>> name has really changed, such that no strings have to be copied. The
>>> property could be called `uniquify-orig-buffer-name`. If the property is
>>> present, it holds the original buffer name, if it is not present the
>>> string itself is the original buffer name.
>> All else being equal, I think changing uniquify-get-unique-names to
>> return a list of strings which have the original buffer names as a
>> property is a reasonable and easy thing to do.  uniquify.el is generally
>> pretty allocation heavy, so I wouldn't worry about the excess
>> allocations, just stick the property on all the returned strings.
>
> Here's how the change can look.
>
> It actually increases consing a bit further, though like mentioned it probably
> doesn't matter:
>
> - Added copy-sequence because I'm not sure if 'uniquify--stateless-curname'
>   always returns a new string (and never the original buffer name string
>  object).

Okay, maybe copying the string could be avoided by checking (equal
(buffer-name buf) uniquify--stateless-curname)?

I wonder why you called the property `uniquify-orig-buffer-name' instead
of `uniquify-orig-buffer', since it carries a buffer object?

Thanks!

Daniel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.