GNU bug report logs - #62621
29.0.60; uniquify can't make buffers unique based on things other than filename

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: sbaugh <at> catern.com, 62621 <at> debbugs.gnu.org
Subject: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename
Date: Fri, 14 Jul 2023 16:51:01 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: sbaugh <at> catern.com,  62621 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 08:46:00 -0400
> 
> 
> Eli Zaretskii <eliz <at> 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.

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, how is this different from using symbols?

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

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

Previous Next

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