From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Date: Wed, 19 Jul 2023 05:47:45 +0300 Message-ID: <56b526dc-3244-e3cf-75db-5cce527c0096@gutov.dev> References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38553"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: sbaugh@catern.com, Eli Zaretskii , 62621@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 19 04:48:17 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 1qLxEc-0009nI-7c for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Jul 2023 04:48:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLxES-000125-4n; Tue, 18 Jul 2023 22:48: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 1qLxER-00011x-15 for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 22:48:03 -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 1qLxEQ-0000k9-Q7 for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 22:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qLxEQ-0005Y2-1M for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 22:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Jul 2023 02:48: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.168973487721286 (code B ref 62621); Wed, 19 Jul 2023 02:48:02 +0000 Original-Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 02:47:57 +0000 Original-Received: from localhost ([127.0.0.1]:54614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLxEK-0005XD-CX for submit@debbugs.gnu.org; Tue, 18 Jul 2023 22:47:56 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:34449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLxEH-0005WH-0x for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 22:47:55 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F03B75C0046; Tue, 18 Jul 2023 22:47:47 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 18 Jul 2023 22:47:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689734867; x=1689821267; bh=kgvHy1PFwkJpCTqIOn84WQwT/l+WqeikHYX qequYAZw=; b=e926B1naI1ZdMJ1NBHXJhz/e5Js0P444q79aRV4XfURZulfaoZl mmRQ0mavGLpbuvbgybqh6RR/fK+I3aSMnzlVNs94FVaC3ofKZmJIG1LnRsuGKBa3 1Px9N+dKnikaiQKC6AgrTR5SfbacYrsS2NVjigUs1SqJ3oFUydEqmWau0Cn0i+G6 vR+e+VYx2T8vuB0qKbCoC+y38TiLdK1SzuiMdkCWWRBJT42IjWBOlH43r/JF3ltu qHSGBe8bOVwldYYhkv1Fdx7R/ZyW4nSZzYf7b3aJOn0Ei+c3gyfUHgO2gwy51lbh BsiNf0RMjwx3ntF9W0qjfVUswbyRgyaRf4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689734867; x=1689821267; bh=kgvHy1PFwkJpCTqIOn84WQwT/l+WqeikHYX qequYAZw=; b=XA+NQwfBUtchRHShW/yv0W6fDIWABKPZIwFHbBGn8j2mJH8u8Xl jNcFEScJRQrcetIdt4K6MnU2HkFU+XM7cyrMCqCvGZs8UBFZlC/6Aofy3Q8U1KVq IiTn0d1xp4m4SIF9zqFoTrP7ygBm3ULYwIKokuCKoRTtqQqMOvsktnkcnt5uPymD 6IkLRwCLZRQZKPM5SFtPuxr6l89wpw9RG1daEnNqZEMxuaHGBSYoVWebGvA8lxAl 3uymRCLi2bcoj9/7nnhTi/oqT30SVlpJLUvskBeJV75IFCRryvvYYgRzOyUjeEdp hs9IyzwkXLDoDS3ZksjuTdCgT9zHUG7SM1A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeehgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Jul 2023 22:47:46 -0400 (EDT) Content-Language: en-US In-Reply-To: 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:265506 Archived-At: On 18/07/2023 19:03, Spencer Baugh wrote: >> 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. > > (I assume you mean "make the presence of the project name mandatory") Ah yes, sorry. > I think there is a good solution to this which was not mentioned in > bug#59502 only add the project name (or dirname or whatever) to the > buffer when that's necessary to give the buffer a unique name.> That > reduces overhead when working only with one project, and neatly fits in > to how uniquify already works for file-visiting buffers. We never talked about such an option. It's a little less obvious, but might indeed fit in more smoothly for both project and non-project use cases (and I also often work on just one project). Something to consider, though: if I am in a project A, and a project B has an eshell buffer and project A does not, 'C-x b' won't tell me that that eshell is in project B. But ideally, it should, I suppose. This might have been the original reasoning to simply include the project name in those buffers' names. > To do this, I think we'd need to change commands to use a function other > than get-buffer-create when accessing e.g. *xref* or *eshell*, which > like create-file-buffer gets a chance to uniquify the buffer name. > > It's a bit tricky though: we want commands to access and reuse existing > a project-specific buffer if there is one, but commands doesn't know the > name of that buffer so can't find it that way. find-file has solved > this same problem ages ago, of reusing an existing buffer if we > find-file a buffer-file-name which is already open. I think we may need > something similar for non-file-visiting buffers. > > Maybe some kind of mechanism to find a buffer with basename "*eshell*" > whose default-directory contains our current default-directory? Kind of > a "locate-dominating-buffer"? Well... a straightforward way would be to have some public function in uniquify which, given a set of name components, would construct the supposed buffer name and see whether one exists. And/or return the newest one that matches (if there are several, sequentially enumerated). But I suppose uniquify doesn't have to be enabled in every session. So a higher-level function could be added to the core. It's hard to decouple this idea from using uniquify, though, so I'm not sure what we'd call it. Alternatively, we'd just check every time whether uniquify is on, and have two different code paths for yes and no. >> - 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 /*eshell* and >> /*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. > > Hm, so if two *eshell* buffers are in the same project, they should > first be uniquified from other *eshell* buffers by adding the project > name, and then uniquified from each other by adding numbers to the end > of the buffer name. I wonder how that's going to play with existing user expectations. Like, if there are no projects, then a regular parent directory name will be used, right? And currently eshell buffer names don't include that at all. But maybe they should?.. Anyway, if the new behavior is opt-in, there won't be a cause for complaint. > I think I can implement this pretty easily in uniquify.el: if a set of > conflicting buffers all have the same dirname, then resolve the conflict > by adding numbers to the end. Yes, I suppose if directory names are equal, it doesn't make sense to prepend further name components -- a number makes more sense. > (Actually I was a bit surprised to realize that uniquify wasn't doing > this already, but I guess it's because it previously has only worked for > file-visiting buffers, which as I mentioned above are kept unique by > buffer-file-name, so there can't be conflicts between two buffer names > if you include their entire buffer-file-name in the buffer name.) True enough. > Incidentally, another feature which I've been thinking about at the > intersection of project.el and uniquify.el: We could rerun uniquify on > project-buffers in a mode where it just outputs sufficiently unique > names without actually renaming the buffers, and then use that in > project-switch-to-buffer. So then when picking the buffer, you are > picking from buffer names which are unique *in that specific project*. > It's otherwise kind of annoying to me that project-switch-to-buffer > includes a bunch of long disambiguating paths in the buffer names even > though the buffer names aren't actually ambiguous in that command. > > Does that sound interesting? I, like you, usually use C-x b. But I > think this feature would make C-x p b much nicer and competitive with > C-x b. That does sound interesting! And actually, when initially reading a message from this thread, I thought it was about something like that. It could be implemented by altering the buffers' completion table, I suppose. But I'm not sure how much of uniquify's code could be reused there. Or the performance characteristics of re-running uniquification every time a buffer name is read.