From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matthias Meulien Newsgroups: gmane.emacs.devel Subject: Re: Name of buffers created by project-shell Date: Sat, 08 May 2021 19:09:05 +0200 Message-ID: <87sg2xrw3y.fsf@gmail.com> References: <87czwh9rv9.fsf@gmail.com> <87zgz526gx.fsf@gmail.com> <80c15296-ebf7-3030-993f-ffb01051d570@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="685"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 08 19:09:49 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lfQSb-000AeU-DO for ged-emacs-devel@m.gmane-mx.org; Sat, 08 May 2021 19:09:49 +0200 Original-Received: from localhost ([::1]:40330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfQSa-0008E2-Dh for ged-emacs-devel@m.gmane-mx.org; Sat, 08 May 2021 13:09:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfQRv-0007IB-PO for emacs-devel@gnu.org; Sat, 08 May 2021 13:09:09 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:42728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lfQRu-0002hO-7F for emacs-devel@gnu.org; Sat, 08 May 2021 13:09:07 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id l2so12299800wrm.9 for ; Sat, 08 May 2021 10:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=0WChtv9ajwUTfP/5sYg9tSonrdkZuzLeFutGUE+3WQ8=; b=KZMB8/UcVY08kJiuEO+3CI7neBmd3UQ3Lvz6wuCeLKft/orJeC6R/DNZucCwrGXQYT PFYzQZ30Qxqee5bo42fmcuMM4Day0WzHmjSiwl1bph4wxuq9v0cOtIuvxgR/+i1OKUf6 cSvDrkOYmx4N/tVLmrAl3GI3oClQTstdZCKbwjJtwLa1knaSPwPIk7HvoUFALqDy2y19 qZW3WDPYJm9QRmeGu3HD3lMvuMvgMdXXYeCh/xi/JVDXuCyFYB1Dyoa9+d4i49dZ14j1 SDdFyZO9Co77qdZ/LFFnt5iX8BTGxQZtaRWaVUm4MujATtamQc7h+CLwbwJ7iJQvfn4W lriA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=0WChtv9ajwUTfP/5sYg9tSonrdkZuzLeFutGUE+3WQ8=; b=UvsntMFbFHuUAkdlW40NZEcwSSh0phmkWlhyqO7EUlG31tYTEYIFMwfe7HHlBz5abx RYqxbd7tkQwWdCfpmTTSDV0niCgIcfoGYpK70a42IYAfZrvCMEz0mR/92SVpC2mv84Ln 06IIu2acf1sWRghIgOgn0KDQn6cIKDhZ1qbxHT5/05PHmrS27YUws0qfO9bzclzoYE/H hnsemlMukEAFKrkJ65KbTX/9exgG5KY1hULsUHklF1dku3I8NTAginwe8U/5WN3RrOIg jkKiF9ff9VbWIqiiSZY2Vt6R4Yn7E9UmLW/A+Ji5mA8p2J64cxkf/GHeb7WYP4QjZpXa KOsA== X-Gm-Message-State: AOAM531a/k8hvqLRea+QBbcxFPcVZ+JLG0njDsEOnuQW85UGNsuLS4tS 4TYI/9023eW1hAUDV8dF1m5yu+NeSTH2ew== X-Google-Smtp-Source: ABdhPJwot3ZQy190WWm36mh9IYTc+uYx8eVEbpzqdeUBsjNvFgJMg0jm1GELVBM0/Xe+4xu3zbcSJA== X-Received: by 2002:a5d:64e1:: with SMTP id g1mr20230364wri.101.1620493744200; Sat, 08 May 2021 10:09:04 -0700 (PDT) Original-Received: from carbon.localdomain (44.107.204.77.rev.sfr.net. [77.204.107.44]) by smtp.gmail.com with ESMTPSA id t206sm11663592wmb.11.2021.05.08.10.09.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 May 2021 10:09:03 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Sun, 21 Mar 2021 21:44:19 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=orontee@gmail.com; helo=mail-wr1-x42f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269059 Archived-At: Hi Dmitry, Sorry for the late reply, I didn't found much time to work on this until now. > Actually, it didn't occur for vc-dir buffers. So it's arguably a bug > in my code. > > Attaching the updated patch which fixes that particular problem, > though I'm a little more suspicious of some of uniquify's choices now. I agree that uniquify way of handling buffers not visiting files is fragile... > In particular, this code depends on list-buffers-directory being set > to a value in particular format which is very non-obvious from this > variable's docstring. Yes, and shell-mode already sets list-buffers-directory to the default directory which is not the (expand-file-name "*shell*" default-directory) that uniquify would expect (and is overwritten by your patch). > And to have uniquify work similarly with buffers created by M-x shell > and M-x eshell as well, these commands need similar changes (we can't > really depend on them in project.el because it's an ELPA Core > package), as well as shell-mode and eshell-mode being listed in > uniquify-list-buffers-directory-modes. When shell minor mode dirtrack-mode is enabled (the default), the value of list-buffers-directory is updated when cd, pushd, popd, etc. are issued; It will thus interfere if uniquify has to rerationalize the buffer name... I saw in commit 1c3a86e7fc2 that project-prefixed-buffer-name has been introduced which I understand as "forgot of uniquify since it doesn't handle buffer not visiting files properly". I have some time to work on improving the uniquify situation but can you confirm there's still interest for this? My rough plan is to change uniquify-list-buffers-directory-modes to be a mapping from major modes to functions that, given a buffer, returns the buffer proposed name and a directory. This would remove the use of list-buffers-directory in uniquify and gives the opportunity for each major mode to provide its convenience function based on current-directory or project-root. The default won't be to add shell-mode and eshell-mode to this new uniquify-list-buffers-directory-modes mapping (to avoid breaking current behavior) but do it locally when shell or eshell are called from project.el. Is this dependency acceptable? -- Matthias