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

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: sbaugh@catern.com,  62621@debbugs.gnu.org
>> Date: Fri, 14 Jul 2023 08:46:00 -0400
>> 
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Here's concretely the diff I would apply.  This makes uniquify.el mention a
>> >> function from project.el.  Is that OK?
>> >
>> > No.
>> 
>> I figured.  So now you see the issue with the symbolic approach.
>
> No, I don't.  Not a significant problem, anyway, and not why it's
> different from using a function.
>
>> If the defcustom just takes a function, though, that solves the
>> dependency issue.  Because the user's config handles taking the function
>> from project.el and putting it in the variable from uniquify.el.
>
> Ease of implementation is an important factor, but the ease of using
> Emacs takes precedence.  So saying that some implementation
> alternative should be taken only because it is easier is not a winning
> argument.

I agree.

> And I don't really understand how this will work in practice: if the
> user-defined function is supposed to be in effect only for buffers
> under project.el,

The transform is supposed to be in effect for all buffers, and
internally it runs some code to decide whether to change the buffer
name.

> how is this different from using symbols?

I can't contrast that to "using symbols" because I just don't understand
what you mean by "using symbols".

Is the diff I posted what you mean by "using symbols", or did you mean
something else?

>> >> > 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 sure this can be resolved, quite easily, actually.  So I don't
> think I understand what you are trying to say here.
>
>> > default-directory of a file-visiting buffer doesn't change.
>> 
>> I don't think that's true.  If I open ~/.emacs.d/init.el then (cd "/")
>> then default-directory in that file-visiting buffer is / instead of
>> ~/.emacs.d
>
> You can shoot yourself in the foot if you like, but why would you?

I agree this is fairly useless but (info "(emacs) File Names") at least
mentions using M-x cd in the context of file-visiting buffers:

   When you visit a file, Emacs sets ‘default-directory’ in the visiting
buffer to the directory of its file.  When you create a new buffer that
is not visiting a file, via a command like ‘C-x b’, its default
directory is usually copied from the buffer that was current at the time
(*note Select Buffer::).  You can use the command ‘M-x pwd’ to see the
value of ‘default-directory’ in the current buffer.  The command ‘M-x
cd’ prompts for a directory’s name, and sets the buffer’s
‘default-directory’ to that directory (doing this does not change the
buffer’s file name, if any).

Nevertheless, I would be happy to make uniquify use default-directory
instead, it will change how this behaves but it's probably OK.  I can do
that in a separate bug.

> Anyway, are we still trying to reach some goal, or are we just trying
> to counter each other's arguments?

I'm not trying to counter your arguments, I just don't understand what
you mean by "using symbols".  I'm happy to have the configuration be
symbol-based but you said "No." to the approach I posted and I don't
know what other approach you are envisioning.