From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 12:55:43 2025 Received: (at submit) by debbugs.gnu.org; 19 Mar 2025 16:55:44 +0000 Received: from localhost ([127.0.0.1]:52845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuwhj-0005LO-6T for submit@debbugs.gnu.org; Wed, 19 Mar 2025 12:55:43 -0400 Received: from lists.gnu.org ([2001:470:142::17]:55394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuwha-0005Ki-4L for submit@debbugs.gnu.org; Wed, 19 Mar 2025 12:55:34 -0400 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 1tuwhS-0007iv-Mh for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2025 12:55:26 -0400 Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tuwhO-0005XP-9P for bug-gnu-emacs@gnu.org; Wed, 19 Mar 2025 12:55:26 -0400 Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-86d36e41070so3044218241.3 for ; Wed, 19 Mar 2025 09:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742403320; x=1743008120; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zS47ZbSoH74qnIXFSztIC8uMHoVwRXYtCRCt4f8A0ZM=; b=N+SYg6ycsLMlNG/zBnyf1J8k0dHnaJcAIIFyB0E/M/nf3nHJar6kvlf2bYIq23Ul4M FQyaML+PUzGVcL6D3Hpi7zn0+e80mt4PJX7jsurGV4jrTZx+5abg9zFYFSsY+6H0cmKq 6XHtT86ioaYH5vVZvRkXnUpvNUSpgkoaUBF6nue40mbhkE8m+Xk9i0dy7zrPMSvQ+QYW RYrvVPGSH1R8SQhHlElxRtdxrrh72IbB20g1Xx3zcmEmGCsoejWGgpE97Fh3hhULz64N 0z6kK9Jo8jpCf3Qgz6PepZIRi/qmSt0yidhh7kjU+hGJAiNyyM6UHO+EAT0X7C7t965x To/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742403320; x=1743008120; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zS47ZbSoH74qnIXFSztIC8uMHoVwRXYtCRCt4f8A0ZM=; b=LVLW7ctEAioAJQCTRAgjWFvtP8MFhMa09CEnpMIqW7u5I9f6afZ1YQED+DFDYwjJQh btBVHUoqiOYSERzYdBdvDNA6nnUp0H1y54FrJSf6lstq1EZu12AvR74orsRoQ6qtNnrO MFDByTuP3paheXgT3U68Y+r4Xi3UtLjMZWLdekvTkOOxo+hk6c/0/wXrvR+voJAiYyp/ m8fxtFNoaYKXJ+m+AhzyKvelmDdm2g9bjKXE57qJCVnZEuupNIG/rKyEsZj5gt2r7VOi 35sbbyhdk+PS0DRRjCgmfNAsOBBJ671kobYULJps4GYxI/X6XzdTneVsn4DjlmTY/1Xo NzXg== X-Gm-Message-State: AOJu0Yx8/MPrGKeBH5+z6jwJ8scneL4zWLHPGPhjMtaZSVmpBXDdXavr 2ibENs3seQgHIJWMo5snNNiOEyyUC9e6ETZwZTJgh2uilrbo6ahTMExk/0MfOQWiSqbRb1i65cF aO//hfmA/OcLG8fe5ZkE0dC2bQhVVyaN3 X-Gm-Gg: ASbGnctCWYFauf8bW5/e0ucr5iC6a+daFaz8hzpkYERK3a0C19nJk0L/N4J+QxP6YB3 tyCv4oVxW8lr/7g8b12haDvAxenocHg47xQCq6IVMFX1Onnhnniinfu7Z6BzC09XCTMgLi7hD7X dFC/Rv9mTkqnos8lfka56cWApPzg== X-Google-Smtp-Source: AGHT+IEWZm2qxSha/kXSQo3xH7DwMmNEGq8JfB8m21zs8IkTSi+sPPwhMMtX2HDJGcZnmUkaRFQoLc3e8zwxwvglSuI= X-Received: by 2002:a05:6102:80a0:b0:4bb:9b46:3f87 with SMTP id ada2fe7eead31-4c4ec648ba3mr3070557137.6.1742403320352; Wed, 19 Mar 2025 09:55:20 -0700 (PDT) MIME-Version: 1.0 From: Ship Mints Date: Wed, 19 Mar 2025 12:55:09 -0400 X-Gm-Features: AQ5f1JqofVhzCC_GcTdP5DG0ISviAKJ3KDAazXTAP91jahlSti7lBm4p8AWc2Ns Message-ID: Subject: [PATCH] project--find-in-directory resolves symlinks To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000f72ed60630b4e208" Received-SPF: pass client-ip=2607:f8b0:4864:20::92c; envelope-from=shipmints@gmail.com; helo=mail-ua1-x92c.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, HTML_MESSAGE=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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000f72ed60630b4e208 Content-Type: multipart/alternative; boundary="000000000000f72ed50630b4e206" --000000000000f72ed50630b4e206 Content-Type: text/plain; charset="UTF-8" This avoids duplicate projects accessed via symlinks that share resolved directory locations. This has bothered me for a while, so here we go. -Stephane --000000000000f72ed50630b4e206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This avoids duplicate projects accessed via symlinks that share resolved= directory locations.=C2=A0 This has bothered me for a while, so here we go= .
-Stepha= ne
--000000000000f72ed50630b4e206-- --000000000000f72ed60630b4e208 Content-Type: application/octet-stream; name="0001-project-find-in-directory-resolves-symlinks-bug-xxx.patch" Content-Disposition: attachment; filename="0001-project-find-in-directory-resolves-symlinks-bug-xxx.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8g5xb0w0 RnJvbSAwNzQ5MDVmZjM2NWM2YmNkN2NiY2Y3MmUwMTU4YWU5ZGIwOTA4YTIwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBzaGlwbWludHMgPHNoaXBtaW50c0BnbWFpbC5jb20+CkRhdGU6 IFdlZCwgMTkgTWFyIDIwMjUgMTI6NTA6MjggLTA0MDAKU3ViamVjdDogW1BBVENIXSBwcm9qZWN0 LS1maW5kLWluLWRpcmVjdG9yeSByZXNvbHZlcyBzeW1saW5rcyAoYnVnI3h4eCkKClRoaXMgYXZv aWRzIGR1cGxpY2F0ZSBwcm9qZWN0cyB0aGF0IHNoYXJlIHJlc29sdmVkIGRpcmVjdG9yeSBsb2Nh dGlvbnMuCgoqIGxpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgKHByb2plY3QtLWZpbmQtaW4tZGly ZWN0b3J5KTogSW52b2tlCidwcm9qZWN0LWZpbmQtZnVuY3Rpb25zJyBvbiAnZmlsZS10cnVlbmFt ZScgcmVzb2x2ZWQgZGlyLgotLS0KIGxpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgfCA0ICsrKysK IDEgZmlsZSBjaGFuZ2VkLCA0IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9saXNwL3Byb2dt b2Rlcy9wcm9qZWN0LmVsIGIvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAppbmRleCA0ZWFjNTQx MTY3YS4uNDVmNTMyOGY2YmUgMTAwNjQ0Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwK KysrIGIvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbApAQCAtMjUxLDYgKzI1MSwxMCBAQCBwcm9q ZWN0LWN1cnJlbnQKICAgICBwcikpCiAKIChkZWZ1biBwcm9qZWN0LS1maW5kLWluLWRpcmVjdG9y eSAoZGlyKQorICAiSW52b2tlIGBwcm9qZWN0LWZpbmQtZnVuY3Rpb25zJyBmb3IgRElSLgorRElS IGlzIHJlc29sdmVkIHRvIGl0cyB0cnVlIG5hbWUsICdjaGFzaW5nJyBzeW1ib2xpYyBsaW5rcywg dG8gYXZvaWQKK2R1cGxpY2F0ZSBwcm9qZWN0cyB0aGF0IHNoYXJlIHJlc29sdmVkIGRpcmVjdG9y eSBsb2NhdGlvbnMuIgorICAoc2V0cSBkaXIgKGZpbGUtdHJ1ZW5hbWUgZGlyKSkKICAgOzsgVXNl ICdpZ25vcmUtZXJyb3InIHdoZW4gMjcuMSBpcyB0aGUgbWluaW11bSBzdXBwb3J0ZWQuCiAgIChj b25kaXRpb24tY2FzZSBuaWwKICAgICAgIChydW4taG9vay13aXRoLWFyZ3MtdW50aWwtc3VjY2Vz cyAncHJvamVjdC1maW5kLWZ1bmN0aW9ucyBkaXIpCi0tIAoyLjQ3LjEKCg== --000000000000f72ed60630b4e208-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 13:04:54 2025 Received: (at 77122) by debbugs.gnu.org; 19 Mar 2025 17:04:54 +0000 Received: from localhost ([127.0.0.1]:52910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuwqc-0005nx-4f for submit@debbugs.gnu.org; Wed, 19 Mar 2025 13:04:54 -0400 Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]:48335) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tuwqY-0005ni-Mz for 77122@debbugs.gnu.org; Wed, 19 Mar 2025 13:04:51 -0400 Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-5259327a937so180221e0c.0 for <77122@debbugs.gnu.org>; Wed, 19 Mar 2025 10:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742403884; x=1743008684; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=V6pe4UAk1hQPQjR9/lF2ri3nkuN9EDoUZuoOkJ6DzbI=; b=JwHwZT1h8cuC/YFUarYBomOXeKQbkA6/eq3kImF7TD8N32WKXFl8wApFK2o4q5sTsr 8ZHLlM223ADrLpzxVaU3huNLVZI/+U5dQegGyZaUPkkB2C0LqA14mJ3MgFTAgg6oRxQ7 dWNuPJOYEGAzaxKBQih+sRquGJyyqQYmPXAnnKA7eyWA9S8obN7UJfmbK16YgHGADCdo CcbNPwCKhOMwQFSvzobNePzRI5z5wckssSlv8Z1GUQz4SrEJJiWDvLaJzWZawLb+9eEI 1+3bnyM5KDTIs2uW4XHHz4PtaVBBxMaDhiV2efPg70KoX/48WA6frOr39wuaFTwaUtLP KFDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742403884; x=1743008684; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=V6pe4UAk1hQPQjR9/lF2ri3nkuN9EDoUZuoOkJ6DzbI=; b=Y0BVJN3Pl9utn6sld2Xn+7suggoxAIWbgUcFQhh9m0PeXdee1aORqCUD+VQJ4IQANX HpiCRViiQBy60fvHdzMCoBXsyXN9PnRpy/zknn0lL/0PoMZPsibWz8cMjINnJtPS8aZa zXW8EAqpd/924e7kd9BeXEivM//HGglDpPECvXih8z7DsAra3Aiz/1vMY3W1H97OqH/N 90XFVi2A+AFyt9PguSVmwfGZ2agKqmgWrVq+o2YrFK67AV7yJ7YBykUPKMS4exhSVJU1 VqFbd0t3onkyJGCdeyd9PmmM0UmNimCLchSuD3Yk6iL/ZKMiN2kXywsKdfNsr4hn4GOR /zwQ== X-Gm-Message-State: AOJu0Yz/7uIlJYflqVcrxXee6iAekCDSskJr8mME9UDot6oj8cBfy0oL FOQysrkMVzJcBrfntxpYhpEvhFPY3a4ujs13CNYluNisOlwH+fHMdwe1giCCddG0owBE8WiZ7z2 K30P1EL9jtZDgPz5khm0cWFGhyBM3Yg== X-Gm-Gg: ASbGnctFO9ToGb2dkynV1uV2bPI3c8Ux8PVXKlfRo71iu7lJE6nTuwHdMsukmFRInNy 92IjNYLYCNpY+4yAORYq6gYwLcVm7mnkdbj9IwdaPK1byuemOVTiHqfCLZBHOy60xLrTldB2dh1 sPfIahdMVKnAgCgx1a62tChhHeOw== X-Google-Smtp-Source: AGHT+IHA78FZcfvjtB7aac1rQnGp+yd8zr7klh/qNydacoikwGaq7+/a5nSRAu3xTLFQFm26IU6zxOumPaNV40FkCvs= X-Received: by 2002:a05:6122:2487:b0:51f:fc9d:875d with SMTP id 71dfb90a1353d-52589218085mr2529937e0c.8.1742403883641; Wed, 19 Mar 2025 10:04:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ship Mints Date: Wed, 19 Mar 2025 13:04:32 -0400 X-Gm-Features: AQ5f1Jo4m6BhvIJ4REKKoG0XnvL6GfqB2TAKbH0OVjVTZZaZAXvRXdYQZwHi6HI Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: 77122@debbugs.gnu.org Content-Type: multipart/alternative; boundary="0000000000008a30ee0630b50410" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008a30ee0630b50410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2025 at 12:57=E2=80=AFPM Ship Mints w= rote: > This avoids duplicate projects accessed via symlinks that share resolved > directory locations. This has bothered me for a while, so here we go. > FWIW, I consider this a bug and would like to see this in Emacs 30.2. --0000000000008a30ee0630b50410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Mar 19, 2025 at 12:57=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
This avoids duplicate projects accessed via symlinks that share resolved d= irectory locations.=C2=A0 This has bothered me for a while, so here we go.<= /div>

FWIW, I consider this a bug and would like to se= e this in Emacs 30.2.
--0000000000008a30ee0630b50410-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 13:10:28 2025 Received: (at 77122) by debbugs.gnu.org; 19 Mar 2025 17:10:28 +0000 Received: from localhost ([127.0.0.1]:52921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuww0-000699-27 for submit@debbugs.gnu.org; Wed, 19 Mar 2025 13:10:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48070) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuwvx-00068u-AP for 77122@debbugs.gnu.org; Wed, 19 Mar 2025 13:10:25 -0400 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 1tuwvq-0002b5-NE; Wed, 19 Mar 2025 13:10:19 -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=PLafX9DmErfUMMdYG7aP8eQLE81FMvmDBBexxiZBKS0=; b=D1q4FaLzluxw mfPEqWd27o2wUEJ1J7AV1iu3MuptJax5YAiBIs5jSLgXo3gTcvl4E6o2TSJr5n5remdinTfHYghIh O/FeXfvlWIb0DBM53TdTI1YdRAVGPoabcLGA5kLQiJMiWqm1RAsvKfev+0YyOsRMGGeSIBMEDN1R3 20RW4BPxXnrQju4uRZY0NypdFU2NKoXT3sqWzAPzrDT6TVLwEp+1i+E7QGDQTH7rtn3Cri+59tbhv MOx3EiDExAam3XNeVHlzmKWJAzqV//anX/hIhaQxILf2Fr9a30I4V+z4lpLcjGujL9WFPscXm7QSd v2QLKt4hlKIXOL7m8gOV5w==; Date: Wed, 19 Mar 2025 19:09:44 +0200 Message-Id: <861putoskn.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Wed, 19 Mar 2025 12:55:09 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Wed, 19 Mar 2025 12:55:09 -0400 > > This avoids duplicate projects accessed via symlinks that share resolved directory locations. This has > bothered me for a while, so here we go. > > From 074905ff365c6bcd7cbcf72e0158ae9db0908a20 Mon Sep 17 00:00:00 2001 > From: shipmints > Date: Wed, 19 Mar 2025 12:50:28 -0400 > Subject: [PATCH] project--find-in-directory resolves symlinks (bug#xxx) > > This avoids duplicate projects that share resolved directory locations. > > * lisp/progmodes/project.el (project--find-in-directory): Invoke > 'project-find-functions' on 'file-truename' resolved dir. > --- > lisp/progmodes/project.el | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index 4eac541167a..45f5328f6be 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -251,6 +251,10 @@ project-current > pr)) > > (defun project--find-in-directory (dir) > + "Invoke `project-find-functions' for DIR. > +DIR is resolved to its true name, 'chasing' symbolic links, to avoid > +duplicate projects that share resolved directory locations." > + (setq dir (file-truename dir)) That's not necessarily what the user will want, since it changes the name of the file (and potentially its directory as well). If the file or the directory have some "magical" name that matters, this will backfire. I think it is better to detect the fact that two directories point to the same place via symlinks (e.g., with file-equal-p), and avoid duplication in that case, but without actually substituting the file's name by its truename. But of course the final word is for Dmitry. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 13:17:25 2025 Received: (at 77122) by debbugs.gnu.org; 19 Mar 2025 17:17:25 +0000 Received: from localhost ([127.0.0.1]:52938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tux2j-0006S1-Bx for submit@debbugs.gnu.org; Wed, 19 Mar 2025 13:17:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50984) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tux2f-0006Ri-TD for 77122@debbugs.gnu.org; Wed, 19 Mar 2025 13:17:23 -0400 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 1tux2Z-0005My-Li; Wed, 19 Mar 2025 13:17:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=RzLmlTgiPSIC2gh0UsKwYtH7f9KhKtk6K7YHLAOu/Xk=; b=WVI2qDs+BCEhJ5GCfTtG RLe0/198mSA3clblTkbgBuinYAC/VEA5rHxm3BDRFkcFUAK01B7X1kvTnlNEZj7/UOaGxqVQ9koBo lvrW+77BTCLVxQG5ybLj8O5lfrszmAcTYFoPXBb5QWPElNO28m6oa8eUbIc/HfP70t7Dzxz4eOwgP 6OZN5eMia5Z0tQI+wiBvaAwO1nstr+pLHZ/RcltL+oFlXSHBNaWKNN9yFUHiaagFtGu927xKp/qKK ieoGXlBveaUDDH2l8j9o9odYjFxio8+N+hgVgNEV1lNdlndSPOYt9uxJSb/6CL+e/FO3QvKUlfwUs MVGMmiijesZEtw==; Date: Wed, 19 Mar 2025 19:16:56 +0200 Message-Id: <86y0x1ndo7.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Wed, 19 Mar 2025 13:04:32 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Wed, 19 Mar 2025 13:04:32 -0400 > > On Wed, Mar 19, 2025 at 12:57 PM Ship Mints wrote: > > This avoids duplicate projects accessed via symlinks that share resolved directory locations. This has > bothered me for a while, so here we go. > > FWIW, I consider this a bug and would like to see this in Emacs 30.2. Let's first discuss how to fix the original problem. If it turns out that the best fix is what you proposed (and I explained why I'm not sure it is), then it's unlikely to be in Emacs 30.2 because it changes behavior as a side effect of the fix, and that change could cause more serious problems. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 13:19:09 2025 Received: (at 77122) by debbugs.gnu.org; 19 Mar 2025 17:19:09 +0000 Received: from localhost ([127.0.0.1]:52947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tux4O-0006Vh-RI for submit@debbugs.gnu.org; Wed, 19 Mar 2025 13:19:09 -0400 Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]:54582) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tux4M-0006V3-Aa for 77122@debbugs.gnu.org; Wed, 19 Mar 2025 13:19:06 -0400 Received: by mail-vk1-xa2d.google.com with SMTP id 71dfb90a1353d-523de5611a3so2733765e0c.1 for <77122@debbugs.gnu.org>; Wed, 19 Mar 2025 10:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742404740; x=1743009540; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NW2+EGWd/EVn4SBqcRznMJsPtRz6zZe/VZbNRmQLC7U=; b=kYIpselqCujGcoohcviUR95jhUNvHFVUd8aHlubbSAUDxjoJ4GglfAk3AiktHW5GP0 wo1YO1a37iwvKX917+CxsZ1/11picu3+U+jX8AcVEwnZnaXtUVKXQfdObTwKexcoevUk Yap3wm5iL4GunUerEuss5kc0b1SMNGtvbJc1NwO38Schr/+AyfnzsX0TwYQeO7qhB40z RTWwZCBWxQT7SGq+7Ug4sEMObyIaR1/EY/d/tWqWjNb1C6WokaZdlZ1RGG+1c098hfbu dTs4z8jEtJumNtUziFC93/S3xMPNbclfgB7Ugtm0ZhlEVEnKsIxxQXFzoYwm4Vc3qWtj PpDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742404740; x=1743009540; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NW2+EGWd/EVn4SBqcRznMJsPtRz6zZe/VZbNRmQLC7U=; b=jHU9+mDN4D961E1sAHeOGD6ikdBVEf88QN0m+JYDeNGyDNGP6yOmJiWI9beq2FCexq X9K/aujdlnIZc20/xl1q58fmYdK1eU6pSNYVupZH9gdbrqRhcGyXhiYpX37qIVKSUGZO WYDyr/ish+mUs/4E7uTg87Di/yzcMH9BNEzupvgoRzTCyal/2pLvSXcXOLnaWZcRn7gf LPMr9ttoMggirOWiJ2ZaPUx3vZUs08l06ixeYg5alvevniWTiRQhJGJEeO/nrqSevMPV 7FCFhzkwDZqwMH68fjerfHiQeUOc+s71fJI5yGpn4QptcYjNf9wkF5GPFWXwV6+oxrpQ HKTQ== X-Gm-Message-State: AOJu0YzDzpfeoOQRNy3g4rofxDENTgdsCw5adLZ/gu2Q+yEFO8zMVO8b jXjznnzmHt+IAMRl4m5YhRADcAOScPigMjWC34+9GpEblA/HJi97UNLejnO3cXXPsztEdy3XjNz WrL+avMnF2/9dHUr3IqA7+MQCjIU= X-Gm-Gg: ASbGnctBiptvLt5LYB3MwB+pk33goubFbmWkdujnMubFmgUSmDXS73wlxqHMQ5/COQ5 PHd/ymKSz/qqW77epMNS/M7/3chQnNW2TbwT27KwnBogOU1daMaWlq7Yh8irS+a3sBD5+YGXWcz q1xzupe3ZGxEmQJmY7eP7+kb7kAg== X-Google-Smtp-Source: AGHT+IFFqTQjXmnt3XNvpn16zE26qPyunv9oS355ae5obZEglJD+zfaEzUmVNGjUW0VO6n8HJDGddlODGEsN7CJT3Yc= X-Received: by 2002:a05:6122:4710:b0:524:2fe2:46ba with SMTP id 71dfb90a1353d-5258929589emr3013765e0c.11.1742404740515; Wed, 19 Mar 2025 10:19:00 -0700 (PDT) MIME-Version: 1.0 References: <861putoskn.fsf@gnu.org> In-Reply-To: <861putoskn.fsf@gnu.org> From: Ship Mints Date: Wed, 19 Mar 2025 13:18:49 -0400 X-Gm-Features: AQ5f1JrRDJf7ehTkFP2VyuUroDs2ZdO_9iGgjdcwTPB0oImYaG1kGIDFMFMfrrY Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000009d0eea0630b5379f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000009d0eea0630b5379f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2025 at 1:10=E2=80=AFPM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Wed, 19 Mar 2025 12:55:09 -0400 > > > > This avoids duplicate projects accessed via symlinks that share resolve= d > directory locations. This has > > bothered me for a while, so here we go. > > > > From 074905ff365c6bcd7cbcf72e0158ae9db0908a20 Mon Sep 17 00:00:00 2001 > > From: shipmints > > Date: Wed, 19 Mar 2025 12:50:28 -0400 > > Subject: [PATCH] project--find-in-directory resolves symlinks (bug#xxx) > > > > This avoids duplicate projects that share resolved directory locations. > > > > * lisp/progmodes/project.el (project--find-in-directory): Invoke > > 'project-find-functions' on 'file-truename' resolved dir. > > --- > > lisp/progmodes/project.el | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > > index 4eac541167a..45f5328f6be 100644 > > --- a/lisp/progmodes/project.el > > +++ b/lisp/progmodes/project.el > > @@ -251,6 +251,10 @@ project-current > > pr)) > > > > (defun project--find-in-directory (dir) > > + "Invoke `project-find-functions' for DIR. > > +DIR is resolved to its true name, 'chasing' symbolic links, to avoid > > +duplicate projects that share resolved directory locations." > > + (setq dir (file-truename dir)) > > That's not necessarily what the user will want, since it changes the > name of the file (and potentially its directory as well). If the file > or the directory have some "magical" name that matters, this will > backfire. > > I think it is better to detect the fact that two directories point to > the same place via symlinks (e.g., with file-equal-p), and avoid > duplication in that case, but without actually substituting the file's > name by its truename. > > But of course the final word is for Dmitry. > I expect that (project-current) whether invoked when default-directory points to a symlinked project or not, returns the same thing. It's an opaque value to users? --0000000000009d0eea0630b5379f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Mar 19, 2025 at 1:10=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Wed, 19 Mar 2025 12:55:09 -0400
>
> This avoids duplicate projects accessed via symlinks that share resolv= ed directory locations.=C2=A0 This has
> bothered me for a while, so here we go.
>
> From 074905ff365c6bcd7cbcf72e0158ae9db0908a20 Mon Sep 17 00:00:00 2001=
> From: shipmints <shipmints@gmail.com>
> Date: Wed, 19 Mar 2025 12:50:28 -0400
> Subject: [PATCH] project--find-in-directory resolves symlinks (bug#xxx= )
>
> This avoids duplicate projects that share resolved directory locations= .
>
> * lisp/progmodes/project.el (project--find-in-directory): Invoke
> 'project-find-functions' on 'file-truename' resolved d= ir.
> ---
>=C2=A0 lisp/progmodes/project.el | 4 ++++
>=C2=A0 1 file changed, 4 insertions(+)
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 4eac541167a..45f5328f6be 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -251,6 +251,10 @@ project-current
>=C2=A0 =C2=A0 =C2=A0 pr))
>=C2=A0
>=C2=A0 (defun project--find-in-directory (dir)
> +=C2=A0 "Invoke `project-find-functions' for DIR.
> +DIR is resolved to its true name, 'chasing' symbolic links, t= o avoid
> +duplicate projects that share resolved directory locations."
> +=C2=A0 (setq dir (file-truename dir))

That's not necessarily what the user will want, since it changes the name of the file (and potentially its directory as well).=C2=A0 If the file=
or the directory have some "magical" name that matters, this will=
backfire.

I think it is better to detect the fact that two directories point to
the same place via symlinks (e.g., with file-equal-p), and avoid
duplication in that case, but without actually substituting the file's<= br> name by its truename.

But of course the final word is for Dmitry.

=
I expect that = (project-current) whether invoked when default-directory points to a symlin= ked project or not, returns the same thing.=C2=A0 It's an opaque value = to users?
--0000000000009d0eea0630b5379f-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 19 22:16:03 2025 Received: (at 77122) by debbugs.gnu.org; 20 Mar 2025 02:16:03 +0000 Received: from localhost ([127.0.0.1]:54531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tv5Rz-0005WM-FH for submit@debbugs.gnu.org; Wed, 19 Mar 2025 22:16:03 -0400 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:39157) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tv5Rt-0005Vj-Q6 for 77122@debbugs.gnu.org; Wed, 19 Mar 2025 22:16:01 -0400 Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 404F213833F8; Wed, 19 Mar 2025 22:15:52 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Wed, 19 Mar 2025 22:15:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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:subject:subject:to:to; s=fm3; t=1742436952; x=1742523352; bh=F8/uq92NDtnzNEjG7zupa8Aa7/QkC+D5txT2IDqC1V0=; b= Hp9RNVyt9I2DDtzUQLA6cFhKI6O2RQVWtKzGdriSXZd3ojuIeE3oDkqcJkkjYJWp bmxanLchlnW8mEj3O6dQ/br30GfVFaXY/vrMh5tb8D0WlF0TLcVEG5MjEBkfujOy 4aACsOdZe+WJTloEHubF7awBLaFUUd2/IIFf9UbGoiPFy0j61atcJeU+UOTo4lPt i/UdwAwPZ+QgJaAz+DfHDciejnFFbAoVrUQgIIc0O2eru6zL1dkJ4B/xsra0M/rD NREgy4Cr87CJGUYIc0PtCV3ghASN1aiOqxl5P6RoNzrYMuIV+r1j+0uAWC5AIMqt RhjmuhrQB5s3iSmD86cu1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1742436952; x=1742523352; bh=F 8/uq92NDtnzNEjG7zupa8Aa7/QkC+D5txT2IDqC1V0=; b=BmvwrImdJ9pAru1Kv D1pOcUjLKkausqz6aSzRV6MrZdCV4Fol063ApImXGbPnEqU/VuZfodBzwotEhYPA q9Ri6oahW5rwYPRa8ANb1Ba+tFdwTqEcsrELzkIy28ncqy93H4F7Q5dKznYHOB3U cLcmz800KzbQkuOWkyIHUWXg/sLNhDKBFkM5an4CuFKnQzS5PJj0NHUEj1sb0NOl MAP+66vENljVg1IgE8fR0fu2YOVc/a/IQdgABEYMm2pS8kxK5n7iwOTv9gQMjuw0 9xZRWLwxG9vGz46By4jb+NdcIeOCG/F+ZQEfIXudwoxMcSwYApMk3XMjAipyAQHd gfHgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugeeileekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthekredttddv jeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrd guvghvqeenucggtffrrghtthgvrhhnpeegueegteffuddvjeevvdelleeitdeftdduhfef feffjedukeevjedvfeffgfevgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthht ohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhhihhpmhhinhhtshesgh hmrghilhdrtghomhdprhgtphhtthhopeejjeduvddvseguvggssghughhsrdhgnhhurdho rhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Mar 2025 22:15:50 -0400 (EDT) Message-ID: Date: Thu, 20 Mar 2025 04:15:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Ship Mints , 77122@debbugs.gnu.org References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi! On 19/03/2025 18:55, Ship Mints wrote: > This avoids duplicate projects accessed via symlinks that share resolved > directory locations.  This has bothered me for a while, so here we go. Could you describe the reasons why your setup is the way it is? Personally, I've never used symlinks at this level, and if I did, I'm not sure I would see the problem with project-root returning different strings for those. What exactly is the problem? Having the "same" project multiple times in project history? I can name a couple of (probably minor) downsides: * The project detection would be slower (more disk I/O). * project-root would more often return a string that is not a parent directory of default-directory. Some code out there probably soft-depends on that. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 20 07:19:32 2025 Received: (at 77122) by debbugs.gnu.org; 20 Mar 2025 11:19:32 +0000 Received: from localhost ([127.0.0.1]:55694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tvDvv-0005cJ-Og for submit@debbugs.gnu.org; Thu, 20 Mar 2025 07:19:32 -0400 Received: from mail-ua1-x92d.google.com ([2607:f8b0:4864:20::92d]:45259) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tvDvs-0005bz-9F for 77122@debbugs.gnu.org; Thu, 20 Mar 2025 07:19:29 -0400 Received: by mail-ua1-x92d.google.com with SMTP id a1e0cc1a2514c-86718c2c3b9so250851241.2 for <77122@debbugs.gnu.org>; Thu, 20 Mar 2025 04:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742469562; x=1743074362; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=20NSQ8JWHeU4jw6WlrUwg/fiQjimf7ypX1JKpeIu+u8=; b=D2bjm/rjuqD9A1XXv30s6pMFWshA0DSgkUMekJ7Xv9DqXzL9S6qxwCmpuH/pGo+qQF BeWB52tHdYQuHTGa3P/Co8p/M0Smiok6lN122bbaUAwf+eijwrDCwYpKOxqa4SYm0d/i OnljJ8DwEp2y3l5+/vBOYPSYumabBHtP9A3jtvBn8u+/Bm0ciXPwwjWO/jMum238oxf5 5fMWY4tFztfJJSlIfC8ibPwcmN8w7AD0bodFlCo3k6bWPhDiMTuOqvPnpwfzR1OyAxdU ayUBPyHyBvA2JEk2JgMPqcsGBVsZ21dfreV6FuaBB4YdArZJ/78ERqnxrpVDI34XzWcC AOnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742469562; x=1743074362; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=20NSQ8JWHeU4jw6WlrUwg/fiQjimf7ypX1JKpeIu+u8=; b=lHepkMVTO68ePTZpJBaXs99alIP/m1SqV57rH3oLbwCsptD+AZcGSevZJs20WRjMi2 k4QmGECN9utXW/jbKLyVmY2Av+c06OVHAHgS+cEjS76duBy5dG8U5Vp8OuC+NJ54WuEw GKYfQCuA4wSHgYIKpCS+1ZfCUrypYEMTzwD9GIymBd7ENczX7K0Jlm7aqYERZZVyYqBV muHKfuEgGFjuJRwBgtq076LHslA0OG1U1jv0bXURi14CGKxROiqVGNdsgCTBZ/Jm6yyo OkWEHahaPeM59o4R/x2QNokqTTXiQoCMVZDdTT1lRx4Pain9Cy0WkIU0hM06emwe5Beo xnJQ== X-Gm-Message-State: AOJu0Ywp4+a6ExhcCvdM28QlkSxnueT5dlAiLxUtZm8a6iNJBRrt51T9 KCp8eggic+EdpH3eDHJpihkTTL+bIA+IAsMnnoA4JJOnG30mhTrxH9NV35bpfkbpbYFbp6f1eH+ Rlb206KymJSL0oIiHp3U/J576taSImIsy X-Gm-Gg: ASbGncseE2pylxlPwl4C1DqZCXkO/zvgEG9p5LhGcBS5SekvsLdIZbljsVw9dtRJ8y/ dGr0xDJTPj7VDt3q/Vhjv1UiMMQNxiLf1Pk4mNrSpIvedGCfbb+7Meq1BUnNoRPSOlfcK1NHhuG WKkS2z1ilO4JFq6EcvUstELRGWs883KNwZfxew X-Google-Smtp-Source: AGHT+IEXAEVJZAhyt1kba/MJQyfsJ1vnmYiPSC2goPey/P/4gNv7NoK5mWkRnO8iRBJspxl7zNXc5F39rh3m2rKTKNE= X-Received: by 2002:a05:6102:dcc:b0:4c1:9d9b:54b8 with SMTP id ada2fe7eead31-4c4ec6000d3mr5353510137.2.1742469562072; Thu, 20 Mar 2025 04:19:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ship Mints Date: Thu, 20 Mar 2025 07:19:10 -0400 X-Gm-Features: AQ5f1Job8g05EVFhMBUC1ZvkCIbnmZ5y6GuZQ1qEE-LyP9Nd0TmKmmKuuvQmav4 Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Dmitry Gutov Content-Type: multipart/alternative; boundary="00000000000047875a0630c44f71" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --00000000000047875a0630c44f71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2025 at 10:15=E2=80=AFPM Dmitry Gutov wr= ote: > Hi! > > On 19/03/2025 18:55, Ship Mints wrote: > > This avoids duplicate projects accessed via symlinks that share resolve= d > > directory locations. This has bothered me for a while, so here we go. > > Could you describe the reasons why your setup is the way it is? > Many of us here do the same out of habit and convenience to normalize our own directory trees as an overlay on the varied-structured work we need to deal with. Personally, I've never used symlinks at this level, and if I did, I'm > not sure I would see the problem with project-root returning different > strings for those. > > What exactly is the problem? Having the "same" project multiple times in > project history? > If one loads two files from the same project but one via the symlinked path, and another via the natural path (often, an underlying tool will choose natural while Emacs chooses default-directory), and one has tools that compare project-likeness between/among buffers, they report different projects. That's misleading and annoying. > I can name a couple of (probably minor) downsides: > > * The project detection would be slower (more disk I/O). > * project-root would more often return a string that is not a parent > directory of default-directory. Some code out there probably > soft-depends on that. > I've been running with the following for a while and haven't found any issues yet, hence the patch to help others with similar situations. (defun my/project--find-in-directory-advice (args) (cons (file-truename (car args)) (cdr args))) (advice-add #'project--find-in-directory :filter-args #'my/project--find-in-directory-advice) We can make this a user option nil (default), t (always), 'inhibit-remote so the user can avoid hammering remote connections. If we could normalize at a lower level and still retain the symmetry between default-directory and a normalized project object, that would suggest caches like the one in project-try-vc have to cache more than one project directory form. Doesn't seem worth the complexity? -Stephane --00000000000047875a0630c44f71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Mar 19, 2025 at 10:15=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote:
Hi!

On 19/03/2025 18:55, Ship Mints wrote:
> This avoids duplicate projects accessed via symlinks that share resolv= ed
> directory locations.=C2=A0 This has bothered me for a while, so here w= e go.

Could you describe the reasons why your setup is the way it is?

Many of us here do the same out of habit and convenience to norm= alize our own directory trees as an overlay on the varied-structured work w= e need to deal with.

Personally, I've never used symlinks at this level, and if I did, I'= ;m
not sure I would see the problem with project-root returning different
strings for those.

What exactly is the problem? Having the "same" project multiple t= imes in
project history?

If one loads two files from the= same project but one via the symlinked path, and another via the natural p= ath (often, an underlying tool will choose natural while Emacs chooses defa= ult-directory), and one has tools that compare project-likeness between/amo= ng buffers, they report different projects.=C2=A0 That's misleading=C2= =A0and annoying.
=C2=A0
I can name a couple of (probably minor) downsides:

* The project detection would be slower (more disk I/O).
* project-root would more often return a string that is not a parent
directory of default-directory. Some code out there probably
soft-depends on that.

I've been running with the = following for a while and haven't found any issues yet,=C2=A0hence the = patch to help others with similar situations.

=C2=A0 (defun my/project--find-in-director= y-advice (args)
=C2=A0 =C2=A0 (cons (file-truename (car args)) (cdr args= )))
=C2=A0 (advice-add #'project--find-in-directory :filter-args #&#= 39;my/project--find-in-directory-advice)

We can make this a user = option nil (default), t (always), 'inhibit-remote so the=C2=A0user can = avoid hammering remote connections.=C2=A0 If we could normalize at a lower = level and still retain the symmetry between default-directory and a normali= zed project object, that would suggest caches like the one in project-try-v= c have to cache more than one project directory form.=C2=A0 Doesn't see= m worth the complexity?

-Stephane

=C2=A0
--00000000000047875a0630c44f71-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 22 21:47:44 2025 Received: (at 77122) by debbugs.gnu.org; 23 Mar 2025 01:47:45 +0000 Received: from localhost ([127.0.0.1]:46421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twARB-0004Ex-5A for submit@debbugs.gnu.org; Sat, 22 Mar 2025 21:47:43 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:34058) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twAR5-0004Dg-1o for 77122@debbugs.gnu.org; Sat, 22 Mar 2025 21:47:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qQAlIjPdN+fU5FrqHmHj+4aT4VcSns4L/X6vy9jvMuE=; b=Tgnlq8ZEmv1Ay9XBDeGdAVmv4n H4g7fmRfQxCNNM9QrcVarDwajeim9s7y1UtZ4LqUwkas/ahqGUZsH/zrubvK++oBsNU1hy+uUV+BQ dPO06lQ6JEjfYTVsirOSOogleUgHvirfE/lwps2eRQuCkruts2Y9vL3kOMsHejPuDGo0uc2eKjwHV /MBSQrgKWiELdq6zW+KVImv77pl9NlKRcyHfA4NRITQCMgCMNBWoiooo9uBXvoHN0+FY5lKplDNKz mHXzljKNKeA9ubFnZ9/xHCtf0rTkHRhPVL27ouo2+ul8RdFwOGKveRd5E2rNn/3Vck7NHejHHKoyA +vn0Qk9g==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1twAQg-003mc6-1q; Sat, 22 Mar 2025 21:47:10 -0400 From: Daniel Colascione To: Dmitry Gutov Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks In-Reply-To: References: User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Sat, 22 Mar 2025 21:47:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Ship Mints X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Dmitry Gutov writes: > Hi! > > On 19/03/2025 18:55, Ship Mints wrote: >> This avoids duplicate projects accessed via symlinks that share >> resolved directory locations.=C2=A0 This has bothered me for a while, so >> here we go. > > Could you describe the reasons why your setup is the way it is? > > Personally, I've never used symlinks at this level, and if I did, I'm > not sure I would see the problem with project-root returning different > strings for those. > > What exactly is the problem? Having the "same" project multiple times > in project history? > > I can name a couple of (probably minor) downsides: > > * The project detection would be slower (more disk I/O). > * project-root would more often return a string that is not a parent > directory of default-directory. Some code out there probably > soft-depends on that. FWIW, I sometimes symlink convenient names to inconvenient ones, and it would be a shame to use the inconvenient names due to excessive symlink chasing. (Other packages aren't great about this.) Can't people who want symlink chasing add something to project-find-functions? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 06:40:49 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 10:40:49 +0000 Received: from localhost ([127.0.0.1]:54353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twfEe-0006lM-GI for submit@debbugs.gnu.org; Mon, 24 Mar 2025 06:40:49 -0400 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]:49315) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twfEc-0006l8-Fg for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 06:40:47 -0400 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-86d377306ddso1834950241.2 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 03:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742812841; x=1743417641; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=boRRz6N/uAFkdlyUbm0BgRimK7sSrxg0iSEn5YPWeZQ=; b=FG/Mc/3PYd/hM4QvhFzS01v1bwEnWyjXJ5Usucml3/Z7Z6ZztOUBMyqedXiCG3W5hE IYmDJZ2GDTpV92oTN7U7cTr1a4Lr8XjbFMwil/TjfsL24FOIHJzKsg/rS18I2DlL1eA7 pHaHBZxlBEgJoIwBmqcY1z6MqCKHk7mHD+jB57TyvRY6wdB4rdu2a/BFxBwCNQYPKAh3 q1y50Um08+DyCVUuIZ/lBLB+tudaT1tq0IOv0qqt/lM4jdgF/W5TShOT0D9pE/2lt/+i PfUsOueSpE4Nng2SX6CMPh/qQlBxUCKXRDFJsCtuegpIjQLd0ZPmboKRiUfiMH37y7w0 MH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742812841; x=1743417641; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=boRRz6N/uAFkdlyUbm0BgRimK7sSrxg0iSEn5YPWeZQ=; b=ntAofifoZrWjGL3BqMWxDS7fpJq1vOR7/t3BwDcRbHFgDshCm+MfjDbZRhAfnFQjnX G+0sR5wT7EA3Tgnx8bH9sY9v9tVWkzjVIlicqdSu3MHVcpHnUGYaGSXtmJDFLzAkIz9d 2kUqQpJYI+djXNr0KQx3D86cvlkU5O6Ohn4SfJNt11iTR6EKggoO0q1D/g8fSpHfRvVE lajU2dWlyEB8j+XATsjPGZH1ZPRGv73EYLVmSoFLk60NmcAM/dSIWxNeGmxoCKWhF0ry 1PS8X+BnPphE3ZOki4OWjaKyG0M1En31G85E4gZG62Mp7l10xzOdHcqJs3jIuPup6H4N lHyA== X-Forwarded-Encrypted: i=1; AJvYcCUddr737RH2XNaGyJk73KjpoSd9qBD4ctvl+jUXdFDkt7WejJpmxK1eFlF0fR+wT4VqVd85kA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyOnB8xvFtffyVY2T24iJmnuA7I+V7ZGYLVyGR3CgaUbalDZ7b4 CsyubiPUIBMsP2ou3PxUCo3eOoXBpm8kT7Q2ceDFykSTtJZpzDsLwA1GA8+3xa2zMwZFJDRXPP+ 8ewIcXpK8r9hly0wFVVW8VWiLNec= X-Gm-Gg: ASbGncuRYfy5GZY7VwrwOxqdDNNpj102Qjl0kZ5IEBBxCRGb3eIg3LC8b/fTSoyMEpZ af88YJfzMAv9AHlT+r8FHcryzZjkysMyvyGMw32GMWjIHFOYIYNJhfeg9kqaUJ1C4y2NNBBOGPT Nb+UD6lsgAByKByQT+TdR0ThUB/A== X-Google-Smtp-Source: AGHT+IG/EUqT/0B5gJiCnopP+a+vX73rAmrzANSNSDvlvokk7Ecn+CEXKzSI+HBnD9mqKDUjHZ6Do5vVC+uXfcyHVEE= X-Received: by 2002:a05:6102:3f0d:b0:4c4:df56:6a2b with SMTP id ada2fe7eead31-4c50d491ca0mr8180928137.4.1742812840421; Mon, 24 Mar 2025 03:40:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ship Mints Date: Mon, 24 Mar 2025 06:40:29 -0400 X-Gm-Features: AQ5f1JrcXkhNvdy0MGyYORlyfqTKYRXw-sa5wFF3vWapdpzIWilRxqzddp_L-YE Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000004372340631143cec" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) --0000000000004372340631143cec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 22, 2025 at 9:47=E2=80=AFPM Daniel Colascione wrote: > Dmitry Gutov writes: > > > Hi! > > > > On 19/03/2025 18:55, Ship Mints wrote: > >> This avoids duplicate projects accessed via symlinks that share > >> resolved directory locations. This has bothered me for a while, so > >> here we go. > > > > Could you describe the reasons why your setup is the way it is? > > > > Personally, I've never used symlinks at this level, and if I did, I'm > > not sure I would see the problem with project-root returning different > > strings for those. > > > > What exactly is the problem? Having the "same" project multiple times > > in project history? > > > > I can name a couple of (probably minor) downsides: > > > > * The project detection would be slower (more disk I/O). > > * project-root would more often return a string that is not a parent > > directory of default-directory. Some code out there probably > > soft-depends on that. > > FWIW, I sometimes symlink convenient names to inconvenient ones, and it > would be a shame to use the inconvenient names due to excessive > symlink chasing. (Other packages aren't great about this.) Can't people > who want symlink chasing add something to project-find-functions? > Yeah, good question. "Can't people" applies pretty much to every feature and option added to Emacs that people can do themselves including overriding functions wholesale. The bigger picture, to me, is that if we add options to do things like this for our users, then we can help more of them, we can refine implementations at deeper levels should we need to, we can prompt people to think more considerately about their working environments. Perhaps some never considered using symlinks as vanity paths and they'll have the choice to treat project objects among those paths canonically. Since I suggested it be optional, it would be off by default, right? If you think you'd want to canonicalize paths to project roots in some places and not others, perhaps we could contrive a project sentinel file ala .project-notruename.el/d or .project-config.el/d, and for people that want to do things in code, a list project can consult. --0000000000004372340631143cec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Sat, Mar 22, 2025 at 9:47=E2=80=AFPM Daniel Colascione <dancol@dancol.org> wrote:
=
Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi!
>
> On 19/03/2025 18:55, Ship Mints wrote:
>> This avoids duplicate projects accessed via symlinks that share >> resolved directory locations.=C2=A0 This has bothered me for a whi= le, so
>> here we go.
>
> Could you describe the reasons why your setup is the way it is?
>
> Personally, I've never used symlinks at this level, and if I did, = I'm
> not sure I would see the problem with project-root returning different=
> strings for those.
>
> What exactly is the problem? Having the "same" project multi= ple times
> in project history?
>
> I can name a couple of (probably minor) downsides:
>
> * The project detection would be slower (more disk I/O).
> * project-root would more often return a string that is not a parent >=C2=A0 =C2=A0directory of default-directory. Some code out there probab= ly
>=C2=A0 =C2=A0soft-depends on that.

FWIW, I sometimes symlink convenient names to inconvenient ones, and it
would be a shame to use the inconvenient names due to excessive
symlink chasing. (Other packages aren't great about this.) Can't pe= ople
who want symlink chasing add something to project-find-functions?

Yeah, good question.=C2=A0 "Can't people" applie= s pretty much to every feature and option added to Emacs that people can do= themselves including overriding functions wholesale.=C2=A0 The bigger pict= ure, to me, is that if we add options to do things like this for our=C2=A0u= sers, then we can help more of them, we can refine implementations at deepe= r levels should we need to, we can prompt people to think more consideratel= y about their working environments.=C2=A0 Perhaps some never considered usi= ng symlinks as vanity paths and they'll have the choice to treat projec= t objects among those paths=C2=A0canonically.

Since I suggested it be optional, it would= be off by default,=C2=A0right?=C2=A0 If you think you'd want to canoni= calize paths to project roots in some places and not others, perhaps we cou= ld contrive a project sentinel file ala .project-notruename.el/d or .projec= t-config.el/d, and for people that want to do things in code, a list projec= t can consult.
=C2=A0
--0000000000004372340631143cec-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 09:03:17 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 13:03:17 +0000 Received: from localhost ([127.0.0.1]:54731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twhSW-0000PO-U9 for submit@debbugs.gnu.org; Mon, 24 Mar 2025 09:03:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60582) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twhSU-0000Oy-9z for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 09:03:14 -0400 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 1twhSM-0004Q7-EK; Mon, 24 Mar 2025 09:03:06 -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=2gML/DeBQcZx/g2RohUl3ohSyaV7RE8II+4xMylrDuA=; b=En6b+Sp/DEDi JtT5+5RLZKjUW+rbr/ZgkGp9J99TFdUodUhEQzZO2Rv5NwmsmJHoFBqtm3S4Qkq8pPygvZteVHWH1 NBF6PYvRxLWCUoqaYVh88jPQm9QwM2ISHhVOFebnjvmyPTLDfZ8MQdzYQps07PU+mqgP9iQaqY+DX itrtwPZp/ugoR6VUIgl9ZmeI+2djUElq0qHc6f6dR117xAUsxRs2sfSl9IHX7AOzX04LDJiHHEo+f n8wNh5EmPLItTAcF3TGqmPaOlGSukjHbfEeMted2NDgGvspdMqsW4BQnFemU/A0rrbBgPLwwmcm9X f1u6By4VRlE9dPPYmXo33w==; Date: Mon, 24 Mar 2025 15:03:02 +0200 Message-Id: <864izifunt.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 06:40:29 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 77122@debbugs.gnu.org, Dmitry Gutov > From: Ship Mints > Date: Mon, 24 Mar 2025 06:40:29 -0400 > > Since I suggested it be optional, it would be off by default, right? If you think you'd want to canonicalize > paths to project roots in some places and not others, perhaps we could contrive a project sentinel file ala . > project-notruename.el/d or .project-config.el/d, and for people that want to do things in code, a list project > can consult. AFAIR, you didn't respond to my suggest to try a different solution. Namely, instead of changing the file name by resolving links, something that could cause problems for some people, how about using file-equal-p to avoid duplication of projects in these cases? If my proposal makes sense, it will allow use to avoid duplication without changing the file names, because symlinks will be chased internally, only where we decide whether two projects are different or not. This is better than having an optional behavior, because inevitably someone will want to use this option, but also wouldn't like his/her project directories appear under their resolved names, and then we are back at the same problem. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 11:15:41 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 15:15:41 +0000 Received: from localhost ([127.0.0.1]:57402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twjWe-0007aN-Up for submit@debbugs.gnu.org; Mon, 24 Mar 2025 11:15:41 -0400 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]:57434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twjWb-0007a7-V7 for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 11:15:38 -0400 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-524125f6cadso4606345e0c.2 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 08:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742829332; x=1743434132; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x2Z6X6I49KClLNgbB/U/3yb/ERabnA2h/I+tGReb9fE=; b=AqDRr8UMl+wSis1r1Cb1yeb2eZiGpsQF0DqIdVJjK/FJIdLi1NkhT3rbANNpHB9aUT IS61Rhb+GTGo7lI1ltzv71swz1YQwgyTJ6o8sbSsVg8rq2h5fjCZvcLq1p88pISd6+XY pRQq9HTN9a1OAYvwowv4+84PGeWlSDxrnx2KJwdT7Cojb+rluDwH+KdvDx+sSAYKFsfi MtvR+GcLiqQZQUI5PmKyueXiBAKgHPNZO/crRBFLfRAUMOGThwLieOn7k5Y6UuVPovFl IDQu4XV59TUMXthbMzEq8gtmsr5/+V3NjNOBqjcO13XUpxCYExcO7dGXKzIXFAFXHsFh va/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742829332; x=1743434132; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x2Z6X6I49KClLNgbB/U/3yb/ERabnA2h/I+tGReb9fE=; b=HOVnGpFZA1COz2rq2b6UqXrwYlPSVDR/VnVhpkXrslo+XICRSh6iAZIOcN+S9o4V6g Pfg6KBZgn+QXtsmargugpYnlgVnXuEuVZh8YVBu9YTBWeiwKpXfrvURsqBwIqqcBM0S2 myTcf0DtZok6FZKdoCs2PGJxsAUR3/BO7Yvkcx5u+aR9YUjw2qAbB3bHbmc86YRkX/1P rX73GWvefeMx7AWFzeo5/PJmQIDqLoat+jioHEU6Gf8L58rdAdRt4SSqRVSOTiQ76vg8 /o58NIgCBv9U3htwGTRSQxGATfPYUrlUJdHBkolGggBNjI26FD2dhLvJxoSX+pnhSzYx Vj/Q== X-Forwarded-Encrypted: i=1; AJvYcCVO5hf08tYwcs4CT8WFZKawjfNQVQGcR4aIrAtuU+r8oinAHAhgru6qvaUa94eCewFjkMotkA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzEFQ4DSf8I8uUbJakfsDLiIrptQtLwhtoKeKcpIsMLL/2Y2dRU vezwQtvsoxRLHPfudLkc7YAJHAMYTS39bjBgZ97V4a+FyFHouP0cVjbM1ZDfRWa6+gtWdDyxMJ0 EhMBWmYp3JbSaGjOtwzCMhffYoLM= X-Gm-Gg: ASbGnct9ltE0V3TlgVuELfFE11ooY+KYA/joTtAWQE6iml5SEaiNnQOHfzandy3jtor NbwPA9KLZZ00GUiLJJHjYCc4R03i1Pr91f2lntZNV2YUKti8AqRjhcHTAQb4NKdC/uj46rcxV4D fOamvdtVsIBE4sAsRynj+21Aex5Q== X-Google-Smtp-Source: AGHT+IFwIq5TcAwlryB70fGB6yULz5qamkkmWHAwQkXA9iKZkzgd4JVlk67OoP6O8BZ3GmKcUds2CJiWjWQkQecRTnE= X-Received: by 2002:a05:6122:490e:b0:516:1ab2:9955 with SMTP id 71dfb90a1353d-525a85008b4mr9251751e0c.6.1742829331886; Mon, 24 Mar 2025 08:15:31 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> In-Reply-To: <864izifunt.fsf@gnu.org> From: Ship Mints Date: Mon, 24 Mar 2025 11:15:20 -0400 X-Gm-Features: AQ5f1JrNqmqGtiaKIbf5K1iJAL2P7XvsLiIGuyb6Psz1-jObWGaGieTDklA8xgg Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000003b4311063118130b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003b4311063118130b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 9:03=E2=80=AFAM Eli Zaretskii wrote: > > Cc: 77122@debbugs.gnu.org, Dmitry Gutov > > From: Ship Mints > > Date: Mon, 24 Mar 2025 06:40:29 -0400 > > > > Since I suggested it be optional, it would be off by default, right? I= f > you think you'd want to canonicalize > > paths to project roots in some places and not others, perhaps we could > contrive a project sentinel file ala . > > project-notruename.el/d or .project-config.el/d, and for people that > want to do things in code, a list project > > can consult. > > AFAIR, you didn't respond to my suggest to try a different solution. > Namely, instead of changing the file name by resolving links, > something that could cause problems for some people, how about using > file-equal-p to avoid duplication of projects in these cases? If my > proposal makes sense, it will allow use to avoid duplication without > changing the file names, because symlinks will be chased internally, > only where we decide whether two projects are different or not. > > This is better than having an optional behavior, because inevitably > someone will want to use this option, but also wouldn't like his/her > project directories appear under their resolved names, and then we are > back at the same problem. > I did consider it. The most popular project objects, project-vc, and transient are defined as (list 'vc vcbackend dir) and (cons 'transient dir), respectively and vc objects are cached. If we don't canonicalize the dir name, we can't find the vc cache entry if a probe is attempted from another dir, even if that dir morally is equivalent. One can't change the embedded dir on the way out of without creating two objects, one with the first location to create the cache entry, and a second from an equivalent convenience dir. I'm curious to hear more about why people would object to (project-root project-obj) being canonicalized. I don't think many people ever manually enter project dirs. The persisted known projects, I'd think, would also benefit from no duplicates. If you see the place in project.el where file-equal-p helps, I'll happily hack on it. --0000000000003b4311063118130b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 9:03=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: 77122@debbugs.gnu.org, Dmitry Gutov <dmitry@gutov.dev>
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 06:40:29 -0400
>
> Since I suggested it be optional, it would be off by default, right?= =C2=A0 If you think you'd want to canonicalize
> paths to project roots in some places and not others, perhaps we could= contrive a project sentinel file ala .
> project-notruename.el/d or .project-config.el/d, and for people that w= ant to do things in code, a list project
> can consult.

AFAIR, you didn't respond to my suggest to try a different solution. Namely, instead of changing the file name by resolving links,
something that could cause problems for some people, how about using
file-equal-p to avoid duplication of projects in these cases?=C2=A0 If my proposal makes sense, it will allow use to avoid duplication without
changing the file names, because symlinks will be chased internally,
only where we decide whether two projects are different or not.

This is better than having an optional behavior, because inevitably
someone will want to use this option, but also wouldn't like his/her project directories appear under their resolved names, and then we are
back at the same problem.

I did consider it.=C2=A0 The mos= t popular project objects, project-vc, and transient are defined as (list &= #39;vc vcbackend dir) and (cons 'transient dir), respectively and vc ob= jects are cached.=C2=A0 If we don't canonicalize the dir name, we can&#= 39;t find the vc cache entry if a probe is attempted from another dir, even= if that dir morally=C2=A0is=C2=A0equivalent.=C2=A0 One can't change th= e embedded dir on the way out of without creating two objects, one with the= first location to create the cache entry, and a second from an equivalent = convenience dir.

I'm curious to hear more about why people would object to (project-= root project-obj) being canonicalized.=C2=A0 I don't think many people = ever manually enter project dirs.=C2=A0 The persisted known projects, I'= ;d think, would also benefit from no duplicates.

If you see the place in project.el=C2= =A0where file-equal-p helps, I'll happily hack on it.=C2=A0
=
--0000000000003b4311063118130b-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 14:24:44 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 18:24:45 +0000 Received: from localhost ([127.0.0.1]:58180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twmTc-0005Go-9x for submit@debbugs.gnu.org; Mon, 24 Mar 2025 14:24:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47140) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twmTa-0005GB-5a for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 14:24:42 -0400 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 1twmTP-0005YA-VL; Mon, 24 Mar 2025 14:24:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=bLNWHUq2hwhs7QpluqdgA50iO/AT0mokBI60RViDHmw=; b=qjD/Boe6rBV554GMrra7 fyJDeKN9XbgvLxxZrfLt0F4acIsvwzx2FzXPNC1dcJu5GpNhVSSI11vEpXjMY6PouwzxzdMKoOz3Q TxrNm6/QhZN+/OH60rQ6pemXRzEKreVxg2e5eb6V/tuRZqUgdhA1RElgAuPam8HPmIGMN06sOywBc jjuTE5y1MC7Wq/aZqM0SLZvHswqBLAU5PzokLjKTfDZ1t/h+MpyfqKs4r/ePOiD5YNUBkHqdqoeCD PHEv2irKhoVKq0yUbxYOUST6ey4QG8tct83fGylmdXGeSKBiq5Z6S8/1wpcBsKw6kis7CA2vPXdV7 oerY10V3N4wSjw==; Date: Mon, 24 Mar 2025 20:24:07 +0200 Message-Id: <86y0wue188.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 11:15:20 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: <864izifunt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Mon, 24 Mar 2025 11:15:20 -0400 > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > On Mon, Mar 24, 2025 at 9:03 AM Eli Zaretskii wrote: > > AFAIR, you didn't respond to my suggest to try a different solution. > Namely, instead of changing the file name by resolving links, > something that could cause problems for some people, how about using > file-equal-p to avoid duplication of projects in these cases? If my > proposal makes sense, it will allow use to avoid duplication without > changing the file names, because symlinks will be chased internally, > only where we decide whether two projects are different or not. > > This is better than having an optional behavior, because inevitably > someone will want to use this option, but also wouldn't like his/her > project directories appear under their resolved names, and then we are > back at the same problem. > > I did consider it. The most popular project objects, project-vc, and transient are defined as (list 'vc > vcbackend dir) and (cons 'transient dir), respectively and vc objects are cached. If we don't canonicalize the > dir name, we can't find the vc cache entry if a probe is attempted from another dir, even if that dir morally is > equivalent. Why can't we? what precludes that? > If you see the place in project.el where file-equal-p helps, I'll happily hack on it. I'm sorry, I cannot afford looking through the project.el code to find this. But if the problem is that directories or files don't compare equal, the file-equal-p is the way to go, so I don't understand why the places where we do the comparison should be hard to find for someone who knows their way in project.el's code and/or has enough time to dig. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 15:29:49 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 19:29:49 +0000 Received: from localhost ([127.0.0.1]:58741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twnUY-00061D-VW for submit@debbugs.gnu.org; Mon, 24 Mar 2025 15:29:48 -0400 Received: from mail-ua1-x932.google.com ([2607:f8b0:4864:20::932]:46446) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twnUV-0005zf-T0 for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 15:29:45 -0400 Received: by mail-ua1-x932.google.com with SMTP id a1e0cc1a2514c-867129fdb0aso4365339241.1 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 12:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742844578; x=1743449378; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gu4a7EnQUNNB1LN/Jsf+J34f9+YQuSI4sgQ/lnkdjsY=; b=EadUxw3IGY1K/hyXuNsuBgcuxiwrk6SeqVxU1j0llEvnRV6Vj3puVux0x55oLfBb5l 3q89TS+xJ5fsu7zqV8hSpeKJgfokLyUT4q49Ln8toSJ1an7frJOsWCIYpbzRNu9VVw08 aCZaXEZqxHR7UDvaV9gtRDCvP2uFd7Yg1qD5uJx5pLPDS1vvjnzSTI2UViE0PT/DkBpC 09VTpCsD04XZZUWj+zuinV+vBeyU0JRSann3k7tP3APej6Ydxu9sUG/azIyIpnWzOeWQ t+xjlXfw6UwUidpjVa/GpJlTxrTsOXjXQsFkR9k+9xqFYxpZ1T3GakNg2G1jdj/qMcZU mqZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742844578; x=1743449378; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gu4a7EnQUNNB1LN/Jsf+J34f9+YQuSI4sgQ/lnkdjsY=; b=aFpvAuyk4P7yNAWA94evJ6LacKEO3cL4nmA6K7CH2b2ho4RMDimzhu1/uCGcxb6tWM l1rwR+QCi/H40RGv9MobnXM/guM0046SmPwcE5/Vi3gyfwoRnMHIhTSaUd8AI05tG/i6 YVVxIb7HdEHA4l0Iz2AgPkKffGQqFovzeWUkFZfPPjgbbwWrfjvQoel1KqCSQXmZLkuC R1hhO4kN1sk9HzlmGDfyDGM//fVt0HSble74PwYoZCYWuABSs85hgJ6C3bWIgAGFhkzZ TFTMrXwjZXLBBUVtVQex5VBRGKaVfH/UK5yr+lOt/hgtfSqLi182XUIOkCWLJabJJce/ tV1w== X-Forwarded-Encrypted: i=1; AJvYcCUlXMFjbAWmrlihK6WeiRsnqld1I11/XePyqxVjF4YCZ8cliu50eMD5ricloSml9cBHMYnH1Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy9Ein99ka4Jou5GcfwC5P2AHMC4E3GSGZodksTpp1G1VLBNDUz pIMucELKqZjv8qOuFepXrx64n5CfdSiSZWnCxXfon1TlYVSYHjdaEDgz35KoR2OgehNu+HfFR4D cKkyB5ur70+sBMQYSn2+r79cGanw= X-Gm-Gg: ASbGncusPc78dMFGrUFeit4pOBMBWd7viepHASrGjh7Z79uwHezc0x3VB7rvVgqM45i /38egaKRkdpfj4qcYKls0j1vpbL8JMbmdfN8Ub1B5CbvpPlo2uRsidlQ3voDAsVFyRh2A41QL0m oQLB8P3NGYiC73SnOuhDUS79Lbwj9hN8GXCJ2T X-Google-Smtp-Source: AGHT+IHoXB3TDHQ2QDCdL3yf6JionGvY8GBQHIe9Y6IapRhJwosKAPHXWhiLtMYUOYw3SWfHvmO5qeqs/WoIwsnrybk= X-Received: by 2002:a05:6102:1520:b0:4bb:cbbc:4c with SMTP id ada2fe7eead31-4c50d47c319mr11840197137.2.1742844577905; Mon, 24 Mar 2025 12:29:37 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> In-Reply-To: <86y0wue188.fsf@gnu.org> From: Ship Mints Date: Mon, 24 Mar 2025 15:29:26 -0400 X-Gm-Features: AQ5f1Jo8Dx4bm8mi0oj2dQ_XthSnsz5RdfGC-aRnCr4eVxRK0L4xlEcvBbFh45Y Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f704c406311b9fd8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f704c406311b9fd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 2:24=E2=80=AFPM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Mon, 24 Mar 2025 11:15:20 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > > > On Mon, Mar 24, 2025 at 9:03=E2=80=AFAM Eli Zaretskii wr= ote: > > > > AFAIR, you didn't respond to my suggest to try a different solution. > > Namely, instead of changing the file name by resolving links, > > something that could cause problems for some people, how about using > > file-equal-p to avoid duplication of projects in these cases? If my > > proposal makes sense, it will allow use to avoid duplication without > > changing the file names, because symlinks will be chased internally, > > only where we decide whether two projects are different or not. > > > > This is better than having an optional behavior, because inevitably > > someone will want to use this option, but also wouldn't like his/her > > project directories appear under their resolved names, and then we are > > back at the same problem. > > > > I did consider it. The most popular project objects, project-vc, and > transient are defined as (list 'vc > > vcbackend dir) and (cons 'transient dir), respectively and vc objects > are cached. If we don't canonicalize the > > dir name, we can't find the vc cache entry if a probe is attempted from > another dir, even if that dir morally is > > equivalent. > > Why can't we? what precludes that? > Nothing. Just a matter of programming, as always. We need to restructure some of project.el to make this work well. I'll have a deeper look/think. > If you see the place in project.el where file-equal-p helps, I'll happily > hack on it. > > I'm sorry, I cannot afford looking through the project.el code to find > this. But if the problem is that directories or files don't compare > equal, the file-equal-p is the way to go, so I don't understand why > the places where we do the comparison should be hard to find for > someone who knows their way in project.el's code and/or has enough > time to dig. > You don't have to look. The issue is that no directories are explicitly compared. You just have to humor that it's a bit evil that a singular project approached from different places produces two different project objects. -Stephane --000000000000f704c406311b9fd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 2:24=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 11:15:20 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>
> On Mon, Mar 24, 2025 at 9:03=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
>
>=C2=A0 AFAIR, you didn't respond to my suggest to try a different s= olution.
>=C2=A0 Namely, instead of changing the file name by resolving links, >=C2=A0 something that could cause problems for some people, how about u= sing
>=C2=A0 file-equal-p to avoid duplication of projects in these cases?=C2= =A0 If my
>=C2=A0 proposal makes sense, it will allow use to avoid duplication wit= hout
>=C2=A0 changing the file names, because symlinks will be chased interna= lly,
>=C2=A0 only where we decide whether two projects are different or not.<= br> >
>=C2=A0 This is better than having an optional behavior, because inevita= bly
>=C2=A0 someone will want to use this option, but also wouldn't like= his/her
>=C2=A0 project directories appear under their resolved names, and then = we are
>=C2=A0 back at the same problem.
>
> I did consider it.=C2=A0 The most popular project objects, project-vc,= and transient are defined as (list 'vc
> vcbackend dir) and (cons 'transient dir), respectively and vc obje= cts are cached.=C2=A0 If we don't canonicalize the
> dir name, we can't find the vc cache entry if a probe is attempted= from another dir, even if that dir morally is
> equivalent.

Why can't we? what precludes that?

=
Nothing.=C2=A0= Just a matter of programming, as always.=C2=A0 We need to restructure some= of project.el to make this work well.=C2=A0 I'll have a deeper look/th= ink.

> If you see the place in project.el where file-equal-p helps, I'll = happily hack on it.

I'm sorry, I cannot afford looking through the project.el code to find<= br> this.=C2=A0 But if the problem is that directories or files don't compa= re
equal, the file-equal-p is the way to go, so I don't understand why
the places where we do the comparison should be hard to find for
someone who knows their way in project.el's code and/or has enough
time to dig.

You don't have to look.=C2=A0 The is= sue is that no directories are explicitly compared.=C2=A0 You just have to = humor that it's a bit evil that a singular=C2=A0project=C2=A0approached= from different places produces two different project=C2=A0objects.

=
-Stephane
--000000000000f704c406311b9fd8-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 15:34:48 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 19:34:49 +0000 Received: from localhost ([127.0.0.1]:58784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twnZQ-0006ov-F8 for submit@debbugs.gnu.org; Mon, 24 Mar 2025 15:34:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50012) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twnZO-0006oL-5A for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 15:34:46 -0400 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 1twnZI-0006BK-LM; Mon, 24 Mar 2025 15:34:40 -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=BfiYK1NrhE3tUnXepfrs9VrnbPmVmBfSjwnorpFF194=; b=IrHPlg0T9oT7 uy4wO6Jexh+iGWQRe3P0+ROZN+Wg+oQWp9gzzY3hHlG9bYWzdkugeOONxkKE1qz7lKYn0R6xlwaxq JKeZ0WNcC0uqJLzXktso9Z+bKsrQTNOI42BEHsW/EQfoK/8FX30nAuE4AMh5ez4t2e+awok8ay5gr iWGxoeazHWn2XAfW2j4nQoH63WsU1RUMgZ02ywXecRPRSzQ69QrGx/6tT6MBNhsDc8W1tC6ME4HFB 6k1xqt+jOailoOcilnE/uxZY+v74KXG67XrsUaaQgV28dJiUqkkFDKz3RPZ6kpt/O+LxjisA4s6iK 8WXTtbsD8+XXwNZN8cZkow==; Date: Mon, 24 Mar 2025 21:34:38 +0200 Message-Id: <86sen2dxyp.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 15:29:26 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Mon, 24 Mar 2025 15:29:26 -0400 > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > If you see the place in project.el where file-equal-p helps, I'll happily hack on it. > > I'm sorry, I cannot afford looking through the project.el code to find > this. But if the problem is that directories or files don't compare > equal, the file-equal-p is the way to go, so I don't understand why > the places where we do the comparison should be hard to find for > someone who knows their way in project.el's code and/or has enough > time to dig. > > You don't have to look. The issue is that no directories are explicitly compared. You just have to humor > that it's a bit evil that a singular project approached from different places produces two different project > objects. I'm confused: how does project.el know it's the same or a different project, without comparing? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 15:39:51 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 19:39:51 +0000 Received: from localhost ([127.0.0.1]:58822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twneI-0007Vk-Uf for submit@debbugs.gnu.org; Mon, 24 Mar 2025 15:39:51 -0400 Received: from mail-ua1-x92b.google.com ([2607:f8b0:4864:20::92b]:56626) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twneF-0007Ur-HK for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 15:39:48 -0400 Received: by mail-ua1-x92b.google.com with SMTP id a1e0cc1a2514c-86d3ac0fec0so4348166241.1 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 12:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742845182; x=1743449982; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DFurqAP3k47br0DGFzIQyogs6be+wDdE+snp2P3oPTU=; b=LQpyzH6HrEZKWmE/1n2j5KbHi/a1WUPvZz3XrnspuQA/flDACrk15F2rXnc2Xyw77C 7jB6efxRe8QNR2odlqmY3nK8twMiQes3KZh4tS4PrRmko61HGKO8HCcHTf2RF5uNmvJY r/6HvYRNOhy4XRVj4sZMQaQvGky5mppehqh0bvhDgnuIlEZlIN+V7Bj2qaR7d7moIJrh jL252bfu/v/s8q7i4cJCY2hZddPMw3C0ONJ/Hh2jd3bq+5xcJd9lcT3i/GoB6odFfgo3 GewVkyONIWqycmnrT+t6Z7vHDnU8hxANSaRzI4fenPa1dMvhIO8WxUJSXDbsT4N8FBmf 10xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742845182; x=1743449982; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DFurqAP3k47br0DGFzIQyogs6be+wDdE+snp2P3oPTU=; b=JkHsU5h/D3ZW0Lv2sSIOkMGbw8EkudqlSxRtru5oLkqYL8JsAmdjJA20p/D0MCUihU P6eeQEa/SbPhcjPNyhYBm7sjPE/oKiA2ZYnuZ71nz7tdco3N91uMeu4/VKARgkGJ0IUV OCvXIhm/7+Yb2G/JdiW7gxnVoNKmPMFHSK8CitIFL0W5KW3wa1Q6bVN8UhOfeK4D52kX H9740sfaI1cg5mRtomY3/+BWHlCmyhOjeStIW10E4FcCa9o4sYyYiAUAUa1pQtJNNaKD YT5SCbZqLmLuW+bW1IqnVFittP0DOIS6BPzHdQ7cCsIj+/NCcf6SeusWYQMkJZXaZur9 Q7/g== X-Forwarded-Encrypted: i=1; AJvYcCU8JyyEam9HA7CxwpWQM5IpcKdjbk2YSMlYq18tEjJNO8HvbX1pPhCmOi54mZR12NvNGp38AA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YylwmSkVx3jwW5IdnkKUYARY70HolHolPtGOSqk2JEqw63p9tNW W3s6B8/ymTtkFs/OYS2+ZNbsljHIPkae0BeCpVg7EjJ8ZGJsU6IKTqVhlBJnJT2pobIRJ6jLalY 225BSj0kmyqh9T2kxBa2Mgr3ZyQ0= X-Gm-Gg: ASbGncuUs2A36BBpuuNKGHLGA+C+hvY/kVk0682XFYztrELRVaABh8xZ7kuvuvT1fyw CCyhp9n5yhFYIeS/WpExZYhyWMe0df6Ypahck+sdA2Y9rQSFt065yOAvHsd3V/Rq02PpqVP2SHm kJkF2RiO+tfODVINHva7n+VSx3KTHb5QK9jRfJ X-Google-Smtp-Source: AGHT+IEe0bm43R9xeJ1J4b1u94XEQfFtOzDD88u+Urq/b3ujqisM6qNs3jvCkpHHoCoJI9RFwXb7U3KJm/8Kio63dn8= X-Received: by 2002:a05:6102:330a:b0:4bb:d394:46d7 with SMTP id ada2fe7eead31-4c50d4afbcfmr9888655137.6.1742845181494; Mon, 24 Mar 2025 12:39:41 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> In-Reply-To: <86sen2dxyp.fsf@gnu.org> From: Ship Mints Date: Mon, 24 Mar 2025 15:39:30 -0400 X-Gm-Features: AQ5f1JpV94YW-0NwdcXoYO61JJojUk5RGqU7kP3wSM2e3BMCBb9tmvDmB55Cqrc Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000f10e4f06311bc3b1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f10e4f06311bc3b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Mon, 24 Mar 2025 15:29:26 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > > If you see the place in project.el where file-equal-p helps, I'll > happily hack on it. > > > > I'm sorry, I cannot afford looking through the project.el code to find > > this. But if the problem is that directories or files don't compare > > equal, the file-equal-p is the way to go, so I don't understand why > > the places where we do the comparison should be hard to find for > > someone who knows their way in project.el's code and/or has enough > > time to dig. > > > > You don't have to look. The issue is that no directories are explicitl= y > compared. You just have to humor > > that it's a bit evil that a singular project approached from different > places produces two different project > > objects. > > I'm confused: how does project.el know it's the same or a different > project, without comparing? > It looks for root markers in/below the specified directory such as .git for project-vc. Once found, it records a project object in a cache based on the dir it originally searched. If approached from another directory, it repeats the process naively. That's what using the canonical name solved for--that all searches use the same key. The resulting "issue" would be that calling (project-root project-object) might return a directory different than default-directory for a particular buffer. It wouldn't be a misrepresentation. --000000000000f10e4f06311bc3b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 15:29:26 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>=C2=A0 > If you see the place in project.el where file-equal-p helps= , I'll happily hack on it.
>
>=C2=A0 I'm sorry, I cannot afford looking through the project.el co= de to find
>=C2=A0 this.=C2=A0 But if the problem is that directories or files don&= #39;t compare
>=C2=A0 equal, the file-equal-p is the way to go, so I don't underst= and why
>=C2=A0 the places where we do the comparison should be hard to find for=
>=C2=A0 someone who knows their way in project.el's code and/or has = enough
>=C2=A0 time to dig.
>
> You don't have to look.=C2=A0 The issue is that no directories are= explicitly compared.=C2=A0 You just have to humor
> that it's a bit evil that a singular project approached from diffe= rent places produces two different project
> objects.

I'm confused: how does project.el know it's the same or a different=
project, without comparing?

It looks for root markers in/b= elow the specified directory such as .git for project-vc.=C2=A0 Once found,= it records a project object in a cache based on the dir it originally sear= ched.=C2=A0 If approached from another directory, it repeats the process na= ively.=C2=A0 That's what using the canonical name solved for--that all = searches use the same key.=C2=A0 The resulting "issue" would be t= hat calling (project-root project-object) might return a directory differen= t than default-directory for a particular buffer.=C2=A0 It wouldn't be = a misrepresentation.
--000000000000f10e4f06311bc3b1-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 16:05:24 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 20:05:24 +0000 Received: from localhost ([127.0.0.1]:59044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1two30-0002m7-NL for submit@debbugs.gnu.org; Mon, 24 Mar 2025 16:05:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44568) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1two2v-0002kK-0u for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 16:05:20 -0400 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 1two2p-0001cm-4f; Mon, 24 Mar 2025 16:05:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=bkOj8c6wpjsfGycTKyYuDl+K5IG2aAovXKozQmJ+fBU=; b=PkWGPuIieCoIsMio33ZK 8dSzHQ5LXrMeC4wZuVfW0msgKJkJ0g4MbZ8IR+7kye2+HMT28g4dGL+xx8Z6EBR8j9CucfICxSIzt H3hnGDIyS/6sb6gaqLCq9HVbuFoKD57Kw4KlBHS3H6jPvKbneP0wMUC0aQcgJ4+PN7RJYjZTiHhgN cW4yIoj5+Oy81hd0cJzq0F7L07lL4zpnRBnAYvp2pq2UAqS73qfvtO0vtRzziRlrzH12KWCTDEqds I/11Y2msC71kcBv9WDvCujDH0WAQOULfjWEgH+nGImAFdlyuvpn3BCXE75TWWQtZTnLlkwdPBfdKl 6td9WX5AiT9qCw==; Date: Mon, 24 Mar 2025 22:05:06 +0200 Message-Id: <86r02mdwjx.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 15:39:30 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Mon, 24 Mar 2025 15:39:30 -0400 > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > On Mon, Mar 24, 2025 at 3:34 PM Eli Zaretskii wrote: > > > From: Ship Mints > > Date: Mon, 24 Mar 2025 15:29:26 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > > If you see the place in project.el where file-equal-p helps, I'll happily hack on it. > > > > I'm sorry, I cannot afford looking through the project.el code to find > > this. But if the problem is that directories or files don't compare > > equal, the file-equal-p is the way to go, so I don't understand why > > the places where we do the comparison should be hard to find for > > someone who knows their way in project.el's code and/or has enough > > time to dig. > > > > You don't have to look. The issue is that no directories are explicitly compared. You just have to > humor > > that it's a bit evil that a singular project approached from different places produces two different > project > > objects. > > I'm confused: how does project.el know it's the same or a different > project, without comparing? > > It looks for root markers in/below the specified directory such as .git for project-vc. Once found, it records a > project object in a cache based on the dir it originally searched. If approached from another directory, it > repeats the process naively. In this description, the directory appears twice. Assuming that the project object either records the directory or the cache uses the directory as the key, using file-equal-p should solve the problem, AFAIU. > That's what using the canonical name solved for--that all searches use the > same key. You can use the same key when searching without canonicalizing, can't you? > The resulting "issue" would be that calling (project-root project-object) might return a directory > different than default-directory for a particular buffer. It wouldn't be a misrepresentation. As this discussion shows, it might well be a "misrepresentation" in some cases. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 16:15:34 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 20:15:34 +0000 Received: from localhost ([127.0.0.1]:59124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twoCr-00047V-Py for submit@debbugs.gnu.org; Mon, 24 Mar 2025 16:15:34 -0400 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]:57558) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twoCp-00046P-8U for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 16:15:32 -0400 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-524125f6cadso4894998e0c.2 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 13:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742847325; x=1743452125; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fXoca/OJu/MmGWD+FsYvRO5ycgDYwJww8cMcjFISLQA=; b=Un3xNOR94lsPKO4niFqr/HGKFnBJG90Zj3qEAp21o7ztRcxP1EDsnpPHeL6oOd+JJr MxaG1YXBZ/MrIS+U+e4va3vLJ8jSDbnU0Gvny5hu/d5n8iCR0BHt5/4D3ltKioV6FuSx zRaWmwWwNTPiCFXS81CyBNrpwgsmvjeegFdzQaBm3ZBEUkqz62sUfRHU4kcqIyKaUHUO kTatpHz8C2KJsHubU6jeBKwMjhKl76HVWV5d/tc05bjI6aWjo5xi14tj91gApMpvultw ad5oHgpptH7RWHxKEkrBs/kvrLzXZexjV6rIqj4CT2+A94/yP8CygLTOBV0B0oqNDID+ w7WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742847325; x=1743452125; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fXoca/OJu/MmGWD+FsYvRO5ycgDYwJww8cMcjFISLQA=; b=bFWjMZebpXkMH0bHj4jKgTnoxcbRlVQ25KDodBzbzcFeDoYT9O+ZEV5A/WK+UeZu/L gCNaq2UEKbjngszsegkhBOE6QYz4bq7vUbmLUnxqxm5NiRZGCT8rpYA4kxIOSP8XovOC fTjmANPiCjEVQyZIjt4yF74Nhnh0sm6iCpLWkdwDrhrkbc69SzG7QL+ATRhcfD4LZN8M MMMuWjpo7WF/YJ0dOPSyB2BKD/0hqbzTvcio+7+gMe4/mN9ZEuwHh4K4yBW463nARaKs JQwiDMKy5VYM+WTfgCPesK52Zw00BIJSyeNMaVfZQFNdb4Watpxp3wOkH5VDP8Mx+EAv n3UA== X-Forwarded-Encrypted: i=1; AJvYcCWQX0Bmg5QTpfBpH54MB0Y1Kb7wbz/xV/TWILQZWhBl917PnIIeZjACiX4IxHluBxzgBXC6ow==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwtBxDKiDAYtQeIRkxSL9AC+uiAokTrda+uRKR5Rcl/0eZUcn48 4LVOKKhi6pTHmLEtYwpGtlYpMZjlhUknP5QdEacHwot/EaOS1CI6cJy45oETgpWmGBcX2flnumk +SvCIvUpo+GDLBWOR1KvQUCaB3yU= X-Gm-Gg: ASbGnctPfYE/Q1zY4v+JekmHhyno0Iq3aXo+rVqFJ+ln8c9m5TY57qiwyYzb+e+fCZU qyCt5nUPiCCqt1eibf19JvxwA+XVp/O8lNtUTNfc23XbUhoxPx55iwkY7UImCI6Q4qxWcSykavQ fzn/NQk3yNUucCUWgmDur25CsPsA== X-Google-Smtp-Source: AGHT+IG5JJvNtdqiL5GfQgqskDyZJfyqlCElpyVs8YQkZgEHeEj8Jeqg/JsUbbb7hn8ChVHk4GsMEHqf31C96OMNF7Y= X-Received: by 2002:a05:6102:304e:b0:4bb:eb4a:f9f0 with SMTP id ada2fe7eead31-4c50d623cecmr10400300137.24.1742847325342; Mon, 24 Mar 2025 13:15:25 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> In-Reply-To: <86r02mdwjx.fsf@gnu.org> From: Ship Mints Date: Mon, 24 Mar 2025 16:15:14 -0400 X-Gm-Features: AQ5f1JoPN3LfUY2j0fZUDvvNDdz-8nW9nQ80-3ULGorEebDgKhM90kYpgMGZExQ Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000b9926106311c4362" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000b9926106311c4362 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 4:05=E2=80=AFPM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Mon, 24 Mar 2025 15:39:30 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > > > On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii wr= ote: > > > > > From: Ship Mints > > > Date: Mon, 24 Mar 2025 15:29:26 -0400 > > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > > > > If you see the place in project.el where file-equal-p helps, I'll > happily hack on it. > > > > > > I'm sorry, I cannot afford looking through the project.el code to > find > > > this. But if the problem is that directories or files don't compar= e > > > equal, the file-equal-p is the way to go, so I don't understand why > > > the places where we do the comparison should be hard to find for > > > someone who knows their way in project.el's code and/or has enough > > > time to dig. > > > > > > You don't have to look. The issue is that no directories are > explicitly compared. You just have to > > humor > > > that it's a bit evil that a singular project approached from > different places produces two different > > project > > > objects. > > > > I'm confused: how does project.el know it's the same or a different > > project, without comparing? > > > > It looks for root markers in/below the specified directory such as .git > for project-vc. Once found, it records a > > project object in a cache based on the dir it originally searched. If > approached from another directory, it > > repeats the process naively. > > In this description, the directory appears twice. Assuming that the > project object either records the directory or the cache uses the > directory as the key, using file-equal-p should solve the problem, AFAIU. > > > That's what using the canonical name solved for--that all searches use > the > > same key. > > You can use the same key when searching without canonicalizing, can't you= ? > > > The resulting "issue" would be that calling (project-root > project-object) might return a directory > > different than default-directory for a particular buffer. It wouldn't > be a misrepresentation. > > As this discussion shows, it might well be a "misrepresentation" in > some cases. > Maybe unexpected but not a misrepresentation. In any case, the project object returned must be equivalent for both directories passed in and that's not how project.el is structured. Using file-equal-p or any other method to find an "equivalent" project object but substitute the "expected" directory results in two objects that don't compare as equal and that's a misrepresentation IMO. --000000000000b9926106311c4362 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 4:05=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 15:39:30 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>
> On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
>
>=C2=A0 > From: Ship Mints <shipmints@gmail.com>
>=C2=A0 > Date: Mon, 24 Mar 2025 15:29:26 -0400
>=C2=A0 > Cc: = dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev
>=C2=A0 >
>=C2=A0 >=C2=A0 > If you see the place in project.el where file-eq= ual-p helps, I'll happily hack on it.
>=C2=A0 >
>=C2=A0 >=C2=A0 I'm sorry, I cannot afford looking through the pr= oject.el code to find
>=C2=A0 >=C2=A0 this.=C2=A0 But if the problem is that directories or= files don't compare
>=C2=A0 >=C2=A0 equal, the file-equal-p is the way to go, so I don= 9;t understand why
>=C2=A0 >=C2=A0 the places where we do the comparison should be hard = to find for
>=C2=A0 >=C2=A0 someone who knows their way in project.el's code = and/or has enough
>=C2=A0 >=C2=A0 time to dig.
>=C2=A0 >
>=C2=A0 > You don't have to look.=C2=A0 The issue is that no dire= ctories are explicitly compared.=C2=A0 You just have to
>=C2=A0 humor
>=C2=A0 > that it's a bit evil that a singular project approached= from different places produces two different
>=C2=A0 project
>=C2=A0 > objects.
>
>=C2=A0 I'm confused: how does project.el know it's the same or = a different
>=C2=A0 project, without comparing?
>
> It looks for root markers in/below the specified directory such as .gi= t for project-vc.=C2=A0 Once found, it records a
> project object in a cache based on the dir it originally searched.=C2= =A0 If approached from another directory, it
> repeats the process naively.

In this description, the directory appears twice.=C2=A0 Assuming that the project object either records the directory or the cache uses the
directory as the key, using file-equal-p should solve the problem, AFAIU.
> That's what using the canonical name solved for--that all searches= use the
> same key.

You can use the same key when searching without canonicalizing, can't y= ou?

> The resulting "issue" would be that calling (project-root pr= oject-object) might return a directory
> different than default-directory for a particular buffer.=C2=A0 It wou= ldn't be a misrepresentation.

As this discussion shows, it might well be a "misrepresentation" = in
some cases.

Maybe unexpected but not a misrepresentation.<= /div>

In any case, = the project object returned must be equivalent for both directories passed = in and that's not how project.el is structured.=C2=A0 Using file-equal-= p or any other method to find an "equivalent" project object but = substitute the "expected" directory results in two objects that d= on't compare as equal and that's a misrepresentation IMO.
--000000000000b9926106311c4362-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 16:26:07 2025 Received: (at 77122) by debbugs.gnu.org; 24 Mar 2025 20:26:08 +0000 Received: from localhost ([127.0.0.1]:59208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twoN5-0005bn-4C for submit@debbugs.gnu.org; Mon, 24 Mar 2025 16:26:07 -0400 Received: from mail-ua1-x92c.google.com ([2607:f8b0:4864:20::92c]:52437) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1twoMz-0005a7-Q6 for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 16:26:05 -0400 Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-86d69774081so2045484241.0 for <77122@debbugs.gnu.org>; Mon, 24 Mar 2025 13:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742847956; x=1743452756; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TlsxcB21XuNU5wb/dJobe9Tm3ySmjgCI3Td6laoyeRg=; b=duxS5Uyyb3Cy9qIjJrsJ8Vxq3BOp1dsbGs2htJ0vol+8sSlqaGITI3CTU5d40mdVOt m+DHRGsu+rJF3zUYSiGzfDluelU7C4yoIR0ytAXazZm9gKnIl0hMTr0/OQodKH7CxuGK 0foTxaOoqQTRkidb0HrTADQZF1VL472uIdUQZpMOD5iJiX9YWpXKW9GZrrogb7OU/5oJ 8/bcrQZqTzj5MD4sGLO10cMftpiEXJ2CZ2SGjQYbWyL6KL2nOuT6pzqbWNT7QmUvWE0M fDXXsMAbv0yNsDX+5XhZkv8kt62UbSSqNShPBNCpkjeUYui8qKcz7tvHh6dEFFUHXwP8 fS/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742847956; x=1743452756; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TlsxcB21XuNU5wb/dJobe9Tm3ySmjgCI3Td6laoyeRg=; b=KJ5zQf195bqmdu8LgEnVfPYXC0QA5RrELyQwUCVq8TTEbgh6rX+iH/mWZeSKXjbaQG zpTvArwYZ2zfVljQZHx1ffcT29bcCJipNkJx7EDMVKSRhK6vqkUlc4BmJqPoc1W6lPL7 MJ58nbJAYEj1Ak/R/2xwBKTsp3iTYy50F9DRMbD+NNYJaIFllCTFFEu38Zg4vTK0lswu spqWNWL2izojfMVPeMS9Op4FDgQABImcfTc6YzFcbSub9U0ACa6t01lmMmSN4xsz8+ed OqTgvTbUlAjyqitlCvs7eCSqb1tikqsA86YLa8bEComsuH1TgP0fHWf9nsTxcnyDqlS6 Bu7g== X-Forwarded-Encrypted: i=1; AJvYcCXlfU3hYpyfryUvc8J2yaRVLA0eQITlhTgKPpch1VdBBXFEBUAb5r0qeU5ckCWESVdyTn97IQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyqabsq2tGDSzldACEdzEr8LiMRnxJT1BWkgMjYptEU7vVIkoAD wFyw+/B2DtDm+NG05qLnJuSdnuP31sOv1Ohzrl5yqIDoRu1jfKJX/GfS/YQ14RpZH22SaoVgSo+ 5mP1RZ8uCMY8qPYOMXjZaQLy3ezg= X-Gm-Gg: ASbGnctkxIa4cSqzBf5C3+wIA0Y5n2fHzcwD0xFh+M4Q+Tq2OXHIDfkkF0giOPyRin9 n9duo0k6ow/EpM5kV0+7b4F0Gj0Nr2gWzGkBNS6sGXmKJsWeoXMJSNEqKVA1Y4jiJvOZKExKcwx l10oxYpZqdgHYjUOEtZC9X11+Z/Q== X-Google-Smtp-Source: AGHT+IEsEdkmDdQmGKaKXmEkiIdry3v3rRrjpYBGBCnXVg8gYAhVFjETd3cMvtQY7xrl6WFm1TLbhXAZkqxshFU9/CE= X-Received: by 2002:a05:6102:304e:b0:4bb:d7f0:6e70 with SMTP id ada2fe7eead31-4c50d481269mr9572889137.5.1742847955794; Mon, 24 Mar 2025 13:25:55 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> In-Reply-To: From: Ship Mints Date: Mon, 24 Mar 2025 16:25:44 -0400 X-Gm-Features: AQ5f1JpzfCf5Ho-bUaJqdlnJc2PZRxbOG61LLIk2v6Mfu1xiTH1Si4U_GPvsgx4 Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000004d834e06311c69bd" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000004d834e06311c69bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 4:15=E2=80=AFPM Ship Mints wr= ote: > On Mon, Mar 24, 2025 at 4:05=E2=80=AFPM Eli Zaretskii wrot= e: > >> > From: Ship Mints >> > Date: Mon, 24 Mar 2025 15:39:30 -0400 >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > >> > >> > On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii w= rote: >> > >> > > From: Ship Mints >> > > Date: Mon, 24 Mar 2025 15:29:26 -0400 >> > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > > >> > > > If you see the place in project.el where file-equal-p helps, I'l= l >> happily hack on it. >> > > >> > > I'm sorry, I cannot afford looking through the project.el code to >> find >> > > this. But if the problem is that directories or files don't compa= re >> > > equal, the file-equal-p is the way to go, so I don't understand wh= y >> > > the places where we do the comparison should be hard to find for >> > > someone who knows their way in project.el's code and/or has enough >> > > time to dig. >> > > >> > > You don't have to look. The issue is that no directories are >> explicitly compared. You just have to >> > humor >> > > that it's a bit evil that a singular project approached from >> different places produces two different >> > project >> > > objects. >> > >> > I'm confused: how does project.el know it's the same or a different >> > project, without comparing? >> > >> > It looks for root markers in/below the specified directory such as .gi= t >> for project-vc. Once found, it records a >> > project object in a cache based on the dir it originally searched. If >> approached from another directory, it >> > repeats the process naively. >> >> In this description, the directory appears twice. Assuming that the >> project object either records the directory or the cache uses the >> directory as the key, using file-equal-p should solve the problem, AFAIU= . >> >> > That's what using the canonical name solved for--that all searches use >> the >> > same key. >> >> You can use the same key when searching without canonicalizing, can't yo= u? >> >> > The resulting "issue" would be that calling (project-root >> project-object) might return a directory >> > different than default-directory for a particular buffer. It wouldn't >> be a misrepresentation. >> >> As this discussion shows, it might well be a "misrepresentation" in >> some cases. >> > > Maybe unexpected but not a misrepresentation. > > In any case, the project object returned must be equivalent for both > directories passed in and that's not how project.el is structured. Using > file-equal-p or any other method to find an "equivalent" project object b= ut > substitute the "expected" directory results in two objects that don't > compare as equal and that's a misrepresentation IMO. > To concretely demonstrate the differences, the function project-name will return different results for each project object based on buffers loaded from different paths, despite the projects being equivalent. project-name is defined as: (file-name-nondirectory (directory-file-name (project-root project))) If the root directory is determined to be different, the objects return different names (and different roots). --0000000000004d834e06311c69bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 4:15=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Mon, Mar 24, 2025 at 4:05=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 15:39:30 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>
> On Mon, Mar 24, 2025 at 3:34=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
>
>=C2=A0 > From: Ship Mints <shipmints@gmail.com>
>=C2=A0 > Date: Mon, 24 Mar 2025 15:29:26 -0400
>=C2=A0 > Cc: = dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev
>=C2=A0 >
>=C2=A0 >=C2=A0 > If you see the place in project.el where file-eq= ual-p helps, I'll happily hack on it.
>=C2=A0 >
>=C2=A0 >=C2=A0 I'm sorry, I cannot afford looking through the pr= oject.el code to find
>=C2=A0 >=C2=A0 this.=C2=A0 But if the problem is that directories or= files don't compare
>=C2=A0 >=C2=A0 equal, the file-equal-p is the way to go, so I don= 9;t understand why
>=C2=A0 >=C2=A0 the places where we do the comparison should be hard = to find for
>=C2=A0 >=C2=A0 someone who knows their way in project.el's code = and/or has enough
>=C2=A0 >=C2=A0 time to dig.
>=C2=A0 >
>=C2=A0 > You don't have to look.=C2=A0 The issue is that no dire= ctories are explicitly compared.=C2=A0 You just have to
>=C2=A0 humor
>=C2=A0 > that it's a bit evil that a singular project approached= from different places produces two different
>=C2=A0 project
>=C2=A0 > objects.
>
>=C2=A0 I'm confused: how does project.el know it's the same or = a different
>=C2=A0 project, without comparing?
>
> It looks for root markers in/below the specified directory such as .gi= t for project-vc.=C2=A0 Once found, it records a
> project object in a cache based on the dir it originally searched.=C2= =A0 If approached from another directory, it
> repeats the process naively.

In this description, the directory appears twice.=C2=A0 Assuming that the project object either records the directory or the cache uses the
directory as the key, using file-equal-p should solve the problem, AFAIU.
> That's what using the canonical name solved for--that all searches= use the
> same key.

You can use the same key when searching without canonicalizing, can't y= ou?

> The resulting "issue" would be that calling (project-root pr= oject-object) might return a directory
> different than default-directory for a particular buffer.=C2=A0 It wou= ldn't be a misrepresentation.

As this discussion shows, it might well be a "misrepresentation" = in
some cases.

Maybe unexpected but not a misrepresentation.

In any cas= e, the project object returned must be equivalent for both directories pass= ed in and that's not how project.el is structured.=C2=A0 Using file-equ= al-p or any other method to find an "equivalent" project object b= ut substitute the "expected" directory results in two objects tha= t don't compare as equal and that's a misrepresentation IMO.
<= /div>

To concretely demonstrate the differences, the f= unction project-name will return different results for each project object = based on buffers loaded from different paths, despite the projects being eq= uivalent.

pro= ject-name is defined as:

(file-name-nondirectory (directory-file-name (project-root proj= ect)))
If the= root directory is determined to be different, the objects return different= names (and different roots).
--0000000000004d834e06311c69bd-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 22:16:48 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 02:16:48 +0000 Received: from localhost ([127.0.0.1]:34072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twtqS-0007TE-91 for submit@debbugs.gnu.org; Mon, 24 Mar 2025 22:16:48 -0400 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]:56135) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twtqN-0007Sm-NA for 77122@debbugs.gnu.org; Mon, 24 Mar 2025 22:16:46 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 0F3F7114010B; Mon, 24 Mar 2025 22:16:38 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 24 Mar 2025 22:16:38 -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:subject:subject:to:to; s=fm3; t=1742868997; x=1742955397; bh=Rz1+4Ctsy8zyaAtY74yvnsy1ti3XeqVH761THWhSUJE=; b= XmXrrQzylZteQxuqaaCuknapzHQAkgDJD81pvNGiHriAfqCijXqJqHc+nLNAFtMa wTrUMEo6Vm49lekxxMTjA4FmSQBTwDtoN9Bj5mRumakN2VZ0OmaIAXNoLSYxTqIc MLkfhirnUDjY82cUBz8qSxy/KhUiSNNLB+HCFnM+wdbK9BJg7PT43iSp5fcqsO7P WCMHn4IZKUAP75koC9puhJCPdN4LJjJkIrr1nDutvyqFcf+o6TBYp0WL5YnospqU UIXZmqIR7eJAySEcv7OeRp+twVFmBwn9+DGS176/LdgTqKZwS2urrdFPFhJr/UW/ JNDoekEmUg/NRnqTZQ5P5A== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742868997; x= 1742955397; bh=Rz1+4Ctsy8zyaAtY74yvnsy1ti3XeqVH761THWhSUJE=; b=D g3bXRIJjdY0DYUPyoLo4MLhIHn8+FUn326oXqAEsrrhphL0qOYJ7dI+pkX/92GL9 Qx18Zd+UKanCBzCEIbCZdzxhQcf4Du8Ec+Ww/cFZylddWyut1TpnmKAl/itodxGi B7fLt5l8AIAUynzjRoQhyG/oOHFFfrzqyHxTH+i+XjvJn7kxnwdnvInjkOcJWqkU CWm0vpW9PADMIfbrh8NPu/ojM0XI7ViFYcidyauOB0SrFl7712fOYYm1CwiU7oLO ImG1OHP7fe+cW2GKEjLilp54nBdWST58u1F+N+RJHN/aPd2CxnAwjWn8KGKd4kx9 4VKUk881vGOQvp5TE+lsw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedugedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeet veegtedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhsse hgmhgrihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthht ohepuggrnhgtohhlsegurghntgholhdrohhrghdprhgtphhtthhopeejjeduvddvseguvg gssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Mar 2025 22:16:35 -0400 (EDT) Message-ID: <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> Date: Tue, 25 Mar 2025 04:16:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Ship Mints , Eli Zaretskii References: <864izifunt.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 24/03/2025 17:15, Ship Mints wrote: > I'm curious to hear more about why people would object to (project-root > project-obj) being canonicalized.  I don't think many people ever > manually enter project dirs.  The persisted known projects, I'd think, > would also benefit from no duplicates. I wonder if you yourself would prefer for all buffer-file-name values, and default-directory values, to be canonicalized as well. The same reasoning would seem to apply to them too anyway. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 06:54:55 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 10:54:55 +0000 Received: from localhost ([127.0.0.1]:36492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx1vr-0000hI-39 for submit@debbugs.gnu.org; Tue, 25 Mar 2025 06:54:55 -0400 Received: from mail-vk1-xa35.google.com ([2607:f8b0:4864:20::a35]:45276) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx1vn-0000gz-Va for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 06:54:53 -0400 Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-5240764f7c1so2122709e0c.2 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 03:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742900086; x=1743504886; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KZ5HbU1r9YCweDbY4zo8E1hR05aW59Da7DMIAWZBBgg=; b=cDBgMdO9QmsfSnuKHHa+UNdIMxjAssNSp2LCkD11nmo6Coi+U8M49nOIDofJm7M3It srmuyruBK7c/S2WsOjPPXBKkC3kRuyjWXm34IbBa4RLIIb15sTwQy//TjQ+DoSzMvP+c YEzsKQWWum7Sp8zBPLZFP5gdH7zPpEcnqq5Qprp5K6WcI/HQ/cwtCgVnvpuYYb5gkpOj ip/TWzV4Rc3W1Z8hZ1D2oP41NrVI4rFSn9uJWUuxz/MUR1ShPEigoCJhPKuJz4z2ELU6 ca333xa3frhBEGxsc0IdvOOKV9ltndLI5M/AL29JigYsXe0+3cdOpGu/vPwUKpNnpoqV IgnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742900086; x=1743504886; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KZ5HbU1r9YCweDbY4zo8E1hR05aW59Da7DMIAWZBBgg=; b=OHmo46eSTHAql2buGDqBKpYY4//tbn7edRaIxLFQQOXn58YdZel0hmLDn7nLSO2iw/ qgDp/it1Z///Sal8Apo/6nVrHMsCU99mdnm7JrfdWYJwUNzKc3YM5vawIIUvb9LA9uoW cY1u7fLD30341dBrbbP61oq3OfrIFRhRR6wuNwGKQxZLjpBEc6uzAvXtshd12uEzlhB0 HOpYHDOSSLTYLPbbOumj8d8pnPvm8cjA+vyLVARGt2fbzDKOn/wmr4Dn3njnx8icEscR ql8LrCzn/J8YOjyZnW4Ep7KE8FjQFV4z/O/0LHL0yv344ARqc3uyegAnLP7ED5u2kHWR XBlA== X-Forwarded-Encrypted: i=1; AJvYcCUen68xzUg9hgKc9NM0KeQJArucIVKDvrdExFxrmYKpxoL/2LfU4sUBKF3osHMt65x20yQRRQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzJzGlOiuxA3FRmX8+4ezpjc9ezoFbot874bpoPpj/rFYx7zYga WpxyQbK8JcIYqTVZhiQCyw149sT9MbJsqPPed5HMKwiVsktW/oCPzZkQpi5MUWVPBWOgSk7VcTJ 0m9H8xzDPmOdMp+rkR7zWetAVGrs= X-Gm-Gg: ASbGncubQTG6ju7hexSutFGQhyFmQj1fuszURMvsl/zi7LGDkM4TBl6pconSGguap/r r+TMg0uzybGz8vPJaRH4IFKIYNr6M7ihOn5V8pNcyjpRJ9qRNcNK1cNjDb7D3MW4ItWHZogx62u wTalSqNMV9lchju5wGnwj17FQQIg== X-Google-Smtp-Source: AGHT+IFqOlJA9vmTmLFdUQsQNBBl3B3V0Ww38OBu4qagNlO1YoMOVyebQ+ww+uqsygTWSzdM/1xTv/MZCYLbvH2RqOg= X-Received: by 2002:a05:6122:2491:b0:518:a0ac:1f42 with SMTP id 71dfb90a1353d-525a82e60famr9354579e0c.1.1742900086213; Tue, 25 Mar 2025 03:54:46 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> In-Reply-To: <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> From: Ship Mints Date: Tue, 25 Mar 2025 06:54:34 -0400 X-Gm-Features: AQ5f1Jqn5t812GtlVeUAzfYE-5jYMLFQ262w9oLFRhYGTw7veomvHMjTd843Wv4 Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Dmitry Gutov Content-Type: multipart/alternative; boundary="00000000000084938a0631288c2a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii , dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000084938a0631288c2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov wr= ote: > On 24/03/2025 17:15, Ship Mints wrote: > > I'm curious to hear more about why people would object to (project-root > > project-obj) being canonicalized. I don't think many people ever > > manually enter project dirs. The persisted known projects, I'd think, > > would also benefit from no duplicates. > > I wonder if you yourself would prefer for all buffer-file-name values, > and default-directory values, to be canonicalized as well. > > The same reasoning would seem to apply to them too anyway. > Ochen funny. I'll submit a separate patch for that one day (sarcasm doesn't work in email, sorry). In the meantime, I maintain my view that project.el needs to report uniform project names and roots for identical projects approached from different places, even if optional. I just took a look at projectile.el, which I'd never looked at before because I prefer using/improving core features. It has a longer user history to see what they've experienced (and it looks like some of project.el's approach is copied almost verbatim e.g., the implementation of project-name). projectile seems to both have users that want symlink chasing and those that don't (looks like ClearCase users--but out of necessity not desire?). As those concerns seem to be project dependent, we could an option that is a list of paths or matchers to include/exclude from chasing, and also a project root semaphore file or project config as I suggested in another message in this thread. I'd enable chasing as my default, opt out in a specific project should I ever have one that needs it rather than the other way around, and enjoy project-name and project-root uniformity. -Stephane --00000000000084938a0631288c2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote:
On 24/03/2025 17:15, Ship Mints wrote:
> I'm curious to hear more about why people would object to (project= -root
> project-obj) being canonicalized.=C2=A0 I don't think many people = ever
> manually enter project dirs.=C2=A0 The persisted known projects, I'= ;d think,
> would also benefit from no duplicates.

I wonder if you yourself would prefer for all buffer-file-name values,
and default-directory values, to be canonicalized as well.

The same reasoning would seem to apply to them too anyway.
=

Ochen funny. I'll submit a separate patch for that one day (sarcasm do= esn't work in email, sorry).

In the meantime, I maintain my view that project.el nee= ds to report uniform project names and roots for identical projects approac= hed from different places, even if optional.

I just took a look at projectile.el, which = I'd never looked at before because I prefer using/improving core featur= es.=C2=A0 It has a longer user history to see what they've experienced = (and it looks like some of project.el's approach is copied almost verba= tim e.g., the implementation of project-name).=C2=A0 projectile seems to bo= th have users that want symlink chasing and those that don't (looks lik= e ClearCase users--but out of necessity not desire?).=C2=A0 As those concer= ns seem to be project dependent, we could an option that is a list of paths= or matchers to include/exclude from chasing, and also a project root semap= hore file or project config as I suggested in another message in this threa= d.

I'd en= able chasing as my default, opt out in a specific project should I ever hav= e one that needs it rather than the other way around, and enjoy project-nam= e and project-root uniformity.

-Stephane
--00000000000084938a0631288c2a-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:15:44 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:15:44 +0000 Received: from localhost ([127.0.0.1]:36670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3C3-0007y5-L0 for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:15:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35940) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tx3C0-0007xp-G9 for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:15:41 -0400 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 1tx3Bv-0001iD-0z; Tue, 25 Mar 2025 08:15:35 -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=Pru7nbcJxda9w+7WvKfIY9SpJxbfw5bb8rycn8/hgHw=; b=KWk1savRWQFc dh6Pznurlb/DZEoZLpaKFAnVcqqD0nvx8aeZYWdDLMq94NLK0cWgYgCT+WAwaxcu5jM2PE0p7DDus PI6BfiVXn4c3Zs6Ryg0yWR51+AiKF2R6y9Abwlk19o6SKPcwN9bajAcpbguxpYy++7w6TWMew22pZ 2D6ceEuS0ogzzoWw9pt7PaeLUxR+KSLTtfjXH1+FcoTsksK42FSM85wBPScSfaNIuZnAvM6qzUQEy 19IQzUq56lCsADC9o/tdlkaBImr3OaQ6TOUtt2YJAKzqOTUlcaI5L6H/X14ePlCDQ3GduCMcljEFM kcvkUmUZ1QIGXPUw434ALQ==; Date: Tue, 25 Mar 2025 14:15:07 +0200 Message-Id: <86msd9e27o.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 16:15:14 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Mon, 24 Mar 2025 16:15:14 -0400 > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > As this discussion shows, it might well be a "misrepresentation" in > some cases. > > Maybe unexpected but not a misrepresentation. > > In any case, the project object returned must be equivalent for both directories passed in and that's not how > project.el is structured. Using file-equal-p or any other method to find an "equivalent" project object but > substitute the "expected" directory results in two objects that don't compare as equal and that's a > misrepresentation IMO. Thus my suggestion to make those objects 'equal', even if they aren't 'eq'. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:17:50 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:17:50 +0000 Received: from localhost ([127.0.0.1]:36675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3E6-000830-Eg for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:17:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57344) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tx3E4-00082i-DP for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:17:48 -0400 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 1tx3Dx-0001r0-U0; Tue, 25 Mar 2025 08:17:43 -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=o6MFStu9OS+MuHZJ2TBs8ASREZgZsl7sjuVabnn8Y+A=; b=jiT1/Pmvhl4L F4d0mTwrRQpiccsvq5aLEhSyXdpiD+rEmyLyxoSWqO2uym6kI9KjlX9t9dg+1UbRaBDrtDengTk/W 8RIcqBCoTYW8/MZq+aKD/51I5FBi37v+8y3b3Ws8Iy3gi4LkX3xyT3JX7b/85lnW+B+5j0BSoupdv 6TxPogHDKzZRVAydlr4xeNKqGrXvXNcQ4e/+XJMr5rYknaDbqAu2encilChY2gb93WCfMlyxZcqMH NRsGLZ833v407eaQn1xYRok/7RgVWx9ZcRHCOF6Um/7RUyo2r37ejxQQQGrY7gWIS5nI8WjzWPHQZ TB/zDGjwpVP2nP8pvYhyKw==; Date: Tue, 25 Mar 2025 14:16:56 +0200 Message-Id: <86ldste24n.fsf@gnu.org> From: Eli Zaretskii To: Ship Mints In-Reply-To: (message from Ship Mints on Mon, 24 Mar 2025 16:25:44 -0400) Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ship Mints > Date: Mon, 24 Mar 2025 16:25:44 -0400 > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > To concretely demonstrate the differences, the function project-name will return different results for each > project object based on buffers loaded from different paths, despite the projects being equivalent. > > project-name is defined as: > > (file-name-nondirectory (directory-file-name (project-root project))) > > If the root directory is determined to be different, the objects return different names (and different roots). Unless I'm misunderstanding what Daniel wrote, the above is actually a feature from his POV. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:26:32 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:26:32 +0000 Received: from localhost ([127.0.0.1]:36719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3MV-00007R-Kw for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:26:32 -0400 Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]:46196) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx3MT-000074-1S for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:26:30 -0400 Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-523ffbe0dbcso6068118e0c.0 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 05:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742905583; x=1743510383; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k7kJjsfuu2Z7GCTNo/ifNzNNIBClyAi0E4bUi14YILs=; b=QcllR6QkH7FgODBP6P3ttBUgaIKqamj50uMcBbkpozHLyYjiDuS5lz3U8SJ/8Odw/t nFNzrK26HormGG+KUqHUcdcjIWrqICXrrPIy7nObwDc/D1mxvtqE74nE+5xBvSM6HOOZ URbcgDGSxfiq+vzLw0Szha5piEyi7JcQzMVB3tzUBB7K4fqMVXA+R8YsWZl7YMZg0J/2 CjDtUqx0RcUnDUgfxOaMnzhJGZiXglmR3ylERaA1aA42/Kz0X/gRXgrmFTDnD3w3xZXI iBnmgiBzeBP+mCgITB14McbNk6+ibo3yDo5op/CfltNqP5mKHsMYVxmnFvNXZ+Pf3q8Q qdSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742905583; x=1743510383; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k7kJjsfuu2Z7GCTNo/ifNzNNIBClyAi0E4bUi14YILs=; b=fAxgjiXQzBQjkB/VbFW5L0iSrQ7f8FR0khiJPp1GLmbxvCcXpbHZBx4iiILwsi1v9E dvP10gIdnx6zK+JF64Tdo23W5P7AVtzC29HdC0B4cYLWnavcahQcTJIsNM/X0ekX1YVS F/63wvplv/UrcOlnFidFsiIYvLO9wCDEIw76fcAFpAgzpP26trxzPQ5LrV49Xl0z1Vdr G9ahycrrobtO3cNDxZmDkn3cYAR/0pF0Bprzl1HndnYsrw1XwCcGrRGoSGDlZf30ntjz 6oFfz9IB1vCuEYp15Mh15nhwfEbUptrmQmVqzq4Jze+k0hfQAnuKyuo+gAJGrpTVQ8DT GYlQ== X-Forwarded-Encrypted: i=1; AJvYcCUsNqqwQRRfkuvDWcZHdVjjaGzr+354Z0W3nNzMlwHMu2Q+Mdl83fpHUX6fWLZNFLKSMqMxVQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyWT73ph+dwfuUVbHfXm0P35ltIIVtJa7FOzPj59gUFwEreyG41 IMxUUy5H2qmWRnIhQrjnb3fFx0WDpAGSl9LzWAqPKVwipooXtVD6YCUFflSdkZe+Ipq5O/RqlQD QQvWKamx+UHGsFyr5xmRUM7j7by4= X-Gm-Gg: ASbGncviEFepL1MPolw6crefeV1RHdDFKZykS3WZKkgj8VSA7QWfuBHNoAH7SHqSng4 L4p3ivQvUM4sr0Chr4rBlryGJ6RjMSFV5emJbFESFmUOtwfI+eHfiNN0Vouw7YcBEAxfGb1Jv+y hDgOSGx407qRPJzGLvBpxVoD4LmQ== X-Google-Smtp-Source: AGHT+IEBWtGB8FbihB8RHn6FlsHj4QIHsyybtwdKgq1OOeSOP0gnM8jOMAXQHLdLnRjXxmZpQ45oWh3RdnIVY5msYjc= X-Received: by 2002:a05:6122:221a:b0:523:f1f9:d03f with SMTP id 71dfb90a1353d-525a82f329bmr10376887e0c.1.1742905582961; Tue, 25 Mar 2025 05:26:22 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> <86ldste24n.fsf@gnu.org> In-Reply-To: <86ldste24n.fsf@gnu.org> From: Ship Mints Date: Tue, 25 Mar 2025 08:26:11 -0400 X-Gm-Features: AQ5f1JqZta6iMMbDuTE_1pfsNuuBDwRH3qf7iOdE2mrSWJbKOR1Wz89a5QEjJUw Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000265842063129d418" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000265842063129d418 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 8:17=E2=80=AFAM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Mon, 24 Mar 2025 16:25:44 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > To concretely demonstrate the differences, the function project-name > will return different results for each > > project object based on buffers loaded from different paths, despite th= e > projects being equivalent. > > > > project-name is defined as: > > > > (file-name-nondirectory (directory-file-name (project-root project))) > > > > If the root directory is determined to be different, the objects return > different names (and different roots). > > Unless I'm misunderstanding what Daniel wrote, the above is actually a > feature from his POV. > Indeed, it might be, but I'm curious what tooling he's using that depends on project-root not being "absolute" so to speak, and relative to his ambient default-directory. --000000000000265842063129d418 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 8:17=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 16:25:44 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
> To concretely demonstrate the differences, the function project-name w= ill return different results for each
> project object based on buffers loaded from different paths, despite t= he projects being equivalent.
>
> project-name is defined as:
>
> (file-name-nondirectory (directory-file-name (project-root project)))<= br> >
> If the root directory is determined to be different, the objects retur= n different names (and different roots).

Unless I'm misunderstanding what Daniel wrote, the above is actually a<= br> feature from his POV.

Indeed, it might be, but I'm cur= ious what tooling he's using that depends on project-root not being &qu= ot;absolute" so to speak, and relative to his ambient default-director= y.
--000000000000265842063129d418-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:28:11 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:28:11 +0000 Received: from localhost ([127.0.0.1]:36726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3O6-0000BL-Tl for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:28:11 -0400 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]:48315) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx3Ny-0000AL-8I for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:28:04 -0400 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-5259327a937so2165745e0c.0 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742905676; x=1743510476; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9S1Cu6d6fbDANIqJ8PFvyUVHv4T/BckyopL+qce2sOc=; b=R4A2o+JrkzCMabhmSRHZiP7kh99+41jgUFRP6QgZGVFGFnlDcPc18vVidmL5dm+pWT UzemeqOQLjKmKy7OHeqNtzn9xlIxDji861gB/uARKlcFE06gxGmoXv59qyZ8Sukbp3et D287cHqYnE624X0tUZEzGIe98hsMC88IWCQZgIptaTyf5VOTGyoXfNTJ83x2k3HgRESE x314bHXFYMW6yfEvE9v/HTgZmLjKl5FD6GyffYblsz8jFs3VqebXJvfivX0wMbL3uPvs ggXizIG+trxh250gM0p92D2fQpA3DT0drRS3ZfoESXY4OWPgSTbr0orZ+F0kASj/yO75 DoeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742905676; x=1743510476; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9S1Cu6d6fbDANIqJ8PFvyUVHv4T/BckyopL+qce2sOc=; b=aIVcDRg2fDPgk/ki/bJ4b9/3p2VeqUtchBKgpOmW+Y1VsXOVLWaKS2jt9iE3J97Cim d1gn87LVt599vDmZTFggeFYkxBe/Uu1lBlA07R7kRdMfn6NSFCY7Y0GNia7RzY5o1OqZ CclyaeI3w53Jwd6Q2AObSlX0gT+ClXUaki1Vlg9B3tBt/m0H3h8jo1s9kkiFRe+r9GcJ qY+FRTK6WErCGwadv/NFb/r2XFrnlQQD2u0sEa+a+7HjU1PaMmqTaTqoBLI7/aWufq9o sLHbfVmkUP4fgjGvmnZeP/Igb1ttsj3tKvT6MImn7wQp46+7a9ISOu5M8D7wxpWSgm3i IxoA== X-Forwarded-Encrypted: i=1; AJvYcCXIF9frh8nzRRtYJYM5Pi5ir+wkJ8SVqDzlZFKfnAz44asZBDfY/2rpfURGURH19BeRUBVryA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyity8rjuZgxiu49US7kll9WFitf+RiokbmvstcRobwIE2CKTf4 HZxHIUBSCQ1/+vHnfetZVey+KCVjiNeR6qiqqFPbP6GhEPT17Rf5p5j3Y/ySEkRsS1h06MMaJbd LYZgdheKrCpHFIMI73BPH7S1qTt4= X-Gm-Gg: ASbGnctgwv7AHV+GrHOVkslE1ArCB2UWig35txYcnaVgiVRDtFA0Xzopa7hPxDrm2b+ mB63NDUMx97epBr8PIAnp9WbPSyimX44pfWbh2abg4Ix5mdz/TcQu1E9yK4rltMKdEw1VwNsodI ICt15qzOjlyV3sOW7TFyM/Zu86nQ== X-Google-Smtp-Source: AGHT+IE48jD6Fj+5bhdCN9brm83Pcx/5gaQQxp9EfYH8QvDsitMrMUFZsLezuiJBf4Aqvvt6bVapBF0J/BO9pscTM+I= X-Received: by 2002:a05:6102:512b:b0:4c1:86a7:74e9 with SMTP id ada2fe7eead31-4c50d4cf594mr11878232137.10.1742905676345; Tue, 25 Mar 2025 05:27:56 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> <86msd9e27o.fsf@gnu.org> In-Reply-To: <86msd9e27o.fsf@gnu.org> From: Ship Mints Date: Tue, 25 Mar 2025 08:27:45 -0400 X-Gm-Features: AQ5f1JqfdKxH_OfeCkB_XeMyZlVeylolgw-yBm5MBLUjWEgK9Cok5biw5vzUOpQ Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000b737e2063129d94a" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000b737e2063129d94a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 8:15=E2=80=AFAM Eli Zaretskii wrote: > > From: Ship Mints > > Date: Mon, 24 Mar 2025 16:15:14 -0400 > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > > > > As this discussion shows, it might well be a "misrepresentation" in > > some cases. > > > > Maybe unexpected but not a misrepresentation. > > > > In any case, the project object returned must be equivalent for both > directories passed in and that's not how > > project.el is structured. Using file-equal-p or any other method to > find an "equivalent" project object but > > substitute the "expected" directory results in two objects that don't > compare as equal and that's a > > misrepresentation IMO. > > Thus my suggestion to make those objects 'equal', even if they aren't > 'eq'. > I hear you, 100%. But I don't see a place to perform that comparison given the current implementation. --000000000000b737e2063129d94a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 8:15=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 16:15:14 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>=C2=A0 As this discussion shows, it might well be a "misrepresenta= tion" in
>=C2=A0 some cases.
>
> Maybe unexpected but not a misrepresentation.
>
> In any case, the project object returned must be equivalent for both d= irectories passed in and that's not how
> project.el is structured.=C2=A0 Using file-equal-p or any other method= to find an "equivalent" project object but
> substitute the "expected" directory results in two objects t= hat don't compare as equal and that's a
> misrepresentation IMO.

Thus my suggestion to make those objects 'equal', even if they aren= 't
'eq'.

I hear you, 100%.=C2=A0 But I don't see = a place to perform that comparison given the current implementation.
<= /div>
--000000000000b737e2063129d94a-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:30:43 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:30:43 +0000 Received: from localhost ([127.0.0.1]:36755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3QZ-0000Pf-4U for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:30:43 -0400 Received: from mail-ua1-x933.google.com ([2607:f8b0:4864:20::933]:46565) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx3QX-0000P7-0A for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:30:41 -0400 Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-86fea8329cdso189595241.1 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 05:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742905835; x=1743510635; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lkgbd68zSrotnE+czDL4YpYsD+3sH5+kxOKrCWJbF3w=; b=Z6VOq60sLl1329Yw6eJ3o+DG6LZLZ0q0eVXV9M8T8yr17LzXlNZCdQ+7GKEqpDgwmf lyjmiIIRDMP1QPd/ZbDzN5WQcFcgSxmx/usf+rsy2/BltuXrSzY4L+86S1LbxNSbJie4 LbqviuCoGqurtzmKaZSsHZUrKEOr4u9JsOlg+fCUkJKEwoNZjR81FmbUZYG06hleNFbc IPRCaHvPICDjnJ9SvjK4CenUXDcOk54by9wVjq/RIRE2TUlEAk9YEokqFHc59hPPnvSN qu6Q0Mu+DzMIoNEMoeEeTniWR/CrXinqC5SS1CZowbkedsn4lXz0H/3SNtpgazHojv+L g3gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742905835; x=1743510635; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lkgbd68zSrotnE+czDL4YpYsD+3sH5+kxOKrCWJbF3w=; b=JYw31WpY3S0XIYDfaKpudpNoK6L14ZhY1ebucO5a54tBNIpLJfiR5OfndnszzU0nBJ Q7oKKLEIKLsuL8VPGef7mzU3ElsIuJadn4g7K/kY+1KEuBQkBaaQpP7oOAy6taDQCbFc x+sfI41FaD1rMPBQi7Je4vJwnC5DxbdppS15WpWiW1LRjRlP6b5zeh+MtmWb2Opy5qWR cdWqt45b4ERI8LTvuvuYVmyyf4w1syT57Ar5a69I6a6nw6rQNIdlIrTdaa+AeAmE4p6q 0oD3+jiwcOfaoA1nNEnFX0C6rVbkj3CX1vfTd8hfmiJldkPWf1UTSqekkSddHtPH/Nuh XZRg== X-Forwarded-Encrypted: i=1; AJvYcCUKZepxIg/FN8FTRIDmHw3SsXAhSkBujIjw1s+9Re3MZM07wVheOznASJOAMQZXWM4OAVXO0g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxfHpnF6kqIqXB2Z68aFTkv2NS0jqfwBtF/3SO9vHMkpBtuWuIU CuigLUUIPnQNkcbtF1xwU6OYajI7yBHoBDnEUaVgERNmjavHlMBrNjTKDFbobqYTPmuwSdFcq1r fhX8PyoCcVLaWHhbLesYl42tPSDA= X-Gm-Gg: ASbGncto9Sp9wU/KuXlvhXxDKqr/kD8APa/Lp1vcoPqIRcddbYWRJH5CaLNDg2PEUQZ sk/nk/J1G+Z83eErL6A6AOqqG/RTvp3Gfcl+70UZycjSrZKK7lQks+QCcrf+dVlt8AJcfFtbfWy HcaNhRvsv1SSus+gGm1EAV465big== X-Google-Smtp-Source: AGHT+IHs8E3ZqRw5OlgcN3G5TXXQOvC2vPajeuIe/k+KMJeANMMkroPB5AR42We/3f6qMTZsSeOqyI85XnnW2QVV7uo= X-Received: by 2002:a05:6102:330a:b0:4bb:e80b:473d with SMTP id ada2fe7eead31-4c50d4b2fdbmr10606780137.6.1742905830621; Tue, 25 Mar 2025 05:30:30 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> <86msd9e27o.fsf@gnu.org> In-Reply-To: From: Ship Mints Date: Tue, 25 Mar 2025 08:30:19 -0400 X-Gm-Features: AQ5f1JqT6XkNQN6223M2HyFX-AyQQv-WYGPIPTKAzxk6XetZBSqIK3rX9p1i74k Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000e9492a063129e2e4" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e9492a063129e2e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 8:27=E2=80=AFAM Ship Mints wr= ote: > On Tue, Mar 25, 2025 at 8:15=E2=80=AFAM Eli Zaretskii wrot= e: > >> > From: Ship Mints >> > Date: Mon, 24 Mar 2025 16:15:14 -0400 >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > >> > As this discussion shows, it might well be a "misrepresentation" in >> > some cases. >> > >> > Maybe unexpected but not a misrepresentation. >> > >> > In any case, the project object returned must be equivalent for both >> directories passed in and that's not how >> > project.el is structured. Using file-equal-p or any other method to >> find an "equivalent" project object but >> > substitute the "expected" directory results in two objects that don't >> compare as equal and that's a >> > misrepresentation IMO. >> >> Thus my suggestion to make those objects 'equal', even if they aren't >> 'eq'. >> > > I hear you, 100%. But I don't see a place to perform that comparison > given the current implementation. > I'll give you a concrete example I've been playing with. I keep my Emacs init files in a git repo. I put the repo in ~/proj/emacs.d. In my home directory, I ln -s ~/proj/emacs.d .emacs.d. In this set up, project-name reports "emacs.d" when default-directory is relative to ~/proj/emacs.d and ".emacs.d" when relative to my home directory. It's the same project and I expect the name to be the same. Also for project-root, as I've said. --000000000000e9492a063129e2e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 8:27=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On = Tue, Mar 25, 2025 at 8:15=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 24 Mar 2025 16:15:14 -0400
> Cc: dancol@danc= ol.org, 7712= 2@debbugs.gnu.org, dmitry@gutov.dev
>
>=C2=A0 As this discussion shows, it might well be a "misrepresenta= tion" in
>=C2=A0 some cases.
>
> Maybe unexpected but not a misrepresentation.
>
> In any case, the project object returned must be equivalent for both d= irectories passed in and that's not how
> project.el is structured.=C2=A0 Using file-equal-p or any other method= to find an "equivalent" project object but
> substitute the "expected" directory results in two objects t= hat don't compare as equal and that's a
> misrepresentation IMO.

Thus my suggestion to make those objects 'equal', even if they aren= 't
'eq'.

I hear you, 100%.=C2=A0 But I don't see a place to perform that = comparison given the current implementation.
=

I'll give you a concrete example I've been playing with.=C2=A0 I k= eep my Emacs init files in a git repo.=C2=A0 I put the repo in ~/proj/emacs= .d.=C2=A0 In my home directory, I ln -s ~/proj/emacs.d .emacs.d.=C2=A0 In t= his set up, project-name reports "emacs.d" when default-directory= is relative to ~/proj/emacs.d and ".emacs.d" when relative to my= home directory.=C2=A0 It's the same project and I expect the name to b= e the same.=C2=A0 Also for project-root, as I've said.
--000000000000e9492a063129e2e4-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 08:55:05 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 12:55:05 +0000 Received: from localhost ([127.0.0.1]:36829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3o8-0001cb-8I for submit@debbugs.gnu.org; Tue, 25 Mar 2025 08:55:04 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:37290) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tx3o5-0001bo-Ab for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 08:55:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Y2j2doX9oX0f5RJJTHs8WR24KJyMjXsZqWWCEjuX0/0=; b=KOMjBEITouA6URZ4YVlf2fmUD4 MeFF1meYYrl6qylZEeZsMUC6q91l9hIfiFfq75pUnx3+DD3UlXZRdD2GHcXgm2OdO1unQJkkbJJED Qp7FZW1CFl5iktLRtlhJS5/oTZrkdve0XR+vGsvHHl8H/U4G01qPhMuh9m930tKRTIxYFHiOSQqD7 TcIbM47bK8gt/RenkZYzsCjIDzSceQYEpLJL9EnyxmIf0US9QSnC3ErFINzyS98Zhm2ippIAGHuEI f3QnF1BW0A6rFzWoCW2B7CBJ2K06nwCai6Ox+5Gyt98EB9gE/ooSpoBeAapScWEOOPBFIuE5st+gp a00zyHaQ==; Received: from 2603-9001-4203-1ab2-1951-ef57-b5ee-b6a5.inf6.spectrum.com ([2603:9001:4203:1ab2:1951:ef57:b5ee:b6a5]:53250 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tx3ne-00405J-0K; Tue, 25 Mar 2025 08:54:34 -0400 Date: Tue, 25 Mar 2025 08:54:53 -0400 From: Daniel Colascione To: Ship Mints , Dmitry Gutov Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks User-Agent: K-9 Mail for Android In-Reply-To: References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On March 25, 2025 6:54:34 AM EDT, Ship Mints wrote= : >On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov wrote: > >> On 24/03/2025 17:15, Ship Mints wrote: >> > I'm curious to hear more about why people would object to (project-ro= ot >> > project-obj) being canonicalized=2E I don't think many people ever >> > manually enter project dirs=2E The persisted known projects, I'd thi= nk, >> > would also benefit from no duplicates=2E >> >> I wonder if you yourself would prefer for all buffer-file-name values, >> and default-directory values, to be canonicalized as well=2E >> >> The same reasoning would seem to apply to them too anyway=2E >> > >Ochen funny=2E I'll submit a separate patch for that one day (sarcasm doe= sn't >work in email, sorry)=2E > >In the meantime, I maintain my view that project=2Eel needs to report uni= form >project names and roots for identical projects approached from different >places, even if optional=2E > >I just took a look at projectile=2Eel, which I'd never looked at before >because I prefer using/improving core features=2E It has a longer user >history to see what they've experienced (and it looks like some of >project=2Eel's approach is copied almost verbatim e=2Eg=2E, the implement= ation of >project-name)=2E projectile seems to both have users that want symlink >chasing and those that don't (looks like ClearCase users--but out of >necessity not desire?)=2E As those concerns seem to be project dependent= , we >could an option that is a list of paths or matchers to include/exclude fr= om >chasing, and also a project root semaphore file or project config as I >suggested in another message in this thread=2E > >I'd enable chasing as my default, opt out in a specific project should I >ever have one that needs it rather than the other way around, and enjoy >project-name and project-root uniformity=2E > >-Stephane Eli is right=2E You want either global path normalization or you don't=2E = Doing it peacemeal at the project level might satisfy some small immediate = need, but it won't solve the whole problem and will inevitably cause downst= ream problems due to the incoherence=2E Also, it's just not universally true that I want to regard the "real" vers= ion of something as its realpath=2E People use symlinks differently=2E In a= world in which we had ubiquitous unprivileged bind mounts *and* symlinks, = the realpath as identity concept might be more powerful, but we don't=2E From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 09:04:53 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 13:04:53 +0000 Received: from localhost ([127.0.0.1]:36873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx3xb-0002B6-8I for submit@debbugs.gnu.org; Tue, 25 Mar 2025 09:04:52 -0400 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]:55566) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx3uh-00023q-0c for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 09:01:51 -0400 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-51eb1823a8eso2548511e0c.3 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 06:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742907705; x=1743512505; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dyPAvkF2wyMo2SkWMU1W1ww1TGej3teTmNF2JICrO60=; b=OETOgEBCiyqjrCFjtX9tntLpbQKE33g2GLbDGKCjESdYclXMTXzb1REXFHivVIX6eE JsKtBXfWgd6OFUxu/oB8a1TKBqJDM5h/6OVVnVgQ6gwNMJALP83FqciBjBvwYEcmGH77 6DT09rnzteJrGmXGIApuaFWuWmjNpMsjZqf28tsZeP4NhER53X890BBZbYLg43LkRVCa rYQMGLAn9N7Ov19MEjzwigpQZ4LYyurQyczahEyDUEoTC2bnC50MPELyvBLwoYZkeF4H Ej0eI/S6EMPzFjC8TwHlC8ojT5gWh6XPk0LB4Jt7ZYlUxlF8SETdLYE6EmggagOdjU1R TCfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742907705; x=1743512505; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dyPAvkF2wyMo2SkWMU1W1ww1TGej3teTmNF2JICrO60=; b=qZgbAXppbUEJdWaXsSRub072sTEdMx8TOuzv0APXHCnka+rsLSDBL2riN6kE2gNGrE emZ01cpUWMjp2AVAX4feKK5/LeG8VK28akH4AhMqqEOoltLJBve+NS0LviexipzwGMVC L3S/aOo50rZtiP1JtzabK6VUyQuwyJ5qtmSkQsGWMdcWnbkrmr2ftpHMrMRicpyU+9iR WESbOOfodVpw9ubTS/uHabA5kDb8sZI8VndMeIWf6+miYHvvXA9F2GGyH0iHlQN+Rd/6 lbTlcR9vCKfLq6hADnbAKnbnXjsa4vQew8JWv041XCxtnpHYryUEpsIwPaCYdYIocwg2 XGuw== X-Forwarded-Encrypted: i=1; AJvYcCWzegQ5HhGQvf4HANzDUBLLm/0vrONIkPik1KfNIXkDCjVnzEkMaN8wVAnKSSEK8PjFu3nkUA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwGvPzjjMDv1g8Sj8DLbvd8V+dCKUj3eNPe1KdjGYgKSVai1cMs YbqZ1PFiW4juybKKAbqTuz1P7AvTNHsS2cKHNiFKypkz0K7bvLFqWvJ8XTj84pN26lxzzLxBeIO I1/OdzCb29tm13+9Hn11iS2j/cg7ouw== X-Gm-Gg: ASbGncuw3uWHho3Heq7X4ZB72GQGlP0MbfhtdpyRQHrjJbGkCK8jqxBAP90tq5PE38E zjxcLkv7JLfDI7p1YI0ZAXMAgaXAAEuj1fcjqL9lI1iSNPGNZjG53QgrZ0LX/QMyX6Q62dHLpD9 LF+7tqBJlgW8IKKVq1weae3Fa48g== X-Google-Smtp-Source: AGHT+IGU6YMA7oZMc3d/vCoSSUqi4UpPydFkGrCnLzcnx/hhRaAhxQyocZDn4sL7qRnVLjdFkzr5W+obVkH949NEvlU= X-Received: by 2002:a05:6122:2109:b0:51f:4154:c1b2 with SMTP id 71dfb90a1353d-525a82f1e34mr12271195e0c.2.1742907703477; Tue, 25 Mar 2025 06:01:43 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> In-Reply-To: From: Ship Mints Date: Tue, 25 Mar 2025 09:01:32 -0400 X-Gm-Features: AQ5f1JpSOT5UP6zUKn0hFAG8gR8qoohCL8DUyg8UqxyGSnUxs2hAeNpe5l-ZuuU Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000008accb406312a52c2" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008accb406312a52c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 8:54=E2=80=AFAM Daniel Colascione wrote: > > > On March 25, 2025 6:54:34 AM EDT, Ship Mints wrote: > >On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov = wrote: > > > >> On 24/03/2025 17:15, Ship Mints wrote: > >> > I'm curious to hear more about why people would object to > (project-root > >> > project-obj) being canonicalized. I don't think many people ever > >> > manually enter project dirs. The persisted known projects, I'd thin= k, > >> > would also benefit from no duplicates. > >> > >> I wonder if you yourself would prefer for all buffer-file-name values, > >> and default-directory values, to be canonicalized as well. > >> > >> The same reasoning would seem to apply to them too anyway. > >> > > > >Ochen funny. I'll submit a separate patch for that one day (sarcasm > doesn't > >work in email, sorry). > > > >In the meantime, I maintain my view that project.el needs to report > uniform > >project names and roots for identical projects approached from different > >places, even if optional. > > > >I just took a look at projectile.el, which I'd never looked at before > >because I prefer using/improving core features. It has a longer user > >history to see what they've experienced (and it looks like some of > >project.el's approach is copied almost verbatim e.g., the implementation > of > >project-name). projectile seems to both have users that want symlink > >chasing and those that don't (looks like ClearCase users--but out of > >necessity not desire?). As those concerns seem to be project dependent, > we > >could an option that is a list of paths or matchers to include/exclude > from > >chasing, and also a project root semaphore file or project config as I > >suggested in another message in this thread. > > > >I'd enable chasing as my default, opt out in a specific project should I > >ever have one that needs it rather than the other way around, and enjoy > >project-name and project-root uniformity. > > > >-Stephane > > Eli is right. You want either global path normalization or you don't. > Doing it peacemeal at the project level might satisfy some small immediat= e > need, but it won't solve the whole problem and will inevitably cause > downstream problems due to the incoherence. > > Also, it's just not universally true that I want to regard the "real" > version of something as its realpath. People use symlinks differently. In= a > world in which we had ubiquitous unprivileged bind mounts *and* symlinks, > the realpath as identity concept might be more powerful, but we don't. > Again...I'm not saying universally, I'm saying optionally, and preferably flexibly optional. --0000000000008accb406312a52c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 8:54=E2=80=AFAM Daniel Colascione <dancol@dancol.org> wrote:
=


On March 25, 2025 6:54:34 AM EDT, Ship Mints <shipmints@gmail.com> wrote:
>On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote: >
>> On 24/03/2025 17:15, Ship Mints wrote:
>> > I'm curious to hear more about why people would object to= (project-root
>> > project-obj) being canonicalized.=C2=A0 I don't think man= y people ever
>> > manually enter project dirs.=C2=A0 The persisted known projec= ts, I'd think,
>> > would also benefit from no duplicates.
>>
>> I wonder if you yourself would prefer for all buffer-file-name val= ues,
>> and default-directory values, to be canonicalized as well.
>>
>> The same reasoning would seem to apply to them too anyway.
>>
>
>Ochen funny. I'll submit a separate patch for that one day (sarcasm= doesn't
>work in email, sorry).
>
>In the meantime, I maintain my view that project.el needs to report uni= form
>project names and roots for identical projects approached from differen= t
>places, even if optional.
>
>I just took a look at projectile.el, which I'd never looked at befo= re
>because I prefer using/improving core features.=C2=A0 It has a longer u= ser
>history to see what they've experienced (and it looks like some of<= br> >project.el's approach is copied almost verbatim e.g., the implement= ation of
>project-name).=C2=A0 projectile seems to both have users that want syml= ink
>chasing and those that don't (looks like ClearCase users--but out o= f
>necessity not desire?).=C2=A0 As those concerns seem to be project depe= ndent, we
>could an option that is a list of paths or matchers to include/exclude = from
>chasing, and also a project root semaphore file or project config as I<= br> >suggested in another message in this thread.
>
>I'd enable chasing as my default, opt out in a specific project sho= uld I
>ever have one that needs it rather than the other way around, and enjoy=
>project-name and project-root uniformity.
>
>-Stephane

Eli is right. You want either global path normalization or you don't. D= oing it peacemeal at the project level might satisfy some small immediate n= eed, but it won't solve the whole problem and will inevitably cause dow= nstream problems due to the incoherence.

Also, it's just not universally true that I want to regard the "re= al" version of something as its realpath. People use symlinks differen= tly. In a world in which we had ubiquitous unprivileged bind mounts *and* s= ymlinks, the realpath as identity concept might be more powerful, but we do= n't.

Again...I'm not saying universally, I'm = saying=C2=A0optionally, and preferably flexibly optional.
--0000000000008accb406312a52c2-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 11:42:33 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 15:42:33 +0000 Received: from localhost ([127.0.0.1]:39701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx6QC-0002sy-Gp for submit@debbugs.gnu.org; Tue, 25 Mar 2025 11:42:33 -0400 Received: from mail-ua1-x930.google.com ([2607:f8b0:4864:20::930]:57370) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx6Q9-0002sh-2w for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 11:42:30 -0400 Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-86ba07fe7a4so4900735241.2 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 08:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742917343; x=1743522143; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OOI6kRN2XmtqTEp8P5SrFfmmKs0TzRX0Yh8f8YD2ga0=; b=CVYo6DwqaJGKP9LOiQkRTefjjgolRxCZaioaf88gI+MBZJO1AtDOjVMDLCjLZeEzaa t3ivdMynyFXmA/WywfCbSO4BjLglNM1OonLaetm4vO80Bzn/vJ3Rqe4MvpTfUGA5AnPl k4jjqisq7AA+wA0VoB/QOTB2Vs422RxJXjDrzQ6kPOT3sd2zfJQrwo/+mmq1WLyKcH6P BgjjqP89G6m6AzbDXaFSovGAHyw+dAo1M/ci+KcNUN8ROFw1EPDMrgjtEYSGiVxJKLw9 GEUmw3F5trSwO3d62YTBKng79qfbCROnlrblVJ3U55Wi3KYcw+YZrU2hOaZvTwysKrRt g1lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742917343; x=1743522143; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OOI6kRN2XmtqTEp8P5SrFfmmKs0TzRX0Yh8f8YD2ga0=; b=HuCBAbuTQzSltC69+ktWHUX00Vwgn8e1V8fEE5mT/Z7oAd2DioAnPRk3COM673f82+ Zmy6WVsXDIf/mPB3EaUqKjHwUiCA/qbg3l2hSbU7XldTS0aw2Yhj2DcLbR5eABEJT90B fyExQ+DXUIaKbDH+lFA9jB2S/r4pI2/EXwgnXvOYvirHoG54eiOy8bK1h0ihABBjN6PZ yjI3N0e/r9VrB9zCfBAq2pwfwFrPDRT/p0/3C7Ywwokf/JdB4ttTDVrFPSodtvhfwu++ UCbYYN1TaA6b0l6JvQ7021Sc1LcL1lUtVi+KzQyX+cIlvZFEjieGiHvSejrbaC4PrNgY ePYA== X-Forwarded-Encrypted: i=1; AJvYcCXBkYJbGwTH2sKU1xU/O58lRMm8s2Z+3NOsvNtOUYhLZEZ2GtFjayoP7fw3pd0l+ZvsHuzUQQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyZ+Tb++npW+6ig3XML6KTt9RJfjv4ezcHYswsZ/X1VJGv9SlMm 58cpgSjueo3CWnce4zrB6R5LH+ZogmQCsTBlSK5oC78qPyYLak2T/cv5iGJT8vzMbQYxwX2oQI6 U4u8kOl1ezZVOx96QpmKYTljCERA= X-Gm-Gg: ASbGnctxZL20iFSrYkM06LqlCss+LolgoytxDL0N7D7u0wxThqy7bDbpiJntk7jUt/A MYTr1MpnloETZyLD8rXPmMls5qeg6ZW4QObsTp9MePbJ6hI2FUZWlDssdY92b342ZLCbkRKEhOt h2MRgINaTWLIB02gAkaHWk+QpkmQ== X-Google-Smtp-Source: AGHT+IFMXm15JHTTmn9rHSTVmK/LWtddSwvlKmMaZQLQluiTHSuyxjR2QMrrikIrFIFpFgA8PVf5XR0GK5K9/SAIHh4= X-Received: by 2002:a05:6102:dca:b0:4c4:e451:6f24 with SMTP id ada2fe7eead31-4c50d623b0amr14441620137.22.1742917343154; Tue, 25 Mar 2025 08:42:23 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> In-Reply-To: From: Ship Mints Date: Tue, 25 Mar 2025 11:42:11 -0400 X-Gm-Features: AQ5f1JpzYqkyGwvLQuJ9yJQiZB7JkLzZ_tvLyFBrdQk_fkWhJab4YVsfmSzX8MI Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000001c993206312c9170" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001c993206312c9170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 9:01=E2=80=AFAM Ship Mints wr= ote: > On Tue, Mar 25, 2025 at 8:54=E2=80=AFAM Daniel Colascione > wrote: > >> >> >> On March 25, 2025 6:54:34 AM EDT, Ship Mints wrote= : >> >On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov wrote: >> > >> >> On 24/03/2025 17:15, Ship Mints wrote: >> >> > I'm curious to hear more about why people would object to >> (project-root >> >> > project-obj) being canonicalized. I don't think many people ever >> >> > manually enter project dirs. The persisted known projects, I'd >> think, >> >> > would also benefit from no duplicates. >> >> >> >> I wonder if you yourself would prefer for all buffer-file-name values= , >> >> and default-directory values, to be canonicalized as well. >> >> >> >> The same reasoning would seem to apply to them too anyway. >> >> >> > >> >Ochen funny. I'll submit a separate patch for that one day (sarcasm >> doesn't >> >work in email, sorry). >> > >> >In the meantime, I maintain my view that project.el needs to report >> uniform >> >project names and roots for identical projects approached from differen= t >> >places, even if optional. >> > >> >I just took a look at projectile.el, which I'd never looked at before >> >because I prefer using/improving core features. It has a longer user >> >history to see what they've experienced (and it looks like some of >> >project.el's approach is copied almost verbatim e.g., the implementatio= n >> of >> >project-name). projectile seems to both have users that want symlink >> >chasing and those that don't (looks like ClearCase users--but out of >> >necessity not desire?). As those concerns seem to be project dependent= , >> we >> >could an option that is a list of paths or matchers to include/exclude >> from >> >chasing, and also a project root semaphore file or project config as I >> >suggested in another message in this thread. >> > >> >I'd enable chasing as my default, opt out in a specific project should = I >> >ever have one that needs it rather than the other way around, and enjoy >> >project-name and project-root uniformity. >> > >> >-Stephane >> >> Eli is right. You want either global path normalization or you don't. >> Doing it peacemeal at the project level might satisfy some small immedia= te >> need, but it won't solve the whole problem and will inevitably cause >> downstream problems due to the incoherence. >> >> Also, it's just not universally true that I want to regard the "real" >> version of something as its realpath. People use symlinks differently. I= n a >> world in which we had ubiquitous unprivileged bind mounts *and* symlinks= , >> the realpath as identity concept might be more powerful, but we don't. >> > > Again...I'm not saying universally, I'm saying optionally, and preferably > flexibly optional. > I just got bitten by project-buffers not reporting all the buffers "strictly" related to the project because project.el thinks there are two different projects. I can't imagine that me and the colleagues of mine that use convenience symlinks are the only ones to see these kinds of inconsistencies. Just thought I'd leave a concrete example in this thread. I've turned my advice back on to force truename canonicalization for the time being. --0000000000001c993206312c9170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 9:01=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On = Tue, Mar 25, 2025 at 8:54=E2=80=AFAM Daniel Colascione <dancol@dancol.org> wrote:


On March 25, 2025 6:54:34 AM EDT, Ship Mints <shipmints@gmail.com> wrote:
>On Mon, Mar 24, 2025 at 10:16=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote: >
>> On 24/03/2025 17:15, Ship Mints wrote:
>> > I'm curious to hear more about why people would object to= (project-root
>> > project-obj) being canonicalized.=C2=A0 I don't think man= y people ever
>> > manually enter project dirs.=C2=A0 The persisted known projec= ts, I'd think,
>> > would also benefit from no duplicates.
>>
>> I wonder if you yourself would prefer for all buffer-file-name val= ues,
>> and default-directory values, to be canonicalized as well.
>>
>> The same reasoning would seem to apply to them too anyway.
>>
>
>Ochen funny. I'll submit a separate patch for that one day (sarcasm= doesn't
>work in email, sorry).
>
>In the meantime, I maintain my view that project.el needs to report uni= form
>project names and roots for identical projects approached from differen= t
>places, even if optional.
>
>I just took a look at projectile.el, which I'd never looked at befo= re
>because I prefer using/improving core features.=C2=A0 It has a longer u= ser
>history to see what they've experienced (and it looks like some of<= br> >project.el's approach is copied almost verbatim e.g., the implement= ation of
>project-name).=C2=A0 projectile seems to both have users that want syml= ink
>chasing and those that don't (looks like ClearCase users--but out o= f
>necessity not desire?).=C2=A0 As those concerns seem to be project depe= ndent, we
>could an option that is a list of paths or matchers to include/exclude = from
>chasing, and also a project root semaphore file or project config as I<= br> >suggested in another message in this thread.
>
>I'd enable chasing as my default, opt out in a specific project sho= uld I
>ever have one that needs it rather than the other way around, and enjoy=
>project-name and project-root uniformity.
>
>-Stephane

