From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 16:51:01 +0300 Message-ID: <83bkgefvp6.fsf@gnu.org> References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26914"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@catern.com, 62621@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 15:51:12 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 1qKJCR-0006jz-Uq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 15:51:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKJCK-0001QZ-KD; Fri, 14 Jul 2023 09:51:04 -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 1qKJCI-0001QK-PM for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 09:51: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 1qKJCI-0002gz-HT for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 09:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKJCI-0001XJ-4P for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 09:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 13:51:02 +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.16893426515880 (code B ref 62621); Fri, 14 Jul 2023 13:51:02 +0000 Original-Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 13:50:51 +0000 Original-Received: from localhost ([127.0.0.1]:41744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJC7-0001Wl-5m for submit@debbugs.gnu.org; Fri, 14 Jul 2023 09:50:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJC4-0001WP-Nq for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 09:50:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKJBy-0002dA-TT; Fri, 14 Jul 2023 09:50:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wTNRDFtYiyiacBB5//l7GcCUk5uof3W+PN+b2dXwJhE=; b=YDqA5oHbp+7b VbUrUN9q+FSi7hX/V8iK8+7heqcupoFIxTIdsSxzU7eSm2h9NgR+lS/wb659ztcI7tXGIQtDFLAs0 Gulm47Y849keSGFdVwTLebpF9OHR7xLKGe/fHpctRlP6vOgurkvxgHH69Iv3XCKZFhkT4iTx4kUzC PojfHiv81abcn1hzjVx7uRw6Qz+VB6U1XWkXFTbuFHKYANqMfA26Ul/eh/13yMQM+QnpWXQuoSA4y G6vIPKZd9ccOvZtnv+w+6f0Gg4U3+NJ8ICu12Eyz+19oDsA8hXbHz6fP2s3nRZsqPQRmGWBoKqQe0 G4zMwPFFdArY2QcoJhrNLg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKJBy-000819-DS; Fri, 14 Jul 2023 09:50:42 -0400 In-Reply-To: (message from Spencer Baugh on Fri, 14 Jul 2023 08:46:00 -0400) 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:265092 Archived-At: > From: Spencer Baugh > Cc: sbaugh@catern.com, 62621@debbugs.gnu.org > Date: Fri, 14 Jul 2023 08:46:00 -0400 > > > Eli Zaretskii 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?