Subject: bug#77312: [PATCH] Add uniquify-get-unique-names

From: Daniel Mendler <[email-masked]>
Date: Sun, 08 Jun 2025 07:41:19 +0200

Dmitry Gutov <[email-masked]> writes:

> Hey Daniel!
>
> On 07/06/2025 11:11, Daniel Mendler wrote:
>> Would it be possible to attach the buffer object or the original buffer
>> name to the completion candidate string as text property? This would
>> make it possible to attach annotations via Marginalia or to execute
>> buffer actions via Embark. Otherwise I don't see a possibility to access
>> the original buffer, since they are only present in the `unique-names`
>> alist local variable.
>
> That makes sense. Just call the property 'buffer'?

That would work. I prefer a more specific property name to ease
grepping/debugging. Also see below regarding the consing.

> I wonder if it would make sense to alter the calling convention for
> uniquify-get-unique-names itself to return a list of propertized strings
> instead. project--read-project-buffer can do the conversion (copy each string
> and attach the property), but it's just extra consing.

I haven't checked if the current function is already working hard to
avoid unnecessary allocations. If yes, it would be wasteful to add extra
string allocations.

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.

> Unless some more new callers are going to prefer the current convention.

Both would be fine for me. Generally I think it is nice to push
functionality to the lower level API, as long as the functionality is
generic enough.

Btw, would you be interested in having `uniquify-get-unique-names' in
Compat, such that you avoid the fboundp check? project.el would have to
depend on Compat for that, but that's essentially free on Emacs 30 and
newer.

Daniel