Eli is right. You want either global path normalization or you don't. D= oing it peacemeal at the project level might satisfy some small immediate n= eed, but it won't solve the whole problem and will inevitably cause dow= nstream problems due to the incoherence.

Also, it's just not universally true that I want to regard the "re= al" version of something as its realpath. People use symlinks differen= tly. In a world in which we had ubiquitous unprivileged bind mounts *and* s= ymlinks, the realpath as identity concept might be more powerful, but we do= n't.

Again...I'm not saying universally, I'm saying=C2=A0optionally, a= nd preferably flexibly optional.

I just got = bitten by project-buffers not reporting all the buffers "strictly"= ; related to the project because project.el=C2=A0thinks there are two diffe= rent projects.=C2=A0 I can't imagine that me and the colleagues of mine= that use convenience symlinks are the only ones to see these kinds of inco= nsistencies.=C2=A0 Just thought I'd leave a concrete example in this th= read.
I'v= e turned my advice back on to force truename=C2=A0canonicalization for the = time being.
--0000000000001c993206312c9170-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 14:54:30 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 18:54:30 +0000 Received: from localhost ([127.0.0.1]:40009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx9Py-0003yb-7g for submit@debbugs.gnu.org; Tue, 25 Mar 2025 14:54:30 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:34868) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tx9Ps-0003yK-9K for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 14:54:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4FEFWU7yel/cXlpPkHrjFtcgmmjt1AT6eqguRrIBFMQ=; b=NTAX8k0c27cKBfpgDzfzxCeduO Jz/o0OT3P9V4M+Op2EQAmRzaOyBuskZ/Z4UpptWu2Hwyy3H+PLLdfI0smbA0I0RXF0WiWoIwn1DeX fSccg6sytLUAqvfar1rlfvX2Y9GN24ejKq+c/FoUzYxipJ6A34I0qIksFdl7eBAoMOU3fqDYzBdIr 3FuAuqFnrGiVixqWbIrbj7qBZzDPU1EusxRfQRE4wKm48MPXvfWm+rb7kHzzSdoXBCuS84ztcYjH4 85nlFZvI5uHY2MhKv7Icm+VcoqlL+uEF9MiJ7YwNwWUoFlW4IZZiR7Ywz6oq8rTadOJylwq0wbR9d xLJ7S58w==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1tx9PS-0041TU-1O; Tue, 25 Mar 2025 14:53:58 -0400 From: Daniel Colascione To: Ship Mints Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks In-Reply-To: References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> <86ldste24n.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Tue, 25 Mar 2025 14:54:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ship Mints writes: > On Tue, Mar 25, 2025 at 8:17=E2=80=AFAM Eli Zaretskii wrot= e: > >> > From: Ship Mints >> > Date: Mon, 24 Mar 2025 16:25:44 -0400 >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > >> > To concretely demonstrate the differences, the function project-name >> will return different results for each >> > project object based on buffers loaded from different paths, despite t= he >> projects being equivalent. >> > >> > project-name is defined as: >> > >> > (file-name-nondirectory (directory-file-name (project-root project))) >> > >> > If the root directory is determined to be different, the objects return >> different names (and different roots). >> >> Unless I'm misunderstanding what Daniel wrote, the above is actually a >> feature from his POV. >> > > Indeed, it might be, but I'm curious what tooling he's using that depends > on project-root not being "absolute" so to speak, and relative to his > ambient default-directory. =F0=9F=A7=A0. If I have a project under ~/foo/bar/qux/blah and I want to symlink to it from ~/blah, and I specifically find-file ~/blah/something.txt, then I want my project to be ~/blah-related, not ~/foo/bar/qux/blah! The difference matters for things like project-shell. Isn't the feature you really want a hypothetical find-file-resolves-symlinks flag that has find-file find the absolute version of anything visited? Some people sincerely want this behavior. Then you'd always be "in" your truename directory in the first place (modulo other entry points like dired, which you could similarly modify). For my use case, I'd actually like to tweak file-truename to report anything under ~/foo/bar/qux/blah as being under ~/blah, but that's a separate and low-priority subject. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 14:58:47 2025 Received: (at 77122) by debbugs.gnu.org; 25 Mar 2025 18:58:47 +0000 Received: from localhost ([127.0.0.1]:40017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tx9U7-0004CP-5c for submit@debbugs.gnu.org; Tue, 25 Mar 2025 14:58:47 -0400 Received: from mail-vk1-xa35.google.com ([2607:f8b0:4864:20::a35]:58387) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tx9U1-0004By-UZ for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 14:58:45 -0400 Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-5240317b3e0so2282082e0c.0 for <77122@debbugs.gnu.org>; Tue, 25 Mar 2025 11:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742929116; x=1743533916; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LdjHuSfh576Ot9YzGtIpHM4iAm7rqvYCgdIbTXkArrw=; b=ZZv/I5a4r2GKAHS89friXzCxIVvVaFkkeUhEkksUJHtjnn2NPwOplh1q6ZtA/jn2Mj DUdrlTVITXFuRfpkrUyALkeCvTlPTIJu93UTWWux9xJ4LdAh4mGcNtciFpeYLWd1gi3L n/g4MRDo1KOdmLMdJwGFzerZVognotcLpuyxk5WDBBQpjIEy31BJ65AWT55iDhhVa6DA IHM+cj+6GC70QocvH1Xo2WUkq3GPNJ77Uj8qB/1PXT8M/JwsTQIMDZe+osOEFzjAsNHl cfhJvnb0sryIwiEJ/+9R5/T9sy04sTnOZldrwd3Qw45hvPq7YfElZSWFb8ImCjn0pghZ KR4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742929116; x=1743533916; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LdjHuSfh576Ot9YzGtIpHM4iAm7rqvYCgdIbTXkArrw=; b=dktgC97GdvR0QB2pvjwjFn/Jp+UKN+NzPG6fjwZNMg+m6m1zAKYwFUkV4lQp2Lqs9Q X0EdcOEhOxyCh+VhnIUYGlVI9JSVGYpM7vWxLkUge7UHFMnSKCoERzbu8u/e85ySYN0l Gag/Lhcgx6qaLG/CU2cSbTRT26R7EzcYADAH1uxOj5IV3opBpeQD+H/oh5MST9a70o0S CkcGPvIaW4EAcFKr2ln01iozgT7KZIxnKFqrB7lB5TPq22Gk9kWpnkAPLxFjRgNdFcH1 rGGjYr5gjh00/278TwouaLgehpvefT4aZnluHTqBglD+2dk/VsXcua6ifegVoovHVi7K s2Wg== X-Forwarded-Encrypted: i=1; AJvYcCUhWhXKH3ou8Q9ejRanG57yqiyscAFCg3ObEsXrNo28pUdq7hoI3nY4PubhbUsqEQ9kEMBq4w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzQcvWho9uPYhKBn53Wu3fN1YwxsOY/hgClcUBNyTxf8tKiSRCN XVVOdmBQQ7PhnkA/Ts/OxmyUUt2jVTbwA2wvCbTh/bHmJleBuBAJx96fMvCEfzjyu26Xgi23NLL 3dewOySzuV3YQV949kR0O1ud/cPU= X-Gm-Gg: ASbGncudPkO7ermAKCtQBLi5fBTYg7eqBvRk2hJv4hI3KXjnlDPPX5XBxIlZ30n5BLN b6avmuR2xloyQXTDKVVDBFjvF2cJfSu0cHZ14RODpigkKUZ2kCR8GgEk4kSF1hpvoIFYiLPpKac F6M8ObOIP30adgFaARALrODJb9nA== X-Google-Smtp-Source: AGHT+IGKlxHLisx2YEyqmsgBM6e1mnlGrLXmYTdeAgE2t8tS1PY1jlw5G4GbJxobAWxhxr570Ej3q9DN3H7wI+pSCO8= X-Received: by 2002:a05:6122:f06:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-525a834e589mr14176864e0c.4.1742929115809; Tue, 25 Mar 2025 11:58:35 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <86y0wue188.fsf@gnu.org> <86sen2dxyp.fsf@gnu.org> <86r02mdwjx.fsf@gnu.org> <86ldste24n.fsf@gnu.org> In-Reply-To: From: Ship Mints Date: Tue, 25 Mar 2025 14:58:23 -0400 X-Gm-Features: AQ5f1JqUtEZrH4GuwHIAu6PHXj4P73de-bhaZxjLZiGgjz4HK0BoATAc8f_LTT4 Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="000000000000d1115906312f4e73" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, dmitry@gutov.dev, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d1115906312f4e73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 2:54=E2=80=AFPM Daniel Colascione wrote: > Ship Mints writes: > > > On Tue, Mar 25, 2025 at 8:17=E2=80=AFAM Eli Zaretskii wr= ote: > > > >> > From: Ship Mints > >> > Date: Mon, 24 Mar 2025 16:25:44 -0400 > >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev > >> > > >> > To concretely demonstrate the differences, the function project-name > >> will return different results for each > >> > project object based on buffers loaded from different paths, despite > the > >> projects being equivalent. > >> > > >> > project-name is defined as: > >> > > >> > (file-name-nondirectory (directory-file-name (project-root project))= ) > >> > > >> > If the root directory is determined to be different, the objects > return > >> different names (and different roots). > >> > >> Unless I'm misunderstanding what Daniel wrote, the above is actually a > >> feature from his POV. > >> > > > > Indeed, it might be, but I'm curious what tooling he's using that depen= ds > > on project-root not being "absolute" so to speak, and relative to his > > ambient default-directory. > > =F0=9F=A7=A0. > > If I have a project under ~/foo/bar/qux/blah and I want to symlink to it > from ~/blah, and I specifically find-file ~/blah/something.txt, then I > want my project to be ~/blah-related, not ~/foo/bar/qux/blah! > The difference matters for things like project-shell. > > Isn't the feature you really want a hypothetical > find-file-resolves-symlinks flag that has find-file find the absolute > version of anything visited? Some people sincerely want this behavior. > Then you'd always be "in" your truename directory in the first place > (modulo other entry points like dired, which you could similarly > modify). > > For my use case, I'd actually like to tweak file-truename to report > anything under ~/foo/bar/qux/blah as being under ~/blah, but that's a > separate and low-priority subject. > That, too, but this all started when I got sufficiently frustrated that project-name doesn't match for both real and symlinked directory avenues. Making project-root's match, solves a bunch of other things where implementations of code, including project-buffers, rely on project-root. --000000000000d1115906312f4e73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 2:54=E2=80=AFPM Daniel Colascione <dancol@dancol.org> wrote:
=
Ship Mints <shipmints@gmail.com> writes:

