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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: sbaugh <at> janestreet.com, 77312 <at> debbugs.gnu.org
Subject: bug#77312: [PATCH] Add uniquify-get-unique-names
Date: Tue, 10 Jun 2025 05:51:29 +0300

On 08/06/2025 08:41, Daniel Mendler wrote:

>> 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.

All right.

>> 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.

Also when you provide the same information via different ways, over time 
they tend to get out of sync. The simpler the better.

> 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.

Yeah, that's a good idea.

> 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.

I usually try to avoid extra deps, but this can make sense, at least for 
users of Emacs>30. Especially if it leads to simplification in multiple 
places.

Can you see other compatibility checks we could forgo this way? Offhand, 
I see another fboundp in 'project-ignores' (default definition) and a 
version< inside 'project-list-buffers-buffer-menu'.

Previous Next

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