From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Date: Fri, 14 Jul 2023 10:14:39 -0400 Message-ID: References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36678"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 62621@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 16:15:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKJZu-0009Hf-6o for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 16:15:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKJZX-0001jk-1h; Fri, 14 Jul 2023 10:15:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKJZW-0001jb-71 for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:15:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qKJZV-0007F6-UC for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:15:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKJZV-0002kr-Q6 for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 14:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62621 X-GNU-PR-Package: emacs Original-Received: via spool by 62621-submit@debbugs.gnu.org id=B62621.168934408810544 (code B ref 62621); Fri, 14 Jul 2023 14:15:01 +0000 Original-Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 14:14:48 +0000 Original-Received: from localhost ([127.0.0.1]:43128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJZH-0002jz-L3 for submit@debbugs.gnu.org; Fri, 14 Jul 2023 10:14:48 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJZF-0002jh-7H for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 10:14:45 -0400 In-Reply-To: <83bkgefvp6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 16:51:01 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265094 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Fri, 14 Jul 2023 08:46:00 -0400 >>=20 >>=20 >> Eli Zaretskii writes: >>=20 >> >> Here's concretely the diff I would apply. This makes uniquify.el men= tion a >> >> function from project.el. Is that OK? >> > >> > No. >>=20 >> 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. >> >>=20 >> >> These customizations are in effect all the time, not just when the us= er >> >> is calling a project.el command. e.g. rename-buffer triggers uniquif= y. >> > >> > Then you can set the buffer-local value of uniquify-dirname-transform >> > in the project.el buffers. Would that solve the problem? >>=20 >> 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. >>=20 >> 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 =E2=80=98default-directory=E2=80=99 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 =E2=80=98C-x b=E2=80=99, its def= ault directory is usually copied from the buffer that was current at the time (*note Select Buffer::). You can use the command =E2=80=98M-x pwd=E2=80=99= to see the value of =E2=80=98default-directory=E2=80=99 in the current buffer. The co= mmand =E2=80=98M-x cd=E2=80=99 prompts for a directory=E2=80=99s name, and sets the buffer=E2= =80=99s =E2=80=98default-directory=E2=80=99 to that directory (doing this does not = change the buffer=E2=80=99s 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.