> On Tue, Mar 25, 2025 at 8:17=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Ship Mints <shipmints@gmail.com>
>> > Date: Mon, 24 Mar 2025 16:25:44 -0400
>> > Cc: da= ncol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev
>> >
>> > To concretely demonstrate the differences, the function proje= ct-name
>> will return different results for each
>> > project object based on buffers loaded from different paths, = despite the
>> projects being equivalent.
>> >
>> > project-name is defined as:
>> >
>> > (file-name-nondirectory (directory-file-name (project-root pr= oject)))
>> >
>> > If the root directory is determined to be different, the obje= cts return
>> different names (and different roots).
>>
>> Unless I'm misunderstanding what Daniel wrote, the above is ac= tually a
>> feature from his POV.
>>
>
> Indeed, it might be, but I'm curious what tooling he's using t= hat depends
> on project-root not being "absolute" so to speak, and relati= ve to his
> ambient default-directory.

=F0=9F=A7=A0.

If I have a project under ~/foo/bar/qux/blah and I want to symlink to it from ~/blah, and I specifically find-file ~/blah/something.txt, then I
want my project to be ~/blah-related, not ~/foo/bar/qux/blah!
The difference matters for things like project-shell.

Isn't the feature you really want a hypothetical
find-file-resolves-symlinks flag that has find-file find the absolute
version of anything visited?=C2=A0 Some people sincerely want this behavior= .
Then you'd always be "in" your truename directory in the firs= t place
(modulo other entry points like dired, which you could similarly
modify).

