bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename

[Dmitry Gutov <dmitry@gutov.dev>]

On 14/07/2023 15:46, Spencer Baugh wrote:
>>>> If the symbolic values are specific to project, simply let-bind
>>>> uniquify-dirname-transform to the value of the appropriate project.el
>>>> defcustom when project.el calls uniquify.
>>> These customizations are in effect all the time, not just when the user
>>> is calling a project.el command.  e.g. rename-buffer triggers uniquify.
>> Then you can set the buffer-local value of uniquify-dirname-transform
>> in the project.el buffers.  Would that solve the problem?
> The buffers it should affect are all file-visiting buffers.  project.el
> doesn't currently have any code which runs for every new buffer.  I
> guess we've considered adding that, but I'm not sure this is a good
> reason...

I'm not sure every project.el user will want this particular behavior 
anyway. project-switch-buffer is handy, but personally, I still most 
often use 'C-x b'.

But there definitely is demand for this option, as evidenced by the 
previously mentioned bug#59502, as well as this (unexpectedly, 
years-old) thread: 
https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00083.html

Speaking of those, do you think it would be feasible to also offer these 
tweaks (as options, or for particular buffers):

- Make the presence of the buffer name mandatory. As shown in the 
examples in bug#59502, it could be useful to always see in buffers like 
*eshell* produced by project-eshell. Or project-vc-dir, for example.

- Hide the parent directory from the uniquification logic (only keeping 
the project name). So that, for example, if I call 'M-x project-eshell' 
and then 'C-u M-x project-eshell', the generated buffer names would not 
try to use the parent segment to uniquify, and just stay as 
<project-name>/*eshell* and <project-name>/*eshell-2*. There is 
currently some bespoke logic for naming these particular buffers, but if 
we could move to uniquify (and obey its custom vars), that would 
probably be an improvement.