For my use case, I'd actually like to tweak file-truename to report
anything under ~/foo/bar/qux/blah as being under ~/blah, but that's a separate and low-priority subject.

That, too, but this all= started when I got sufficiently frustrated that project-name doesn't m= atch for both real and symlinked directory avenues.=C2=A0 Making project-ro= ot's match, solves a bunch of other things where implementations of cod= e, including project-buffers, rely on project-root.
--000000000000d1115906312f4e73-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 23:02:21 2025 Received: (at 77122) by debbugs.gnu.org; 26 Mar 2025 03:02:21 +0000 Received: from localhost ([127.0.0.1]:40671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txH25-0002q4-7w for submit@debbugs.gnu.org; Tue, 25 Mar 2025 23:02:21 -0400 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]:56741) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txH20-0002pn-Gq for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 23:02:17 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 8E20A1140125; Tue, 25 Mar 2025 23:02:10 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Tue, 25 Mar 2025 23:02:10 -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:subject:subject:to:to; s=fm3; t=1742958130; x=1743044530; bh=vBuvicTll1i5AP47DECI+99UJWT/kjoiNra3G7I4oHk=; b= K8qQm16RRRi+YIM7JUtAXHc60Z4M7bQHmOKv4AEwvd+yJ2rTayyn5BY5prpp+CRl D8z7z2mYllbCaqpDsVfIHL+Ph23Kko/uzoddXuDWh+VZIeiA3ClB0pJo6xciFegh mlb+wDA1NLATvR+DHn9Fj2nhNkW51buyVOlA7hogSZIBpJwFZo3b6U5sIWF3ZF3A QI6cIKlQFmZ0h4lsBDoftroz2Q5urgSd/ZSQSEaAdQwr+8VNdLUDYBuoBZUACFf8 tlf5Ic0bALr8s0H+InYLmZnJyjIQ+2SaWzvxCkR03OJNxHCExIgzbls/hP4W8SfK EjR/+qMKClToZQ62eMCPxg== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742958130; x= 1743044530; bh=vBuvicTll1i5AP47DECI+99UJWT/kjoiNra3G7I4oHk=; b=n WEw518+HXtZvPdwo67Xgy6fShRkMHkQSGDJOhVIvOr7feJUQripzD/BNaZEg5fiM P6jhS6oEOBod89ELNfcluFGMbrWzg9IvETrUNgLflAP/lAoYzPZ0iFbPFmXl51LD njsWm+eVxA1Vl7Bb0zzCFEXeJ1fQ/xHAfX2R8AeZD6dgsC5XQblX1z+jPRFoSiMl EXx756JfVNuHknB3pSAjLub5oJbxwu+mi6GZxAQJBXUVfJ05Z2MIrPeHWdBlzehB f4jEg+1f7PoEBSQ2HD4Zehf/BA3A32vZY5sZLIH2yfXUweylUhSxqiwVlwdboDaB THLl8BxBz/qw6l1ULz7SA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduieegfeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeet veegtedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhsse hgmhgrihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthht ohepuggrnhgtohhlsegurghntgholhdrohhrghdprhgtphhtthhopeejjeduvddvseguvg gssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Mar 2025 23:02:08 -0400 (EDT) Message-ID: Date: Wed, 26 Mar 2025 05:02:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Ship Mints References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii , dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 25/03/2025 12:54, Ship Mints wrote: > Ochen funny. I'll submit a separate patch for that one day (sarcasm > doesn't work in email, sorry). I was not making a joke. Wouldn't it be easier, for your purposes, if symlinks were followed right away? > In the meantime, I maintain my view that project.el needs to report > uniform project names and roots for identical projects approached from > different places, even if optional. > > I just took a look at projectile.el, which I'd never looked at before > because I prefer using/improving core features.  It has a longer user > history to see what they've experienced (and it looks like some of > project.el's approach is copied almost verbatim e.g., the implementation > of project-name).  projectile seems to both have users that want symlink > chasing and those that don't (looks like ClearCase users--but out of > necessity not desire?). Does it have that decision configurable as well? Could you point to the user option, or whatever else it has for that purpose? From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 25 23:11:34 2025 Received: (at 77122) by debbugs.gnu.org; 26 Mar 2025 03:11:34 +0000 Received: from localhost ([127.0.0.1]:40733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txHAz-0003KM-Pl for submit@debbugs.gnu.org; Tue, 25 Mar 2025 23:11:34 -0400 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]:34213) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txHAw-0003K3-Fs for 77122@debbugs.gnu.org; Tue, 25 Mar 2025 23:11:31 -0400 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 9E9C5114018F; Tue, 25 Mar 2025 23:11:24 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Tue, 25 Mar 2025 23:11:24 -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:subject:subject:to:to; s=fm3; t=1742958684; x=1743045084; bh=ei74YckK5B3iYqcaZoEry1wa6i+DD95oyviI3B9o8+4=; b= L4O8tBpUPUFXy84RnucLgD/8g9R6aTCMyFZbx53zWECNDL7p/300QdTEghByfDep EzpbNne1ig7ubdSfvsLNlpTQh8IiUo4c2liHTgl3bZhT9BuHcttH8EXAoI2kcrge dY2Y6RtX1Pu3hGxR+5BEg2lGDscGE/0QBn4f8aEPUkMkj+8eFA/B5K/SFTglSraZ ulTncZ5oNf3z9H9nfdW7vT6LlfXjxamgaTu08rzDi2PSASlCM/enjflQEspZursx pJYRH+8pttsoWbfvmmw+Z4ZKYXQ/IqGkM9DitaNZCWqdpk/yVoOOWOSFhW8QiV6T llbQF2xjtlGabiusjgOQ6Q== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742958684; x= 1743045084; bh=ei74YckK5B3iYqcaZoEry1wa6i+DD95oyviI3B9o8+4=; b=Y HwIN5uV/3vbFxtJwuipA1ATCRDwSWb+WraSdd86mgmau71XUOp3uP/gQsS8MY0c/ +6ewcfnr7Ie2c/4KBJZjXaqLkXQ/0iCpCl65U5Uy/8v8k+ktjdq7nwk4wj47GKBB /9VI7iwVfv1nzdErjVZyxHBymzlSsHtLACSvgb9jUi8LuBl8B1oL6dp0gHoxMzbk ryCo303gkui+7v96aKpwr5bwySEHe/8gvZkl3aXtSVXpf5ew1Sy1XzGNgZZgU5IR Fzcq7zk0bWAFcLEGLjedG6KXlVothXAMJcgMljSYo/ZyBNyc/7nRkV5hsUX33ke4 3sXQIUUfoV8mijMtKxXXQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduieeggeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeet veegtedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhsse hgmhgrihhlrdgtohhmpdhrtghpthhtohepuggrnhgtohhlsegurghntgholhdrohhrghdp rhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejjeduvddvseguvg gssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Mar 2025 23:11:22 -0400 (EDT) Message-ID: <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> Date: Wed, 26 Mar 2025 05:11:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Ship Mints , Daniel Colascione References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 25/03/2025 17:42, Ship Mints wrote: > I just got bitten by project-buffers not reporting all the buffers > "strictly" related to the project because project.el thinks there are > two different projects.  I can't imagine that me and the colleagues of > mine that use convenience symlinks are the only ones to see these kinds > of inconsistencies.  Just thought I'd leave a concrete example in this > thread. Thanks for the example. > I've turned my advice back on to force truename canonicalization for the > time being. Does that change really help? In my testing, what it results in, is showing only the buffers belonging to the "canonical" project, both when project-switch-buffer is called when in it, or when inside a "symlinked" version. Buffers visited from the "symlinked" project are not suggested in completion anymore. When reproducing, try using find-file (C-x C-f) to open the buffers. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 26 07:49:04 2025 Received: (at 77122) by debbugs.gnu.org; 26 Mar 2025 11:49:04 +0000 Received: from localhost ([127.0.0.1]:41811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txPFo-0001N5-7j for submit@debbugs.gnu.org; Wed, 26 Mar 2025 07:49:04 -0400 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]:61946) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1txPFk-0001MV-1Q for 77122@debbugs.gnu.org; Wed, 26 Mar 2025 07:49:00 -0400 Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-86b31db3c3bso2656934241.3 for <77122@debbugs.gnu.org>; Wed, 26 Mar 2025 04:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742989734; x=1743594534; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uIjoYj2isJAZdioxusEYXIEKqQmF954ILcMiYCstOGM=; b=Ynck/nSDRWSAw7cG+AlDQSgwI72cIuiOsyyPu4LlnH14reu/G9jwH5+VFn6p3YslOA 97AGhkuvDTCJDhwvyVKLTcUxUx69ZsaekXXxYZTi6yGjE30p/sFmAwPZxGiA5B8k4YFr PN+f2m9vXXgOSEVAx0y8cL9UZfUTQNu+VoPTeN7rcbib3Vc/L6dgAtL0FacVLegvvEtt nBruUUCOCPU9Zhfd5V/xV94qv5Pw7x3VAQht/LRM9+r8LFeqD2PxLTiY1NyWejP9a5S5 /vdbQH9cEPvx13N3QGTdIAbdG/fqhFvMtwuZBwhIv8Nk9DATQ6NMKdYi7eAke802bt98 MVGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742989734; x=1743594534; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uIjoYj2isJAZdioxusEYXIEKqQmF954ILcMiYCstOGM=; b=Mut4+R+M3W+p4m98mZlPbgtG0i4CSHqWT4D4AbeZZrw8HgQfBwSLPs6Iw285OSW3AA lBBUzMfae7QE+Agn0Fte+Vo8zIDPiKeItC3Ds/bHYP4YpyxYQicnwvIYLGz9hxav6jvl pF0xCANLVO6akBVA9iIq5G9GAU3zHcEEvpWScfz70epXW0nwmP6XfLce28u0o8Qd90dR 4BgEV+bB7ha/9mftc4WHhcsMCqPJWP1kUJ6khLByblQTGJi78iQSYKaRvzlZC5bmRLd1 ngsMKHlWUb2toh3Xr0rQw5pDi220fttv1EkQaTvbpo7t6sjPzUdwIMjzUwAoE7nY6Sxo i9rA== X-Forwarded-Encrypted: i=1; AJvYcCVqL/sAJ3zSznJhZDrNSqll+SP/T18Lh4s36No8xXIUjD2CqHHq+ISrALqvqagMG5hXblPE+g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw8By92FgJc6d0rkf63rzy+Tm6rwthL9xmyULpP6bmXwyOsNt+x E/gAfQQ869uBWIPXn4A2BV3QmtVl3ZX4wgPlruUvKEVKJ2VSmRzTZEDYUT0+2hBADoH6T8+6x5d hlpFZfPsgMrxHmQNTiJrQgKQdjKw= X-Gm-Gg: ASbGncuUXtM/dN/6QJQaIy5dfVPidd0diTM42MYxrvg/IciY0vHkorCcRDgfGeL0hQ/ xc4veP5/GSMSvNyoQ2nVzwHO2QAbV/mjuhXOKiSrZyQIUpnTaiYK1DxMOcBvujNKY/eVAQbUCH1 txLw+Qq3yi+H9N8GkbWe9z7RiItQ== X-Google-Smtp-Source: AGHT+IEY4cC3o8/AyRINA2HNDEhAYDTnZ3L3WOfl0Edc/ID/2/BbM2FYnAQxiUlAw6LiFleWagVK0N6HOz4m+KXoVE8= X-Received: by 2002:a05:6102:54ab:b0:4c1:903e:7bf0 with SMTP id ada2fe7eead31-4c50d51c4acmr15497350137.13.1742989732166; Wed, 26 Mar 2025 04:48:52 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> In-Reply-To: <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> From: Ship Mints Date: Wed, 26 Mar 2025 07:48:41 -0400 X-Gm-Features: AQ5f1Jqbr51l_CFPHXFxU0V8dArUYk-btq_psctIWTssuXB77dcTGpNHBsedM6E Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000d5450606313d6b7d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d5450606313d6b7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov wr= ote: > On 25/03/2025 17:42, Ship Mints wrote: > > I just got bitten by project-buffers not reporting all the buffers > > "strictly" related to the project because project.el thinks there are > > two different projects. I can't imagine that me and the colleagues of > > mine that use convenience symlinks are the only ones to see these kinds > > of inconsistencies. Just thought I'd leave a concrete example in this > > thread. > > Thanks for the example. > > > I've turned my advice back on to force truename canonicalization for th= e > > time being. > > Does that change really help? > It does for unifying project-name and project-root. In my testing, what it results in, is showing only the buffers belonging > to the "canonical" project, both when project-switch-buffer is called > when in it, or when inside a "symlinked" version. Buffers visited from > the "symlinked" project are not suggested in completion anymore. > > When reproducing, try using find-file (C-x C-f) to open the buffers. > Yes, indeed, project-buffers also needs some help. Thanks for the continuing discussion. WRT projectile, having only eyeballed the code (I haven't used it), it seems truename use is not optional. It looks like projectile-project-buffer-p is defined in terms of truename https://github.com/bbatsov/projectile/blob/55db082cdf7b849335ccf24b7ba5aa26= 07d6fe93/projectile.el#L1775, project-root caches the truename (but I see a bug in the code which doesn't normalize dir on the way in so users likely get odd results) https://github.com/bbatsov/projectile/blob/55db082cdf7b849335ccf24b7ba5aa26= 07d6fe93/projectile.el#L1385, the file cache is in terms of truename https://github.com/bbatsov/projectile/blob/55db082cdf7b849335ccf24b7ba5aa26= 07d6fe93/projectile.el#L1262 . --000000000000d5450606313d6b7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote:
On 25/03/2025 17:42, Ship Mints wrote:
> I just got bitten by project-buffers not reporting all the buffers > "strictly" related to the project because project.el=C2=A0th= inks there are
> two different projects.=C2=A0 I can't imagine that me and the coll= eagues of
> mine that use convenience symlinks are the only ones to see these kind= s
> of inconsistencies.=C2=A0 Just thought I'd leave a concrete exampl= e in this
> thread.

Thanks for the example.

> I've turned my advice back on to force truename=C2=A0canonicalizat= ion for the
> time being.

Does that change really help?

It does for unifying project= -name and project-root.

In my testing, what it results in, is showing only the buffers belonging to the "canonical" project, both when project-switch-buffer is ca= lled
when in it, or when inside a "symlinked" version. Buffers visited= from
the "symlinked" project are not suggested in completion anymore.<= br>
When reproducing, try using find-file (C-x C-f) to open the buffers.

= Yes, indeed,=C2=A0project-buffers also ne= eds=C2= =A0some=C2=A0help.<= /span>

Thanks for the continuing discussion.

WRT projectile, having only eyeballed the code (= I haven't used it), it seems truename use is not optional.=C2=A0 It loo= ks like projectile-project-buffer-p is defined in terms of truename=C2=A0https://github.com/bbatsov/projectil= e/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1775,=C2= =A0project-root caches the truename (but I see a bug in the code which does= n't normalize dir on the way in so users likely get odd results) https://github.com/bbatsov/projectile/bl= ob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385, the fi= le cache is in terms of truename=C2=A0https://github.com/bbatsov/projectile/blob/55db082cdf7b849335ccf24b7ba5= aa2607d6fe93/projectile.el#L1262.=C2=A0
--000000000000d5450606313d6b7d-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 26 09:00:31 2025 Received: (at 77122) by debbugs.gnu.org; 26 Mar 2025 13:00:31 +0000 Received: from localhost ([127.0.0.1]:42025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txQMw-0006Oz-MG for submit@debbugs.gnu.org; Wed, 26 Mar 2025 09:00:31 -0400 Received: from fout-b7-smtp.messagingengine.com ([202.12.124.150]:46913) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txQMr-0005rS-NP for 77122@debbugs.gnu.org; Wed, 26 Mar 2025 09:00:26 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id F1F6E11401C9; Wed, 26 Mar 2025 09:00:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Wed, 26 Mar 2025 09:00:20 -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:subject:subject:to:to; s=fm3; t=1742994019; x=1743080419; bh=n3vTdityEva+aQqemP95BVBhdHqbZsjS6+0TXrPmBZ4=; b= XS0dHKGN4Dwy0LN/MbS3D3wxrJcIy/hmtbht++qcZqZlzq9vaInxUwTpfHSUgqJ2 j76jd0zbpKZcDzKov7XHrV/Mj2SVtJoLl/Eh1GkTwMcvahUyK9jHxp4S9LceDEKR 4Y0rHJfr5yNY3m7BG2avOXrJH6DUYM+vQEBTnXUei10Ybks//a5+2rUL9wYLjrie h2VuvxLN2n/ERvk2qRQx/xkqvorKO1jeYUYD/s2ZJ8SLKQbYyRE9lcT7n1dYR254 LeTAP7cF1g1IN/csPZRqsVr8VOkSq1dcx3d87Eza5Pn8/SAnTZWaqIsn6GCKI1uY Nc6vsrtHmO9w97L/jTS1LQ== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742994019; x= 1743080419; bh=n3vTdityEva+aQqemP95BVBhdHqbZsjS6+0TXrPmBZ4=; b=s WCSDm1MoHAvbcDVBXz7fli0dKD8c/dQNMPRTFfbYo2QW/wsX6CCCY4DMRC8dhYX6 uxalqEPcD6oKDLoIYwhYQ9TzmI4BUdaa2GKl++/3vgLDSJZ8svNMazfH2u9hp0I/ zJISlkVtRHSQszTqBQ4+yo87tHVpd3U3kkvsQYJPIExNNLDR1vkG9plRYucCIAMN lBNX0/ELD+CRJLDXoTuN6yOIBmgsga4ZabbaoFePnngqPF92IFvnUohuHaSk1i6w Xuaws0H7YD7Ey/AbRdBteuPqvTfc4KhN6aF9O0pUNnD9ONjsDbDnYq88rLz5JccM Kc/qvissIPACFpiFCMScQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduieehheelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddt vdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovh druggvvheqnecuggftrfgrthhtvghrnhepfedvjeeviefffeeukeelveeikeegtddtveei leevgfdvgffhtdfggeeffeegiefgnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhr hiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtohepshhhihhpmhhinhhtshesghhmrghilhdrtghomhdprhgtphhtthho pegurghntgholhesuggrnhgtohhlrdhorhhgpdhrtghpthhtohepvghlihiisehgnhhurd horhhgpdhrtghpthhtohepjeejuddvvdesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Mar 2025 09:00:17 -0400 (EDT) Message-ID: Date: Wed, 26 Mar 2025 15:00:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Ship Mints References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 26/03/2025 13:48, Ship Mints wrote: > On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov > wrote: > > On 25/03/2025 17:42, Ship Mints wrote: > > I just got bitten by project-buffers not reporting all the buffers > > "strictly" related to the project because project.el thinks there > are > > two different projects.  I can't imagine that me and the > colleagues of > > mine that use convenience symlinks are the only ones to see these > kinds > > of inconsistencies.  Just thought I'd leave a concrete example in > this > > thread. > > Thanks for the example. > > > I've turned my advice back on to force truename canonicalization > for the > > time being. > > Does that change really help? > > > It does for unifying project-name and project-root. Do they have corresponding scenarios that cause confusion? > In my testing, what it results in, is showing only the buffers > belonging > to the "canonical" project, both when project-switch-buffer is called > when in it, or when inside a "symlinked" version. Buffers visited from > the "symlinked" project are not suggested in completion anymore. > > When reproducing, try using find-file (C-x C-f) to open the buffers. > > > Yes, indeed, project-buffers also needs some help. We could add a user option for project-buffers specifically, as one approach. > Thanks for the continuing discussion. > > WRT projectile, having only eyeballed the code (I haven't used it), it > seems truename use is not optional.  It looks like projectile-project- > buffer-p is defined in terms of truename https://github.com/bbatsov/ > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > projectile.el#L1775 blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > projectile.el#L1775>, project-root caches the truename (but I see a bug > in the code which doesn't normalize dir on the way in so users likely > get odd results) https://github.com/bbatsov/projectile/ > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385 > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the > file cache is in terms of truename https://github.com/bbatsov/ > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > projectile.el#L1262 blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. I wonder how it affects Projectile's performance over Tramp. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 26 11:52:47 2025 Received: (at 77122) by debbugs.gnu.org; 26 Mar 2025 15:52:47 +0000 Received: from localhost ([127.0.0.1]:43965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txT3e-00063S-QA for submit@debbugs.gnu.org; Wed, 26 Mar 2025 11:52:47 -0400 Received: from mail-vk1-xa36.google.com ([2607:f8b0:4864:20::a36]:43294) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1txT3b-00063C-HN for 77122@debbugs.gnu.org; Wed, 26 Mar 2025 11:52:44 -0400 Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-523fa0df55dso1006244e0c.1 for <77122@debbugs.gnu.org>; Wed, 26 Mar 2025 08:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743004358; x=1743609158; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NWmOQSXsPjmjxo6Wk1+oXgYAzg+mAo3T3fCJBGfnDb8=; b=OrvNqLq+Ac1MYkp5RwsfYcFopviVcsyNvealQBQ1L61wkjqhvxW4DeBWfJP1N5Sm6X L4zcDKwxTlVgLfN6EYKMrkZba6WMm8DCT7It8kVT3oHYqeMjLuZ6Ew1zEX7jCnJoFu1+ rsPpDH3wWs1qkUxuXhekjMKTyywTKx74bezUO5hC/60VGnWqxyQc8FbwB7hbwUJ+Ji+P vOUvwJ9lBaZpaQF+gdnaDP9fbYfB4mtS5pu3VBAuE99Ej74Uj3WSr8XhY2fvBsfr2qDF mbUH13XRC5oKxTNdQTo8sOKuXrbkIomPlx6vwuvPn57HHPtuUd1ZPSlVNRa5mOS0SP3Y AlzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743004358; x=1743609158; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NWmOQSXsPjmjxo6Wk1+oXgYAzg+mAo3T3fCJBGfnDb8=; b=I046OacG35tRk/B7Pu9rEnBpkdJpsdah10nbtU8dBJkkRMZ6XsUtOoezKHMg4vOsfu LM4F2fzwXqUrYT5VzjM9Z5gqsmWwPv4LhWwduhAEdJUvEHOoStMcrZtazP+dm/Xx9n68 FrG+iIA9rRXBzMlNGpvRZsN69zG8zOAyv3T/dgn6tvQo/R2OqFSLkbWhCF5QhIlq0jAj MEewX9lQIE7lfHx+psvXumLjevHYbfUVzKdNByKVgIksnh/NFOIWt0pKYQTs9/rFNKPK kkk/P1RWavMiVy/8W5fhG3kPxP3EtbS2q+fUwN6UcyVzXE9J2K3WUme8vvxnEZ5qIYdo r7Cw== X-Forwarded-Encrypted: i=1; AJvYcCVCpJXrL9yJKRrtfXUN5qGEt7jFkYq81ucBYlYvbiAHPVaKbWi0937cMU5r/6x7i5kPqGwyvg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwBEr93bOs4iaHsHO0B1j9HS1nk8L392PwoH3qeuk0hnhnXU/Rq wWT7gP6qWp16WY1868dWYPEJmsG/yU2xvhVl7f9QmnyUKD9hdABu5OtNQDGgFbWAtIUoDQC+kv4 1Q5kURjA7bAuRKQ1grMUol7Zvac8= X-Gm-Gg: ASbGnctw5xxzcTyVT5BMLxOKOyXdPW0VpazsG5KB2RNXsQ8ZZnArAd4Pu082VykYkWN ROQdCL1JLaHU7fspPCxUZnufVCpGXv0wYwLtm9EtpXle20b1McK8qRS+qb5xV9mgvZh1E+rda8d byzyfYZHsYRMFZkGaPk3FG2RSaRw== X-Google-Smtp-Source: AGHT+IFo5m3I5hFQbj58bx3HyW0E7xfWsR1r8kyKWHtm//BuWoJE7RbZR+tEePP9B2wk0qp/CFL9r2uzM9xUWzJEBJ0= X-Received: by 2002:a05:6122:f86:b0:524:2fe0:61bc with SMTP id 71dfb90a1353d-526005c4e28mr400259e0c.5.1743004357534; Wed, 26 Mar 2025 08:52:37 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> In-Reply-To: From: Ship Mints Date: Wed, 26 Mar 2025 11:52:26 -0400 X-Gm-Features: AQ5f1JpW1Kc7IBS1UilUVm-1pri8XMrDCRxR6FwR9m7n18eMJSKjlCdDmFG2kPA Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Dmitry Gutov Content-Type: multipart/alternative; boundary="00000000000092b069063140d32b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000092b069063140d32b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov wro= te: > On 26/03/2025 13:48, Ship Mints wrote: > > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov > > wrote: > > > > On 25/03/2025 17:42, Ship Mints wrote: > > > I just got bitten by project-buffers not reporting all the buffe= rs > > > "strictly" related to the project because project.el thinks ther= e > > are > > > two different projects. I can't imagine that me and the > > colleagues of > > > mine that use convenience symlinks are the only ones to see thes= e > > kinds > > > of inconsistencies. Just thought I'd leave a concrete example i= n > > this > > > thread. > > > > Thanks for the example. > > > > > I've turned my advice back on to force truename canonicalization > > for the > > > time being. > > > > Does that change really help? > > > > > > It does for unifying project-name and project-root. > > Do they have corresponding scenarios that cause confusion? > > > In my testing, what it results in, is showing only the buffers > > belonging > > to the "canonical" project, both when project-switch-buffer is call= ed > > when in it, or when inside a "symlinked" version. Buffers visited > from > > the "symlinked" project are not suggested in completion anymore. > > > > When reproducing, try using find-file (C-x C-f) to open the buffers= . > > > > > > Yes, indeed, project-buffers also needs some help. > > We could add a user option for project-buffers specifically, as one > approach. > I assume this would be the same option that canonicalizes project-roots so it's all synchronized. > Thanks for the continuing discussion. > > > > WRT projectile, having only eyeballed the code (I haven't used it), it > > seems truename use is not optional. It looks like projectile-project- > > buffer-p is defined in terms of truename https://github.com/bbatsov/ > > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > > projectile.el#L1775 > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > > projectile.el#L1775>, project-root caches the truename (but I see a bug > > in the code which doesn't normalize dir on the way in so users likely > > get odd results) https://github.com/bbatsov/projectile/ > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385 > > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the > > file cache is in terms of truename https://github.com/bbatsov/ > > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > > projectile.el#L1262 > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. > > I wonder how it affects Projectile's performance over Tramp. > No idea. But I can say that I have wrapped a bunch of project.el functions to avoid remote file operations based on a personal user option (some of my users are heavy Trampers, some hosts are slow). But the way I've done it is a blanket inhibition, not project-specific or some other appropriate criteria which would be nicer. Perhaps a .project.eld file with variables akin to dir-locals that project could consult. I haven't had the time to think that through. I've also implemented personal 'consult' project and related buffer-matching functions to handle project root canonicalization. Those functions are not in terms of project-buffers and perhaps should be as they miss out on back-end specializations. I've started a discussion in the consult repo to offer to contribute PRs over there. --00000000000092b069063140d32b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov <dmitry@gutov.dev> wrote:
On 26/03/2025 13:48, Ship Mints wrote:
> On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev
> <mailto:dmitr= y@gutov.dev>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 25/03/2025 17:42, Ship Mints wrote:
>=C2=A0 =C2=A0 =C2=A0 > I just got bitten by project-buffers not repo= rting all the buffers
>=C2=A0 =C2=A0 =C2=A0 > "strictly" related to the project b= ecause project.el=C2=A0thinks there
>=C2=A0 =C2=A0 =C2=A0are
>=C2=A0 =C2=A0 =C2=A0 > two different projects.=C2=A0 I can't ima= gine that me and the
>=C2=A0 =C2=A0 =C2=A0colleagues of
>=C2=A0 =C2=A0 =C2=A0 > mine that use convenience symlinks are the on= ly ones to see these
>=C2=A0 =C2=A0 =C2=A0kinds
>=C2=A0 =C2=A0 =C2=A0 > of inconsistencies.=C2=A0 Just thought I'= d leave a concrete example in
>=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0 > thread.
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the example.
>
>=C2=A0 =C2=A0 =C2=A0 > I've turned my advice back on to force tr= uename=C2=A0canonicalization
>=C2=A0 =C2=A0 =C2=A0for the
>=C2=A0 =C2=A0 =C2=A0 > time being.
>
>=C2=A0 =C2=A0 =C2=A0Does that change really help?
>
>
> It does for unifying project-name and project-root.

Do they have corresponding scenarios that cause confusion?

>=C2=A0 =C2=A0 =C2=A0In my testing, what it results in, is showing only = the buffers
>=C2=A0 =C2=A0 =C2=A0belonging
>=C2=A0 =C2=A0 =C2=A0to the "canonical" project, both when pro= ject-switch-buffer is called
>=C2=A0 =C2=A0 =C2=A0when in it, or when inside a "symlinked" = version. Buffers visited from
>=C2=A0 =C2=A0 =C2=A0the "symlinked" project are not suggested= in completion anymore.
>
>=C2=A0 =C2=A0 =C2=A0When reproducing, try using find-file (C-x C-f) to = open the buffers.
>
>
> Yes, indeed, project-buffers also needs some=C2=A0help.

We could add a user option for project-buffers specifically, as one
approach.

I assume this would be the same option that= canonicalizes project-roots so it's all synchronized.
=
> Thanks for the continuing discussion.
>
> WRT projectile, having only eyeballed the code (I haven't used it)= , it
> seems truename use is not optional.=C2=A0 It looks like projectile-pro= ject-
> buffer-p is defined in terms of truename https://github.com/bbatsov/=
> projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1775 <https://github.com/bbatsov/projec= tile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1775>,=C2=A0project-root caches the truename (but I = see a bug
> in the code which doesn't normalize dir on the way in so users lik= ely
> get odd results) https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385
> <https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>,= the
> file cache is in terms of truename https://github.com/bbatsov/ <= br> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1262 <https://github.com/bbatsov/projec= tile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>.= </>

I wonder how it affects Projectile's performance over Tramp.

No idea.=C2=A0 But I can say that I have wrapped a bunch of project.= el functions to avoid remote file operations based on a personal user optio= n (some of my users are heavy Trampers, some hosts are slow).=C2=A0 But the= way I've done it is a blanket inhibition, not project-specific or some= other appropriate criteria which would be nicer.=C2=A0 Perhaps a .project.= eld file with variables akin to dir-locals that project could consult.=C2= =A0 I haven't had the time to think that through.

I've also implemented personal= 'consult' project and related buffer-matching functions to handle = project root canonicalization.=C2=A0 Those functions are not in terms of pr= oject-buffers and perhaps should be as they miss out on back-end specializa= tions.=C2=A0 I've started a discussion in the consult repo to offer to = contribute PRs over there.
--00000000000092b069063140d32b-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 26 20:28:48 2025 Received: (at 77122) by debbugs.gnu.org; 27 Mar 2025 00:28:48 +0000 Received: from localhost ([127.0.0.1]:45012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txb71-0000Ob-Jy for submit@debbugs.gnu.org; Wed, 26 Mar 2025 20:28:48 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:52270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txb6y-0000O3-JZ for 77122@debbugs.gnu.org; Wed, 26 Mar 2025 20:28:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DLxeHJtxl7qCpvf9KqrgXgbkbX+0mUz0UFQxs5KFGIA=; b=lUzOg4zAZQmGvUejuTjR7q3uZ9 +FrybqdH+jgXy0MgcaPVyik6iu87TP18eBGF/NIByFZM0A/zEdFywrzp+xnfPyxspUvBEgWmjc0jB UOq8nrUESCoJfE0FNSUgvMGoYZxcUkv0ImpHXS6SuHy4StTfp643GAHpZQBN98SBXLWqbIIcOVn1m oUJyDv1oTwvkXLiRaL3ji55/+l7iPzpXfFkEMJ1mpKRQPtMzcfZ75HRGieIAeY9SozEuHz4DFbssS WswZxcluzSRzMBPw76y0Tzw0GbxTdJsQiD/iqXvNfljWgEVv8gylzW3iy+00AfBROml8yNqqM96nB kmagikrA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1txb6W-0049kG-1J; Wed, 26 Mar 2025 20:28:16 -0400 From: Daniel Colascione To: Ship Mints Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks In-Reply-To: References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Wed, 26 Mar 2025 20:28:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ship Mints writes: > On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov w= rote: > >> On 26/03/2025 13:48, Ship Mints wrote: >> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov > > > wrote: >> > >> > On 25/03/2025 17:42, Ship Mints wrote: >> > > I just got bitten by project-buffers not reporting all the buff= ers >> > > "strictly" related to the project because project.el thinks the= re >> > are >> > > two different projects. I can't imagine that me and the >> > colleagues of >> > > mine that use convenience symlinks are the only ones to see the= se >> > kinds >> > > of inconsistencies. Just thought I'd leave a concrete example = in >> > this >> > > thread. >> > >> > Thanks for the example. >> > >> > > I've turned my advice back on to force truename canonicalization >> > for the >> > > time being. >> > >> > Does that change really help? >> > >> > >> > It does for unifying project-name and project-root. >> >> Do they have corresponding scenarios that cause confusion? >> >> > In my testing, what it results in, is showing only the buffers >> > belonging >> > to the "canonical" project, both when project-switch-buffer is cal= led >> > when in it, or when inside a "symlinked" version. Buffers visited >> from >> > the "symlinked" project are not suggested in completion anymore. >> > >> > When reproducing, try using find-file (C-x C-f) to open the buffer= s. >> > >> > >> > Yes, indeed, project-buffers also needs some help. >> >> We could add a user option for project-buffers specifically, as one >> approach. >> > > I assume this would be the same option that canonicalizes project-roots so > it's all synchronized. > >> Thanks for the continuing discussion. >> > >> > WRT projectile, having only eyeballed the code (I haven't used it), it >> > seems truename use is not optional. It looks like projectile-project- >> > buffer-p is defined in terms of truename https://github.com/bbatsov/ >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> > projectile.el#L1775 > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> > projectile.el#L1775>, project-root caches the truename (but I see a bug >> > in the code which doesn't normalize dir on the way in so users likely >> > get odd results) https://github.com/bbatsov/projectile/ >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385 >> > > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the >> > file cache is in terms of truename https://github.com/bbatsov/ >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> > projectile.el#L1262 > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. >> >> I wonder how it affects Projectile's performance over Tramp. >> > > No idea. But I can say that I have wrapped a bunch of project.el functio= ns > to avoid remote file operations based on a personal user option (some of = my > users are heavy Trampers, some hosts are slow). But the way I've done it > is a blanket inhibition, not project-specific or some other appropriate > criteria which would be nicer. Perhaps a .project.eld file with variables > akin to dir-locals that project could consult. I haven't had the time to > think that through. > > I've also implemented personal 'consult' project and related > buffer-matching functions to handle project root canonicalization. Those > functions are not in terms of project-buffers and perhaps should be as th= ey > miss out on back-end specializations. I've started a discussion in the > consult repo to offer to contribute PRs over there. I'm not unsympathetic to the need, but I think we need to understand whether your request is project-specific or not. I realized that the Emacs features I wanted already exist. In particular, find-file-visit-truename should excise symlinks from every visited path, and directory-abbrev-alist should be able to alias one directory to another. Can you add your symlink directory to directory-abbrev-alist and have it rewritten to the truename? From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 27 10:41:46 2025 Received: (at 77122) by debbugs.gnu.org; 27 Mar 2025 14:41:46 +0000 Received: from localhost ([127.0.0.1]:50740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txoQR-0001wf-RE for submit@debbugs.gnu.org; Thu, 27 Mar 2025 10:41:45 -0400 Received: from mail-vk1-xa35.google.com ([2607:f8b0:4864:20::a35]:47403) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1txoQO-0001vZ-3E for 77122@debbugs.gnu.org; Thu, 27 Mar 2025 10:41:41 -0400 Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-51eb1a714bfso1063416e0c.3 for <77122@debbugs.gnu.org>; Thu, 27 Mar 2025 07:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743086494; x=1743691294; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UmC506MFUlPRFYSbyFdty592n0p3mbi4qiJGk0vCu/E=; b=RlWRVoQHx4ZISsCclVB6EdnPk4hAWhDR3V+0dJHhiK4gDFOIHxB6VnHBDnNdOUXhBC 4GicEL7cCwZWVHnEai7o80ap8o/2Hbmo2OWV7K1WnC/5bVpR1yTo0gu/f8GFSWHgFSz8 pRoOgsgOe2raKrmli4jbmTQQ8VGypwmPjelHSMBKScJYJrsx/OjQyf+lRH6NYOm2GRA1 stEwEJNR4SZjbK4SicUUR+Tg0mpibHXscXZQgDEjtnJbXP/HRlI96fGFY4TODzeacY62 Tgi42aShSEsmG3VelWrJQR+X9LfkgFyNbWNArXjwYkeczi7Bc83s7L3aWQ9DbHf6h/V3 b4AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743086494; x=1743691294; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UmC506MFUlPRFYSbyFdty592n0p3mbi4qiJGk0vCu/E=; b=aWSVGuStQ/8svAWCo/qWlxMI1JgylmcOwXwNIF6RJmym65L4Eo8lIwy2PXUbhp4H/R f/lP+F6qPe03yr8xHQdS/Rra2uH6aIxcd1y6K3g8lzLENuBaEKA48spoT7TAX8VF76nq WYsAGzg4NCzNp1A9+MA5U40lVAYtx6sdjgRgUkLG9mmN51/LT8PKiGveV4NNtxSxuME8 I+uS907YPy9bIF70fw1Q4kjG70PeciZ38v9jtud7ZggUWX7bEH9/4rnEfadzylCxkfoP 5qychx8XAcFEH8RDLvzJ1sQMB0IENELgSGsMfgp9Q1LV4NCSDYD6CVskRP/DD6ek0hnX VBOA== X-Forwarded-Encrypted: i=1; AJvYcCUiK2Odeq1z+eOrtGFAZQp7R7LsIkgewpgoOFw6P7yaPDV8lcGokOc9N4jJ9W6EzC7AbWeotg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyTkB+44nPS25V8q0xAla32ZQez5wZOSYoOGNk/TKpzwMbBF1/A UhelBaG9SJUFYKE9HBgJfaDKi3Ma7iNv4pycdq44muGtO8Yjxi8SzTWiqd6lTtm5CxvGGxRcB3b hld1Di4qgoiNBzDwohZPDkZaZdhs= X-Gm-Gg: ASbGncusLt9MlJiaOgbGoJuJgvSVBnHwWybUCfPsaaQofLeEQUm07rEg1TxSFixUvGZ BVGtAztqVlWrmP0xD18qbYQAeTfITPSJ6UKghBwHG0ukIcDMM70yjQcFfhNpQx8KFV3t6BnKXR6 P7oQfjTiqFXkK5Jjiou4f8DLeSDw== X-Google-Smtp-Source: AGHT+IFykdEd3+LwoC5Ck00XlXrh/0mvkJFI7Le+5cNGn3nTCND+HH77EjLWEUAGbsynQcxkI78Mmlhrqgqu6dvoBG0= X-Received: by 2002:a05:6122:2229:b0:51f:3eee:89e7 with SMTP id 71dfb90a1353d-52600aedec5mr2819313e0c.11.1743086494044; Thu, 27 Mar 2025 07:41:34 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> In-Reply-To: From: Ship Mints Date: Thu, 27 Mar 2025 10:41:22 -0400 X-Gm-Features: AQ5f1JpdcLWf9zh-KCWlXYRlkGxHmbGjl8fraEkArcBo0ecaeVZ0pYfrQp-OwAo Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000004a5f06063153f39d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000004a5f06063153f39d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2025 at 8:28=E2=80=AFPM Daniel Colascione wrote: > Ship Mints writes: > > > On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov = wrote: > > > >> On 26/03/2025 13:48, Ship Mints wrote: > >> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov >> > > wrote: > >> > > >> > On 25/03/2025 17:42, Ship Mints wrote: > >> > > I just got bitten by project-buffers not reporting all the > buffers > >> > > "strictly" related to the project because project.el thinks > there > >> > are > >> > > two different projects. I can't imagine that me and the > >> > colleagues of > >> > > mine that use convenience symlinks are the only ones to see > these > >> > kinds > >> > > of inconsistencies. Just thought I'd leave a concrete exampl= e > in > >> > this > >> > > thread. > >> > > >> > Thanks for the example. > >> > > >> > > I've turned my advice back on to force truename > canonicalization > >> > for the > >> > > time being. > >> > > >> > Does that change really help? > >> > > >> > > >> > It does for unifying project-name and project-root. > >> > >> Do they have corresponding scenarios that cause confusion? > >> > >> > In my testing, what it results in, is showing only the buffers > >> > belonging > >> > to the "canonical" project, both when project-switch-buffer is > called > >> > when in it, or when inside a "symlinked" version. Buffers visite= d > >> from > >> > the "symlinked" project are not suggested in completion anymore. > >> > > >> > When reproducing, try using find-file (C-x C-f) to open the > buffers. > >> > > >> > > >> > Yes, indeed, project-buffers also needs some help. > >> > >> We could add a user option for project-buffers specifically, as one > >> approach. > >> > > > > I assume this would be the same option that canonicalizes project-roots > so > > it's all synchronized. > > > >> Thanks for the continuing discussion. > >> > > >> > WRT projectile, having only eyeballed the code (I haven't used it), = it > >> > seems truename use is not optional. It looks like projectile-projec= t- > >> > buffer-p is defined in terms of truename https://github.com/bbatsov/ > >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> > projectile.el#L1775 >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> > projectile.el#L1775>, project-root caches the truename (but I see a > bug > >> > in the code which doesn't normalize dir on the way in so users likel= y > >> > get odd results) https://github.com/bbatsov/projectile/ > >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385 > >> > >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, > the > >> > file cache is in terms of truename https://github.com/bbatsov/ > >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> > projectile.el#L1262 >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. > > >> > >> I wonder how it affects Projectile's performance over Tramp. > >> > > > > No idea. But I can say that I have wrapped a bunch of project.el > functions > > to avoid remote file operations based on a personal user option (some o= f > my > > users are heavy Trampers, some hosts are slow). But the way I've done = it > > is a blanket inhibition, not project-specific or some other appropriate > > criteria which would be nicer. Perhaps a .project.eld file with > variables > > akin to dir-locals that project could consult. I haven't had the time = to > > think that through. > > > > I've also implemented personal 'consult' project and related > > buffer-matching functions to handle project root canonicalization. Tho= se > > functions are not in terms of project-buffers and perhaps should be as > they > > miss out on back-end specializations. I've started a discussion in the > > consult repo to offer to contribute PRs over there. > > I'm not unsympathetic to the need, but I think we need to understand > whether your request is project-specific or not. I realized that the > Emacs features I wanted already exist. In particular, > find-file-visit-truename should excise symlinks from every visited path, > and directory-abbrev-alist should be able to alias one directory > to another. Can you add your symlink directory to > directory-abbrev-alist and have it rewritten to the truename? > Of course people can always hack around these cases manually. To me, what makes project.el special is that it has an implicit promise to organize buffers related to a project. That the existing implementation depends on the ambient directory from which a file buffer was created to determine what's related has become a "leaky abstraction" where symlinks to projects are involved. The documentation in project.el kind of alludes to this limitation in an implied way for transient projects. It is silent on directory assumptions for vc projects, instead delegating to the vc back end. It would benefit the whole community to offer a resolution to let project.el fulfil its buffer organization mission independent of convenience names and that doesn't rely on management of directory-abbrev-alist (eek). --0000000000004a5f06063153f39d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Mar 26, 2025 at 8:28=E2=80=AFPM Daniel Colascione <dancol@dancol.org> wrote:
=
Ship Mints <shipmints@gmail.com> writes:

> On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov <dmitry@gutov.dev> wrote: >
>> On 26/03/2025 13:48, Ship Mints wrote:
>> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev
>> > <mailto:dmitry@gutov.dev>> wrote:
>> >
>> >=C2=A0 =C2=A0 =C2=A0On 25/03/2025 17:42, Ship Mints wrote:
>> >=C2=A0 =C2=A0 =C2=A0 > I just got bitten by project-buffers= not reporting all the buffers
>> >=C2=A0 =C2=A0 =C2=A0 > "strictly" related to the = project because project.el thinks there
>> >=C2=A0 =C2=A0 =C2=A0are
>> >=C2=A0 =C2=A0 =C2=A0 > two different projects.=C2=A0 I can&= #39;t imagine that me and the
>> >=C2=A0 =C2=A0 =C2=A0colleagues of
>> >=C2=A0 =C2=A0 =C2=A0 > mine that use convenience symlinks a= re the only ones to see these
>> >=C2=A0 =C2=A0 =C2=A0kinds
>> >=C2=A0 =C2=A0 =C2=A0 > of inconsistencies.=C2=A0 Just thoug= ht I'd leave a concrete example in
>> >=C2=A0 =C2=A0 =C2=A0this
>> >=C2=A0 =C2=A0 =C2=A0 > thread.
>> >
>> >=C2=A0 =C2=A0 =C2=A0Thanks for the example.
>> >
>> >=C2=A0 =C2=A0 =C2=A0 > I've turned my advice back on to= force truename canonicalization
>> >=C2=A0 =C2=A0 =C2=A0for the
>> >=C2=A0 =C2=A0 =C2=A0 > time being.
>> >
>> >=C2=A0 =C2=A0 =C2=A0Does that change really help?
>> >
>> >
>> > It does for unifying project-name and project-root.
>>
>> Do they have corresponding scenarios that cause confusion?
>>
>> >=C2=A0 =C2=A0 =C2=A0In my testing, what it results in, is show= ing only the buffers
>> >=C2=A0 =C2=A0 =C2=A0belonging
>> >=C2=A0 =C2=A0 =C2=A0to the "canonical" project, both= when project-switch-buffer is called
>> >=C2=A0 =C2=A0 =C2=A0when in it, or when inside a "symlink= ed" version. Buffers visited
>> from
>> >=C2=A0 =C2=A0 =C2=A0the "symlinked" project are not = suggested in completion anymore.
>> >
>> >=C2=A0 =C2=A0 =C2=A0When reproducing, try using find-file (C-x= C-f) to open the buffers.
>> >
>> >
>> > Yes, indeed, project-buffers also needs some help.
>>
>> We could add a user option for project-buffers specifically, as on= e
>> approach.
>>
>
> I assume this would be the same option that canonicalizes project-root= s so
> it's all synchronized.
>
>> Thanks for the continuing discussion.
>> >
>> > WRT projectile, having only eyeballed the code (I haven't= used it), it
>> > seems truename use is not optional.=C2=A0 It looks like proje= ctile-project-
>> > buffer-p is defined in terms of truename https://github.com= /bbatsov/
>> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1775 <https://github.com/bbats= ov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1775>, project-root caches the truename (bu= t I see a bug
>> > in the code which doesn't normalize dir on the way in so = users likely
>> > get odd results) https://github.com/bbatsov/proj= ectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L= 1385
>> > <https://github.com/bbatsov/projectile/ >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L= 1385>, the
>> > file cache is in terms of truename https://github.com/bbats= ov/
>> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> > projectile.el#L1262 <https://github.com/bbats= ov/projectile/
>> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L= 1262>. </>
>>
>> I wonder how it affects Projectile's performance over Tramp. >>
>
> No idea.=C2=A0 But I can say that I have wrapped a bunch of project.el= functions
> to avoid remote file operations based on a personal user option (some = of my
> users are heavy Trampers, some hosts are slow).=C2=A0 But the way I= 9;ve done it
> is a blanket inhibition, not project-specific or some other appropriat= e
> criteria which would be nicer.=C2=A0 Perhaps a .project.eld file with = variables
> akin to dir-locals that project could consult.=C2=A0 I haven't had= the time to
> think that through.
>
> I've also implemented personal 'consult' project and relat= ed
> buffer-matching functions to handle project root canonicalization.=C2= =A0 Those
> functions are not in terms of project-buffers and perhaps should be as= they
> miss out on back-end specializations.=C2=A0 I've started a discuss= ion in the
> consult repo to offer to contribute PRs over there.

I'm not unsympathetic to the need, but I think we need to understand whether your request is project-specific or not.=C2=A0 I realized that the<= br> Emacs features I wanted already exist.=C2=A0 In particular,
find-file-visit-truename should excise symlinks from every visited path, and directory-abbrev-alist should be able to alias one directory
to another.=C2=A0 Can you add your symlink directory to
directory-abbrev-alist and have it rewritten to the truename?

Of course people can always hack around these cases manually.

To me, what makes proj= ect.el special is that it has an implicit promise to organize buffers relat= ed to a project.=C2=A0 That the=C2=A0existing implementation depends on the= ambient directory from which a file buffer was created to determine what&#= 39;s related has become a "leaky abstraction" where symlinks to p= rojects are involved.=C2=A0 The documentation in project.el kind of alludes= to this limitation in an implied way for transient projects.=C2=A0 It is s= ilent on directory assumptions for vc projects,=C2=A0instead delegating to = the vc back end.

It would benefit the whole community to offer a resolution to let proje= ct.el fulfil its buffer organization mission independent of convenience nam= es and that doesn't rely on management of directory-abbrev-alist (eek).=
--0000000000004a5f06063153f39d-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 27 11:22:37 2025 Received: (at 77122) by debbugs.gnu.org; 27 Mar 2025 15:22:38 +0000 Received: from localhost ([127.0.0.1]:50892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txp40-0000Zg-LT for submit@debbugs.gnu.org; Thu, 27 Mar 2025 11:22:37 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:53648) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txp3w-0000Ym-H6 for 77122@debbugs.gnu.org; Thu, 27 Mar 2025 11:22:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+pxushkRCxmprG2R68EF9Vr9wcDJrjvkCA4yqAK8gfY=; b=N9D6g0Ak7suzTPSLpL6mdTu62L KJhzJr8Gt0amYoe37SsL72oZ42qAZD+sjzNnCwRefTB4ldFYkvX9nXPK0NiKbtnQkbPObB6W06YeE FGN+nMuvaLnjcwRHH4cKKij1lE2VYvAk1kZjKolV8c48UnzOwr4fraBHjTBRCkGpfzxBgrZ+npvW5 DKOgMHypBucUqMqXcWMCEf9MG8fr4c9trlO79gHlBb33TqnRMNT48xX7uE6KZS5LxCcI4QXJ407fT Oa5YFhIoM1O6YzH5w9Dwow+KFPoCwnr9ZWwo7ASWf6wwf/L+wTjjFLgrcynea7RN5xNWwOu4yIp27 vV8C4ttg==; Received: from [2600:1006:b114:5ef0:0:7:d2d3:2501] (port=46636 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1txp3T-004DnS-1r; Thu, 27 Mar 2025 11:22:03 -0400 Date: Thu, 27 Mar 2025 11:22:22 -0400 From: Daniel Colascione To: Ship Mints Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks User-Agent: K-9 Mail for Android In-Reply-To: References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> Message-ID: <9FA4B7B7-2DAE-4C5B-A7B0-054E769FFE13@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On March 27, 2025 10:41:22 AM EDT, Ship Mints wrot= e: >On Wed, Mar 26, 2025 at 8:28=E2=80=AFPM Daniel Colascione wrote: > >> Ship Mints writes: >> >> > On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov wrote: >> > >> >> On 26/03/2025 13:48, Ship Mints wrote: >> >> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov > >> > > wrote: >> >> > >> >> > On 25/03/2025 17:42, Ship Mints wrote: >> >> > > I just got bitten by project-buffers not reporting all the >> buffers >> >> > > "strictly" related to the project because project=2Eel thin= ks >> there >> >> > are >> >> > > two different projects=2E I can't imagine that me and the >> >> > colleagues of >> >> > > mine that use convenience symlinks are the only ones to see >> these >> >> > kinds >> >> > > of inconsistencies=2E Just thought I'd leave a concrete ex= ample >> in >> >> > this >> >> > > thread=2E >> >> > >> >> > Thanks for the example=2E >> >> > >> >> > > I've turned my advice back on to force truename >> canonicalization >> >> > for the >> >> > > time being=2E >> >> > >> >> > Does that change really help? >> >> > >> >> > >> >> > It does for unifying project-name and project-root=2E >> >> >> >> Do they have corresponding scenarios that cause confusion? >> >> >> >> > In my testing, what it results in, is showing only the buffers >> >> > belonging >> >> > to the "canonical" project, both when project-switch-buffer is >> called >> >> > when in it, or when inside a "symlinked" version=2E Buffers vi= sited >> >> from >> >> > the "symlinked" project are not suggested in completion anymor= e=2E >> >> > >> >> > When reproducing, try using find-file (C-x C-f) to open the >> buffers=2E >> >> > >> >> > >> >> > Yes, indeed, project-buffers also needs some help=2E >> >> >> >> We could add a user option for project-buffers specifically, as one >> >> approach=2E >> >> >> > >> > I assume this would be the same option that canonicalizes project-roo= ts >> so >> > it's all synchronized=2E >> > >> >> Thanks for the continuing discussion=2E >> >> > >> >> > WRT projectile, having only eyeballed the code (I haven't used it)= , it >> >> > seems truename use is not optional=2E It looks like projectile-pr= oject- >> >> > buffer-p is defined in terms of truename https://github=2Ecom/bbat= sov/ >> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> >> > projectile=2Eel#L1775 > >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> >> > projectile=2Eel#L1775>, project-root caches the truename (but I se= e a >> bug >> >> > in the code which doesn't normalize dir on the way in so users lik= ely >> >> > get odd results) https://github=2Ecom/bbatsov/projectile/ >> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile=2Eel#L138= 5 >> >> > > >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile=2Eel#L138= 5>, >> the >> >> > file cache is in terms of truename https://github=2Ecom/bbatsov/ >> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ >> >> > projectile=2Eel#L1262 > >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile=2Eel#L126= 2>=2E >> >> >> >> >> I wonder how it affects Projectile's performance over Tramp=2E >> >> >> > >> > No idea=2E But I can say that I have wrapped a bunch of project=2Eel >> functions >> > to avoid remote file operations based on a personal user option (some= of >> my >> > users are heavy Trampers, some hosts are slow)=2E But the way I've d= one it >> > is a blanket inhibition, not project-specific or some other appropria= te >> > criteria which would be nicer=2E Perhaps a =2Eproject=2Eeld file wit= h >> variables >> > akin to dir-locals that project could consult=2E I haven't had the t= ime to >> > think that through=2E >> > >> > I've also implemented personal 'consult' project and related >> > buffer-matching functions to handle project root canonicalization=2E = Those >> > functions are not in terms of project-buffers and perhaps should be a= s >> they >> > miss out on back-end specializations=2E I've started a discussion in= the >> > consult repo to offer to contribute PRs over there=2E >> >> I'm not unsympathetic to the need, but I think we need to understand >> whether your request is project-specific or not=2E I realized that the >> Emacs features I wanted already exist=2E In particular, >> find-file-visit-truename should excise symlinks from every visited path= , >> and directory-abbrev-alist should be able to alias one directory >> to another=2E Can you add your symlink directory to >> directory-abbrev-alist and have it rewritten to the truename? >> > >Of course people can always hack around these cases manually=2E > >To me, what makes project=2Eel special is that it has an implicit promise= to >organize buffers related to a project=2E That the existing implementatio= n >depends on the ambient directory from which a file buffer was created to >determine what's related has become a "leaky abstraction" where symlinks = to >projects are involved=2E The documentation in project=2Eel kind of allud= es to >this limitation in an implied way for transient projects=2E It is silent= on >directory assumptions for vc projects, instead delegating to the vc back >end=2E > >It would benefit the whole community to offer a resolution to let >project=2Eel fulfil its buffer organization mission independent of >convenience names and that doesn't rely on management of >directory-abbrev-alist (eek)=2E I hear you, but I'm not sure the situation is so clear cut=2E Of course we= want a single project in the user's mind to map to one process object on t= he Emacs heap: there's just genuine diversity in opinions of what counts as= "the same" and I think project is the wrong level of abstraction for expre= ssing your desired unification=2E We already have a way for the use to expr= ess a preference that the fully resolved name of a file be considered its i= dentity, and we already have a mechanism through which the user can inform = Emacs of the canonical version of an ambiguous path=2E Maybe we can improve the UX=2E When we find ourselves with two project obj= ects (say A and B) that refer to the same true path, we can ask the user to= choose between making A canonical, making B canonical, and rejecting the u= nification --- then remember that choice in the existing mechanism=2E That'= ll fix the non-project path ambiguity problems too=2E From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 27 12:04:47 2025 Received: (at 77122) by debbugs.gnu.org; 27 Mar 2025 16:04:48 +0000 Received: from localhost ([127.0.0.1]:51009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txpin-0007eh-OH for submit@debbugs.gnu.org; Thu, 27 Mar 2025 12:04:47 -0400 Received: from mail-vk1-xa30.google.com ([2607:f8b0:4864:20::a30]:58492) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1txpil-0007dT-54 for 77122@debbugs.gnu.org; Thu, 27 Mar 2025 12:04:44 -0400 Received: by mail-vk1-xa30.google.com with SMTP id 71dfb90a1353d-5240317b3e0so456815e0c.0 for <77122@debbugs.gnu.org>; Thu, 27 Mar 2025 09:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743091477; x=1743696277; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+3CDeyIKZcjmqNguYRqwGgwvLYt1FaWtqRtRsLjib2w=; b=f5jGtiC6cjaiPT6RfpL7Vm57bTpMPQUSjhHn1RqWDsaVhd+eJeEjbGprAMeGoRXEd0 zjtXNuHwcsouV0riPVmYwj3rULRInVUaVpoaOv78kuTqZWlAsMtPTokeSqzk6xapASoD YtWhzq3mwG3tvbYskTtZScAdd+pJISlZ+dp8E0BqSyjci3HQ6vv0TuzjTKfrh+tTaYGU SvROU3H0uRcyu84g3zrbfJx83DCFCkds+KQC1QUc7D3P2qd6S6OY4UCbSfzq2aGANM63 O+KJ0nVvsZngVM5ECqOPdMo0BIaA6u7NLLqEeHKHagBUEy/HxZ78JSyWc8OgqZ5dBsxs PxvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743091477; x=1743696277; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+3CDeyIKZcjmqNguYRqwGgwvLYt1FaWtqRtRsLjib2w=; b=EU8qGxFOR6Lj4oKAhzAmC/FAEogoebR6B8O8VB/pQ8U4X7MAWebP+3jOnxxPK9zgew yT+zgwAgmwg8Wr7wsu2th853sid71HW/3rRmaoo72LtZEMcP2ZUWhH+fJCk11aN1MTZg 8Z/8Zbi9yXHrXQBtuJjV8UZIIUSnZ2yhyVLOUtJrzm46duw+o0c3aTN/QezQCCLBMLzi 0oQMhVu2+dCg5DYTYB/9Kr+MdDrKoH+xnnt+7RlifgmcaXM5Kg7y62rioLsh1BSIcR5F C3s5grA0t/vNfBxPQatB1jrYLFaaVzG7143stx9xRnXtRAVCg3BEPGbTciImh6a2vyMF 2UAA== X-Forwarded-Encrypted: i=1; AJvYcCWFJZ3njIXKyfbc11MQaogs0usIp5TUwUA4tiMVH5Ag1Qvm1/Nr8T0X7alzj7XwVfmoj3PxDg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwVHSMSJrxNw7BcekXdHZx5+W4znKfLwnXNB+4q78cHFbHQ7+7r 3qAuNrUjEIwoYDY8enQsT86+EnWgv0Oj8pLwTAM9Nw2qB6TxKHyT3qpnhFWMfM1zo4TJFdyaliO DErhql5bndRnq3fpfG6OgZUq0L1s= X-Gm-Gg: ASbGncvzIk/pT1ZI7F5TY0A0iIvcDMpnQkVqdXk2nriYoONOV5ANQoxJlxBoKJdlyzb HX2T/+NM+/qzKsvxLVlLm2+1X+kR7EMJeiZxsfGqEqaVkWm1K60nST7VZ4hsgKaywGG1ez9JxSM aI3nnOU9qq2iqFUkTfPsy5mFs/iEbDoITk3go2 X-Google-Smtp-Source: AGHT+IEjxvp9/A89jntlq2EZ7FT6AUMthmVIWwSl7SfDYYKH2qE5kgTMtK24VYDyrP7Osso/vg59+K5sDy4Ue0aC2lU= X-Received: by 2002:a05:6122:400c:b0:520:3536:feb5 with SMTP id 71dfb90a1353d-52600b0d969mr3783054e0c.11.1743091476908; Thu, 27 Mar 2025 09:04:36 -0700 (PDT) MIME-Version: 1.0 References: <864izifunt.fsf@gnu.org> <99a063ba-59b2-4875-a05e-3d0360f99a74@gutov.dev> <0d3cddcd-8f4c-4a4a-9b3f-18a539f71b0f@gutov.dev> <9FA4B7B7-2DAE-4C5B-A7B0-054E769FFE13@dancol.org> In-Reply-To: <9FA4B7B7-2DAE-4C5B-A7B0-054E769FFE13@dancol.org> From: Ship Mints Date: Thu, 27 Mar 2025 12:04:25 -0400 X-Gm-Features: AQ5f1JqWga7HCLdAIY5tx_2x67la4Tzb8vmKJ1w8-1l5diaXz_7MnnbvAcrMoD4 Message-ID: Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks To: Daniel Colascione Content-Type: multipart/alternative; boundary="0000000000004ad4c60631551c73" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77122 Cc: 77122@debbugs.gnu.org, Dmitry Gutov , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000004ad4c60631551c73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2025 at 11:22=E2=80=AFAM Daniel Colascione wrote: > > > On March 27, 2025 10:41:22 AM EDT, Ship Mints wrote= : > >On Wed, Mar 26, 2025 at 8:28=E2=80=AFPM Daniel Colascione > wrote: > > > >> Ship Mints writes: > >> > >> > On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov > wrote: > >> > > >> >> On 26/03/2025 13:48, Ship Mints wrote: > >> >> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Gutov >> >> > > wrote: > >> >> > > >> >> > On 25/03/2025 17:42, Ship Mints wrote: > >> >> > > I just got bitten by project-buffers not reporting all the > >> buffers > >> >> > > "strictly" related to the project because project.el think= s > >> there > >> >> > are > >> >> > > two different projects. I can't imagine that me and the > >> >> > colleagues of > >> >> > > mine that use convenience symlinks are the only ones to se= e > >> these > >> >> > kinds > >> >> > > of inconsistencies. Just thought I'd leave a concrete > example > >> in > >> >> > this > >> >> > > thread. > >> >> > > >> >> > Thanks for the example. > >> >> > > >> >> > > I've turned my advice back on to force truename > >> canonicalization > >> >> > for the > >> >> > > time being. > >> >> > > >> >> > Does that change really help? > >> >> > > >> >> > > >> >> > It does for unifying project-name and project-root. > >> >> > >> >> Do they have corresponding scenarios that cause confusion? > >> >> > >> >> > In my testing, what it results in, is showing only the buffer= s > >> >> > belonging > >> >> > to the "canonical" project, both when project-switch-buffer i= s > >> called > >> >> > when in it, or when inside a "symlinked" version. Buffers > visited > >> >> from > >> >> > the "symlinked" project are not suggested in completion > anymore. > >> >> > > >> >> > When reproducing, try using find-file (C-x C-f) to open the > >> buffers. > >> >> > > >> >> > > >> >> > Yes, indeed, project-buffers also needs some help. > >> >> > >> >> We could add a user option for project-buffers specifically, as one > >> >> approach. > >> >> > >> > > >> > I assume this would be the same option that canonicalizes > project-roots > >> so > >> > it's all synchronized. > >> > > >> >> Thanks for the continuing discussion. > >> >> > > >> >> > WRT projectile, having only eyeballed the code (I haven't used > it), it > >> >> > seems truename use is not optional. It looks like > projectile-project- > >> >> > buffer-p is defined in terms of truename > https://github.com/bbatsov/ > >> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> >> > projectile.el#L1775 >> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> >> > projectile.el#L1775>, project-root caches the truename (but I see= a > >> bug > >> >> > in the code which doesn't normalize dir on the way in so users > likely > >> >> > get odd results) https://github.com/bbatsov/projectile/ > >> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385 > >> >> > >> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385= >, > >> the > >> >> > file cache is in terms of truename https://github.com/bbatsov/ > >> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > >> >> > projectile.el#L1262 >> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262= >. > >> > >> >> > >> >> I wonder how it affects Projectile's performance over Tramp. > >> >> > >> > > >> > No idea. But I can say that I have wrapped a bunch of project.el > >> functions > >> > to avoid remote file operations based on a personal user option (som= e > of > >> my > >> > users are heavy Trampers, some hosts are slow). But the way I've > done it > >> > is a blanket inhibition, not project-specific or some other > appropriate > >> > criteria which would be nicer. Perhaps a .project.eld file with > >> variables > >> > akin to dir-locals that project could consult. I haven't had the > time to > >> > think that through. > >> > > >> > I've also implemented personal 'consult' project and related > >> > buffer-matching functions to handle project root canonicalization. > Those > >> > functions are not in terms of project-buffers and perhaps should be = as > >> they > >> > miss out on back-end specializations. I've started a discussion in > the > >> > consult repo to offer to contribute PRs over there. > >> > >> I'm not unsympathetic to the need, but I think we need to understand > >> whether your request is project-specific or not. I realized that the > >> Emacs features I wanted already exist. In particular, > >> find-file-visit-truename should excise symlinks from every visited pat= h, > >> and directory-abbrev-alist should be able to alias one directory > >> to another. Can you add your symlink directory to > >> directory-abbrev-alist and have it rewritten to the truename? > >> > > > >Of course people can always hack around these cases manually. > > > >To me, what makes project.el special is that it has an implicit promise = to > >organize buffers related to a project. That the existing implementation > >depends on the ambient directory from which a file buffer was created to > >determine what's related has become a "leaky abstraction" where symlinks > to > >projects are involved. The documentation in project.el kind of alludes = to > >this limitation in an implied way for transient projects. It is silent = on > >directory assumptions for vc projects, instead delegating to the vc back > >end. > > > >It would benefit the whole community to offer a resolution to let > >project.el fulfil its buffer organization mission independent of > >convenience names and that doesn't rely on management of > >directory-abbrev-alist (eek). > > > I hear you, but I'm not sure the situation is so clear cut. Of course we > want a single project in the user's mind to map to one process object on > the Emacs heap: there's just genuine diversity in opinions of what counts > as "the same" and I think project is the wrong level of abstraction for > expressing your desired unification. We already have a way for the use to > express a preference that the fully resolved name of a file be considered > its identity, and we already have a mechanism through which the user can > inform Emacs of the canonical version of an ambiguous path. > > Maybe we can improve the UX. When we find ourselves with two project > objects (say A and B) that refer to the same true path, we can ask the us= er > to choose between making A canonical, making B canonical, and rejecting t= he > unification --- then remember that choice in the existing mechanism. > That'll fix the non-project path ambiguity problems too. I don't think it matters to me which A or B (or C or D) becomes the "master" but I'd still prefer the master to be rooted in the true path. The one that gets recorded in projects.eld, I think should be the master and if we have a user option where the true name always becomes master, that's cool. If we're willing to prompt, then we'd be willing to have a user option to default to a selection and not prompt. That would be fine with me. --0000000000004ad4c60631551c73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Mar 27, 2025 at 11:22=E2=80=AFAM Daniel Colascione <dancol@dancol.org> wrote:


On March 27, 2025 10:41:22 AM EDT, Ship Mints <shipmints@gmail.com> wrote:
>On Wed, Mar 26, 2025 at 8:28=E2=80=AFPM Daniel Colascione <dancol@dancol.org> w= rote:
>
>> Ship Mints <shipmints@gmail.com> writes:
>>
>> > On Wed, Mar 26, 2025 at 9:00=E2=80=AFAM Dmitry Gutov <dmitry@gutov.dev> = wrote:
>> >
>> >> On 26/03/2025 13:48, Ship Mints wrote:
>> >> > On Tue, Mar 25, 2025 at 11:11=E2=80=AFPM Dmitry Guto= v <dmitry@gutov.de= v
>> >> > <mailto:dmitry@gutov.dev>> wrote:
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0On 25/03/2025 17:42, Ship Mints w= rote:
>> >> >=C2=A0 =C2=A0 =C2=A0 > I just got bitten by projec= t-buffers not reporting all the
>> buffers
>> >> >=C2=A0 =C2=A0 =C2=A0 > "strictly" relate= d to the project because project.el thinks
>> there
>> >> >=C2=A0 =C2=A0 =C2=A0are
>> >> >=C2=A0 =C2=A0 =C2=A0 > two different projects.=C2= =A0 I can't imagine that me and the
>> >> >=C2=A0 =C2=A0 =C2=A0colleagues of
>> >> >=C2=A0 =C2=A0 =C2=A0 > mine that use convenience s= ymlinks are the only ones to see
>> these
>> >> >=C2=A0 =C2=A0 =C2=A0kinds
>> >> >=C2=A0 =C2=A0 =C2=A0 > of inconsistencies.=C2=A0 J= ust thought I'd leave a concrete example
>> in
>> >> >=C2=A0 =C2=A0 =C2=A0this
>> >> >=C2=A0 =C2=A0 =C2=A0 > thread.
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0Thanks for the example.
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0 > I've turned my advice b= ack on to force truename
>> canonicalization
>> >> >=C2=A0 =C2=A0 =C2=A0for the
>> >> >=C2=A0 =C2=A0 =C2=A0 > time being.
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0Does that change really help?
>> >> >
>> >> >
>> >> > It does for unifying project-name and project-root.<= br> >> >>
>> >> Do they have corresponding scenarios that cause confusion= ?
>> >>
>> >> >=C2=A0 =C2=A0 =C2=A0In my testing, what it results in= , is showing only the buffers
>> >> >=C2=A0 =C2=A0 =C2=A0belonging
>> >> >=C2=A0 =C2=A0 =C2=A0to the "canonical" proj= ect, both when project-switch-buffer is
>> called
>> >> >=C2=A0 =C2=A0 =C2=A0when in it, or when inside a &quo= t;symlinked" version. Buffers visited
>> >> from
>> >> >=C2=A0 =C2=A0 =C2=A0the "symlinked" project= are not suggested in completion anymore.
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0When reproducing, try using find-= file (C-x C-f) to open the
>> buffers.
>> >> >
>> >> >
>> >> > Yes, indeed, project-buffers also needs some help. >> >>
>> >> We could add a user option for project-buffers specifical= ly, as one
>> >> approach.
>> >>
>> >
>> > I assume this would be the same option that canonicalizes pro= ject-roots
>> so
>> > it's all synchronized.
>> >
>> >> Thanks for the continuing discussion.
>> >> >
>> >> > WRT projectile, having only eyeballed the code (I ha= ven't used it), it
>> >> > seems truename use is not optional.=C2=A0 It looks l= ike projectile-project-
>> >> > buffer-p is defined in terms of truename https://g= ithub.com/bbatsov/
>> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6= fe93/
>> >> > projectile.el#L1775 <https://github.= com/bbatsov/projectile/
>> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
>> >> > projectile.el#L1775>, project-root caches the tru= ename (but I see a
>> bug
>> >> > in the code which doesn't normalize dir on the w= ay in so users likely
>> >> > get odd results) https://github.com/bba= tsov/projectile/
>> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projec= tile.el#L1385
>> >> > <https://github.com/bbatsov/projecti= le/
>> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projec= tile.el#L1385>,
>> the
>> >> > file cache is in terms of truename https://github.= com/bbatsov/
>> >> > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6= fe93/
>> >> > projectile.el#L1262 <https://github.= com/bbatsov/projectile/
>> >> > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projec= tile.el#L1262>.
>> </>
>> >>
>> >> I wonder how it affects Projectile's performance over= Tramp.
>> >>
>> >
>> > No idea.=C2=A0 But I can say that I have wrapped a bunch of p= roject.el
>> functions
>> > to avoid remote file operations based on a personal user opti= on (some of
>> my
>> > users are heavy Trampers, some hosts are slow).=C2=A0 But the= way I've done it
>> > is a blanket inhibition, not project-specific or some other a= ppropriate
>> > criteria which would be nicer.=C2=A0 Perhaps a .project.eld f= ile with
>> variables
>> > akin to dir-locals that project could consult.=C2=A0 I haven&= #39;t had the time to
>> > think that through.
>> >
>> > I've also implemented personal 'consult' project = and related
>> > buffer-matching functions to handle project root canonicaliza= tion.=C2=A0 Those
>> > functions are not in terms of project-buffers and perhaps sho= uld be as
>> they
>> > miss out on back-end specializations.=C2=A0 I've started = a discussion in the
>> > consult repo to offer to contribute PRs over there.
>>
>> I'm not unsympathetic to the need, but I think we need to unde= rstand
>> whether your request is project-specific or not.=C2=A0 I realized = that the
>> Emacs features I wanted already exist.=C2=A0 In particular,
>> find-file-visit-truename should excise symlinks from every visited= path,
>> and directory-abbrev-alist should be able to alias one directory >> to another.=C2=A0 Can you add your symlink directory to
>> directory-abbrev-alist and have it rewritten to the truename?
>>
>
>Of course people can always hack around these cases manually.
>
>To me, what makes project.el special is that it has an implicit promise= to
>organize buffers related to a project.=C2=A0 That the existing implemen= tation
>depends on the ambient directory from which a file buffer was created t= o
>determine what's related has become a "leaky abstraction"= where symlinks to
>projects are involved.=C2=A0 The documentation in project.el kind of al= ludes to
>this limitation in an implied way for transient projects.=C2=A0 It is s= ilent on
>directory assumptions for vc projects, instead delegating to the vc bac= k
>end.
>
>It would benefit the whole community to offer a resolution to let
>project.el fulfil its buffer organization mission independent of
>convenience names and that doesn't rely on management of
>directory-abbrev-alist (eek).


I hear you, but I'm not sure the situation is so clear cut. Of course w= e want a single project in the user's mind to map to one process object= on the Emacs heap: there's just genuine diversity in opinions of what = counts as "the same" and I think project is the wrong level of ab= straction for expressing your desired unification. We already have a way fo= r the use to express a preference that the fully resolved name of a file be= considered its identity, and we already have a mechanism through which the= user can inform Emacs of the canonical version of an ambiguous path.

Maybe we can improve the UX. When we find ourselves with two project object= s (say A and B) that refer to the same true path, we can ask the user to ch= oose between making A canonical, making B canonical, and rejecting the unif= ication --- then remember that choice in the existing mechanism. That'l= l fix the non-project path ambiguity problems too.

I don't= think it matters to me which A or B (or C or D) becomes the "master&q= uot; but I'd still prefer the master to be rooted in the true path.=C2= =A0 The one that gets recorded in projects.eld, I think should be the maste= r and if we have a user option where the true name always becomes master, t= hat's cool.

If we're willing to prompt, then we'd be willing to have a user = option to default to a selection and not prompt.=C2=A0 That would be fine w= ith me.
--0000000000004ad4c60631551c73--