From unknown Wed Jun 18 00:21:41 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#41572 <41572@debbugs.gnu.org> To: bug#41572 <41572@debbugs.gnu.org> Subject: Status: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Reply-To: bug#41572 <41572@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:21:41 +0000 retitle 41572 28.0.50; [PATCH] Support plain project marked with file .emac= s-project reassign 41572 emacs submitter 41572 Zhu Zihao severity 41572 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 00:45:15 2020 Received: (at submit) by debbugs.gnu.org; 28 May 2020 04:45:15 +0000 Received: from localhost ([127.0.0.1]:50629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeAPr-0008GA-0h for submit@debbugs.gnu.org; Thu, 28 May 2020 00:45:15 -0400 Received: from lists.gnu.org ([209.51.188.17]:44556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je9HG-0006SU-VJ for submit@debbugs.gnu.org; Wed, 27 May 2020 23:32:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53224) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je9HG-0007xS-PF for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 23:32:18 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:37506) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1je9HF-0000eZ-T9 for bug-gnu-emacs@gnu.org; Wed, 27 May 2020 23:32:18 -0400 Received: by mail-wr1-x430.google.com with SMTP id x13so11719813wrv.4 for ; Wed, 27 May 2020 20:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nvwWOMTGQ77E0LmZeuZKEvQxuFEurtKs8hS6ulk6Aag=; b=isjhY+H8PBGWl+nyBooQ6/yNroJxqyv6LFGDCCbIMNeIe0Brrv80UhWt5tF/xz8xxM 1uXlaeC6hT6WSG8n8Siou9iIx/cxtO7oOWD6PGNVzWnYIW0JP+l2Hp1RYxkwwu7olpeW 7Rc3JlkdfS+fN67g87lgcu9u9WgHO7JM1ABNwmykmrQIOceL0PxQYGah3KbZcolkTNAC d+aNFIMgyD/e1K7Olpehg+t7yTndewS4SxZ3nKST7Y/QmZuPP4a+d98VAgzqsbboOn3V fkF8rYXRE+2v+SC/IcR3imPlFAO6RWmdKGne0CPv8yPKwPU8lOc1GezXkzFTPWDPb+ui GKuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nvwWOMTGQ77E0LmZeuZKEvQxuFEurtKs8hS6ulk6Aag=; b=Oqs9QMIyZAeUdESmJqJENpJ9PXlYPQdirma0xx0OXoo8S1RzUAMXi67OkFsVO1Im80 w/1ZXLeazHTJV5TzerFPTGT4aGRMR5D9A5ONnc/BDWREOO4bK8DqDZSrKdF7hxKEEaK9 ofdsV3k1tfXXZXyxBrBBVN0ab5E8n5IgCZEeNEThZAjv9aJaOGhSLdRlAII4hNaq8DDo QSk32MF6i9R2hSF1sq++cOS8CA6QlRRQhMsVa64wdfwahHA31Bg4pix6r1zgZRvVDtxc gp7knW8ew0OE9tw6WHZE2QU3Dl/svtC6BHmZ2X2+1n0wgpFBFoAr1c/GhAv/ihtrf6Bw 9rqQ== X-Gm-Message-State: AOAM532aBH7RmLlFBesCuIW2sUwzTpfkNfL6fTZdu+vaF1BHjFpe/P1y YMqmkxhvR6HPmSQr5eM6LuKXiWWFlj62pGON4xU6PTCGc5A= X-Google-Smtp-Source: ABdhPJxTdukTWahp/AqRaOdg6icx3eip4dzVvwdvd0qOyYZnmu7XjEn1D9dP00fsG7jNn1jWO6AhKjNPVTjF0XY7R1g= X-Received: by 2002:a5d:4801:: with SMTP id l1mr1237166wrq.235.1590636735538; Wed, 27 May 2020 20:32:15 -0700 (PDT) MIME-Version: 1.0 From: Zhu Zihao Date: Thu, 28 May 2020 11:32:04 +0800 Message-ID: Subject: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="00000000000096a7b705a6acf9c2" Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=cjpeople2013@gmail.com; helo=mail-wr1-x430.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 28 May 2020 00:45:13 -0400 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: -2.1 (--) --00000000000096a7b705a6acf9c2 Content-Type: text/plain; charset="UTF-8" This patch add support for "plain project" in project.el. Plain project is a kind of project without any VC backend but should be. To mark a directoy as project, put an empty magic file .emacs-project under the directory, and project.el should be responsible for it. ~~~~ >From cb0a67cfacf141a8b1955c08c3f459bcac801a39 Mon Sep 17 00:00:00 2001 From: Zhu Zihao Date: Thu, 28 May 2020 11:04:44 +0800 Subject: [PATCH] Support plain project marked with file .emacs-project * lisp/progmodes/project.el (project-try-plain): New function * lisp/progmodes/project.el (project-root): New dispatch variants * lisp/progmodes/project.el (project-find-functions): Add project-try-plain --- lisp/progmodes/project.el | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 88f73e4fb31..4c1810aeb56 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -94,7 +94,7 @@ (require 'cl-generic) -(defvar project-find-functions (list #'project-try-vc) +(defvar project-find-functions (list #'project-try-plain #'project-try-vc) "Special hook to find the project containing a given directory. Each functions on this hook is called in turn with one argument (the directory) and should return either nil to mean @@ -194,6 +194,18 @@ project-files (or dirs (list (project-root project))))) +(defun project-try-plain (dir) + "Return the plain project instance of current DIR. + +A directory with magic file \".emacs-project\" will be recognized as +plain project." + (pcase (locate-dominating-file dir ".emacs-project") + (`nil nil) + (root (cons 'plain root)))) + +(cl-defmethod project-root ((project (head plain))) + (cdr project)) + (defun project--files-in-directory (dir ignores &optional files) (require 'find-dired) (require 'xref) -- 2.26.2 --00000000000096a7b705a6acf9c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This patch add support for "p= lain project" in project.el. Plain project is a
kind of project wit= hout any VC backend but should be.

To mark a directoy as project, pu= t an empty magic file .emacs-project under the

directory, and p= roject.el should be responsible for it.

~~~~
=

From cb0a67cfacf141a8b1955c08c3f459bcac801a39 Mon Sep 1= 7 00:00:00 2001
From: Zhu Zihao <all_but_last@163.com>
Date: Thu, 28 May 2020 11:04:44 +0800Subject: [PATCH] Support plain project marked with file .emacs-project
* lisp/progmodes/project.el (project-try-plain): New function
* lis= p/progmodes/project.el (project-root): New dispatch variants
* lisp/prog= modes/project.el (project-find-functions): Add project-try-plain
---
= =C2=A0lisp/progmodes/project.el | 14 +++++++++++++-
=C2=A01 file changed= , 13 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/projec= t.el b/lisp/progmodes/project.el
index 88f73e4fb31..4c1810aeb56 100644--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ = -94,7 +94,7 @@
=C2=A0
=C2=A0(require 'cl-generic)
=C2=A0
-(= defvar project-find-functions (list #'project-try-vc)
+(defvar proje= ct-find-functions (list #'project-try-plain #'project-try-vc)
= =C2=A0=C2=A0 "Special hook to find the project containing a given dire= ctory.
=C2=A0Each functions on this hook is called in turn with one
= =C2=A0argument (the directory) and should return either nil to mean
@@ -= 194,6 +194,18 @@ project-files
=C2=A0=C2=A0=C2=A0 (or dirs
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (list (project-root project)))))
=C2= =A0
+(defun project-try-plain (dir)
+=C2=A0 "Return the plain pr= oject instance of current DIR.
+
+A directory with magic file \"= .emacs-project\" will be recognized as
+plain project."
+= =C2=A0 (pcase (locate-dominating-file dir ".emacs-project")
+= =C2=A0=C2=A0=C2=A0 (`nil nil)
+=C2=A0=C2=A0=C2=A0 (root (cons 'plain= root))))
+
+(cl-defmethod project-root ((project (head plain)))
+= =C2=A0 (cdr project))
+
=C2=A0(defun project--files-in-directory (dir= ignores &optional files)
=C2=A0=C2=A0 (require 'find-dired)
= =C2=A0=C2=A0 (require 'xref)
--
2.26.2



--00000000000096a7b705a6acf9c2-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 03:42:27 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 07:42:27 +0000 Received: from localhost ([127.0.0.1]:50871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeDBI-0004Oa-6N for submit@debbugs.gnu.org; Thu, 28 May 2020 03:42:27 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:53109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeDBF-0004OL-Vo for 41572@debbugs.gnu.org; Thu, 28 May 2020 03:42:22 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 96E555C005C; Thu, 28 May 2020 03:42:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 28 May 2020 03:42:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warpmail.net; h= from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=fm3; bh=jTPLFG5+MDVKpud27S0apR4uSu /9OJV0/JE1A1y49TM=; b=dP54LyPaEEI7iprfS/ZubOE8Uyp387kFsOvAhftb5+ V1F1OKyoN9CVG9eeBsQ55n4L3Tq59IE3HxKLBWVegPawsOXsf8Txb8f88Y0ltW2f amAsKLf6OERpty5K6q/kl5/4Go8V5tbV2iJ7TcbCkr9FgA9WISmmZrqOQf7vu0pw NqdtPljUE4pYq9jxURMnHlSjBXeqY7Lg1WV8tmDvkvsU06txOCmvMK68yPOgc91K 0onYibxsyKA6tOnYHal85TIFvbnP3CGnuiZym72/x8WffXg8wdIWbStAOwJyKgiP 5h3yzLj7d0ynW1KozkcIC8zsCXUXBU2sTEFw7Z7HHS+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jTPLFG 5+MDVKpud27S0apR4uSu/9OJV0/JE1A1y49TM=; b=1ndU6hA882QlvhO1XK8aBW a/fcOZtc0Yi8Ss3szFfO1hvrOCbaHW2CJUvbSJ3HxSjPM/0kELAgZGWP9p2+oBcv iyZHVDT4WQb9ezOn7WMmfc6bb+hEje2K46WzsuzBeXRffed43bxerVaBmWemOGH9 2isndiwQREL8r5JZCQVDz52c0hI69sNsOsTPzK39QRQYXlyGm8JykzwenTwKNeBo 8puuS5JZKjhOFbPq1/90yNQdauqwKBEKAlAIlLpb6qjesPZBX9KyzkW+Q67hJiFJ 7jo8bbdYikBgkK+Iq2lWESs5ZVPHJFqjDQgLRyMXYHmE0gZwu37Gy9bmGCqSodHA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufhfffgjkfgfgggtsehttd ertddtredtnecuhfhrohhmpedfrfhhihhlihhpucfmrddfuceophhhihhlihhpseifrghr phhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnhepudekueevlefgfeeigefhgeelte evieehhfetjefgieduheegvdfhffejhfffleffnecukfhppeejledrvdduledrvddtjedr udefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hphhhilhhiphesfigrrhhpmhgrihhlrdhnvght X-ME-Proxy: Received: from localhost (p4fdbcf8b.dip0.t-ipconnect.de [79.219.207.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E6F13061856; Thu, 28 May 2020 03:42:16 -0400 (EDT) From: "Philip K." To: Zhu Zihao Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: Date: Thu, 28 May 2020 09:42:12 +0200 In-Reply-To: (Zhu Zihao's message of "Thu, 28 May 2020 11:32:04 +0800") Message-ID: <877dwweca3.fsf@warpmail.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: 41572@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.7 (-) Zhu Zihao writes: > To mark a directoy as project, put an empty magic file .emacs-project under the > directory, and project.el should be responsible for it. Is there any more standard name than ".emacs-project"? Or could a directory local-variable be used? I like the idea, but wouldn't want to have so many ".emacs-project" files lying around in toy projects. -- Philip K. From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 08:24:26 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 12:24:26 +0000 Received: from localhost ([127.0.0.1]:51231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeHaD-0007ei-UW for submit@debbugs.gnu.org; Thu, 28 May 2020 08:24:26 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:39897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeHaB-0007eU-7X for 41572@debbugs.gnu.org; Thu, 28 May 2020 08:24:23 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EC87F5C00E4; Thu, 28 May 2020 08:24:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 28 May 2020 08:24:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warpmail.net; h= from:to:cc:subject:in-reply-to:date:message-id:mime-version :content-type:content-transfer-encoding; s=fm3; bh=3AsbQFLCcGTtu 3MbPJuU+0mKvGjufaHOvyHrdjcvKBo=; b=pv3NAnDAx8YBk6EAQyHm54v/KEn9a ToIVVC59U7Xp59NxP1rrfqkWiIf3qbL6Q9lcJ/Alj8kTq90Iq3nrGq0NvS5C3IAS FFChse7+r1HJ3WUkTLmyDUcWMBR67VThDIrVVZVigSvf8ooyVb3BSSD/1xhpfRlz bdWUyJpsqWrNWxtnj3OXBykYSH3EiXOTyGLf0XK8G9Pvs5Y4Xs9nnPKELHQW6BrY Ux3zQmTj81SgwN8URPHM01bpfQgsBqKf6k42Ah7WpJphWTx7I/7V+zulPcC3HuDD zTGzqfPsLulyjp7FROax2CivZkbq9mPHnoW5gajJqb+grP3SOb0LKVqEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=3AsbQFLCcGTtu3MbPJuU+0mKvGjufaHOvyHrdjcvKBo=; b=bPWB9h80 nBzmRIPd6o2e4ztUYI0QNlOpsMD+KaUnXBHapqEcq/gWfWFWaIwR9ZO3u3KJVN0v FgpZqctDhiYt1j+2sPZLbBnjheMl/pyKLwUNsuJhcqEeVvuPP9HCYpZ9DprP7n3K xBAbSN1E+Yl+iOW1VeYfn55nIStUCfIi86ak579UVlEBeAxaPkAmZnuW29QvNE4A nFnUEaYjd3myF5OqZuxSxj0wFOUP2WmN6o+7IiH7zb3DuW/+ShZjpTie+dMcFO8R QIh8XIZ7OfYMUhDExTkusGeLvbkNx6QeB7kiunonpI6pc7d6Df3Jkp9Mw7zswmdz w9Pj9h0OyjPJIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddviedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujgffkfggtgfgsehtqhertd dttdejnecuhfhrohhmpedfrfhhihhlihhpucfmrddfuceophhhihhlihhpseifrghrphhm rghilhdrnhgvtheqnecuggftrfgrthhtvghrnhephfdujeevuddvffetudfghfduvdfgve ffueefvdeljeeuffejheeludeftdduffefnecukfhppeejledrvdduledrvddtiedrvddv feenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphh hilhhiphesfigrrhhpmhgrihhlrdhnvght X-ME-Proxy: Received: from localhost (p4fdbcedf.dip0.t-ipconnect.de [79.219.206.223]) by mail.messagingengine.com (Postfix) with ESMTPA id 50C813280059; Thu, 28 May 2020 08:24:17 -0400 (EDT) From: "Philip K." To: Zihao Zhu Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project In-Reply-To: (message from Zihao Zhu on Thu, 28 May 2020 19:20:41 +0800) Date: Thu, 28 May 2020 14:24:04 +0200 Message-ID: <874ks0dz8b.fsf@warpmail.net> 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: 41572 Cc: 41572@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.7 (-) Zihao Zhu writes: > IMO, it's not practical to use directory local variable > > 1. directory local variable goes ".dir-local.el". But we can't mark=20 > every directory contain this file as project. We have to do extra search= =20 > if we use directory local variable. Not necessarily, if the directory variable would contain a (relative) path to where the project root is. > In your use case. I think we can add variable "project-known-projects",=20 > you can=C2=A0 add your favorite directory to it, you can also persist thi= s=20 > variable using savehist.el I actually think this is better (given there is a command to add a directory to the list of known projects), because you could also build a project switcher on this foundation. And if the variable is a user option (which I think it should be), savehist shouldn't be necessary. --=20 Philip K. From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 08:36:09 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 12:36:10 +0000 Received: from localhost ([127.0.0.1]:51244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeHlZ-0007wt-Lj for submit@debbugs.gnu.org; Thu, 28 May 2020 08:36:09 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:55789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeHlU-0007wL-1U for 41572@debbugs.gnu.org; Thu, 28 May 2020 08:36:08 -0400 Received: by mail-wm1-f65.google.com with SMTP id c71so2933940wmd.5 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 05:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kcpjlAry7hAVjDr08KCdHX7wZVmOI2kmdZGJCbV6UkQ=; b=EahEs6MaUDRHp0HFM8CR4D/qblSG3MWy3ejoXFfnS3ttSiLWJCT7RR620f3hZCV2Ox 3Fm7oqra9RANIzz1+4SHY8q4iW8ZD9E0Tr0BL+QAWnzp5uE8xAo9PHZNpd3TlKMEDrXE eRMP7KdQ02VgIFUo12y0/xDqvGwwhmrxTmZ76tNVjak7sPgkrozQn7pw1OEC3nU1fqVB rmY+Vu0lLB6VvSOllmallh4k6SxvmKrndZvIUkCfi3nTLt8PKE6clYYxNpcu7ioVNcWE II7+tZeKV8oGZRWBVEFLWJfcmuf/VCxhlLPSrkWfbZ4oKPOcW0KLlAOw9Wsyflcr2/eD ncDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kcpjlAry7hAVjDr08KCdHX7wZVmOI2kmdZGJCbV6UkQ=; b=BnG6JXd6huNXAT9xb7aaeqajHoF0pZd+ZZcVarykmvXyR6LczgB0VW8QgYVKMoZ8jL VULS7RRqkvGSpRx8wQWzvMR6gqUJEVTPa3M8z56q7y7lUdwInyKpBn62a6CFSEzgysOZ 7ULpgMcFrx9h3Oxuf5UJEKRx5P7EuwvVLZGXxRl0IzWv/OaTCfGcSBlSsgh0PRb514ym jrke7mqlgJf/95bYbtsvx0bR+xAFHBtXUVqeSHVVxrenvxmHjQV/DiepvFx8/uG5V3aN u3Ryun5ElbvAwA1JviJcfCRggJTm5114f26zOYF2c00qwDkEFSKUko4JCWPJXdMog5r3 EzcA== X-Gm-Message-State: AOAM532h/VnY6zCZJ+uVEOcWehXGyOKuxRpDmnFN8YPwgVp/jgQEOfUb Wcbt4dyJsLC3D3It3BFL0/juB+Ii X-Google-Smtp-Source: ABdhPJzzrO49rpBhJJ1ES6IsyS0+QlszFSFEXPeVx9/fLViRCrlu5qY6+ryfODgI4c4E1P2qq8aGzg== X-Received: by 2002:a1c:5408:: with SMTP id i8mr3131795wmb.94.1590669357723; Thu, 28 May 2020 05:35:57 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a6sm5778994wrn.38.2020.05.28.05.35.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 05:35:57 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Zhu Zihao , 41572@debbugs.gnu.org References: From: Dmitry Gutov Message-ID: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> Date: Thu, 28 May 2020 15:35:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 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.5 (/) Hi! On 28.05.2020 06:32, Zhu Zihao wrote: > This patch add support for "plain project" in project.el. Plain project is a > kind of project without any VC backend but should be. > > To mark a directoy as project, put an empty magic file .emacs-project > under the > > directory, and project.el should be responsible for it. Is that really a good idea? I mean, you of course can set up a project type like that yourself. But if it's included in project.el, it means we're taking it seriously. And there's no way to specify the ignored files, say. And file enumeration will inevitably be slower than in VC-based projects. Do you have a lot of projects that aren't backed by VC repositories? From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 11:14:41 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:14:41 +0000 Received: from localhost ([127.0.0.1]:52784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeKEy-0003an-OX for submit@debbugs.gnu.org; Thu, 28 May 2020 11:14:41 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:35089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeGaj-0001mY-4Q for 41572@debbugs.gnu.org; Thu, 28 May 2020 07:20:53 -0400 Received: by mail-lf1-f65.google.com with SMTP id 82so16358014lfh.2 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 04:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jh1kEJ4HUm/oMiOanXZAZZ+hXrTiNdYMIJR60LpoXQQ=; b=VZRiSao+LvRZC34Rlz7sr+bTFE2iN+oVosnEKN0AxD5jIYAj4DrbnHD2nJAMlQ9mzz ZmYAqP5+eKCrI+ngJ0JvMEyFZeuoKU2qZSdY+KuqYeDba3LeuRVaclkdta5T/r7nrNro eCsHVFjUpV5vQK6jEFoVcABXjWbjAoSeXFxqq175l/VptWP7oLPVCrouh6zUdxAWshcp RJfv9ys50yD8DAWdzxRgNrXEbs0GINLHbhaC7cvZq1DM9ahXYdWMnZZg+FRtSZ5JHrFv bC691e/oG9bqPa2fDcr8Jedu1GvCyOrgHIu9LarK1buPfxJZ42wy+g7vhNyGFRe2h4rW MVXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jh1kEJ4HUm/oMiOanXZAZZ+hXrTiNdYMIJR60LpoXQQ=; b=UQjrIaUdDaEpv0juRaj8Ath4jsCjLX6WxtH6UZFyxJB5oW6Rr7H9MLCttq0ftUBLA2 lvUb4wTCIz8z9tOfmksumQJ8tOXgumLZJ/cwxje3AUBwbKH5VeP4Ef9vDWrPFqMtb0AD 9YCeTeVO/xjQhFDFNRcfZoOJ5EF/HBJzee/L6KCs0R/Wuby5ln4+P/6+bmljlvSyA91U HESrALRXkQHtw3ujbzYVj84rRIduWXiYq1nAVHpDnjf3nvm1NOCSE2q9swpftFGxdQaB XWzdALYX35bOVIcpj8Vs4FQ4qK1bp0fXHTM/y5DzMpHf2lIlBWNSa12vhtEizyaYfwdm OmxA== X-Gm-Message-State: AOAM5329diyWD1E22QNeXfWTR76/PTi8KN2Q6lJ0eGw1ru77kaCXdd0Z niafEkebZ5ynBq0XuGo8U7qw12SkORk= X-Google-Smtp-Source: ABdhPJyQmTUFSPqwKFEQ6hPknGi+Ufv2lk7cLjeHhxsCqZ+HAd/YH0RvCzhZ+KdglgyT69qiwBNQpg== X-Received: by 2002:ac2:485a:: with SMTP id 26mr1156423lfy.57.1590664846651; Thu, 28 May 2020 04:20:46 -0700 (PDT) Received: from [192.168.101.55] ([45.130.145.124]) by smtp.gmail.com with ESMTPSA id y18sm1568975ljj.81.2020.05.28.04.20.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 04:20:45 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: "Philip K." References: <877dwweca3.fsf@warpmail.net> From: Zihao Zhu Message-ID: Date: Thu, 28 May 2020 19:20:41 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <877dwweca3.fsf@warpmail.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41572 X-Mailman-Approved-At: Thu, 28 May 2020 11:14:39 -0400 Cc: 41572@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.8 (/) IMO, it's not practical to use directory local variable 1. directory local variable goes ".dir-local.el". But we can't mark every directory contain this file as project. We have to do extra search if we use directory local variable. 2. If we have variable "project-directory-plain-project-p", It's a problem for us to determine the root of project because we will get the same directory local value for all sub-directories of project root. In your use case. I think we can add variable "project-known-projects", you can  add your favorite directory to it, you can also persist this variable using savehist.el On 2020/5/28 下午3:42, Philip K. wrote: > Zhu Zihao writes: > >> To mark a directoy as project, put an empty magic file .emacs-project under the >> directory, and project.el should be responsible for it. > Is there any more standard name than ".emacs-project"? Or could a > directory local-variable be used? I like the idea, but wouldn't want to > have so many ".emacs-project" files lying around in toy projects. > From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 11:14:41 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:14:41 +0000 Received: from localhost ([127.0.0.1]:52786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeKEz-0003ap-8P for submit@debbugs.gnu.org; Thu, 28 May 2020 11:14:41 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:37678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeGhk-0001zH-9B for 41572@debbugs.gnu.org; Thu, 28 May 2020 07:28:08 -0400 Received: by mail-wr1-f50.google.com with SMTP id x13so12830126wrv.4 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 04:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j/Lusj2BzewKWiBpnMS0+fQe+QqIp9Ij9aVcwnV0iVA=; b=QlLI55pBrUyIM3ugV8lu5ha6eG/MsnXp5SOkgyL1vVgm/7Qw236taYkYE50iij08t0 JwFCF+t/+yuRbY+A9Vri5+6/Bt4VttNqOtLrm1bKz2S2hmWeH0fmGqL4YPVDuOMrOysn 2iTjt7RyOrrggQDnVlJu+1GkBwRYtu0HttCHxfI/28pEnSW8zZ2OrT8aO6sav8O9J6Oj hUjtJbjjYnexIedPJB4JYI9tGwDE5leESJ0B5+yl+h3bbxqd6SB5nuW6I3FuwkyCfzAv DERipuLpRZ3XwrzdgvnkrRKJLmunggj7wwaZaKk/er5xx70SU6yJHHzI3h3Vi0hHO6h4 zH+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j/Lusj2BzewKWiBpnMS0+fQe+QqIp9Ij9aVcwnV0iVA=; b=qOqxwiVbq7DhkXu9StOcnjmaqam9jP4rSJQO1OEHWq/Ukjtkt7RXCz0VvT/2Qe7RUz 39XejLURsl/XbH7D9X0IC3WCeAT4AQbG0yHUZ+WcbCfOw39FEQeNxjsGhf+boKFy0JQf ysQfMpxhjjR4aM+AWyaVOlebN1JXHu5UFVNeQIXw5cNP3BnshTF5cY0rZ7mbRdsRUIkL ubNG1bFa9IKSysHwvdV/CftBLKHzD9eqdrKeMsRNhetgJS97FVuYokErhbkahvZjZj5y rfoHVWbtNnKIZHAm7oqN2YgSodJt2HuBaVHzYusDPLxU+Mwb9wxVFqWheAUraXGvuNAv oYng== X-Gm-Message-State: AOAM531HEx/Ekao8hm8NhA0jzjlrSkjxNACEqk9sHvl9ATkYQbYczswU GwmLHTEwsCyynNumMHsR64dy4ojfiz2M+QE4/hQ= X-Google-Smtp-Source: ABdhPJxSJpQOgWbmMSoKJvPHs4uQkc0p1F0+/eCF56rA/nMMi0kh3UcuOHnxWzyVz5bnraPqMW8VHTwKVyhmrpmczS0= X-Received: by 2002:a5d:4d89:: with SMTP id b9mr3378671wru.210.1590665281667; Thu, 28 May 2020 04:28:01 -0700 (PDT) MIME-Version: 1.0 References: <877dwweca3.fsf@warpmail.net> In-Reply-To: <877dwweca3.fsf@warpmail.net> From: Zhu Zihao Date: Thu, 28 May 2020 19:27:48 +0800 Message-ID: Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: "Philip K." Content-Type: multipart/alternative; boundary="00000000000012062a05a6b39f0f" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 41572 X-Mailman-Approved-At: Thu, 28 May 2020 11:14:39 -0400 Cc: 41572@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.7 (/) --00000000000012062a05a6b39f0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMO, it's not practical to use directory local variable 1. directory local variable goes ".dir-local.el". But we can't mark every directory contain this file as project. We have to do extra search if we use directory local variable. 2. If we have variable "project-directory-plain-project-p", It's a problem for us to determine the root On 2020/5/28 =E4=B8=8B=E5=8D=883:42, Philip K. wrote: Zhu Zihao writes: To mark a directoy as project, put an empty magic file .emacs-project under= the directory, and project.el should be responsible for it. Is there any more standard name than ".emacs-project"? Or could a directory local-variable be used? I like the idea, but wouldn't want to have so many ".emacs-project" files lying around in toy projects. --00000000000012062a05a6b39f0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=20 =20 =20

IMO, it's not practical to use directory local variable

1. directory local variable goes ".dir-local.el". But we c= an't mark every directory contain this file as project. We have to do extra search if we use directory local variable.

2. If we have variable "project-directory-plain-project-p"= , It's a problem for us to determine the root


On 2020/5/28 =E4=B8=8B=E5=8D=883:42, Philip K. wrote:
Zhu Zihao <cjpeople2013@gmail.com> writes:


To mark a directoy as project, put an empty magic file .emacs-=
project under the
directory, and project.el should be responsible for it.

Is there any more standard name than ".emacs-project"?=
 Or could a
directory local-variable be used? I like the idea, but wouldn't want to
have so many ".emacs-project" files lying around in toy projects.
--00000000000012062a05a6b39f0f-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 11:47:00 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:47:00 +0000 Received: from localhost ([127.0.0.1]:52866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeKkG-0004RW-H0 for submit@debbugs.gnu.org; Thu, 28 May 2020 11:47:00 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:41184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeKkE-0004RC-G2 for 41572@debbugs.gnu.org; Thu, 28 May 2020 11:46:58 -0400 Received: by mail-lf1-f46.google.com with SMTP id u16so15085841lfl.8 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 08:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GubtCaiHjQE6ZsMWQerCzLSvngFKfYG196MQNu5a8Qs=; b=GrHND2mzAQD1B+2MfMZkjEMDvJiiZ8XFWx2LFuOxzaBU84tYxKy9gSDpTEDO65Nx/U NMSYtpRx7rLMRD5WaQzspLfZAv1HXp8rzDkZe3L2lKebdFrGtDHeqH6GxKS6NBl5qrpJ qzNE5YihlYIKagU6yZSxsuR39ZU91hcmx/UFhJ2DZDxB5vFMoUpt3qjUArMjjoozd+ds VQBEXGokbSVf3UCgia1ymndxybBfnISVAbx43PrHh6mODZApAHov3SResjP0WucpzvJv nFYkSGoi6BqJOsuAc0fkovVYFocSJKOKBBdN8k3I+/ojoUCPSFJv9CecNwbjxEHDNkox WXJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GubtCaiHjQE6ZsMWQerCzLSvngFKfYG196MQNu5a8Qs=; b=Gc8XKK1tmDAK87C8y+iPdtLAjkcn+b4Uo17CcUglULY+baRxqrM37hIyiUiVtIdDz6 ggimj7e5Hgq9WpNw5XijvXfrnn+amhkNp0exo6VaK7PzzaoEGwirBfMmI8hUlX+wGfJf qBgBY4cgtYHSCIDOn4Lbml/0uyWKOQdmHw3ZjdabHY/a3UNci6brTeJpUaroFdYosdQl YBl+YizZTg4Hn5gHKPI+fvejYfgVr5oNGCvZuWUomwVKOWcx0Lh72U2W251b7IupWWs+ Q9IOiXTyUVNP2vbxMswhfhA5Tn3fFGY1RJ2qaIvYVUPPOrfBcNAJAqB0gW5NinHXj0zs 8WZw== X-Gm-Message-State: AOAM53049exnrbwMnbnDhwkJmnt0Mmh8KEqUQReLzIhRrCBftAIst8+n tLLdq+l+kHmBMbTNqiKKjwE56FQrtSk= X-Google-Smtp-Source: ABdhPJwR3KCKFqF4b4GiqXe9/MQGWk7JLPFm1+zjS3l438v8lTIgo1d2mtb4uk6IkBoBux66fN+Kvw== X-Received: by 2002:a19:8453:: with SMTP id g80mr2011812lfd.167.1590680812004; Thu, 28 May 2020 08:46:52 -0700 (PDT) Received: from [192.168.101.55] ([45.130.145.124]) by smtp.gmail.com with ESMTPSA id x8sm1498391lji.95.2020.05.28.08.46.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 08:46:51 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , 41572@debbugs.gnu.org References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> From: Zihao Zhu Message-ID: Date: Thu, 28 May 2020 23:46:43 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41572 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.8 (/) If I have a project.el based plugin,  and  I wanna use them in a directory not under VC. Add an mark to force project.el work is easier than modify the source of plugin or initialize VC system. And this  can also be used as a side solution to use project.el in unsupported VCed project in Emacs (AFAIK, P4(Perforce) is not supported by vc.el). IMO, a plain project is like a transient project. On 2020/5/28 下午8:35, Dmitry Gutov wrote: > Hi! > > On 28.05.2020 06:32, Zhu Zihao wrote: >> This patch add support for "plain project" in project.el. Plain >> project is a >> kind of project without any VC backend but should be. >> >> To mark a directoy as project, put an empty magic file .emacs-project >> under the >> >> directory, and project.el should be responsible for it. > > Is that really a good idea? > > I mean, you of course can set up a project type like that yourself. > > But if it's included in project.el, it means we're taking it > seriously. And there's no way to specify the ignored files, say. And > file enumeration will inevitably be slower than in VC-based projects. > > Do you have a lot of projects that aren't backed by VC repositories? From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 15:59:09 2020 Received: (at 41572) by debbugs.gnu.org; 28 May 2020 19:59:09 +0000 Received: from localhost ([127.0.0.1]:53127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeOgH-0002Bp-6Z for submit@debbugs.gnu.org; Thu, 28 May 2020 15:59:09 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:35475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeOgE-0002BE-SF for 41572@debbugs.gnu.org; Thu, 28 May 2020 15:59:07 -0400 Received: by mail-wr1-f65.google.com with SMTP id x14so594156wrp.2 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 12:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JoLLXPZ2pNsIkcIKRLZxLyraQvlQplh4Z2uvQkIx9bs=; b=b09NJjJEiYoCfAhKMwKYnubuPXzLxA1436/IiDAVei2cvYVg+sXV+xpw67kQu1/UBS hyXiNAR3XFkGtg1vwRlwHQrGVhNS0Cz2n6kQ4uRwr0lqqKONeueQtGb/nGmh7hK2CTtK wQm2i56HxS/zTTa05SiM0EVX9FkGpudmBZoz2x0E0f4Z/OcfEZDhuFTQhGVT0B92FmwX UW3U/N0i7BgmB2LlvSu6ixDUj8HfR+TY9F/6HMs7N6oorv91NwmQ7sAq37XCz5mdsFqv TDPpa2Dve5+5GYflq3HZL2c9ODCE1NG6DV5r9/eiK3nwp6cDWVyfJNv6Xr6Q17uw+p6b yX5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JoLLXPZ2pNsIkcIKRLZxLyraQvlQplh4Z2uvQkIx9bs=; b=f2fm0bomDLNBRhv2ikq96XqhGIw9crVzneAEzRS+mtJDALtvy2eh6c3WACsQ8pVZFr iwFzK2iD6PqAT9Xv2EkrGAzPS72m6Fm2iIYIAq92pPg0C/8qYTI0sctWcJYUYSew69ti ooU0jCGFnVkObiA1nQ9TsbkxeFGNtCXC8MZcgR/6LgmS8zm9y18mbHpBT4M0+gy9mAI8 +3pDUCYVMjmh8LI3Qv1gGnCEBi6pIKnDaGESRi97TYLDIBUtIKuZzShXoKpwP1PWlJuC /QwyP1M51SOPGBCCwuEexKoh6bV6weOYp3yJX7cjlUlT2KAlslXy2tZaBiFjAuXUBroG zG1A== X-Gm-Message-State: AOAM532J00x/fkzJ1D66E1N48AEIBnLTeYa0dTH3mQT0VcJZO6OvL/4d CsUYvAgcO41ltSdi57RzQiJ5UlUv X-Google-Smtp-Source: ABdhPJyi+SCvgZEi8CfO57sGBzZ0bd8HSdCjbYgN4y9gOUK4xd1tWl21JWuNw+JB3EDm3GM3K+P6rw== X-Received: by 2002:adf:9545:: with SMTP id 63mr4944063wrs.303.1590695940634; Thu, 28 May 2020 12:59:00 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s2sm7102523wmh.11.2020.05.28.12.58.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 12:58:59 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Zihao Zhu , 41572@debbugs.gnu.org References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> From: Dmitry Gutov Message-ID: Date: Thu, 28 May 2020 22:58:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 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.5 (/) On 28.05.2020 18:46, Zihao Zhu wrote: > If I have a project.el based plugin,  and  I wanna use them in a > directory not under VC. Add an mark to force project.el work is easier > than modify the source of plugin or initialize VC system. The problem with that, is that next time we'll get a report that these projects are too slow. Or that people who added .emacs-project file in the middle of a VC repository suddenly get significantly worse file listing performance, without expecting it. So we'd have to add caching to the file list, and then some invalidation, probably. And I'm not a fan of having manual invalidation commands. That's why I'm wary of adding such a separate project type by default, especially when the initial proposal doesn't add any of the advanced features described above, or explains how they won't be necessary. But opinions welcome. > And this  can also be used as a side solution to use project.el in > unsupported VCed project in Emacs (AFAIK, P4(Perforce) is not supported > by vc.el). Perhaps we could add Perforce support to project-vc instead? There was a vc-p4 packages somewhere out there. But if it's entirely dead, we could add such support to project--vc-list-files directly. Or, better yet, release it as a project-p4 package on GNU ELPA. That all depends, of course, on whether the p4 command line utility also has the means to quickly list repository files and add ignores. > IMO, a plain project is like a transient project. One difference is, nobody really expects much from "transient" projects. And this type of project is only applied when the directory is not covered by any other kind of project. From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 00:34:46 2020 Received: (at 41572) by debbugs.gnu.org; 29 May 2020 04:34:46 +0000 Received: from localhost ([127.0.0.1]:53560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeWjF-0004Lk-Sb for submit@debbugs.gnu.org; Fri, 29 May 2020 00:34:46 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:38690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeWjE-0004LY-2z for 41572@debbugs.gnu.org; Fri, 29 May 2020 00:34:44 -0400 Received: by mail-lj1-f193.google.com with SMTP id m18so912521ljo.5 for <41572@debbugs.gnu.org>; Thu, 28 May 2020 21:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=PggfGWRXipMh9fmk4HE05hn8c5c8xytkbb6oOywYKbE=; b=LahYJ84rQukBAEm/fXZVZf+AiFR66uYFTNumyAb6m02B+hH95/xYpnviduoO9qfoJp NVuG0QRs+AJWkTE5/PHqGHSK5Qnhhht3F4yjX1l9/clg2gRu+nU8Cml0LsR1Uq3NQRTs mhIgin8mjR2JbE/K5ziGaXmQW7mr4flLdDHYrPJgqaSlS+kJrhvpuYE3MEXFJ67kWxA/ EW94Wyx19KqXi+EC0JcW3MKsIHE3ka0/3kDH8nmlEBhnGLi5kWXmEeox8keOyOKMvxCa aDyjMq2j0XJw9A+N7hDswQ+unBK4upoIAsK71H1edTm6B31nOpJTKdJ5h3iLU4VvFhjZ 2kEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=PggfGWRXipMh9fmk4HE05hn8c5c8xytkbb6oOywYKbE=; b=JN7zvsvKPP5pd+jO6tBJokmoGE8/f7zhEMlb+Ny/+CDJ7FK3CPsGnCtcwTAPqL3aUd CjrS1gWmQAUzQxHdpWhQ+mHAlaxWule48aTxc2ZO9jrqMTtwx4PVa3thmiqV1myudi2n ljBplW5yqQ06v9XQ79Zkyk8Onydk9swo+xAVML247fj3t4S3BZDc4xW7Fcx+EIQCrIZR GYAiaPGRMcNUlhZm6tMszcKe1zZkj40oX1AEP7UFguH8DsGtlwEo/+kB8LO/UqnL+G5y Ie8DzHh6UD1kIXq4cY5fEKM5FbZ5g0KdOLPgSfmPEHJDNj+m2PxJ8GuibTo6ke0tsMD0 CC9Q== X-Gm-Message-State: AOAM5300gRrhDrOTxBvw612whiViF4ZFCFc5p3MxOCzAWzZ4zkko52L1 0MHDzs4diQdbj0XQ3sOVeXQoPg9Uo3I= X-Google-Smtp-Source: ABdhPJxSoWWZnaGCzOGZmRlB2Ah8hTEzn2dk3gfK3llFuuSq8MOgBx+UH3xw6A+Z6dXChD054OkefA== X-Received: by 2002:a2e:150f:: with SMTP id s15mr3032977ljd.102.1590726877611; Thu, 28 May 2020 21:34:37 -0700 (PDT) Received: from [192.168.101.55] ([45.130.145.124]) by smtp.gmail.com with ESMTPSA id a16sm1760498ljh.111.2020.05.28.21.34.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 21:34:36 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , 41572@debbugs.gnu.org References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> From: Zihao Zhu Message-ID: <679e6ff0-b0e4-e212-34bc-60ff676d0b00@gmail.com> Date: Fri, 29 May 2020 12:34:33 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 41572 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.8 (/) Besides Perforce, Darcs and Fossil aren't supported yet. If we have plain project, we don't have to fiddle around with different sorts of VC. A more netrual suggestion: We can make project-find-functions a defcustom first. On 2020/5/29 上午3:58, Dmitry Gutov wrote: > On 28.05.2020 18:46, Zihao Zhu wrote: >> If I have a project.el based plugin,  and I wanna use them in a >> directory not under VC. Add an mark to force project.el work is >> easier than modify the source of plugin or initialize VC system. > > The problem with that, is that next time we'll get a report that these > projects are too slow. Or that people who added .emacs-project file in > the middle of a VC repository suddenly get significantly worse file > listing performance, without expecting it. > > So we'd have to add caching to the file list, and then some > invalidation, probably. And I'm not a fan of having manual > invalidation commands. > > That's why I'm wary of adding such a separate project type by default, > especially when the initial proposal doesn't add any of the advanced > features described above, or explains how they won't be necessary. > > But opinions welcome. > >> And this  can also be used as a side solution to use project.el in >> unsupported VCed project in Emacs (AFAIK, P4(Perforce) is not >> supported by vc.el). > > Perhaps we could add Perforce support to project-vc instead? > > There was a vc-p4 packages somewhere out there. But if it's entirely > dead, we could add such support to project--vc-list-files directly. > > Or, better yet, release it as a project-p4 package on GNU ELPA. > > That all depends, of course, on whether the p4 command line utility > also has the means to quickly list repository files and add ignores. > >> IMO, a plain project is like a transient project. > > One difference is, nobody really expects much from "transient" > projects. And this type of project is only applied when the directory > is not covered by any other kind of project. From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 03:11:33 2020 Received: (at 41572) by debbugs.gnu.org; 29 May 2020 07:11:33 +0000 Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeZAy-0008Io-UO for submit@debbugs.gnu.org; Fri, 29 May 2020 03:11:33 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:52687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeZAw-0008IZ-QT for 41572@debbugs.gnu.org; Fri, 29 May 2020 03:11:31 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8C23C5C00C1; Fri, 29 May 2020 03:11:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 29 May 2020 03:11:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=warpmail.net; h= from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=fm3; bh=uohvfNk7Xc8mBVcDy07vO553pC tl1n5hWEiCQYj8NNw=; b=UXwaJ7cIl9IbZD/A89Q6KDbUNc+v5wMMsJnryT6qje +fwlGD4Om/+l+hCQV/jGQeXLrblFroIIkWMIqVIydgjE6mISk25Qze2QYXfCOEek Vkx7FvcGv7AEyxSMXsy6iXRjZS5oYK1zKJoeN3CYm+s7Xf3tVPqayMYF4R88G60t PWf3QV6jBEWSih035VfSemizgfjOr6ZIMHkj51btjZN+y9ehPMq+H3gUR6OQhi/7 euX/EG0WxpYlSBU7wLZuzjHKofEsqzO3XC9VcFOeWhd41ccxmjVvUGPBIXc2hifi uWYSAgxXVWqczuIWiWrUGIMnLN3OcAF/NKQQ7nUE/b/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=uohvfN k7Xc8mBVcDy07vO553pCtl1n5hWEiCQYj8NNw=; b=sz/hil1Qjsa/zyTB+Rm6Ml IDibBJvwEo4AT5eqK+YmO4tdjnMUxOod3kHscl0da3pCss4T3sEKEPCqfQjmEhvB Kl9lNr8V1IiyiqOIRMlZip1cq8MTbZvF04BmT8XBnpPqFx3ezL61K46H7pjKIrOf lHtWCRbRogpiO8Aig+Mj5U7qOqyVrMkyeQqoZ/3eEhmYXyO3FLsp/HLjTi/LCwm4 RlsW4d9sbLwc5HZ68r+/pcuJWoqh9VgdfPj/r0HezLNWBge8AZvOnpr/dyhEEqg/ KG+0j+B4AbF4MH74qOgt3DrcJtET6V1+8Uj0//RXtYK3qjjaM4OP02zuf1F9ZRpg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvjedguddtlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufhffjgfkfgggtgesthdtredttdertdenucfhrhhomhepfdfrhhhi lhhiphcumfdrfdcuoehphhhilhhiphesfigrrhhpmhgrihhlrdhnvghtqeenucggtffrrg htthgvrhhnpeeiudffuedvhfetfedvledtveektdehtdfgueekkedtkeefgedtheegieff leefleenucffohhmrghinheptghhihhsvghlrghpphdrtghomhdpihhrihhfrdhfrhenuc fkphepjeelrddvudelrddvtdeirddvvdefnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepphhhihhlihhpseifrghrphhmrghilhdrnhgvth X-ME-Proxy: Received: from localhost (p4fdbcedf.dip0.t-ipconnect.de [79.219.206.223]) by mail.messagingengine.com (Postfix) with ESMTPA id EDEF03280067; Fri, 29 May 2020 03:11:24 -0400 (EDT) From: "Philip K." To: Zihao Zhu Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <679e6ff0-b0e4-e212-34bc-60ff676d0b00@gmail.com> Date: Fri, 29 May 2020 09:11:22 +0200 In-Reply-To: <679e6ff0-b0e4-e212-34bc-60ff676d0b00@gmail.com> (Zihao Zhu's message of "Fri, 29 May 2020 12:34:33 +0800") Message-ID: <87k10vnrl1.fsf@warpmail.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: 41572@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: -1.7 (-) Zihao Zhu writes: > Besides Perforce, Darcs and Fossil aren't supported yet. If we have > plain project, we don't have to fiddle around with different sorts of > VC. Actually Fossil and Dards are supported, but you have to install the vc backends: - http://chiselapp.com/user/venks/repository/emacs-fossil - https://www.irif.fr/~jch//software/repos/vc-darcs/ -- Philip K. From debbugs-submit-bounces@debbugs.gnu.org Fri May 29 09:58:41 2020 Received: (at 41572) by debbugs.gnu.org; 29 May 2020 13:58:41 +0000 Received: from localhost ([127.0.0.1]:55688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefWy-00047h-Jq for submit@debbugs.gnu.org; Fri, 29 May 2020 09:58:41 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:37809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jefWi-00046m-DP for 41572@debbugs.gnu.org; Fri, 29 May 2020 09:58:39 -0400 Received: by mail-wm1-f45.google.com with SMTP id f5so3664675wmh.2 for <41572@debbugs.gnu.org>; Fri, 29 May 2020 06:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N++1gk0G3IekXNkPhcG/4JBHrD7T2KbFdhs7usna9fk=; b=mGrcHWT15SYfmcOAJQGdVZ8N9VMpxFlaZ2XGFKzuvUhIrNdvzykMZaOQu7yokzeZI5 apsYwc1sFNgAGjIHVMUvCC3xUu+AXz7IiAqicUmtskzHgKk4R7sQ2NhVFu25M4rjd+Yv C+uqwNeLyj3JnGLcdokHE31ujE7nTjv6J8mKn8aadzB/mEGu4IQMVGY0/be2ttlcZNHw Jmxkz8kcrnUhC3M7gXe64sFN3Rg3hP/uIGTjkv8h7qPx94iA8qVazWt0nOreAwupoDnA +DV4ZMsNivJbtUUE5M2U0gXrxAjZdBkRklmAcl09VJhqqKyeCvQz3Kezk3kw3rKcBofB mqTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N++1gk0G3IekXNkPhcG/4JBHrD7T2KbFdhs7usna9fk=; b=hT/ziwbU1yvAn+48aHIuvePcXPjuL32FK6R6UJpOqAd4S+3K23stPp0URGa/l8vUyb FDYUINe1Zz7RDbmNWeslqdhkhEc+kQItY3psqeRI0+YCWwaC4pVUag+ZRE+BswS/yycC l8W12a09rtKIyldh3hKC45U0QRDwPgJLgnh+YJa+HxbrbR+dqMjP9bD0qGE6mZUp3SFb 8J55xVX8VYTvctjbB5kk3SJXgwTGhNHpv4qY4zPWrKoWsSvCfAp6+fgzMaJdvHbOkbpU gRO7m036eEG6YS4kikHx5VVuVeXvHZhM6zb/ylQzaQX9y/iAVdMOH8HbeC/6gPsrxNwY Ms3g== X-Gm-Message-State: AOAM5339Pwco7fM+6RZ7ZJrLD5a/t9/AQLsYCko2gWjnaJV7DkSQNpJp D1JSEkQcvoWEsTTdKp0CozUqGwhh X-Google-Smtp-Source: ABdhPJzli2qtOONLr+BLA63EB+VQTDHbzgtjJf9+JsOSRui/ZRvrlqJIqhpqQ6Jo6Ga3j++0lPx/4A== X-Received: by 2002:a1c:1b17:: with SMTP id b23mr8564908wmb.3.1590760698232; Fri, 29 May 2020 06:58:18 -0700 (PDT) Received: from [192.168.0.69] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id q1sm10237573wmc.12.2020.05.29.06.58.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 06:58:17 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Zihao Zhu , 41572@debbugs.gnu.org References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <679e6ff0-b0e4-e212-34bc-60ff676d0b00@gmail.com> From: Dmitry Gutov Message-ID: Date: Fri, 29 May 2020 16:58:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <679e6ff0-b0e4-e212-34bc-60ff676d0b00@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 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.5 (/) On 29.05.2020 07:34, Zihao Zhu wrote: > > A more netrual suggestion: We can make project-find-functions a > defcustom first. It's a hook. It's stable, you can use it. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 02 20:28:29 2020 Received: (at 41572) by debbugs.gnu.org; 3 Jun 2020 00:28:29 +0000 Received: from localhost ([127.0.0.1]:41355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgHGf-0002yQ-6w for submit@debbugs.gnu.org; Tue, 02 Jun 2020 20:28:29 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:48723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgHGd-0002y6-OS for 41572@debbugs.gnu.org; Tue, 02 Jun 2020 20:28:28 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 16DCEC0009; Wed, 3 Jun 2020 00:28:18 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> Date: Wed, 03 Jun 2020 02:40:32 +0300 In-Reply-To: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> (Dmitry Gutov's message of "Thu, 28 May 2020 15:35:55 +0300") Message-ID: <87pnahjgdr.fsf@linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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.7 (-) > Do you have a lot of projects that aren't backed by VC repositories? Usually new projects in early stages of development not ready to commit even the initial revision. However, maybe in this case better to employ some heuristics to detect the project root, e.g. to search for such common files as "Gemfile" for Ruby, "mix.exs" for Elixir, etc. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 03 07:04:28 2020 Received: (at 41572) by debbugs.gnu.org; 3 Jun 2020 11:04:28 +0000 Received: from localhost ([127.0.0.1]:42153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgRC8-0006KU-0P for submit@debbugs.gnu.org; Wed, 03 Jun 2020 07:04:28 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:40528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgRC5-0006KB-6F for 41572@debbugs.gnu.org; Wed, 03 Jun 2020 07:04:26 -0400 Received: by mail-wr1-f66.google.com with SMTP id h5so1874034wrc.7 for <41572@debbugs.gnu.org>; Wed, 03 Jun 2020 04:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=PIyH/GOmhbnyCW0vo+uGhtwwZOgCBNLyQUgivd7P+r8=; b=S/fK67oU8zhhItqi3QUB0PM8gSzdUSPIE9cS8zx47KLbs7OZht2ECFai9gSFSLKWvF sEtZ5yNdshvP7WKwCFGZ77Dv0gJZckx22amftN2lQyqkmZH8cvDvqrmqG6dS2gN+LU+x ApPcj/i5riWZ3E5kWEgfBlFDMJ7DesT9oQWeTt0TybzZezKU1z+ek4vjC6YjFPitj3KS qm5Z93jpo0giYvgE9EFbHcOf8UK5wC9ZVnxAPxFDisZyEbWRkbxkO63L0QnWc62ZgnyI wWnCsaGnHvJPA+GWcd/gOTmPQRxoJKjyn2G4kAG05kVMx638MwZiAr1lK8Q9Y32MXmqs K+Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=PIyH/GOmhbnyCW0vo+uGhtwwZOgCBNLyQUgivd7P+r8=; b=oXbNvzWu+T0kF8KiKCLU5kApc+A3+/APsvRsFVYRpyxy8McrbG+wQdMlsSutO3z1Ao edXXl+tD7zZ+VjCMZeI/J1Us4uwJY12YiVtor2sZqQph7012ux4pGX0q0RQC/iQ/2ZTm +9K1ZHFUDdWIlR2fUXHw70HcxDnBPfVaFROYQ3gdG11wm2fUJEsxDwhQmaLGNk67YNCM NvZAiGSCyJFNPkCjyGCvvDceWsR7NXhdHayWMt3CC3Ip9eeNS1AViB01goIUS1t+MIf0 Zb266E45+tUw+IxZ/DbMOtiK2QyKnhl4mxhGO+54KRE8XhlNM0r8FI+LudmyymzPQowr AkDg== X-Gm-Message-State: AOAM532omZ+V+UPCh/yqGfuGogisreaCJBsSSEaIIZTtVIb9N/KHxfTk MDcW6KG0hKU6N+saYTagYx4COA== X-Google-Smtp-Source: ABdhPJw6RPEG2P3YmVGS5Xcmu3zd2G+LvIooA3D8fL7kUVYxmUmcgCIKll7lb1Dz7wJ+H6YamzB7Kg== X-Received: by 2002:adf:f183:: with SMTP id h3mr33053835wro.403.1591182259214; Wed, 03 Jun 2020 04:04:19 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:1f68:7ff5:120d:64e]) by smtp.gmail.com with ESMTPSA id t14sm3021124wrb.94.2020.06.03.04.04.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 04:04:18 -0700 (PDT) From: "Basil L. Contovounesios" To: "Philip K." Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <874ks0dz8b.fsf@warpmail.net> Date: Wed, 03 Jun 2020 12:04:12 +0100 In-Reply-To: <874ks0dz8b.fsf@warpmail.net> (Philip K.'s message of "Thu, 28 May 2020 14:24:04 +0200") Message-ID: <87zh9k4dhv.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) 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: 41572 Cc: Zihao Zhu , 41572@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 (-) "Philip K." writes: > Zihao Zhu writes: > >> In your use case. I think we can add variable "project-known-projects",= =20 >> you can=C2=A0 add your favorite directory to it, you can also persist th= is=20 >> variable using savehist.el > > I actually think this is better (given there is a command to add a > directory to the list of known projects), because you could also build a > project switcher on this foundation. > > And if the variable is a user option (which I think it should be), > savehist shouldn't be necessary. FWIW, Emacs 28 now has the user option project-list-file, which is a file populated with the list of known projects maintained in the variable project--list. See the following emacs-devel discussion: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03301.html https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00035.html --=20 Basil From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 05 15:02:24 2020 Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 19:02:24 +0000 Received: from localhost ([127.0.0.1]:49916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhHbk-0001Jk-5x for submit@debbugs.gnu.org; Fri, 05 Jun 2020 15:02:24 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:45222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhHbi-0001EO-8k for 41572@debbugs.gnu.org; Fri, 05 Jun 2020 15:02:22 -0400 Received: by mail-wr1-f43.google.com with SMTP id c3so10774818wru.12 for <41572@debbugs.gnu.org>; Fri, 05 Jun 2020 12:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NKSe5q2bMRqdSQYrw8tE87dpw1jEvSUCdgDzDNbWcQs=; b=A/czDHOXX4ZAIxJF2ou66h2Ge/1T8aUP9Aik3GOjYpHHs0HR2yGeEQ9v7f/YQAuW5P Kkqaw1PUN81rs3lKoxhzcEE5sfWzfhso8pH9PGS4EnNJjdZRNVA/yCo9n+o83pE5JgvG lK9g+AppJynyTraw+tj9bZFiilIHtT2al3o8SAXU0cG1P1PteXWuHwFknxcycWgwMaBI +T78WbugjzuB24Ziyw+nR4mS1iJ6M48WKCFnnQmQYSS5Ua45nPNUbDvSkGKoDmexvQhE Us5ceXdmM3IkJ9j58/NEJKm/lQWUSoDQ2tXrIsAwFK7cMCKvtxr1VPhBTc7e4YPahu3t xM0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NKSe5q2bMRqdSQYrw8tE87dpw1jEvSUCdgDzDNbWcQs=; b=S35GPfT+pltJ7kRzMSF4zH2XT7qqnE5eziPh4Z+Awg64mqwQzlli1uCaKkmWcM1OPY ny0pxQG5I8EStv7xTeIw1tXdoZOuKuZkfj4z9WNSqbX+Lhv7JOBRrlEr6KLF4HjkfWn9 9x2UZGmZEgR+/83MHDwcqq2V9bRp+MusEQaGmTcSHNNqb7lVlu79pPORD8PEI14Ao8rg G+Avs6TTP9se3tmBHRxQzyR6nBjcF7x1XM6Y1R0Q8gkEXIkB8ZydVvFUy0Ar+URfO48o 5UdE42OSTIuKicy59TeYX9BJ43EsXVYKOcy4hmyrL7Een1GnPxcyikBYaktC06btC5zR mdBw== X-Gm-Message-State: AOAM532tPCmPTIseTpBxHmKScRrA3RhQoUEWXGPO4NfO1JrJfiCWPOok IyNfQYcNAA4XIRZiHYt7OJqBhKKI X-Google-Smtp-Source: ABdhPJye5pROzwVQ9VoM3ZcgsdeLfeS9mbdGDmV0GEDdMGXMJ21GaNMMwWP7xykz+U4f65DVZ2s7mA== X-Received: by 2002:adf:b60b:: with SMTP id f11mr11008018wre.7.1591383735115; Fri, 05 Jun 2020 12:02:15 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id o20sm13739198wra.29.2020.06.05.12.02.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jun 2020 12:02:14 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> From: Dmitry Gutov Message-ID: Date: Fri, 5 Jun 2020 22:02:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87pnahjgdr.fsf@linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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.5 (/) On 03.06.2020 02:40, Juri Linkov wrote: >> Do you have a lot of projects that aren't backed by VC repositories? > > Usually new projects in early stages of development > not ready to commit even the initial revision. A 'git init' wouldn't exactly hurt, though. > However, maybe in this case better to employ some heuristics > to detect the project root, e.g. to search for such common files > as "Gemfile" for Ruby, "mix.exs" for Elixir, etc. I like this suggestion better (no "special" files), but would we be able to avoid scope creep? Wouldn't users then expect being able to specify ignored directories in such projects? And then faster indexing (e.g. using caching), compared to the VC backend? Projectile uses the "special file" for the former, and I'm not really fond of its solution for the latter. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 05 15:47:29 2020 Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 19:47:29 +0000 Received: from localhost ([127.0.0.1]:50011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhIJM-0002n8-Ur for submit@debbugs.gnu.org; Fri, 05 Jun 2020 15:47:29 -0400 Received: from mail2.protonmail.ch ([185.70.40.22]:60042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhHvE-00029F-81 for 41572@debbugs.gnu.org; Fri, 05 Jun 2020 15:22:33 -0400 Date: Fri, 05 Jun 2020 19:22:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=protonmail; t=1591384945; bh=i9v6NjKsWKtbmtfWD3azQlOI3b+ytwwKmZ9yI2O9Jt0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=q9PsAt9L3k/+tJIfm0IOc9bmdcb6ymrSKFg2MJwLBlWWGqNbPOBU28h2AhpGtEqvi +HhbUEslg6OVJ8q5zLotl4+fZMFCCzgBzZyI9SOgyOB19pI9AbUf93wrbyhphnZCKL 8K/Vv6GwuaxA+Z+aY4urZYoUGXUHmLDLJOeRrl8tb9kRYKjWQoFTMbFWOmypkGng1m frNO5gqllYTwLePuGUgTo9cCx01C6cPds4lInbQAaA1GCJzMCR9IngfxQUgVmdOx28 ttpbWB5PE5mq70dPzMsCL3DHYa1yFZX2QoGpRGHy+K+BLFpvXUymGf4lmtO4+rnqy5 1NS7s1xAAIXRQ== To: Dmitry Gutov , Juri Linkov From: Theodor Thornhill Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Message-ID: <87ftb92u8q.fsf@thornhill.no> In-Reply-To: References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=4.9 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NEW_DOMAIN_24H, SH_ZRD_HEADERS_FRESH,URIBL_ZRD shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 X-Mailman-Approved-At: Fri, 05 Jun 2020 15:47:26 -0400 Cc: Zhu Zihao , 41572@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: , Reply-To: Theodor Thornhill Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) =20 Hello, =20 =20 "Dmitry Gutov" writes: > I like this suggestion better (no "special" files), but would we be able > to avoid scope creep? Wouldn't users then expect being able to specify > ignored directories in such projects? And then faster indexing (e.g. > using caching), compared to the VC backend? Isn't this already supported? In a major mode I'm making right now I believe I have covered both options: (defcustom elm-root-file "elm.json" "...") =20 =20 (defun elm-project-root (dir) "Create the cons cell `project-root' needs to discover root." (let ((root (locate-dominating-file dir elm-root-file))) (when root (cons 'elm root)))) =20 (cl-defmethod project-root ((project (head elm))) (cdr project)) (cl-defmethod project-ignores ((project (head elm)) dir) (append vc-directory-exclusion-list ;; This could also be a defcustom ofc (list "./elm-stuff/"))) (add-hook 'project-find-functions #'elm-project-root) - This will add both the option to not execute git init, but still find roo= t. - Also grepping will ignore the "node-modulesy" "elm-stuff". - In addition, the vc-directory-exclusion-list can be edited to support arb= itrary patterns, at least with my limited testing. - It should be no problem to add a ".emacs-project" there in your own confi= g? =20 Am I missing something, or is this already available? This of course depend= s on major modes supporting this integration? =20 Theodor =20 =20 > > Projectile uses the "special file" for the former, and I'm not really > fond of its solution for the latter. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 05 19:11:47 2020 Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 23:11:47 +0000 Received: from localhost ([127.0.0.1]:50296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhLV4-0001NH-Sv for submit@debbugs.gnu.org; Fri, 05 Jun 2020 19:11:47 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:52638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhLV4-0001Mz-4P for 41572@debbugs.gnu.org; Fri, 05 Jun 2020 19:11:46 -0400 Received: by mail-wm1-f43.google.com with SMTP id r9so9774921wmh.2 for <41572@debbugs.gnu.org>; Fri, 05 Jun 2020 16:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kO7Jv1p8ZOXkM42UdXLgn3IWoqVFuub4zLRVpfhEGEU=; b=IWmdshvJ6BHWKz0ZEx+jFZrxmEK6M8iucBSyFrREHK3JB4Uf8KJolgdQyVEGG4m744 UIL0d8SR+0PKJVW6YI4jCqSj7/HA534ufObZEowA6XOW5e7I8RMrinc0JwCh34CQSC5F pRbkRjRvQQ4z8p4QBacKZDV7R2G8PMje/kpq0TdMkEIBT//wehJIAIyT6UQ1z7t5uP6M 2NDqatv57Rwvs6oyzcXNX+i0bgOQUcYDzeH7cRryaU79fDUQncTbSkRbmfpOJWVnvZ6X mCbEeF/w1dak9GfY/f2ZQDYvIwdHWan2D0KsBcXBSR37UrGXeApGUbW1L8bA5cZnsQLm x8jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kO7Jv1p8ZOXkM42UdXLgn3IWoqVFuub4zLRVpfhEGEU=; b=Z2PfGyIzJWQY079LWTXsG3Okhyrizq8SJJY/Jx50fpbx2R9QCDN4E3hHa/308drerK L/grqO9V2Y88ob175nYJmT0vosNUACg61vl66aWsuA8dW6g6mzdIePQkb8xgb+SixRCd /tZUQ6bsitfTpel9U2fhwFwhEGqKq6RfcFwzJhKtFN6TxCBNc47FzyTNM9/Ivxvnofso Ft+3zctNsztsU/6rfQBeOBN1iseel9djrb99Zou5tFwTqiNbUYjL3wFQQGaMRmr51jY+ vxoThn0/H3448vQNFqYwcQlnXpbFUamCDZ76LxSGjYy4eJIJZcksEvdzBC/E6mJTWg+5 jH9g== X-Gm-Message-State: AOAM530cmWVKeaaPdfUZfx+RnibB+DyKsCeQsH2S9vSk2sWB05Jmt/l7 q641hQ+cYQRUxBZWXm+Y8pXy153+ X-Google-Smtp-Source: ABdhPJy8H/O1eZdQ1Yjil3QX3fI3qZZod93JZBNsRrPUioyggr6DR4Lplwa+lqaR+Fa0fXpQ8KF95A== X-Received: by 2002:a1c:2e58:: with SMTP id u85mr4753495wmu.123.1591398699876; Fri, 05 Jun 2020 16:11:39 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id k13sm12299458wmj.40.2020.06.05.16.11.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jun 2020 16:11:39 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Theodor Thornhill , Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> From: Dmitry Gutov Message-ID: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> Date: Sat, 6 Jun 2020 02:11:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87ftb92u8q.fsf@thornhill.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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.5 (/) Hi! On 05.06.2020 22:22, Theodor Thornhill wrote: > "Dmitry Gutov" writes: > >> I like this suggestion better (no "special" files), but would we be able >> to avoid scope creep? Wouldn't users then expect being able to specify >> ignored directories in such projects? And then faster indexing (e.g. >> using caching), compared to the VC backend? > > Isn't this already supported? Not in the "plain" project backend as proposed. > In a major mode I'm making right now I believe I have covered both options: Ignoring is covered by the API, yes. How did you cover the caching issue? Also note that unless your new project backend is "good enough", you might make the users' experience worse as a result, at least in some respects. > (defcustom elm-root-file "elm.json" > "...") > > (defun elm-project-root (dir) > "Create the cons cell `project-root' needs to discover root." > (let ((root (locate-dominating-file dir elm-root-file))) > (when root > (cons 'elm root)))) > > (cl-defmethod project-root ((project (head elm))) > (cdr project)) > > (cl-defmethod project-ignores ((project (head elm)) dir) > (append vc-directory-exclusion-list > ;; This could also be a defcustom ofc > (list "./elm-stuff/"))) > > (add-hook 'project-find-functions #'elm-project-root) The code is good. With probably one exception: if you have a big enough project, and it's checked into Git, the VC project will be much faster at indexing files than your project implementation (because project-files by default uses 'find'). But if you also define a faster project-files override, it should be fine. Another issue is, well, if the user has a different package that defines projects installed (maybe Projectile grows project.el integration someday), or they're simply used to the VC backend, they might be surprised with some finer details unless you clearly document that your package does add a new project backend. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 04:48:38 2020 Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 08:48:39 +0000 Received: from localhost ([127.0.0.1]:50673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhUVK-0006zQ-OX for submit@debbugs.gnu.org; Sat, 06 Jun 2020 04:48:38 -0400 Received: from mail1.protonmail.ch ([185.70.40.18]:49009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhUVJ-0006zB-2q for 41572@debbugs.gnu.org; Sat, 06 Jun 2020 04:48:38 -0400 Date: Sat, 06 Jun 2020 08:48:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=protonmail; t=1591433310; bh=BuszfLBo3clOM618Ad6q1UJHx7QBKulH3eFSIQ14BPY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=OrfaucEtMbZktDNzUmlOcKBzF2fH7UJMUZrqHkcZgQhw0BO8KLZJTaU6ts1u7jHjT UMIoXmQkaxv6Ykc7oYRgPkQ6SE9OfXjjmVBtJLi0cxBPcOHTFFEOBeiO0U3JG6Azl0 HWN7PSgADMlhVAEItppVn5oZb763tjRDHtsnF1aNUXneZWQ6uXKknSX9gFRZbn77XF /UQb8UbC5ChYWJYTE/6/sZ4ztL3pV7xeOmo3QLhqlYc/D7/lL/KiZaLO6LXxFW8O/s KucNUT/s5k3//NgGsj4T/6LvYan0xKsmGArnPuwSXzi9eySdGCOMP8A/8+Sfd4hosM hp0PgVHnmEDhA== To: Dmitry Gutov , Juri Linkov From: Theodor Thornhill Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Message-ID: <87d06ck2b0.fsf@thornhill.no> In-Reply-To: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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: , Reply-To: Theodor Thornhill Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) =20 "Dmitry Gutov" writes: Hi! > "Dmitry Gutov" writes: [...] > Not in the "plain" project backend as proposed. I see your point. =20 [...] > Another issue is, well, if the user has a different package that defines > projects installed (maybe Projectile grows project.el integration > someday), or they're simply used to the VC backend, they might be > surprised with some finer details unless you clearly document that your > package does add a new project backend. Thanks - Wasn't aware of this. Seems like a better solution over all is to = enforce the vc-backend? It seems like we get the "transient" version, or th= e "vc" version, but defining your own will have several drawbacks? Theo From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 07:15:29 2020 Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 11:15:29 +0000 Received: from localhost ([127.0.0.1]:50896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhWnR-0006rz-Gs for submit@debbugs.gnu.org; Sat, 06 Jun 2020 07:15:29 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:50258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhWnP-0006rl-T2 for 41572@debbugs.gnu.org; Sat, 06 Jun 2020 07:15:28 -0400 Received: by mail-wm1-f66.google.com with SMTP id v19so10703888wmj.0 for <41572@debbugs.gnu.org>; Sat, 06 Jun 2020 04:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gXG07hb9Hs9uGtBFRerD9m2CxUG7OhwQVSmZjWttqKo=; b=XdyrlHObINGhlL8vXb0Oc59P7XAeAfQ5YESOjYH2LLk9RusKJbdVIOs3vGN+Xy+rME SitBGi5YB5/ldS/YOr6+6ZV1tPspYi6ppGw1GZxqnTSk9BPx7l7erhLiCHJz0VZst3wh 3EAM1/rYHKrfDUAsQJtnMPFEdXV53Q9O2rqrXLIqjEnTyeiCMgnPjk1QwlgWkUCLC/cY PWIiRFoyDYhIWlL7k+ASfvLSfgau3Wb3rdeJiPz8Nbb2HwViEPpFysGdCyVtXnjX6Qx6 5+8NRX5z0SdbWXNcl1sB5KtzLa+TCAllpniy+f9WSt7fF0h6vL2bVmELcnUAphD2Z5l0 Q6QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gXG07hb9Hs9uGtBFRerD9m2CxUG7OhwQVSmZjWttqKo=; b=jJ1BwcRR6j5tvY91dXc0Js8SEM22fhuZzmL+7mP54knSXNvG/qHEKWjmWkqvuZwvOJ alWUYnije36LyjmfOEsOO5ljg0fq3Cj3yk/JGrLeieSgj5A7Xlm6PJMoIQq4tjv9KaWi X0igSCqI+efE6Be0zBfqoaB5eZcCm0XF8OOo3w/g5VqUT36oPs+Wd4tJNX9WFcoAqLaE jM132IF3/FhT4Ffx3/b77o9AqTY+RtouqT3l2+Pm62Q+IlravnyPljxmY2AxN45A3FNo /PYdCL+mGT7unjtavne6EGU9CIjPvPD1NlHvPnO7iwpzBUr9HsHB/XedU/X4lgDGGMu1 /qag== X-Gm-Message-State: AOAM530FwzrUUuYKIj/bXvIuz3fkzeNLmoklYt3Yrejv+iOlbxki/OA5 P57nM3ey0Dxq9U5Jw9/6MIeJAfG1 X-Google-Smtp-Source: ABdhPJzk7i4iU8aCXiyS2gnopadO0wSk4fyqaz2r+2tpfvVkw+rpG0YycfJoVh6YBIIelrqbO7+GIA== X-Received: by 2002:a7b:c353:: with SMTP id l19mr7274276wmj.187.1591442121893; Sat, 06 Jun 2020 04:15:21 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id m129sm15953292wmf.2.2020.06.06.04.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 04:15:20 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Theodor Thornhill , Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> From: Dmitry Gutov Message-ID: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> Date: Sat, 6 Jun 2020 14:15:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87d06ck2b0.fsf@thornhill.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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.5 (/) On 06.06.2020 11:48, Theodor Thornhill wrote: > Thanks - Wasn't aware of this. Seems like a better solution over all is to enforce the vc-backend? It seems like we get the "transient" version, or the "vc" version, but defining your own will have several drawbacks? Unless you make sure it's full-featured, indeed. But the problem might become more severe in the future if we add more capabilities to projects. This particular problem with speed could be alleviated if we export a utility function similar to project--vc-list-files, so that other impls could use Git's file listing speed. The primary drawback is the semantics: the current impl always follows .gitignore for its ignores (but accepts additional ones), whereas an arbitrary project can have a totally different set of ignores. So, at the very least, I'm in doubt how to write the docstring. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 07:53:52 2020 Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 11:53:52 +0000 Received: from localhost ([127.0.0.1]:50957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXOa-0001U8-Ft for submit@debbugs.gnu.org; Sat, 06 Jun 2020 07:53:52 -0400 Received: from mail-40131.protonmail.ch ([185.70.40.131]:44693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXOW-0001Tn-Fb for 41572@debbugs.gnu.org; Sat, 06 Jun 2020 07:53:50 -0400 Date: Sat, 06 Jun 2020 11:53:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=protonmail; t=1591444421; bh=hiF5EhvOsWU+EE6Ja4TDMkRDODcCIDxVnP6w3ytm1OA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=lrICO8dIIT4Z90bWB43q8s/0A3/DpDqQe8VVNEf3yBXmfsCOE198Vt7QasLShmibV e0AStxGtJ2PrM+n6OotFOX7j8Hp5mh87ZArtULc2wHNPOxvEXIqUNf5bXmDC49qWzO iob1STh0GPtKM0fxKAuj4NYQsIOO0KrqcOz3m/Fdy5YvbBhuMqKhgEzRS4+frkmIap TnZsIrchwxdRpOU83VVeehsAcEXOvA/MQM0qzX/YtQu0aPN5xmHDVFfBV8uBwDKXc6 L322511qYmZHiyKFZHybm6MVX28dvurL4fbcB80+Hmn6JzO2Yt1IoYegtKWOSg1xr8 9uZw6+zA9i1gQ== To: Dmitry Gutov , Juri Linkov From: Theodor Thornhill Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Message-ID: In-Reply-To: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_db20d863af94fcb3624a954aa1757875" X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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: , Reply-To: Theodor Thornhill Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --b1_db20d863af94fcb3624a954aa1757875 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gU2F0LCBKdW4gNiwgMjAyMCBhdCAxMzoxNSwgRG1pdHJ5IEd1dG92IDxkZ3V0b3ZAeWFuZGV4 LnJ1PiB3cm90ZToKCj4+IFVubGVzcyB5b3UgbWFrZSBzdXJlIGl0J3MgZnVsbC1mZWF0dXJlZCwg aW5kZWVkLiBCdXQgdGhlIHByb2JsZW0gbWlnaHQKPiBiZWNvbWUgbW9yZSBzZXZlcmUgaW4gdGhl IGZ1dHVyZSBpZiB3ZSBhZGQgbW9yZSBjYXBhYmlsaXRpZXMgdG8gcHJvamVjdHMuCgpUaGlzIHdv dWxkIGVzc2VudGlhbGx5IG1lYW4gdGhhdCBhdCBsZWFzdCB1bnRpbCB0aGUgYXBpIGlzIGNvbXBs ZXRlbHkgc3RhYmxlIHRoZSBnaXQgdmVyc2lvbiBpcyB0aGUgZGUgZmFjdG8gaW1wbGVtZW50YXRp b24/CgpIb3cgYWJvdXQgYXMgeW91IHByb3Bvc2VkIGV4dHJhY3QgdGhlIHZjIHVudGlsLCB0aGVu IGNvbXBvc2UgZGlmZmVyZW50IHZlcnNpb25zPyBNb3N0IHByb2plY3RzIHdpbGwgdXNlIGl0IGFu eXdheXMsIGFuZCBteSBmb28tbW9kZSBzaG91bGRu4oCZdCBoYXZlIG1pc3Mgb3V0LgoKSSBtZWFu LCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQg4oCcLnByb2plY3TigJ0sIEkgYXNzdW1lIHdlIHN0aWxs IHdhbnQgdG8gdXNlIHZjIGJhY2tlbmQgYWZ0ZXIgd2UgZG8gZ2l0IGluaXQuIFNob3VsZCB3ZSBo YXZlIHRvIGRlbGV0ZSB0aGF0IHNhaWQgZmlsZSB0aGVuPyBXaGF0IGlmIHdlIGFjY2VwdCBzb21l IHBhdHRlcm4sIHRoZW4gbWVyZ2UgYWxsIHRoZSBvdGhlciBmdW5jdGlvbnM/IEkgYmVsaWV2ZSB3 ZSBjYW7igJl0IHVzZSBnZW5lcmljcywgY2FsbC1uZXh0LW1ldGhvZCBhbmQgZnJpZW5kcyBmb3Ig dGhpcz8KCj4+IGFyYml0cmFyeSBwcm9qZWN0IGNhbiBoYXZlIGEgdG90YWxseSBkaWZmZXJlbnQg c2V0IG9mIGlnbm9yZXMuIFNvLCBhdAo+IHRoZSB2ZXJ5IGxlYXN0LCBJJ20gaW4gZG91YnQgaG93 IHRvIHdyaXRlIHRoZSBkb2NzdHJpbmcuCgpBbiBhcmJpdHJhcnkgcHJvamVjdCBjYW4gdGhlbiBq dXN0IGFkZCBhIOKAnGxpc3QgZmlsZeKAnCBmdW5jdGlvbnMsIGFuZCBpZiBnaXQgaXMgbm90IHRo ZXJlLCBpdCB3aWxsIGp1c3QgcmV0dXJuIG5pbAoKVGhlbw== --b1_db20d863af94fcb3624a954aa1757875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0icHJvdG9ubWFpbF9tb2Jp bGVfc2lnbmF0dXJlX2Jsb2NrIj48ZGl2Pk9uIFNhdCwgSnVuIDYsIDIwMjAgYXQgMTM6MTUsIERt aXRyeSBHdXRvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRndXRvdkB5YW5kZXgucnUiIGNsYXNzPSIi PmRndXRvdkB5YW5kZXgucnU8L2E+Jmd0OyB3cm90ZTo8Y2FyZXQ+PC9jYXJldD48L2Rpdj48L2Rp dj48YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+Jmd0OyZu YnNwO1VubGVzcyB5b3UgbWFrZSBzdXJlIGl0J3MgZnVsbC1mZWF0dXJlZCwgaW5kZWVkLiBCdXQg dGhlIHByb2JsZW0gbWlnaHQ8YnI+YmVjb21lIG1vcmUgc2V2ZXJlIGluIHRoZSBmdXR1cmUgaWYg d2UgYWRkIG1vcmUgY2FwYWJpbGl0aWVzIHRvIHByb2plY3RzLjwvYmxvY2txdW90ZT48ZGl2PlRo aXMgd291bGQgZXNzZW50aWFsbHkgbWVhbiB0aGF0IGF0IGxlYXN0IHVudGlsIHRoZSBhcGkgaXMg Y29tcGxldGVseSBzdGFibGUgdGhlIGdpdCB2ZXJzaW9uIGlzIHRoZSBkZSBmYWN0byBpbXBsZW1l bnRhdGlvbj88L2Rpdj48ZGl2Pjxicj48L2Rpdj5Ib3cgYWJvdXQgYXMgeW91IHByb3Bvc2VkIGV4 dHJhY3QgdGhlIHZjIHVudGlsLCB0aGVuIGNvbXBvc2UgZGlmZmVyZW50IHZlcnNpb25zPyBNb3N0 IHByb2plY3RzIHdpbGwgdXNlIGl0IGFueXdheXMsIGFuZCBteSBmb28tbW9kZSBzaG91bGRu4oCZ dCBoYXZlIG1pc3Mgb3V0LjxjYXJldD48L2NhcmV0PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBtZWFu LCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQg4oCcLnByb2plY3TigJ0sIEkgYXNzdW1lIHdlIHN0aWxs IHdhbnQgdG8gdXNlIHZjIGJhY2tlbmQgYWZ0ZXIgd2UgZG8gZ2l0IGluaXQuIFNob3VsZCB3ZSBo YXZlIHRvIGRlbGV0ZSB0aGF0IHNhaWQgZmlsZSB0aGVuPyBXaGF0IGlmIHdlIGFjY2VwdCBzb21l IHBhdHRlcm4sIHRoZW4gbWVyZ2UgYWxsIHRoZSBvdGhlciBmdW5jdGlvbnM/IEkgYmVsaWV2ZSB3 ZSBjYW7igJl0IHVzZSBnZW5lcmljcywgY2FsbC1uZXh0LW1ldGhvZCBhbmQgZnJpZW5kcyBmb3Ig dGhpcz88YnI+PGJyPjwvZGl2PjxkaXY+PGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVv dGUiIHR5cGU9ImNpdGUiPiZndDsmbmJzcDthcmJpdHJhcnkgcHJvamVjdCBjYW4gaGF2ZSBhIHRv dGFsbHkgZGlmZmVyZW50IHNldCBvZiBpZ25vcmVzLiBTbywgYXQ8YnI+dGhlIHZlcnkgbGVhc3Qs IEknbSBpbiBkb3VidCBob3cgdG8gd3JpdGUgdGhlIGRvY3N0cmluZy48YnI+PGJyPjwvYmxvY2tx dW90ZT48ZGl2PkFuIGFyYml0cmFyeSBwcm9qZWN0IGNhbiB0aGVuIGp1c3QgYWRkIGEg4oCcbGlz dCBmaWxl4oCcIGZ1bmN0aW9ucywgYW5kIGlmIGdpdCBpcyBub3QgdGhlcmUsIGl0IHdpbGwganVz dCByZXR1cm4gbmlsJm5ic3A7PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVvJm5i c3A7PC9kaXY+ --b1_db20d863af94fcb3624a954aa1757875-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 08:18:02 2020 Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 12:18:02 +0000 Received: from localhost ([127.0.0.1]:51004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXlx-00025e-RY for submit@debbugs.gnu.org; Sat, 06 Jun 2020 08:18:02 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:37853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhXlv-00025R-D9 for 41572@debbugs.gnu.org; Sat, 06 Jun 2020 08:17:59 -0400 Received: by mail-wm1-f52.google.com with SMTP id y20so3889978wmi.2 for <41572@debbugs.gnu.org>; Sat, 06 Jun 2020 05:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Of2gLaV61Cs4M5yuC5g7LoRhCOsUVY67f1//MDT+2gE=; b=g6su/AS1HCZnv6rW6hrjJHGxJQaJJdo9VGrMfySDPz7Bxo/sdjcsuitRR8FgAKH5dY rWIFLw08Lh5oAFbIGIyQUDTrJcJsgHn8LkWLAJFd1TU9QV0BrUUP6gjIAIBhstuDzsBA gBGHnFQxa4zjzX8IIfoIue6chgfX/r6+irOBHUJy8FdLOXwgrlO7fXvQk3yKc1cifLwb ZJXRCW/RdRqDTnzEmnEdyxX4jSclnMwLBMVslsbw4UCL83qnB3BVscc15kek+6nMUhpD fltr1jQPMxDEg2sAyCMCe5PfxKpYCYJ94zbB3+dF77oJ//maGscEUw+RJ7hqywqOnEFZ xgdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Of2gLaV61Cs4M5yuC5g7LoRhCOsUVY67f1//MDT+2gE=; b=eI9C04rOFouy9NIsqqguPE3XrbKyZv8lgzcXBfQpd7lPkJj7Nd5bzgevoOepxvL3qG Atn8/d1jBzWEGjeAuyeiMiyc1yC4HDkRmiZ8pAFnoQNKGOEoR2urLR3g79Bpiz9iufZi UWLxaZhAO7UM3GL+a6e7cVR94sdt6T6SRsk6tj9WJpQd+Je55YDFm80drmyvsqAm0Nqr KsaKsusf8PD5l1E8krGwxZTavIu1EtH7QA60RxhdMZ3vG4yU1ssR1mv7XIx3ZeBETMdU GoFrz427B22JiGzEdR93zk70j+5QNmziR4hD3uLp87Ao3tLd2R+22DxdJ1+QcRvThTHn WNdg== X-Gm-Message-State: AOAM533C1OBUsmAhY3aAuUU9FbSVMTVCBz9bLDfKNdJGPawT9n97GGrW D70ZbPL09X4lh7cxeroPC/MdTVZa X-Google-Smtp-Source: ABdhPJxe48RNNcFd2vdRPBFv96KHt3wmVvPQD+q97kqSLlb5sw/phrKltwR5uZMtXekffk/JFvCpIQ== X-Received: by 2002:a1c:1d94:: with SMTP id d142mr7279286wmd.42.1591445873187; Sat, 06 Jun 2020 05:17:53 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id a124sm15259346wmh.4.2020.06.06.05.17.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 05:17:52 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Theodor Thornhill , Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> From: Dmitry Gutov Message-ID: Date: Sat, 6 Jun 2020 15:17:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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.5 (/) On 06.06.2020 14:53, Theodor Thornhill wrote: > > > On Sat, Jun 6, 2020 at 13:15, Dmitry Gutov > wrote: >> > Unless you make sure it's full-featured, indeed. But the problem might >> become more severe in the future if we add more capabilities to projects. > This would essentially mean that at least until the api is completely > stable the git version is the de facto implementation? It's the "official" one, but, for instance, Projectile which we already mentioned before, could hook into the API and provide the same level of performance. As far as future features go, it could be a concern, but can be addressed as the features appear. The crucial point is, though, that "lightweight" project backends are probably not a good idea. > How about as you proposed extract the vc until, then compose different > versions? Most projects will use it anyways, and my foo-mode shouldn’t > have miss out. Not sure what you're saying here. > I mean, if we want to support “.project”, I assume we still want to use > vc backend after we do git init. Should we have to delete that said file > then? I think the "simple" backend, if added, would go after the VC one in project-find-functions. So doing 'git init' would automatically switch over, with all the accompanying consequences. > What if we accept some pattern, then merge all the other > functions? I believe we can’t use generics, call-next-method and friends > for this? Could you elaborate? >> > arbitrary project can have a totally different set of ignores. So, at >> the very least, I'm in doubt how to write the docstring. >> > An arbitrary project can then just add a “list file“ functions, and if > git is not there, it will just return nil How does that address the question of ignores? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 06 09:37:25 2020 Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 13:37:25 +0000 Received: from localhost ([127.0.0.1]:51081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZ0n-0006Hv-6i for submit@debbugs.gnu.org; Sat, 06 Jun 2020 09:37:25 -0400 Received: from mail-40134.protonmail.ch ([185.70.40.134]:14583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhZ0k-0006Hf-Tn for 41572@debbugs.gnu.org; Sat, 06 Jun 2020 09:37:24 -0400 Date: Sat, 06 Jun 2020 13:37:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=protonmail; t=1591450636; bh=a7GAOn8wtRVEHIH8KAnbjY1RWEzdrnc9o7uNAvy4/ns=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=UhZG14XD/ZQASHR4XgUFOXA2uLfj0OF+PsPPSxUzpkzg9dKcfU81Cb1hd9IP0hHfz Nty4DQBqKzf0Ftu9XzYjIKIArzmnvK/AyQw/2BbAdTeIL+oZIkwinHpw1IDDeCh5wG gd1eivVDt5WY7OTVZlaau65S2JFqENrMhol91QxxTnkCQCu1P2DRXl7Gj1EvVxEDCs nj75YvSzLX9jeoXvX5iuXQ5j7cSKnJcmowKGeDQGe7KYr2AG50ekFmncIyDrVjL4xn puCIJTOVbjhNgPvXC61iwU+LXdOji/yr11AZi116Pp2sRPIT+TT9z7CBDwR14xsAtQ xEKMFl9TNTKZg== To: Dmitry Gutov , Juri Linkov From: Theodor Thornhill Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Message-ID: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> In-Reply-To: References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_157792d5398ea306f2df5fd06a21fb79" X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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: , Reply-To: Theodor Thornhill Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --b1_157792d5398ea306f2df5fd06a21fb79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 PiBDb3VsZCB5b3UgZWxhYm9yYXRlPwoKQWN0dWFsbHksIEkgdGhpbmsgSeKAmWxsIHdpdGhkcmF3 IHRoZSBvdmVyIGVuZ2luZWVyaW5nIHRlbmRlbmN5IG9mIG1pbmUgaGVyZSBhbmQgcmF0aGVyIHJl ZmluZToKCkkgYmVsaWV2ZSBpdCBpcyBhcHByb3ByaWF0ZSB0byB2aWV3IHByb2plY3QuZWwgdG8g aGF2ZSB0d28gZGlmZmVyZW50IGZvY3VzZXMgaGVyZTogb25lIGZvciB0aGUgZ2VuZXJhbCBpZGVh IGFuZCBvbmUgbWlub3IgbW9kZSAob3ZlcmxvYWRlZCB0ZXJtLCBJIGtub3cuLi4pIGZvciB2Yy4K ClRvIGhlbHAgdGhlIG91dCBvZiB0aGUgYm94IGV4cGVyaWVuY2Ugd2l0aCB0aGUgcHJvamVjdC12 YyBJIHRoaW5rIGVpdGhlcjoKCi0gYWRkaW5nIGNvbW1vbiBwYXR0ZXJucyB0byBwcm9qZWN0LXZj LWlnbm9yZXMgaW5zdGVhZCBvZiBuaWwsIHRvIGFjY29tbW9kYXRlIGZvciBpbXByb3Blcmx5IGNv bmZpZ3VyZWQgLmdpdGlnbm9yZQoKLSBzaW1wbHkgYWRkaW5nIGRvY3VtZW50YXRpb24gZW1waGFz aXppbmcgcHJvamVjdC12Y3MgcmVsaWFuY2Ugb24gLmdpdGlnbm9yZQoKQXMgc3VjaCBpdCBjb3Vs ZCBiZSBuZWl0aGVyIHByb2plY3Qgbm9yIHByb2plY3QtdmMgcmVzcG9uc2liaWxpdHkgdG8gYWRk IHRoZSBwbGFpbiB2ZXJzaW9uLgoKV2lsbCBwcm9qZWN0LmVsIGJlIHNwbGl0IGF0IHNvbWUgcG9p bnQ/IEkgbWVhbiBtb3ZpbmcgdmMgdGhpbmdzIHRvIHZjLgpJIGZvciBvbmUgKG1heWJlIG9ubHkg b25lKSBmaW5kIHRoZSBzY29wZSBvZiBwcm9qZWN0LmVsIGEgYml0IGNvbmZ1c2luZwoKVGhlbw== --b1_157792d5398ea306f2df5fd06a21fb79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9InByb3Rv bm1haWxfcXVvdGUiIHR5cGU9ImNpdGUiPkNvdWxkIHlvdSBlbGFib3JhdGU/PGJyPjxjYXJldD48 L2NhcmV0PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5BY3R1YWxseSwgSSB0aGluayBJ4oCZ bGwgd2l0aGRyYXcgdGhlIG92ZXIgZW5naW5lZXJpbmcgdGVuZGVuY3kgb2YgbWluZSBoZXJlIGFu ZCByYXRoZXIgcmVmaW5lOjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBiZWxpZXZlIGl0IGlzIGFwcHJv cHJpYXRlIHRvIHZpZXcgcHJvamVjdC5lbCB0byBoYXZlIHR3byBkaWZmZXJlbnQgZm9jdXNlcyBo ZXJlOiBvbmUgZm9yIHRoZSBnZW5lcmFsIGlkZWEgYW5kIG9uZSBtaW5vciBtb2RlIChvdmVybG9h ZGVkIHRlcm0sIEkga25vdy4uLikgZm9yIHZjLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VG8g aGVscCB0aGUgb3V0IG9mIHRoZSBib3ggZXhwZXJpZW5jZSB3aXRoIHRoZSBwcm9qZWN0LXZjIEkg dGhpbmsgZWl0aGVyOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LSBhZGRpbmcgY29tbW9uIHBh dHRlcm5zIHRvIHByb2plY3QtdmMtaWdub3JlcyBpbnN0ZWFkIG9mIG5pbCwgdG8gYWNjb21tb2Rh dGUgZm9yIGltcHJvcGVybHkgY29uZmlndXJlZCAuZ2l0aWdub3JlPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4tIHNpbXBseSBhZGRpbmcgZG9jdW1lbnRhdGlvbiBlbXBoYXNpemluZyBwcm9qZWN0 LXZjcyByZWxpYW5jZSBvbiAuZ2l0aWdub3JlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyBz dWNoIGl0IGNvdWxkIGJlIG5laXRoZXIgcHJvamVjdCBub3IgcHJvamVjdC12YyByZXNwb25zaWJp bGl0eSB0byBhZGQgdGhlIHBsYWluIHZlcnNpb24uJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5XaWxsIHByb2plY3QuZWwgYmUgc3BsaXQgYXQgc29tZSBwb2ludD8gSSBtZWFuIG1vdmlu ZyB2YyB0aGluZ3MgdG8gdmMuJm5ic3A7PC9kaXY+PGRpdj5JIGZvciBvbmUgKG1heWJlIG9ubHkg b25lKSBmaW5kIHRoZSBzY29wZSBvZiBwcm9qZWN0LmVsIGEgYml0IGNvbmZ1c2luZzwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+VGhlbzxjYXJldD48L2NhcmV0Pjxicj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48L2Rpdj4= --b1_157792d5398ea306f2df5fd06a21fb79-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 20 16:55:19 2020 Received: (at 41572) by debbugs.gnu.org; 20 Jul 2020 20:55:19 +0000 Received: from localhost ([127.0.0.1]:36355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jxcog-0003y4-O8 for submit@debbugs.gnu.org; Mon, 20 Jul 2020 16:55:19 -0400 Received: from mail-ej1-f65.google.com ([209.85.218.65]:44986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jxcof-0003xn-GA for 41572@debbugs.gnu.org; Mon, 20 Jul 2020 16:55:17 -0400 Received: by mail-ej1-f65.google.com with SMTP id ga4so19456472ejb.11 for <41572@debbugs.gnu.org>; Mon, 20 Jul 2020 13:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AZ9V8Nyl8T9foV4/q489uvGEnFbzEmcpaU4kysrp6wU=; b=q/fBKOnFMtAWsohlrlwaD03E9P+AwYakG5/A8WsXadFtLgBjBGTiGAYSuwBqhCVDHL rZ8Tjn6YxNBr5o3JdZ+4srDO88hyw8yGsfdUW0kLBpdxsuO444N7JYsGoc9YvYhKJdfB OxyoqOpz5aIB3+eGGtQX05nrmyzwhp6JPf/hhHJLvw7LyeZJmidkCZvN63hfCbsDuqUi dFYaCUnxoCd9Fhlcta2oCO4fBYmasPH7mCy1FLbg0rS2usvayT4Mjhmfkok/zMJ6urbM gLHUJZ4vSTdlztSiwDMl6ABM4DlxDyCoeahqBdwl+9zye9fyl6KzC0KvUJRS+ID097Ft BNkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AZ9V8Nyl8T9foV4/q489uvGEnFbzEmcpaU4kysrp6wU=; b=aLGhMaiB3PToHTM5DNR8RGeUF9nYfHSFIPDJlvLq4pdpwOrkxX7LPEjR+qAt/x+LL3 nxyNSurFO3XI3e7sxGnMZxkVpH31sbEhhbIYQG3jPWmmdN82nyXrMW29uCJZadgh6IxR SQscSZKfpzmAXvWa0H30qGZw2EAse8YLl6oxO3eJTg6Rpq9wktXFc1fpy7kdTE31ooYP kyJImmFd+n6q0R+XIBpymvVdx2YorA85wBub8FX3qxbd61imJZK6N1iT89SoswT3obvj cChZSRcYO6bV1DQWDZtDzSbNFFmMGqOAnGYGOUROq+cMB8Lr3knrg2N/LeUOBiWv4nbv ayIQ== X-Gm-Message-State: AOAM531EqAW208F/N3Mrc7Mps0yWrGhU25K3dcAHFtanfZ5hioGCLih3 beYmWLS2qHwU9p35Tya+4zkJE5wO X-Google-Smtp-Source: ABdhPJzo2Au0x8R+W3B8Asx3o0mqY3evQMw2UxYgsgnRw9KlRtvuODbXmGHLct2zb22ZcnzYF6w33Q== X-Received: by 2002:a17:906:3ac4:: with SMTP id z4mr21034508ejd.65.1595278511281; Mon, 20 Jul 2020 13:55:11 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d23sm15195098eja.27.2020.07.20.13.55.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2020 13:55:10 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Theodor Thornhill , Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> From: Dmitry Gutov Message-ID: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> Date: Mon, 20 Jul 2020 23:55:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , 41572@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 (-) On 06.06.2020 16:37, Theodor Thornhill wrote: > > >> Could you elaborate? > > Actually, I think I’ll withdraw the over engineering tendency of mine > here and rather refine: > > I believe it is appropriate to view project.el to have two different > focuses here: one for the general idea and one minor mode (overloaded > term, I know...) for vc. Right. > To help the out of the box experience with the project-vc I think either: > > - adding common patterns to project-vc-ignores instead of nil, to > accommodate for improperly configured .gitignore > > - simply adding documentation emphasizing project-vcs reliance on .gitignore I have hopefully addressed the above items in commit 7259377. Let me know if you think the description is missing something. > As such it could be neither project nor project-vc responsibility to add > the plain version. project-vc could morph into something like "project-auto"... with a customizable list of project markers. Still thinking about it. > Will project.el be split at some point? I mean moving vc things to vc. > I for one (maybe only one) find the scope of project.el a bit confusing That would be a good idea, but I think that would make it two different packages. ELPA Core doesn't understand multifile packages, AFAIK. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 30 23:11:23 2020 Received: (at 41572) by debbugs.gnu.org; 1 Oct 2020 03:11:23 +0000 Received: from localhost ([127.0.0.1]:33683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNp06-00045T-Tm for submit@debbugs.gnu.org; Wed, 30 Sep 2020 23:11:23 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNp05-00045E-Mz for 41572@debbugs.gnu.org; Wed, 30 Sep 2020 23:11:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=7QtiPewNwwJ/J0BLVs1mj7+GNSTnjnFCNK3R0S7UxcA=; b=MIO9uS6Fq2oA6o4/jFoyOqopX8 UWDJ0LSeWyzCLFH1mY23jLfzD66vJvylihO5/8+xTaNt17rQsgV9IBT+3GX5z6TK81tEE9mNF7B// dLu8gVcUVp7dmlhkytVWWlssaI288Mpih3rl/EzrxQmCahvmlSr7iIQjtN8TGRPCihGE=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNozw-0001K6-6G; Thu, 01 Oct 2020 05:11:15 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> X-Now-Playing: Matmos's _The West_: "Action At A Distance" Date: Thu, 01 Oct 2020 05:11:10 +0200 In-Reply-To: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> (Dmitry Gutov's message of "Mon, 20 Jul 2020 23:55:08 +0300") Message-ID: <871riitzch.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: If I'm skimming this thread correctly, there wasn't much enthusiasm for the proposed new functionality, so I'm closing this bug report. If there's further progress to be made here, please respond to t [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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 (-) If I'm skimming this thread correctly, there wasn't much enthusiasm for the proposed new functionality, so I'm closing this bug report. If there's further progress to be made here, please respond to the debbugs address and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 30 23:11:28 2020 Received: (at control) by debbugs.gnu.org; 1 Oct 2020 03:11:28 +0000 Received: from localhost ([127.0.0.1]:33687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNp0C-00045n-7e for submit@debbugs.gnu.org; Wed, 30 Sep 2020 23:11:28 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNp0B-00045N-7h for control@debbugs.gnu.org; Wed, 30 Sep 2020 23:11:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eDWsRUTSQ/HbW/PO3MrlWBzFsN9H76OezCvVxNN0Bo0=; b=H2TsgmO1aukM4Z8US6diQ8Nwmc 1OIwEZJdhPn2+a6QH+/GuWdvtf9TERgzd4PjVTJqaCl+QEVDRpdFIsn4hGZa0E+ieoLtxB09RtUHz IiSoIr7l3jnFiOqrwKQS9IG/yjYZNCZiGtj6BZK8M+L1oSXWpYHQ6KcNX/2zVCo3aKaw=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNp03-0001KG-IG for control@debbugs.gnu.org; Thu, 01 Oct 2020 05:11:21 +0200 Date: Thu, 01 Oct 2020 05:11:18 +0200 Message-Id: <87zh56skrt.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #41572 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 41572 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control 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 (-) close 41572 quit From unknown Wed Jun 18 00:21:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 29 Oct 2020 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 25 18:38:09 2021 Received: (at control) by debbugs.gnu.org; 25 Sep 2021 22:38:09 +0000 Received: from localhost ([127.0.0.1]:35037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUGJ7-00056R-1a for submit@debbugs.gnu.org; Sat, 25 Sep 2021 18:38:09 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:35449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUGJ4-00055u-3O for control@debbugs.gnu.org; Sat, 25 Sep 2021 18:38:08 -0400 Received: by mail-wr1-f53.google.com with SMTP id i23so38928551wrb.2 for ; Sat, 25 Sep 2021 15:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=Aol3+r4kjFBDS416xw+zxlst0BAwhI8GTpANHnAOjEo=; b=XcbQpiVNH2qbag7SLWE6H2Wy7WQ5+uizMXW9NWVxI7Ux3rL0K1w0Kj68tww31CtCvf 7NzEHE2RONEjdRNXj7Y/zSeFLo+FSFDTl87gEtpYZ9WvPAMLZXYPP8Bq/X3VVc9WAD0v JoPA99LppIu1KPyokkrWrtdczvoG21ygbWE07FrZ+AzQNxxWRzOhSJlXvWtTtErS6Y22 Abs6SPpItMHTkrxRfaFMOXD0jM+MiIkn3qiYWg/eAXhh5wDcpkzXrwibYKQW3oIZ3vVm xQW/rtsddG1Nj2DnGffuW3RrCgzFj1fnXj+jcIU3W+k52O6hwJ+4Mbh28lfsXuYuY67a BFRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Aol3+r4kjFBDS416xw+zxlst0BAwhI8GTpANHnAOjEo=; b=kFjjR7RvJgfAMiVtZhphsz5IKutFu1dtL0GP6xAIffMwTALiE01qaN5XT99HGTkLTQ cQ00e5n0BvWMM8pxvK8phJ3D/Zq0LJXVI4L3nIjSos+CjKL/GFWguS+8KHb0kLIyXEDo UJeGT31sNP4XdIck2l8Zf3JCiAewJvDeeBpdndyNj8hi0KUufas3GXgzPG1dhBL7PPBq 5+wOlJVe5a4BwvzvRn3QE0AVG3xhEnXW4i2IZCcXl9O4V9/l3A948D5bShqOQLJeJlNo FIeeIHLgweb1d7j2zVEe0PDIqrFfl4HYWEX1DVnfa+nTZivPVEZ0Ms/GMDLXCTxJGH7k W1mQ== X-Gm-Message-State: AOAM531iPRrNPkKr2+uyt3m1FnIpF++uGt5OMC5MEIKa2Vv/qHHG54pU 4O5NE7I1j5NOhbkMPHNWNxyrnVGwz8k= X-Google-Smtp-Source: ABdhPJyC42NZQMl4UGCUqdtLzZ+aO/8WK0Nb4TMXbai/nxRwiV2gYEuHRCIUib0tdJpvDKSD5mL0jA== X-Received: by 2002:adf:d084:: with SMTP id y4mr18993432wrh.249.1632609480146; Sat, 25 Sep 2021 15:38:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t6sm15931332wmj.12.2021.09.25.15.37.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 15:37:59 -0700 (PDT) To: control@debbugs.gnu.org From: Dmitry Gutov Subject: unarchive 41572 Message-ID: <83a0e004-71de-fb27-a5d6-2966c514dd74@yandex.ru> Date: Sun, 26 Sep 2021 01:37:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: control 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.5 (/) unarchive 41572 From unknown Wed Jun 18 00:21:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: Did not alter fixed versions and reopened. Date: Sat, 25 Sep 2021 22:42:02 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # Did not alter fixed versions and reopened. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 25 19:13:50 2021 Received: (at 41572) by debbugs.gnu.org; 25 Sep 2021 23:13:50 +0000 Received: from localhost ([127.0.0.1]:35096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUGrd-0008Lj-Tp for submit@debbugs.gnu.org; Sat, 25 Sep 2021 19:13:50 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:44690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUGrc-0008LT-6m for 41572@debbugs.gnu.org; Sat, 25 Sep 2021 19:13:48 -0400 Received: by mail-wr1-f48.google.com with SMTP id d6so38848262wrc.11 for <41572@debbugs.gnu.org>; Sat, 25 Sep 2021 16:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3QNX3ntMhZb0ls26odfk48nxG7WM5TsFRBN/18B6MJo=; b=mcpfSKrB2gy+8bTYlZyDkKAKabgVkTZ0iA8fQlwa3LBBDw3Gwts5CeAPEM+ycngwz1 TItX17ICK8a+VqBjQpRAVEt0GDCTXcUe/MxGYyBkm6SP6IK6l0BOibWxxLHTQkd8rZzU WAy8/YZhVAJyr0M0PUsry8gxYKf6Z4Wnap8GqCAOV/diIdw7Fu7YV8f/e5mbKfmFhvNi TCoqp/z3XIqzHCl+CdsTbbaPDF3nSsb51HENXe0FyQ+qm3zgydbB9a8grYrg0xWUU3s/ N95YFc0DZr0LXnjsqHrOMBy2qFyQVLaLcmrCn57ZpPPvKtwOkBGvWD2AEO+wwDjMgj74 o2jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=3QNX3ntMhZb0ls26odfk48nxG7WM5TsFRBN/18B6MJo=; b=e3wvGuoLFE9qIdjskU1BaeOb74gjjOWDzy71wRwmaMZyPH9Rne4a+zoaykUtSPoxbv /CFAKSuFwKvhZvQLVjv7/uCdWfbfLAX2JjtCztSzjKcQ8xRrJlu+2AYdOKfDY9IjsTdG 4rVlZEplYmKXKuWycQFeCT0YZ4BpY4veuxeCqtZU7BFE1KOyehH6rVotxOp+JaezYb0T 0uCTCD2mHh5E2A4r8FpkLsv929Ujft++kgQ3rQeutCLLszFgXnkZ8YvSkTo0SKQ/3P8M 9bNNNjBGIEua16NF1YPFT02CySqQe8DwDSUWYXfCEbfbIlfjblTT2oKuH0Dmqmy8AFlj wL4A== X-Gm-Message-State: AOAM530qYt0IvousApuPZjsoIYuD+smHaLnftbEm4vJPhuglmzh/oKy7 WN71BrPpD0O960peCfmxSCbKCKlvTXM= X-Google-Smtp-Source: ABdhPJwybYJ+B66CSt7cje1eNQ0BCqbasIi0KUJtah8xrWB2nDzGdSwgNFbWoOron6aPqSYHAl0r/w== X-Received: by 2002:a5d:4608:: with SMTP id t8mr19504043wrq.136.1632611622343; Sat, 25 Sep 2021 16:13:42 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id z8sm2134709wrm.63.2021.09.25.16.13.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 16:13:41 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> From: Dmitry Gutov Message-ID: Date: Sun, 26 Sep 2021 02:13:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <871riitzch.fsf@gnus.org> Content-Type: multipart/mixed; boundary="------------8889971C46DE9C778BB18D39" Content-Language: en-US X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.6 (/) This is a multi-part message in MIME format. --------------8889971C46DE9C778BB18D39 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 01.10.2020 06:11, Lars Ingebrigtsen wrote: > If I'm skimming this thread correctly, there wasn't much enthusiasm for > the proposed new functionality, so I'm closing this bug report. If > there's further progress to be made here, please respond to the debbugs > address and we'll reopen. There are valid issues here, but there was no clear picture of how to solve them best. But it would be good to try to do that (at least to some extent) before Emacs 28 is released. The first issue is that projects that don't use any of the supported VCS are not recognized at all. Since these days most large projects do use version control, we can expect that projects which do not, should be relatively small. And our find-based implementation will generally be fast enough. Also, looking at the home-grown project definitions out there, people often don't bother with the 'ignores' method, so maybe a backend which provides no way to specify them will still cover most of the needs. It could be extended with such feature later anyway. Patch adding such backend with a customizable list of "markers" is attached. I wasn't sure whether to add support for wildcards there, because file-expand-wildcards does not optimize for the trivial case, and directory-files is slower than file-exists-p. I'm mostly worried about Tramp performance here, but some pathologically huge directory could be a problem as well, IDK. project-fallback-markers only includes .dir-locals.el, but it can be easily customized. Not sure if it should include other standard file names, such as Makefile, Gemfile, mix.exs, and so on. The first version doesn't have them. Another question is the name. 'plain' sounds not very descriptive. I've considered 'fallback' and 'novc', eventually settling on the former. Opinions welcome, though. --------------8889971C46DE9C778BB18D39 Content-Type: text/x-patch; charset=UTF-8; name="project-fallback.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="project-fallback.diff" diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 57a961c260..8eee0c7d27 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -165,7 +165,7 @@ project :version "28.1" :group 'tools) -(defvar project-find-functions (list #'project-try-vc) +(defvar project-find-functions (list #'project-try-vc #'project-try-fallback) "Special hook to find the project containing a given directory. Each functions on this hook is called in turn with one argument, the directory in which to look, and should return @@ -662,6 +662,27 @@ project-buffers (push buf bufs))) (nreverse bufs))) +(defcustom project-fallback-markers '(".dir-locals.el") + "List of file name to use as fallback project root markers. + +Each entry should be a relative file name (no directory part). + +The fallback project backend detects a project as a directory +containing one of these files." + :type 'list) + +(defun project-try-fallback (dir) + (let ((root (locate-dominating-file dir #'project-fallback--root-p))) + (and root (cons 'fallback root)))) + +(defun project-fallback--root-p (dir) + (let ((default-directory dir)) + (seq-some (lambda (marker) (file-exists-p marker)) + project-fallback-markers))) + +(cl-defmethod project-root ((project (head fallback))) + (cdr project)) + ;;; Project commands --------------8889971C46DE9C778BB18D39-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 25 20:22:45 2021 Received: (at 41572) by debbugs.gnu.org; 26 Sep 2021 00:22:45 +0000 Received: from localhost ([127.0.0.1]:35146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUHwL-0001el-6H for submit@debbugs.gnu.org; Sat, 25 Sep 2021 20:22:45 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:41881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUHwJ-0001eV-Dc for 41572@debbugs.gnu.org; Sat, 25 Sep 2021 20:22:44 -0400 Received: by mail-wr1-f50.google.com with SMTP id w29so39158819wra.8 for <41572@debbugs.gnu.org>; Sat, 25 Sep 2021 17:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SjWfTar/kX2u97meKkfQsnhKKWoCnEX9udcQmXMZ+Ac=; b=nXRaqwv7aCb+00fOzN9FuQG69xaJEQFZQhul7VBPzAzap2dPFdMB4MXL68y5m+8yTs JsE+uIY32HU9rSXXsIt2+Y81EFTRwQyRjU6P9BAktSobrs9Qd9Ttd36S1B9/cGGVKLQU WCsHDuYjE3U0rBvqOdZB8AKUaT9IIyt9Tc6xmGHc2gulype/U45dnadshYEzjFRBhWbQ khEkPuSzdEm0iMiAMStdSyXNte0DJ84iSQGyt1BaGjei4LSR+vlPc9lTUY1+PKTSvlMR laR1vsRJNNKzPbNCmYtiLF3Yh+HELWA1uGfg2i8clRhC12k+znjyX4OUraLrBYNjMhRb 6bZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=SjWfTar/kX2u97meKkfQsnhKKWoCnEX9udcQmXMZ+Ac=; b=k77WTuA1QBDsSoahDieCeQxbdfCA1/XmB3H25PNIWjIxQnEbQEGVEkInEoatbcR0tD go6f64cOwQ6YFY/ZMyFktUSj4aoFCQQTtopi6+wjcCy6iksfi0fAP65at1qPAAktiTaj sWY8hDDn2Eio1FWqBa/2hIKVongmKBis44o+KRb+OUoxq5yBsZsu1o7mVW27M0fNVJ7D GzLwQtvNVAqQCgpXvk3E3GlRXaTiR52Zd5BU8tKKsK7L7dtRODAm+6JUjuK0uo64YjVv WdMj64oaMZps2oZVThWjAMEpNTWLFtRj5h+U910M1j1CEHcakY4WErkhc7pTwfrjO5je v8zA== X-Gm-Message-State: AOAM533gklWtt6pNpiiNsiQoE8EJZw79LWfCr6cFzPad3NOILgziw7+S xdwXM/5oApvIcmcosH+n1lU= X-Google-Smtp-Source: ABdhPJw/kPOzBRSuaQknogYzggig0SdGTqmZsZ1HfQusoNucu7vZ0JACM7cVbFMgBn+KeN47k7Ku2w== X-Received: by 2002:a05:6000:1446:: with SMTP id v6mr20072502wrx.427.1632615757564; Sat, 25 Sep 2021 17:22:37 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x14sm12512481wmc.10.2021.09.25.17.22.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 17:22:36 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> From: Dmitry Gutov Message-ID: Date: Sun, 26 Sep 2021 03:22:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <871riitzch.fsf@gnus.org> Content-Type: multipart/mixed; boundary="------------B58A981BA8E68E443A635214" Content-Language: en-US X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.6 (/) This is a multi-part message in MIME format. --------------B58A981BA8E68E443A635214 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Another issue is people working on monorepos (often backed by Git) sometimes want to split them into separate projects. Either because they only work on a certain part of the whole project, or because they want to use Eglot, and that package has tied LSP roots detection to project roots (but the language server might expect some project configuration files in the root which reside in a subdirectory). Here's a typical question/request for this functionality: https://emacs.stackexchange.com/questions/58463/project-el-override-project-root-with-dir-local-var/58468 Patch attached, it adds new user option project-vc-subprojects which alters the root-finding logic and cuts out the subproject contents from the parent project with the mechanism of "ignores". The latter capability (excluding subproject's files) informed the choice of the approach. Which is altering the vc project backend's behavior, rather that offering this feature through another backend, like the one added in the previous patch, for example. I don't know if all users of this feature will want them excluded, though. The attached implementation does, and maybe another option could be added to disable this. Or we could drop this part of the behavior, insisting that users who want it could add the corresponding entries to project-vc-ignores. This way they would be listing the subprojects twice, however. And the project-vc-merge-submodules=nil behavior matches the other option (submodule files are excluded from the parent). Again, thoughts welcome. --------------B58A981BA8E68E443A635214 Content-Type: text/x-patch; charset=UTF-8; name="project-vc-subprojects.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="project-vc-subprojects.diff" diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 57a961c260..e45667ed15 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -369,6 +369,23 @@ project-vc-merge-submodules :package-version '(project . "0.2.0") :safe #'booleanp) +(defcustom project-vc-subprojects nil + "List of relative directory names to consider separate projects. +Each entry should a string, name of a subproject root directory +relative to the VC root. + +Every entry in this list will be considered a separate project +for the purposes of files listings, searches, etc, and the parent +project will exclude those files. + +One would usually set this variable through .dir-locals.el. + +If subprojects are Git submodules, you can use the variable +`project-vc-merge-submodules' instead." + :type 'list + :version "28.1" + :safe (lambda (val) (and (listp val) (seq-every-p #'stringp val)))) + ;; FIXME: Using the current approach, major modes are supposed to set ;; this variable to a buffer-local value. So we don't have access to ;; the "external roots" of language A from buffers of language B, which @@ -428,7 +445,22 @@ project-try-vc root))))) ('nil nil) (_ (ignore-errors (vc-call-backend backend 'root dir)))))) - (and root (cons 'vc root)))) + (when root + (let* ((relative-dir (file-relative-name dir root)) + (subproject (seq-find + (lambda (sub-dir) + (string-prefix-p (file-name-as-directory sub-dir) + relative-dir)) + (project--value-in-dir + 'project-vc-subprojects + dir)))) + (if subproject + (cons 'vc (propertize + (concat root subproject) + ;; Side-channel so we don't change the value format. + ;; But we could do that instead. + 'vc-subproject t)) + (cons 'vc root)))))) (defun project--submodule-p (root) ;; XXX: We only support Git submodules for now. @@ -467,7 +499,9 @@ project-external-roots (cl-defmethod project-files ((project (head vc)) &optional dirs) (mapcan (lambda (dir) - (let ((ignores (project--value-in-dir 'project-vc-ignores dir)) + (let ((ignores + (nconc (project--vc-subproject-ignores dir) + (project--value-in-dir 'project-vc-ignores dir))) backend) (if (and (file-equal-p dir (cdr project)) (setq backend (vc-responsible-backend dir)) @@ -579,6 +613,12 @@ project--git-submodules (nreverse res))) (file-missing nil))) +(defun project--vc-subproject-ignores (dir) + (unless (get-text-property 0 'vc-subproject dir) + (mapcar + (lambda (supb) (format "./%s" (file-name-as-directory supb))) + (project--value-in-dir 'project-vc-subprojects dir)))) + (cl-defmethod project-ignores ((project (head vc)) dir) (let* ((root (cdr project)) backend) @@ -608,6 +648,7 @@ project-ignores (vc-call-backend backend 'ignore-completion-table root) (vc-not-supported () nil))))) (project--value-in-dir 'project-vc-ignores root) + (project--vc-subproject-ignores root) (mapcar (lambda (dir) (concat dir "/")) --------------B58A981BA8E68E443A635214-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 26 02:38:42 2021 Received: (at 41572) by debbugs.gnu.org; 26 Sep 2021 06:38:42 +0000 Received: from localhost ([127.0.0.1]:35568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNoA-0000w4-F0 for submit@debbugs.gnu.org; Sun, 26 Sep 2021 02:38:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNo8-0000vo-FQ for 41572@debbugs.gnu.org; Sun, 26 Sep 2021 02:38:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=/cL2V3lifAFUcBUL+ypncDCfBxc0wA+qG6dByZCkj1c=; b=nWd+xwwbnt526BsKXuttWEVwwU otL0pWBVkZOWWp0V0AbdLTySBzmwdsxP0HG2iaDcFGa6IAjdGt71V3SifhyBjyzd7J3VJ00wxAWH8 LtbaFgb8oFXsDyyF54AmHWsc9CilfoK8djimQIM9RAwtSFGioJw6YEPEaCtWltvqGpzk=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mUNny-0006Do-PJ; Sun, 26 Sep 2021 08:38:33 +0200 From: Lars Ingebrigtsen To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEWhlEBJRSr////o CFXIAAAAAWJLR0QCZgt8ZAAAAAlwSFlzAAABLAAAASwAc4jpUgAAAAd0SU1FB+UJGgYdMGXR1RkA AADgSURBVCjPdZLRCgQhCEUVxneD/J+CejfI//+VtWxmdx9GmMHDvZlKAO+BdqKcXG/4U9AUqDEt oF+F0r/tR3kFfAXg0Ut5musi30Yzj6/CYz4CjJ7KA/XqkWxI0h+lpbTu4OXFBmukAL4AJwNyO6Db vsA/5QMrSI/trvoDDNz4htZS1kgzSascgF0HVw24xGQ03b1zrdV6juGv7OvIqe4Ta0E6B22lqBjV HqWzFDSxPQNQ8Q3aPNvz7Yhp1XONhwSg22xaiQ6WQoanUS8gdmz+p/UaQvBbux+7h55kou9v6gPB V0n+mfEx0AAAAFplWElmTU0AKgAAAAgABQESAAMAAAABAAEAAAEaAAUAAAABAAAASgEbAAUAAAAB AAAAUgEoAAMAAAABAAEAAAITAAMAAAABAAEAAAAAAAAAAAEsAAAAAQAAASwAAAABYCqauwAAACV0 RVh0ZGF0ZTpjcmVhdGUAMjAyMS0wOS0yNlQwNjoyOTo0OCswMDowMPFja4cAAAAldEVYdGRhdGU6 bW9kaWZ5ADIwMjEtMDktMjZUMDY6Mjk6NDgrMDA6MDCAPtM7AAAAF3RFWHRleGlmOllDYkNyUG9z aXRpb25pbmcAMawPgGMAAAAASUVORK5CYII= X-Now-Playing: The Senior Allstars - =?utf-8?Q?=E2=80=98Slipping?= Into =?utf-8?Q?Darkness=E2=80=99's?= _Late Night Tales: Version Excursions (Selected By Don Letts)_: "Originally recorded by WAR " Date: Sun, 26 Sep 2021 08:38:27 +0200 In-Reply-To: (Dmitry Gutov's message of "Sun, 26 Sep 2021 02:13:39 +0300") Message-ID: <87tui7suxo.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Dmitry Gutov writes: > There are valid issues here, but there was no clear picture of how to > solve them best. But it would be good to try to do that (at least to > some extent) before Emacs 28 is released. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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 (---) Dmitry Gutov writes: > There are valid issues here, but there was no clear picture of how to > solve them best. But it would be good to try to do that (at least to > some extent) before Emacs 28 is released. OK; I'm reopening this report, then. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 26 02:38:48 2021 Received: (at control) by debbugs.gnu.org; 26 Sep 2021 06:38:48 +0000 Received: from localhost ([127.0.0.1]:35571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNoG-0000wM-Lr for submit@debbugs.gnu.org; Sun, 26 Sep 2021 02:38:48 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNoE-0000vx-R7 for control@debbugs.gnu.org; Sun, 26 Sep 2021 02:38:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NHSXCEsS/xw8Xv4Qcnb5/uyOHsBEkHObqwxeTWx/8g8=; b=m7cAVdxBNyWk/fVyM/l4k16rm5 fibbfm9hhi4XsPIBUrIgcQjJwZMLcq8xdKzirhmcw6sIXU95tpKB9iQRirKcSZsDJcMdLqqcDqSQa OYY0jecGEWEZMdwayJ/NzrY7GIUsqug9EdCla0uQ8fD1hsWZTSM1mj/Zde4bpfjJPmR8=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mUNo6-0006E2-Rd for control@debbugs.gnu.org; Sun, 26 Sep 2021 08:38:40 +0200 Date: Sun, 26 Sep 2021 08:38:38 +0200 Message-Id: <87sfxrsuxd.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #41572 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: reopen 41572 tags 41572 - fixed patch quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) reopen 41572 tags 41572 - fixed patch quit From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 26 02:39:08 2021 Received: (at control) by debbugs.gnu.org; 26 Sep 2021 06:39:08 +0000 Received: from localhost ([127.0.0.1]:35577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNoZ-0000y5-S6 for submit@debbugs.gnu.org; Sun, 26 Sep 2021 02:39:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUNoY-0000wh-59 for control@debbugs.gnu.org; Sun, 26 Sep 2021 02:39:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=H209QeEzpVYFEhD/O9dq4hEh9qEYLmKOz+B80n45K5g=; b=XVzLuiBF0MDWJF9FOTxhNibBsn En9UVzOyKPhYbQi3xkwS6bSVfM3zmJMZIu7AZmNz43D0R+diMYYUgSfzNzCtac5JHxTHLeaQzuTf1 laT8ORoPGf60zTS21UxJJ+o0JapAvN7rc6rqccrhGM98Rpmou2YcSLTMxNCImoYiFfe0=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mUNoQ-0006ED-Cj for control@debbugs.gnu.org; Sun, 26 Sep 2021 08:39:00 +0200 Date: Sun, 26 Sep 2021 08:38:57 +0200 Message-Id: <87r1dbsuwu.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #41572 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 41572 + patch quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) tags 41572 + patch quit From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 03 14:27:39 2021 Received: (at 41572) by debbugs.gnu.org; 3 Oct 2021 18:27:39 +0000 Received: from localhost ([127.0.0.1]:34935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mX6D5-0007I1-Cz for submit@debbugs.gnu.org; Sun, 03 Oct 2021 14:27:39 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:41221) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mX6D3-0007Hj-0K for 41572@debbugs.gnu.org; Sun, 03 Oct 2021 14:27:38 -0400 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 89A9460002; Sun, 3 Oct 2021 18:27:27 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> Date: Sun, 03 Oct 2021 21:06:16 +0300 In-Reply-To: (Dmitry Gutov's message of "Sun, 26 Sep 2021 02:13:39 +0300") Message-ID: <87zgrq2ctj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) > Patch adding such backend with a customizable list of "markers" is > attached. I've tested that it allows using 'C-x p g' in any directory, not only in a repository! This is a great feature, thanks. But a small problem that there is a need to exclude some subdirectories from the search by 'C-x p g'. And I don't understand if your another patch with 'project-vc-subprojects' could help with this? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 04 22:03:13 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 02:03:14 +0000 Received: from localhost ([127.0.0.1]:38650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZnV-0002Fr-M9 for submit@debbugs.gnu.org; Mon, 04 Oct 2021 22:03:13 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:46749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZnU-0002Fe-KP for 41572@debbugs.gnu.org; Mon, 04 Oct 2021 22:03:12 -0400 Received: by mail-lf1-f48.google.com with SMTP id i24so29929015lfj.13 for <41572@debbugs.gnu.org>; Mon, 04 Oct 2021 19:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n2s9qgAyA6DImPRKIeKL4ZMFb+CKVtRIPUnwPylzjsw=; b=ot50namP/ITjgbneUr0JgAn0H02H5RRlTCBO6YNp921Idj2d5jVRdFO5B45ZwC63SB 1ObR0icXsZRcg8RiC31j/CCK4PWpDm/SyRfEXJPIrCuyACa34zOLYhQhs90EHGY8pY8S CyFOjKVB0iCzuoBpe/BIr7o1p4XYdIAVHKLLIAM0VFHfhTe/v3hA43RiVZREFpgt7Bdn mTidCRP8xslzFk1FRGl4rnGg8Rhpx42l+WUO+RUCf/VdW0jDq3dbgjJgHADaL4mG18pV +nlgDsnGrxozYoFklT6xOt9lUbmhFb420rCc9eNpKbJklsydIGpEXf8gR2Dalz6TycfP AeSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n2s9qgAyA6DImPRKIeKL4ZMFb+CKVtRIPUnwPylzjsw=; b=BgV5YUKvCG+cjwR7GUcwuU3USlhx/cuaWJhDLeL/PAvizxxJP+pvpAueGUXgvJHi18 z+jz/yQa7Os6Pnn6inKwQlXFpnOTK6RtpkiR6EYU7oOSpOR1eoinrDDzZyj/UKyrbtFr ny0s1MvtJHZ8gUXVJjwPlfF5P912ZJZjuHmPpayW9L/cB/wtlYXRDgORFhhLu9cmVHpJ 4r332r29nmj7S7rO+vPyPjZMqtFr4K51n4vfjHretm62WYV+J8LQC1KlUCwnMtHoA9Yd +UXXja9voPAbBHHFIjqjVgb6LPoxn4MKw4wP/Zg0Icgnenc6gmKmESD0OnqDlfSeup4b eDBA== X-Gm-Message-State: AOAM532NAB0pBW8QU8NXFAR7aJkYtmqu1yFdb24t4mrivWgvUw0oCTm/ 2wUQ4lGvexKqhz5SeuztXX6MuMYcCrs= X-Google-Smtp-Source: ABdhPJzTUE88XiDltvya0PpHQVF1oJmrLIT4lHhAhj+gtwsXvFAqQNWxJwlOTCrb55wrL3TgkHxA3w== X-Received: by 2002:a05:6512:3502:: with SMTP id h2mr578088lfs.415.1633399386960; Mon, 04 Oct 2021 19:03:06 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id t3sm1741291ljg.68.2021.10.04.19.03.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 19:03:06 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> Date: Tue, 5 Oct 2021 05:03:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87zgrq2ctj.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 03.10.2021 21:06, Juri Linkov wrote: >> Patch adding such backend with a customizable list of "markers" is >> attached. > > I've tested that it allows using 'C-x p g' in any directory, > not only i [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.48 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.48 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 03.10.2021 21:06, Juri Linkov wrote: >> Patch adding such backend with a customizable list of "markers" is >> attached. > > I've tested that it allows using 'C-x p g' in any directory, > not only in a repository! This is a great feature, thanks. Thanks for testing. > But a small problem that there is a need to exclude some subdirectories > from the search by 'C-x p g'. And I don't understand if your another patch > with 'project-vc-subprojects' could help with this? Now, it's for something else (subprojects within monorepos). A way to specify ignore entries for "fallback" projects can be added easily with a variable like project-fallback-ignores (same as project-vc-ignores). I've been debating internally whether we need such a variable at all, and whether it should simply be an alias for project-vc-ignores. But, uh, probably not? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 04 22:08:58 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 02:08:58 +0000 Received: from localhost ([127.0.0.1]:38654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZt4-0002Nn-Ag for submit@debbugs.gnu.org; Mon, 04 Oct 2021 22:08:58 -0400 Received: from mail-lf1-f51.google.com ([209.85.167.51]:36361) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZt1-0002NT-Rf for 41572@debbugs.gnu.org; Mon, 04 Oct 2021 22:08:57 -0400 Received: by mail-lf1-f51.google.com with SMTP id b20so80108355lfv.3 for <41572@debbugs.gnu.org>; Mon, 04 Oct 2021 19:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ASXIuG1RGnOolDtUe2vktAfBdszmfk+M7UWZoHEDg+8=; b=lOy+jfd0jp77PwqTG6DY4hfN+yiEE+PXx0zgKMKuACpwwdx2tf3D14+8vlta5eiyo/ UoWyLJ5kQMIXdI0J/jYaQgZohqtcqcCcdHVKI1CIud92Sjr6E9gZ8NO1+nn7I8Xh3LzD 8QKNOACWMk71v1X7how/2DIokHvoWunGZiKOO5Wgv+oGr9Y1Xl/rxrbHLFFk0Ug6bEii 6w4ZKQJWU+Z05/WfYGBBrycDm6e9UzlRgZnIVWsjteQ+igrtMWxeHOHloY4HIuxj08ql YQxwUSrwVzOzJsLEwXLCjLJZUTwA44yHR4QETuupUf4tPwUpdGDMiKT5Ug6Jnmyy6VnW PiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ASXIuG1RGnOolDtUe2vktAfBdszmfk+M7UWZoHEDg+8=; b=CAdT/m/7r22IYIIMpzHzrnbWPediBrqLfLppCBDROjHZZHvG45dDYS3FK0jQYEI07w zB9BzlUQtq4gQzA09DuyUatJShrU6TzWYcoTdvZxa3npWam5sbA9pRdV0VyQ/kr0oCVP ZuDK8NFzhVL7XiE4Wv0SJWp8yGE0JvaCpXm3/wD/fG2RuuWRd6PmIkBp7IIUQ0+2jiw4 bmMIBemPUcbC1R12hWy4qh4Ya+aArq79qJt4zmX/A0e0Ym4Y05wnRgHaw6j0tJNx61Qb +Cj/wUa3QDMm9Y2OcvMABkhRMipV8M2HckzM+wKx9DSwncKCU95OLC976UZV4NQFiina Y/uw== X-Gm-Message-State: AOAM533Z9e3Lb9cfyvQc2SpLFbCrMl4D6Vq9HfVMt0Uwqu94zUxMRxv+ D1sU4Ku16I66NDR75ADMtx8waQp4pIM= X-Google-Smtp-Source: ABdhPJzNNA+lSh662VjehHJoUGIoFAR7YvOy4qvbZqKL7JbwLkNlmb4K4buLDKHeI6eWdOCq/ht9Hg== X-Received: by 2002:a05:6512:6c1:: with SMTP id u1mr581797lff.203.1633399729969; Mon, 04 Oct 2021 19:08:49 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id f7sm1766972lfv.96.2021.10.04.19.08.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 19:08:49 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project From: Dmitry Gutov To: Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> Message-ID: <0c74b78e-88a8-874d-7321-4fd2e3dc9ca7@yandex.ru> Date: Tue, 5 Oct 2021 05:08:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 05:03, Dmitry Gutov wrote: > Now, it's for something else (subprojects within monorepos). s/Now/No Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.51 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.51 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 05.10.2021 05:03, Dmitry Gutov wrote: > Now, it's for something else (subprojects within monorepos). s/Now/No From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 02:58:47 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 06:58:47 +0000 Received: from localhost ([127.0.0.1]:38871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXePX-0001J5-36 for submit@debbugs.gnu.org; Tue, 05 Oct 2021 02:58:47 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:57781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXePU-0001If-06 for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 02:58:45 -0400 Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 48275FF810; Tue, 5 Oct 2021 06:58:34 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> Date: Tue, 05 Oct 2021 09:52:23 +0300 In-Reply-To: <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> (Dmitry Gutov's message of "Tue, 5 Oct 2021 05:03:05 +0300") Message-ID: <87r1d0at40.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) > A way to specify ignore entries for "fallback" projects can be added easily > with a variable like project-fallback-ignores (same as > project-vc-ignores). I've been debating internally whether we need such > a variable at all, and whether it should simply be an alias for > project-vc-ignores. But, uh, probably not? Adding such a line to .dir-locals.el would be fine: ((nil . ((project-vc-ignores . '("subdir1/" "subdir2/"))))) Or this would be even better: ((nil . ((project-ignores . '("subdir1/" "subdir2/"))))) From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 08:42:39 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 12:42:39 +0000 Received: from localhost ([127.0.0.1]:39320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXjmI-0007Ba-R1 for submit@debbugs.gnu.org; Tue, 05 Oct 2021 08:42:38 -0400 Received: from mail-lf1-f51.google.com ([209.85.167.51]:33767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXjmH-0007BL-LD for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 08:42:38 -0400 Received: by mail-lf1-f51.google.com with SMTP id y23so46359961lfb.0 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 05:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=m4d7iBNulO/JhoXPODppoAUnBIujJNeQH/0f281ootE=; b=CQfI7UGLvxPwBlOrAP3CDYIbk5LIawC1/b/VYf3+eqoHj0z9GN1G6igOB3/vS19gK9 yx4AlpyVzTQBWAiLvE82qwyUEqk7WU/f9Et5P1TbUNVmUGpPhCDNcRvikoK99x4wrjCa epuori/ShqT2wnHz3Un+IL7byatjmxPWtte+Ns2feiyjPcHyvXffw7o6eRKThp4PrRWI l8dwW23+u+Fg6M3hRt7XNfYRPwI1CYICp7CiChQUNUJlWF512vqqXMgV89ol02XjMeVB CXvrGIGGu9c/Pny7HKmj1D0EJ178ER+DIXo09bb8U4QK/C3/1ngVrOsDSwCQGYXjvHo4 pnHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=m4d7iBNulO/JhoXPODppoAUnBIujJNeQH/0f281ootE=; b=V73ZDhmDtBJQxfse2pX0reNZ5dUAHNxfgBoNXhleJKO3pQZlg+yUZqxuDgvT5sB2RE OB/zf1X5Amz+ApGa4mc5bAgbiwlxz1yL7F66PIzR2n302G8XQa9yrBFYfILyDgvR5Rud lwLn7a09ObStzkkN3iDHcjFsOOgt61Zd/7cUut3RKgC4Ht3WH5cq1jl/3+lxm8Qmmxk1 mUQy8Yvc+/sI6lGj9YNRHN4sWAwIc1BEb9/Dx0F3Z1jgET5RiD/+Wf69bKqp4v9Sle/F Hg9glJOhpZUzo5hbdbvkorkqns+7gvkCOtaMAQDRnWWEqKC3iUMyqns37/2Wc1b0f/fq z3JQ== X-Gm-Message-State: AOAM530o8P1dkB1/idIoTeBOdHStQpwtXUOWKnbXq25ciRxhJmrJTJLr gWB3fi+giSJpfSyehX9ErUCncx88ztQ= X-Google-Smtp-Source: ABdhPJyYyMjfnEnYLY9XkubU7wbGqR0wb+PhGA+pmK3jDi2soCZMrghrDLyvEb9HebTn2ZVpfGLL7Q== X-Received: by 2002:a2e:4c02:: with SMTP id z2mr22694907lja.403.1633437750681; Tue, 05 Oct 2021 05:42:30 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id a4sm1947816ljn.122.2021.10.05.05.42.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 05:42:29 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 5 Oct 2021 15:42:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87r1d0at40.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 09:52, Juri Linkov wrote: >> A way to specify ignore entries for "fallback" projects can be added easily >> with a variable like project-fallback-ignores (same as >> project-vc-ignores). [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.51 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.51 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 05.10.2021 09:52, Juri Linkov wrote: >> A way to specify ignore entries for "fallback" projects can be added easily >> with a variable like project-fallback-ignores (same as >> project-vc-ignores). I've been debating internally whether we need such >> a variable at all, and whether it should simply be an alias for >> project-vc-ignores. But, uh, probably not? > Adding such a line to .dir-locals.el would be fine: > > ((nil . ((project-vc-ignores . '("subdir1/" "subdir2/"))))) ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) > Or this would be even better: > > ((nil . ((project-ignores . '("subdir1/" "subdir2/"))))) I wouldn't want to create an impression that this variable affects any and all project.el backends, including third-party ones. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 10:39:19 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 14:39:19 +0000 Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXlbD-0004wH-9x for submit@debbugs.gnu.org; Tue, 05 Oct 2021 10:39:19 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]:35825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXlbB-0004w1-93 for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 10:39:18 -0400 Received: by mail-lf1-f43.google.com with SMTP id m3so85995641lfu.2 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 07:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lwGIVO0rhRhOD9wgZRMxIPphrYoTNuqhtFfOAOv47sE=; b=AFALYa3CNSrP1O5Pcd2nCyHr433/YMyBOJH0zGqABDgLlnT2qiInHtA8xqdUfDa+Bn yJWewlBlkETBTnrnhkX0V74n5NV9E4yxwPy+YXGpuONP5uLHosJ4mqXKgGmkDp5jRVkR 9NZmLRDvCid8n2/Fa/2I0goW9iWAXDU5WPCd1uhWhHMfZZsCClAR+rQKt9IuedHdatkv JqI9ybqKK3Vve1+omirorje6PMJF2p20K9JGBzH2i/w35/vtiShMelrPfv8y8BPmfKIj RSB9oEjmugLE9+9j6qxeMRNg+KIdDx29A4EqyDWJ0IHEkosLvI9VJ8gLVVvMRK6C/azX kTjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lwGIVO0rhRhOD9wgZRMxIPphrYoTNuqhtFfOAOv47sE=; b=ltiAvouDnIihDWmuHN4IV+VFRTYOJSMWmxDTl2wKv04uEUnWt5NdvDK9tJQlRWS75H fENNKPu0w/OPSaPO//dOjFx/NnKE405JUeM00f25FXGMMeOirXn/Y9bOGbVbBDA6rwDr 5d6AY4OGhJLr1VE3/B+8Ug1hR6Uj7/AEeUwBOHmjOEmF7NOZXCW7p5XHAk2y9I4ty3Tp MKWrSezinDMUfphCXWQ8L9Km1fZo2TFWT/0jnOMeNeIX64hmDa8TrKygXzx+HlLEAUd5 L3XAEr9pHkPMbZrMBb1hkC2+CQ8IbnkENt7LGViViWmcxK3ir+Rf2nJMTIthwHPCnNdb Gq0w== X-Gm-Message-State: AOAM530wKGY7HQHbdEYMHpSpqcZSe44EXlqpDK5J4XG9prBvMvVebOHP Glze3Cn7M5ns0oeq837kd9s= X-Google-Smtp-Source: ABdhPJyArtJNYHn1rIDoej+2A4q8TdTESB/Nu6sOESBFVULfTIlFFum0KvWXrcpfk4+s76+ZDVRkug== X-Received: by 2002:a05:651c:2044:: with SMTP id t4mr3939662ljo.421.1633444745564; Tue, 05 Oct 2021 07:39:05 -0700 (PDT) Received: from [192.168.199.3] (broadband-46-242-10-137.ip.moscow.rt.ru. [46.242.10.137]) by smtp.gmail.com with ESMTPSA id v11sm1923493ljg.62.2021.10.05.07.39.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 07:39:05 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> Message-ID: <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> Date: Tue, 5 Oct 2021 17:39:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6F17B8E38643BEF2C5BD653D" Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) This is a multi-part message in MIME format. --------------6F17B8E38643BEF2C5BD653D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello. I have some stake in this issue too. The proposed patch is ok, but I think that we can go for a more ambitious solution here that would require just a little more work, but would be a lot more useful. Maybe lets have a make-file-backend function, the output of which you can cons onto project-find-functions, so any file defined like this would be just another separate backend. This function in turn can be used by major mode developers and users to implement project backends. If we look at the list of projects supported by Projectile , we can see that this one function is enough already to implement most of them. Having such file backends also leaves the question of whether the particular file should have a higher priority than VC to the end user, depending on where he(or some major mode he's using) adds a particular one into the list. As for whether there should be some kind of default file marked project, sure, the user can just remove it if he want to. --------------6F17B8E38643BEF2C5BD653D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello. I have some stake in this issue too.

The proposed patch is ok, but I think that we can go for a more ambitious solution here that would require just a little more work, but would be a lot more useful.

Maybe lets have a make-file-backend function, the output of which you can cons onto project-find-functions, so any file defined like this would be just another separate backend.

This function in turn can be used by major mode developers and users to implement project backends. If we look at the list of projects supported by Projectile, we can see that this one function is enough already to implement most of them. Having such file backends also leaves the question of whether the particular file should have a higher priority than VC to the end user, depending on where he(or some major mode he's using) adds a particular one into the list.

As for whether there should be some kind of default file marked project, sure, the user can just remove it if he want to.

--------------6F17B8E38643BEF2C5BD653D-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 11:04:15 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 15:04:15 +0000 Received: from localhost ([127.0.0.1]:41619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXlzK-0005aA-Hr for submit@debbugs.gnu.org; Tue, 05 Oct 2021 11:04:14 -0400 Received: from mail-lf1-f41.google.com ([209.85.167.41]:42570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXlzD-0005Zi-SU for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 11:04:12 -0400 Received: by mail-lf1-f41.google.com with SMTP id x27so86829719lfa.9 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 08:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Hev1+o+alyTRQs+kT9WhH1oMzMJqWUh7wM3AGjK8P1U=; b=G3U6q0wY/4TaK2UdKcEnMu7kNHEGa0edEAMY8wIMCr2nMGT3vx4PlnEIiRNIKXgjZi cI4LlW/yhnmvLS0Ag3LoJcz0zwbLsDDdzuxYozvyCO9wvHh3RSD69VhYSsc7D/ONpsiS fDAvkPm6NbUs8AxGM5H1kbNZPtPg7d72JZorZ/LRvIxwMjGQOAPs3kQ+ONptql5encHv MVDJiUwLipHHc0eG6veQeAX4C0MOUqJSiVOt8/8s/OywJ8gLkuN8v/J84VatrZG7xNxW pPK0uMl2Ets7oWyP4MtOrCdtEr4WlxCkZkIU4VCF88fes35r9YpzjpJ2irWXuOO/sCfY ktbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Hev1+o+alyTRQs+kT9WhH1oMzMJqWUh7wM3AGjK8P1U=; b=ZX7cFPEJ50JtBrleuFTHZfu1E6B9Ht9BFplPYkLELdgo2MNHZP09/yxv9GFZMJVVdx GdPVNRdENZB3wYra8IjLIHDda/hAox8oOC7XSXuINBsocXBpiLjw7KPdO82JnfKDRBMh C1GQfPqmmaqZvqWYudrRX8GoJJfRABJvOwewP9dvVTyaHOpqUsYn79wXztqTgIQwz2do 52uiKamrYPJuR6vojCwc03ck+a8SnVrRXBXCzmm1pd+vGFgvrB8QZXQCuqOhE5NhI4Lv Vlwc4UCW8m0A4yWd6duZviKlCy71IVZut9Oh2nF9XhUaCwoPuhveDnLLTDjHE6hcCUQD D7ew== X-Gm-Message-State: AOAM533SDvh9+oS2///fbCrLUS+OjSQ7IPavOtqLbd9d1NMeUYvlP/f2 oNlCOdVw/fbfokS+svHy1LU= X-Google-Smtp-Source: ABdhPJxh6J3r4b9gTA/Pqx8k5AEdLms0yu7DNggt7X8tjgTOVS0/nuo5HhLwD0VlhwGZXwr+6FigwA== X-Received: by 2002:a2e:a26b:: with SMTP id k11mr23356126ljm.185.1633446231221; Tue, 05 Oct 2021 08:03:51 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id 8sm1993469ljr.10.2021.10.05.08.03.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 08:03:50 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> From: Dmitry Gutov Message-ID: <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> Date: Tue, 5 Oct 2021 18:03:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.9 (/) Hi Nikolay, On 05.10.2021 17:39, Nikolay Kudryavtsev wrote: > Hello. I have some stake in this issue too. > > The proposed patch is ok, but I think that we can go for a more > ambitious solution here that would require just a little more work, but > would be a lot more useful. > > Maybe lets have a make-file-backend function, the output of which you > can cons onto project-find-functions, so any file defined like this > would be just another separate backend. > > This function in turn can be used by major mode developers and users to > implement project backends. If we look at the list of projects supported > by Projectile > , we > can see that this one function is enough already to implement most of > them. Having such file backends also leaves the question of whether the > particular file should have a higher priority than VC to the end user, > depending on where he(or some major mode he's using) adds a particular > one into the list. Is this pretty much to be able to choose the backends order? I'm afraid it's not a good idea: any backend that comes before the VC backend can make the user experience worse. Because Git-based (fast) file listing is only implemented for the VC backend. > As for whether there should be some kind of default file marked project, > sure, the user can just remove it if he want to. And you can customize which file names serve as markers. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 11:21:28 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 15:21:28 +0000 Received: from localhost ([127.0.0.1]:41652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXmG0-00061o-5z for submit@debbugs.gnu.org; Tue, 05 Oct 2021 11:21:28 -0400 Received: from mail-lf1-f42.google.com ([209.85.167.42]:35494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXmFx-00061Y-96 for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 11:21:27 -0400 Received: by mail-lf1-f42.google.com with SMTP id m3so86535967lfu.2 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=UOB+qmj7c/5PRenv1dNY5iOyYMAJnxHn91wFM6o9lY4=; b=L7NnrYtdqbY2RhEUgKeO8neFNYkf5b9DinlnEdORA5ZaEJ9+pwie0kERZRTNTE25CG 4fTSTXor2mUAH6brrYijRsLGuoTy1s2oa8VwQVBP83WilOTdnR/dEZPxd4kBzFlDyd5U mmJQSnbrLCnMOUwm1xBzX73/H7YsPNO5oeRj1a18FGk/mnH3oWFIIX0h1TXOTPJBHw5s vga+HRvXypHvu6m+jT31u/qDEKLNTeiTo70DoTeWNCek3VOIyERq8c5e/MkNNV/6/HO4 wbEwrLI64De9QMPB2wsfDJNeFLoU+X5y8E/BKeN6hSR9BAuFOBhLTPn2dVi8qxOTNejV 39pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UOB+qmj7c/5PRenv1dNY5iOyYMAJnxHn91wFM6o9lY4=; b=E6gBEmh3NknJw2nqezlhZr7lBRBfDKOaDXCXE94/XKZd4uEdkqnIj7MrL9/SzYyCYP +cFcIWC0jwbOCdkbyiRFkgd8n3YCa5ziMgnmClv8/fHnaMrSQXTUPTjIZA8i+Tk3DF2G eNoBORyDxNQ9p8MyFnYyoxMPMSnXueGg5JJYDvnPsnVMWngXKIT7KGWV9978CVp90AR4 Sdwj+Zgcacpwv4ndtYPybChmVqaS2ouT6Ejeun9hQfylOcsSKkbyAOJSiUmarwKwv/cg GmkPxDyZ6tedzrzqwlZYKJwyc4IPykjoHLEWHb59W8WSRw9R9kwhenQe/2lU+eLzss9C ywZg== X-Gm-Message-State: AOAM531C+A/rvr/Ru/ZYxTNNr+EB7lJuR7xsdG+bb4vONUH5dCtjT4K7 hcVCStobss2VEKr0VfIIQrM= X-Google-Smtp-Source: ABdhPJx3KPZKIhZGMeJNP+Z9YxKzk6oK935PymSEwL/4QDC0CdCoVn1fgwPS839xy2I7qV43uGlo8g== X-Received: by 2002:a2e:7212:: with SMTP id n18mr23476358ljc.64.1633447279269; Tue, 05 Oct 2021 08:21:19 -0700 (PDT) Received: from [192.168.199.3] (broadband-46-242-10-137.ip.moscow.rt.ru. [46.242.10.137]) by smtp.gmail.com with ESMTPSA id p6sm1313130lfs.109.2021.10.05.08.21.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 08:21:18 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> Message-ID: <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> Date: Tue, 5 Oct 2021 18:21:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) It's mostly to somewhat empower people to add new backends. But being to chose backend order is helpful too, since lets say I'm a major mode developer. I add my project type to the end of the list. Then someone says "hey, my VC structure is non-standard so the project gets detected wrongly" and I can just point the user to reorder his list. I don't think we should worry about the user experience getting worse too much, since anyone touching project-find-functions should know what they're doing. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 12:56:42 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 16:56:42 +0000 Received: from localhost ([127.0.0.1]:41764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnk9-0002FO-QH for submit@debbugs.gnu.org; Tue, 05 Oct 2021 12:56:41 -0400 Received: from mail-lf1-f42.google.com ([209.85.167.42]:39760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnk8-0002FA-DT for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 12:56:40 -0400 Received: by mail-lf1-f42.google.com with SMTP id n8so32267838lfk.6 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 09:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hOUZwFJWCX2XXnJYggBVtWp8/INa4AwYK/Ku1rB28mk=; b=kdP0jCaXHQJZQDx7aODDVo7Z5Snk+O5rSxT9Ew5SHxvDImmyA/reXizBwx4iUzSRbu y5u9ZXLicAaTbkDnB0tJFNuBSv0gDuVrgCmr5bSuOQjfxV0NHRRDXVIjZzm5Fm//zzBm HbWp869gzQ2RJz1c2ucKTGo+WUiYPmyttN3znaOCYIXqMLXjOMNZySEzVSTbhwcBx+xO 4yf4ZMeJ+NVTVwUsNxYayHyRu0OgIlT0yYQOx4VWlt6e4HeynOtuNBdwsHN9UGCZRV6u tSYa9JrLgIeZsBrVOGpOYRZSDrp9iwpEL8ht3mWGRn6K9v0LcDwVpDXjrTVx3hKlmbmY 6DDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hOUZwFJWCX2XXnJYggBVtWp8/INa4AwYK/Ku1rB28mk=; b=AhHL89QYDqDQtOQBIl+nXCsoveghMXdqTkhC3z9PRqyjM0cjI19hlRceb3JqqQChBe N1iVAAeMuGbO0orQiqrcEzTYwu4SZlpc8yHdysL+3jafXJ2R4jhU/wqbkhkknrRt7nTK PKd5jDVJ6yI3e+6WtqSPaL+hdAIc+SHOSikTjkCP24r/6APaZ5hx3khQGtmoWqHGFIoJ oGmn06YkG/UiBgoBlRJzqCC52ARoxzezQNfpIJnq3xG2zsDvS8b3nin4mKvVkZabo4mb ZC87IDrH9FY0YGpAaT53LL0jG7WCl1dpimCuDhmkH+RRhhhHEWT4T3m52MnNmCrpM66U mLOA== X-Gm-Message-State: AOAM530+kgx9dpF8mt76gnKDACET8GvDsMUVwhKunqvdWxS4hM+CMfY0 guDo4Qj/eMeBy0SD8GRdpEA= X-Google-Smtp-Source: ABdhPJz9uu35aqm0xKubAHEW6jUqBQhOiKn9KgfeTT1yyCmdEMdd5zNjpDMC6DfFHYPuSdC3mefHsQ== X-Received: by 2002:a05:651c:120f:: with SMTP id i15mr22677314lja.59.1633452989220; Tue, 05 Oct 2021 09:56:29 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id n9sm2008984lfu.88.2021.10.05.09.56.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 09:56:28 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> From: Dmitry Gutov Message-ID: <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> Date: Tue, 5 Oct 2021 19:56:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 18:21, Nikolay Kudryavtsev wrote: > It's mostly to somewhat empower people to add new backends. It's not too difficult to do even now. > But being to chose backend order is helpful too, since lets say I'm a > major mode developer. I add my project type to the end of the list. Then > someone says "hey, my VC structure is non-standard [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.42 listed in wl.mailspike.net] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.42 listed in list.dnswl.org] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.9 (/) On 05.10.2021 18:21, Nikolay Kudryavtsev wrote: > It's mostly to somewhat empower people to add new backends. It's not too difficult to do even now. > But being to chose backend order is helpful too, since lets say I'm a > major mode developer. I add my project type to the end of the list. Then > someone says "hey, my VC structure is non-standard so the project gets > detected wrongly" and I can just point the user to reorder his list. As long as major mode developers don't do that, it's probably fine. But you can provide a backend of your own > I don't think we should worry about the user experience getting worse > too much, since anyone touching project-find-functions should know what > they're doing. I wouldn't be so sure. Especially if you tell your users to do that. But let's talk about "your project type". Is it an existing backend? What kind of projects are we talking about? Does it optimize the file listing performance? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 13:01:11 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 17:01:11 +0000 Received: from localhost ([127.0.0.1]:41786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnoV-0003RW-Cx for submit@debbugs.gnu.org; Tue, 05 Oct 2021 13:01:11 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:43725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnoP-0003HI-OU for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 13:01:09 -0400 Received: (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id F2DA0C0002; Tue, 5 Oct 2021 17:00:56 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> Date: Tue, 05 Oct 2021 19:32:56 +0300 In-Reply-To: (Dmitry Gutov's message of "Tue, 5 Oct 2021 15:42:29 +0300") Message-ID: <87wnmr793j.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) >>> A way to specify ignore entries for "fallback" projects can be added easily >>> with a variable like project-fallback-ignores (same as >>> project-vc-ignores). I've been debating internally whether we need such >>> a variable at all, and whether it should simply be an alias for >>> project-vc-ignores. But, uh, probably not? >> Adding such a line to .dir-locals.el would be fine: >> ((nil . ((project-vc-ignores . '("subdir1/" "subdir2/"))))) > > ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) This is fine too. >> Or this would be even better: >> ((nil . ((project-ignores . '("subdir1/" "subdir2/"))))) > > I wouldn't want to create an impression that this variable affects any and > all project.el backends, including third-party ones. Ok. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 14:19:32 2021 Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 18:19:32 +0000 Received: from localhost ([127.0.0.1]:41887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXp2K-0006fz-1v for submit@debbugs.gnu.org; Tue, 05 Oct 2021 14:19:32 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:36447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXp2H-0006fl-Bj for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 14:19:30 -0400 Received: by mail-lf1-f53.google.com with SMTP id b20so90660793lfv.3 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 11:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=AdSNcuZXc3mSJBbUCiHgHfUsAYovhfF3TRWFljLJbzs=; b=HMWh0+Fmh5IhpYyTgEMNXzeHxa5bkozwj5RhuqkUNChq+J/EMUoPJ18IB1omz1UuIo 7Sj7LJ6XG/nuq9cRKpfkmXIFi7vE3o1lR6zHF7kesinTEdL/pUNw0t/rDPH5ECyy4RW+ IlWWLWX4iC8lTxYCNvwTSzu2i61/W16Da/YtW28EWpBKvNieKMazm511r/DheMI975/g bDA+brKe3/oORgUUnrLaqPMzwTMTfk0Gv5FDXmQN35Ix06DvSMdmytVdkWIFF5ahRBLV E4U/ba59O59oMZRb0dEYIOaF3MOVBMveNbrJdJtLWDXQ65KAcdQ/o3oxCarqyz+rlzDk g55w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=AdSNcuZXc3mSJBbUCiHgHfUsAYovhfF3TRWFljLJbzs=; b=hsyxg0dNWnWTfp5YcoAgbCL6jA1JNU6CWTdky19Ezg+l9t0T6VB5wn0ozymA8T72vE 81wsqXSEiyjHmdZq3e5Qle0VjMeNnSLY4y2RWaqmsEo8L9nOvkwOHVVnZwed99AlKTpw MOiDF1go5LYu5TPEKuZjoQe0ZlKgGGX5Q7H16rilkkCQc5J1+7spnSzd/aNCBujf4/p8 Jk21xhtVpEOMWMbQI4r9HhtxwwuEBtc7/H3RFzAKhy2fyQ3lKASPMSplPElzzcAIDFNu ol4T5ik3EPw+g/1IZ/E0ES0PVB72wye/wuDndjILbRjvutk+kFsxeimQ2H3F2Cjh9Mz5 xgvQ== X-Gm-Message-State: AOAM532vzPLu2wY3AKiqtdJM2DvSKVd/907OtjERWZ1G7xs0FGlu2zva f9BYagvFmfnF+farM6KOWro= X-Google-Smtp-Source: ABdhPJzxb1Z94hdoU18s5vB7sFM1db2uQKsqnJ3hnbDyH/oM+S5atgb1V1sqDv5a7rAfeWRWylGPjA== X-Received: by 2002:a19:c10d:: with SMTP id r13mr5327393lff.339.1633457963328; Tue, 05 Oct 2021 11:19:23 -0700 (PDT) Received: from [192.168.199.3] (broadband-46-242-10-137.ip.moscow.rt.ru. [46.242.10.137]) by smtp.gmail.com with ESMTPSA id o5sm2034455lft.278.2021.10.05.11.19.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 11:19:22 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> Message-ID: <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> Date: Tue, 5 Oct 2021 21:19:21 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) I currently have a very basic real use case on my hands. There's a particular programming language that has it's own project file type. Since it's a project type, it makes sense to plug it in as project backend. And then on top of this I can implement project target actions like build, compile and debug(this is actually another matter that probably needs to be implemented in(or over) project.el at some point, I'll probably open a discussion about it later). So it all makes sense so far, at least conceptually. But here you're saying "you should not add a new file-based backend until you really think about the project file list optimization first". This violates the classic rule of doing the right thing first, then optimizing second. So while I feel this a real issue, it IMHO should be filed and discussed separately and is a nonblocker for this particular task. Now to contradict myself, lets continue discussing this issue. I think this is a local version of a more global multiple backends problem. Lets say we have the same project(more precisely, a set of files) that is served by multiple backends. Roughly we order project-find-functions in this order: major-mode backends, tool backends(eg. GNU Global), generic backends(VC). The preference for the major mode backends over others is due to that "VC has different root" use case. Tool backends are preferred to VC due to that you can start a new Global project as sort of a custom project hack. And here we run into the problem: our major mode while it provides a backend, does not optimize file listing, but there's a backend that does. I think TRT is project.el choosing a different secondary backend in this case as long as it has the same project root. For this it needs to have some rules, to know which backend better fits a particular situation, which does not. This would require a change of backend registration, since you can't just have one function, so in the end the api would look something like this: (register-project #'my-project-find-function :optimizes-file-listing nil) From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 20:11:15 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 00:11:15 +0000 Received: from localhost ([127.0.0.1]:42129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXuWg-0005DR-Th for submit@debbugs.gnu.org; Tue, 05 Oct 2021 20:11:15 -0400 Received: from mail-lf1-f41.google.com ([209.85.167.41]:41737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXuWe-0005DD-Fa for 41572@debbugs.gnu.org; Tue, 05 Oct 2021 20:11:13 -0400 Received: by mail-lf1-f41.google.com with SMTP id j5so2814922lfg.8 for <41572@debbugs.gnu.org>; Tue, 05 Oct 2021 17:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aBWTrtEPWT7rHU68L0X/kj2aKile47hvVZ+OK0dtoCA=; b=p/rPw4aYO01UcCWJ978nT3HwLEVdCGphhAkSMWdHK76XHpCN3GaeE47TIL9y/0j/Fi QO3j5Bq9ruNJfHoYszfsh6re5S4O9QhLPy8vA2jbRXx5BJjWiqF79qlSuqno8LslWBR9 Qlsyz8LGiX8WnCVo9CYKvRa2Q/Sw5klBGACGavzeTOVAqYfcj0QNIBXwVuy9cRxtAR+x n240fEtqwwnde0WTJXfarDgDS7HgmL18nRKoK7A1g9iN4glzmZnypxRWEBBBCOk/+r2o n321Di7oLt6UAfvwvknNbFSuzKRYa14QgRjaJv0czTytqQQ4GHvVAkc5MNrVq0XoV0PM u3Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aBWTrtEPWT7rHU68L0X/kj2aKile47hvVZ+OK0dtoCA=; b=eX4kj23jlzo/VbJ827EMKHc9+OEJX64yOwUQpq2Egeaj9Z4dakQwpUCahOiCAtKSfE JkDu90eM4nsrK08cUO6Frkcr7c8wLAibVGSpEnrKhvROSA8SoNYoeVyLon6rD0mL7CuV WA6B+SZ7Jmyhb1jsI7DsCtmwl6uh9herbt0vkf2C0pEkAaOsbv7HF372cKclapSFD827 YiGZjcb8Gk1rc4ov3Vsr57vjj3F0Z2LLTy/moB3yZ/ilarkjWBxJ/P3nTrEB0e7tWAP8 QqNtzYaO3NQ+9o8kL1ARD5yD+sCbtJ1RVC8yaHxdZ4ftqM7y2MIKBM5ZvT9utyO6TLtz S7Pg== X-Gm-Message-State: AOAM530llL0fsnaUi/OsiCq67I3KMLYA6IHfaU83nMYld/8BdlwwYqgG wn/b8FgHFnBVEtHd8T0rjgg= X-Google-Smtp-Source: ABdhPJxJ2WNNc3nrR0AnA5bL156z/URrwzT48ZEmOoGx6sHLhq2GBxioaM5mrl4UAIATRl9y9jAlkQ== X-Received: by 2002:a05:6512:6d2:: with SMTP id u18mr6318789lff.453.1633479066385; Tue, 05 Oct 2021 17:11:06 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id n19sm2104640ljc.11.2021.10.05.17.11.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 17:11:05 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> From: Dmitry Gutov Message-ID: Date: Wed, 6 Oct 2021 03:11:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 21:19, Nikolay Kudryavtsev wrote: > I currently have a very basic real use case on my hands. There's a > particular programming language that has it's own project file type. > Since it's [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.41 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.41 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.9 (/) On 05.10.2021 21:19, Nikolay Kudryavtsev wrote: > I currently have a very basic real use case on my hands. There's a > particular programming language that has it's own project file type. > Since it's a project type, it makes sense to plug it in as project > backend. And then on top of this I can implement project target actions > like build, compile and debug(this is actually another matter that > probably needs to be implemented in(or over) project.el at some point, > I'll probably open a discussion about it later). Right, we are yet to consider this functionality properly. > So it all makes sense so far, at least conceptually. But here you're > saying "you should not add a new file-based backend until you really > think about the project file list optimization first". This violates the > classic rule of doing the right thing first, then optimizing second. So > while I feel this a real issue, it IMHO should be filed and discussed > separately and is a nonblocker for this particular task. Let's talk about correctness. The "right thing". Suppose we have a large Git repo, which contains a "foo project" (as you might see it), marked by Foofile in its 'foo' subdirectory. And suppose we allow the project-foo backend to come first before the VC backend. When we are inside the directory ./project/foo, that's the current project. File listing shows ("./project/foo/a", "./project/foo/b", etc). But when we go up a directory, "./project/". And when asked to list its files, how do we avoid including "./project/foo/a" in that list? It would make sense to exclude any nested projects, right? But we can't do that if the project detection logic is so flexible that the project-vc backend couldn't find out about subprojects inside it except by visiting every subdirectory and querying for the current project there, which would obviously be too slow. So it's a correctness issue as well. Hence the simpler-but-easier-to-get-right approach in the other patch (with the project-vc-subprojects variable). Even if it might require more effort from the end user, unfortunately. > Now to contradict myself, lets continue discussing this issue. I think > this is a local version of a more global multiple backends problem. Lets > say we have the same project(more precisely, a set of files) that is > served by multiple backends. Roughly we order project-find-functions in > this order: major-mode backends, tool backends(eg. GNU Global), generic > backends(VC). The preference for the major mode backends over others is > due to that "VC has different root" use case. Tool backends are > preferred to VC due to that you can start a new Global project as sort > of a custom project hack. Setting project-find-functions in a major mode is a questionable thing to do, because then you end up with Emacs where files in the same directory belong to different projects. As we say in the commentary: ;; It is a good idea to depend on the ;; directory only, and not on the current major mode, for example. ;; Because the usual expectation is that all files in the directory ;; belong to the same project (even if some/most of them are ignored). We want to support even backends where this approach is violated (on a best-effort basis), but let's not make this the common scenario. > And here we run into the problem: our major mode while it provides a > backend, does not optimize file listing, but there's a backend that > does. I think TRT is project.el choosing a different secondary backend > in this case as long as it has the same project root. If there is a next backend which indicates the same root, why do we need the first one? > For this it needs > to have some rules, to know which backend better fits a particular > situation, which does not. Why do you need so many backends, anyway? One per language, one per tool, etc. That seems to reduce the concept of a project to "this one parent directory containing a file some tool cares about". What would be the meaning of the value (project-current) returns? Suppose I call project-find-file, meaning to jump to another file in the same Git repository. And instead I am shown only a list of files in the current subdirectory because it contains, say, a Makefile. Is that a good idea to enact this kind of behavior automatically? Or suppose we add a backend that looks for 'Makefile', another for 'Gemfile', another for 'Rakefile', etc. What user-level commands are going to benefit from this setup? A command that shows the available Makefile tasks? It can just as well call 'locate-dominating-file' to find the nearest directory containing it. Same for 'M-x rake', and so on. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 03:40:53 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 07:40:53 +0000 Received: from localhost ([127.0.0.1]:42369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY1Xp-00025w-7X for submit@debbugs.gnu.org; Wed, 06 Oct 2021 03:40:53 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:50459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY1Xn-00025i-4k for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 03:40:52 -0400 Received: (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 04B611BF203; Wed, 6 Oct 2021 07:40:42 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> Date: Wed, 06 Oct 2021 10:21:06 +0300 In-Reply-To: <87wnmr793j.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 05 Oct 2021 19:32:56 +0300") Message-ID: <878rz6wrdp.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) >>>> A way to specify ignore entries for "fallback" projects can be added easily >>>> with a variable like project-fallback-ignores (same as >>>> project-vc-ignores). I've been debating internally whether we need such >>>> a variable at all, and whether it should simply be an alias for >>>> project-vc-ignores. But, uh, probably not? >>> Adding such a line to .dir-locals.el would be fine: >>> ((nil . ((project-vc-ignores . '("subdir1/" "subdir2/"))))) >> >> ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) > > This is fine too. Actually, the name 'project-fallback-ignores' would be too weird when used in .dir-locals.el. The users will ask "Fall back from where?" Maybe a better name would be 'project-directory-ignores' with the directory-based backend name 'project-directory'? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 10:09:44 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 14:09:44 +0000 Received: from localhost ([127.0.0.1]:45073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY7c7-0000x0-Mn for submit@debbugs.gnu.org; Wed, 06 Oct 2021 10:09:44 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:33659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY7c5-0000wk-W4 for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 10:09:42 -0400 Received: by mail-lf1-f46.google.com with SMTP id y23so11302637lfb.0 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Exr0oU1l6qjHOgZVkfrSOTdHe+MM/FA7VEk7qJ3O6Tw=; b=cl+C+0DT25kg2CjTPWUQmT4nq2PhlNFYRxdOJ3hsKnv0yvkw2O5jU/eZihqfO7E2zg JZI41t4sP/5EPa5h8MeLP24bYYPFB174o1fjBrlW0XNU26Dd2FQBgkmztmw9OXxEhne+ OtducdwHV4THrzPc+OwZUeFZsjX7h4EQmAnf9F6uBX7YQpGuWOzVVUuOfT1jGtfepIc9 rNFaoRm+tM6d6wQPxxvWsMZiKa1FaEsycQM5liPKhh3zUC+R1edIW68azquQ2s5fUPg/ oIKvwxujw4uMnD9h7L0lwDzM2fh5/Q9wEkepfqjn41y6TqdSgcPUgPH2GIShI/4DKpK4 oecA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Exr0oU1l6qjHOgZVkfrSOTdHe+MM/FA7VEk7qJ3O6Tw=; b=sE4Lbl+Gc7d1+mYyAVRUTcMIwaxjVIpGJfkYKVIu8PaHm2dpZhT3cUz+VYnn8KP5FN l+MmEvJWIqopVWMgD79vRgRb79xzNFv987bcFUt1JKH3BKW7yrPb4YTXfK5A+CCUTQ52 kEhBHYEy3Hq5+TyE3ockGS9mv9zhFg4+57TMtlUbnJ6Q+pHwexCHAZVDs+tetj46MaUE ZjfQn1vc8TOBo7jcC4KymAYHtm01FwD15gIPyxihJ0AOxWKZ0h823HlXqUEnTcBN+GhC NFFH67I0nYKnlfX3IO9+Uo8yqS0HGNGQuCXiXWDSnftfOHACcuJsMuohfjLUGHzXIlCB F3+w== X-Gm-Message-State: AOAM532n5SrG+pXcXHd5gmayuWCYEpMKxDG02XTq5Dovy4WDaZTL5QZw MJIdXmlFOZx88TXs2UL33zU= X-Google-Smtp-Source: ABdhPJyweCIeJYy6VzcrObaON4H//GEPxuZ0b6/u4XYDhC5ThDHwpZgMaWstX5PRYcX0oaUeoY2TYw== X-Received: by 2002:a2e:2243:: with SMTP id i64mr28933246lji.333.1633529371604; Wed, 06 Oct 2021 07:09:31 -0700 (PDT) Received: from [192.168.199.3] (broadband-46-242-10-137.ip.moscow.rt.ru. [46.242.10.137]) by smtp.gmail.com with ESMTPSA id e26sm496818ljg.13.2021.10.06.07.09.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 07:09:30 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> Message-ID: <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> Date: Wed, 6 Oct 2021 17:09:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) > But when we go up a directory, "./project/". And when asked to list > its files, how do we avoid including "./project/foo/a" in that list? > It would make sense to exclude any nested projects, right? Not necessarily. It may be a useful thing to do for some projects, but it does not follow from anything that it should be the only or the default option. The correct solution here is IMHO implementing some kind of .project-settings.el file in which you can set hide-nested-project-files. > Setting project-find-functions in a major mode is a questionable thing > to do, because then you end up with Emacs where files in the same > directory belong to different projects. I'm not talking about setting it locally in the mode, more about modes providing such functions on load. That's another important question. More backends are more functions to test, so it's reasonable to add backends only when they're needed. I may avoid programming in language X from some months so no reason to keep that backed on, but when I start editing a file in that language, the major mode loads and so should the backend. > If there is a next backend which indicates the same root, why do we > need the first one? We don't know what the next backend in line indicates. Nor do we care about it since the current one already gives us something. We just try to find backends until we find one in the order of priority and then stop. > Suppose I call project-find-file, meaning to jump to another file in > the same Git repository. And instead I am shown only a list of files > in the current subdirectory because it contains, say, a Makefile. Is > that a good idea to enact this kind of behavior automatically? If a user believes that it looks like a duck, it should squeak like one. Sure you personally may want to suppress some possible project backends from firing, but someone may want the opposite. I want to remind you of this recent-ish thread on HGE: https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00045.html Lets take the maven example presented there. We have a project containing modules. The user wants to compile both independently. We can write two different compilation commands, one that works on the project and one that works on the module. Or we can just have a single command, since the compilation process is not different in any way for both. Then we can give that command some prefix that would make it work not on the project itself but on the root project of that project. The Makefile example is your strongest argument here, but we can define find functions for it recursively. That is until you find a Makefile that does not have a dominating Makefile of it's own. And if all else fails you can just use the proposed plain project mark. > What user-level commands are going to benefit from this setup? It seems that we somewhat differ in our priorities for project treatment. You seem to prioritize the logical grouping of files for editing operations, while I prioritize "actionability". If a certain directory has a set of unique actions that can be performed on it, then it's a project for me. And while your observation that such emphasis on actionability may result in worse logical grouping is broadly true, it is not necessarily true that a blind reliance on VC backend would result in proper logical grouping. Sure, that would be true for most projects, but oftentimes you have multiple independent, but related projects sharing the same repository. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 12:39:49 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 16:39:49 +0000 Received: from localhost ([127.0.0.1]:45374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY9xN-0007Jz-AM for submit@debbugs.gnu.org; Wed, 06 Oct 2021 12:39:49 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:35039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY9xM-0007Jm-1t for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 12:39:48 -0400 Received: (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id DCB7620003; Wed, 6 Oct 2021 16:39:39 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> Date: Wed, 06 Oct 2021 19:29:50 +0300 In-Reply-To: <878rz6wrdp.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 06 Oct 2021 10:21:06 +0300") Message-ID: <87zgrmxie9.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) >>> ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) >> >> This is fine too. > > Actually, the name 'project-fallback-ignores' would be too weird > when used in .dir-locals.el. The users will ask "Fall back from where?" > > Maybe a better name would be 'project-directory-ignores' > with the directory-based backend name 'project-directory'? Or simply 'project-dir-ignores' where 'dir' refers to 'dir-locals'. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 17:14:09 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 21:14:09 +0000 Received: from localhost ([127.0.0.1]:45601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYEEr-0005vp-J1 for submit@debbugs.gnu.org; Wed, 06 Oct 2021 17:14:09 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:37872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYEEn-0005vB-ON for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 17:14:09 -0400 Received: by mail-lf1-f53.google.com with SMTP id z11so7740320lfj.4 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 14:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=T9J6wO4ZMxrMnOAKLfZP1hGNZVkbyWkdK0K1S4y38C4=; b=UN4vw9TC+kCtCdKY+/Abhn0beWaVxGS860js35Cq+gJd1kLXA2fyGArxz2u0WwPWca +Kbte0EP/TSQwQMq29RcA9S4wcQy3a+0MoCzMGmIqM0loGpLcqOFUEuzZq70eI5MqN5o l1pvkPRjMmBz2jf9GjdMz+iJsAqS8iGv0Um5UNlAYPUgo3bB3iSlFhD5QaR0bTThRfkm GdrZqY76QuVqEdVHEhmjmIngX6A1lHPkShol5zD/Oznrx3XME2dVa9TVQ9054BN7wPuw zsTcbLRum7FFBfcKmulB2Z2zh7RA2/uaesPQOeMlKW5OhsKmD9ZghDierHKzG7CjLSJ+ Q3ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T9J6wO4ZMxrMnOAKLfZP1hGNZVkbyWkdK0K1S4y38C4=; b=4jKe3qSSxRVeFNX0eqaFqYiLMNb+c0Mg0HMXcpj23NQtvhqGCVT6HgQmjmBKG5jQW0 zQn89EWpdwG+ptUP25Vz/hSimlmYbd56P8JlIDpiOSN0lfvKokNyscVmFN9B1qsh4a9W za9nCQObfF97h7LGaJNtFEmZqp04cW5GUkUPCTr55dHIqx0MONoD6/anTKR3IYyzViD/ Bv8wpg+PBVZGa1VqnTPEd43ugOI3ySb5xXKS3f3b7rVBk4RM5KRzJ7XF83U8ZU1MNFzb qyN98U8H/buhiF5qxlqDdHIKe1j3vdhR5VuTzxHqCkWNzwlZ3JmdbXeGLKMEUPYpPAnX jqwQ== X-Gm-Message-State: AOAM5312B+/Colxy8N+1UW3B7H3nILDP2jxu4UARJC/itZxV5VWa+S3K bR8WdS3u29moQ+JIewSTWqgqbm8I4CY= X-Google-Smtp-Source: ABdhPJxKtjIIBrrGACO9KjXrcO87yonU5wIPHfqZ3yzuvq647LaNBhmvnH5vXyWvvmibkQ6bqChA1w== X-Received: by 2002:a05:6512:ad4:: with SMTP id n20mr350370lfu.66.1633554839527; Wed, 06 Oct 2021 14:13:59 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id g9sm302666ljk.80.2021.10.06.14.13.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 14:13:58 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> Date: Thu, 7 Oct 2021 00:13:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <878rz6wrdp.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 06.10.2021 10:21, Juri Linkov wrote: > Actually, the name 'project-fallback-ignores' would be too weird > when used in .dir-locals.el. The users will ask "Fall back from where?" It's the standard practice: using the prefix, so it's "ignores pertaining to the project-fallback project backend". Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.53 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.53 listed in list.dnswl.org] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 06.10.2021 10:21, Juri Linkov wrote: > Actually, the name 'project-fallback-ignores' would be too weird > when used in .dir-locals.el. The users will ask "Fall back from where?" It's the standard practice: using the prefix, so it's "ignores pertaining to the project-fallback project backend". Fallback from what? From the VC backend. The fallback backend is used when the VC backend is not (there is no recognized VC repository). > Maybe a better name would be 'project-directory-ignores' > with the directory-based backend name 'project-directory'? I don't know if it's better. What does "directory" mean? Every backend, every project has directories. As mentioned previously, the other option I had considered was 'novc'. Then the variable would be called project-novc-ignores. This is not a done deal, just what seems the most optimal to me at the moment. But opinions welcome. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 17:16:28 2021 Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 21:16:28 +0000 Received: from localhost ([127.0.0.1]:45606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYEH5-0005zm-Up for submit@debbugs.gnu.org; Wed, 06 Oct 2021 17:16:28 -0400 Received: from mail-lf1-f52.google.com ([209.85.167.52]:39870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYEH4-0005zb-Sp for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 17:16:27 -0400 Received: by mail-lf1-f52.google.com with SMTP id n8so15161285lfk.6 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 14:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ahf0FaxoOjdx3TPptUm1hw4juAq9adnwXoADsvQDW24=; b=V/gFk9o539PEb/2oZ/R0z1edBJIA6sqc5BauZRHjm6GCNdNKcxLlbVuNo3kCmKaJdv lW8OehTKQNiAn5PuVn1vRcQCgwz+ijrkMkExwNIv5ascIr00p6EDH03Ac8+jsVrKvZMg AO5Wm7SKLWP5mMtS7zMmGQUIK4YVldXtNNqwiwsJF+ZhXJrdzf0e7WYgjyMHzLY6PGKy PVJ2XtBRs788MbL+2fG+hFAZfb7B8lBzIxdqJBO/MRXW4edUFEHT62xs+57n3PE2StrD RReXKMv/XmZMRtECyw3/EfdHuxWvdbvaEQvZLmabfZZKVTbNzX8SqdufJbpJCR6J7/+r bMdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ahf0FaxoOjdx3TPptUm1hw4juAq9adnwXoADsvQDW24=; b=FfEq9+dAU5V2sWLLkTM6tC86SJ7uzVRdjkPRUM4LoxGRXWEkCkFgdcZf1XC+6ONnEN tXkT4tMhTTp8aQCSnHTn7415LJWFdRrWUgR0l+GXGzjXKb1CmZsrijw5NC6LTJmIKWVZ /cO6tgF7hmfiPKrEWF4ugZfiZvz57UujToAKfcFJTwDGbATWlb+RE8CcuJSdN69GPjDO aQWoAncDi0uh/fVrFIXzZWpKnMlxYSAL3U6DMjvxgMQaYYfkC6MJfpc1yi1ZBQsQZZUp /42/jRK2AfW8LyrXR4r5IzZC16LBAyv/coegfDrR+EvoQHvZ4vNTGslPtJ8sEcMCD2FC IMZQ== X-Gm-Message-State: AOAM5337qg331m+DMBjIb5kLZ6ew9WLaK5/gEKp7LdvYR3LoKIfqA2zT +AzPD0T3KfWFdEmDu/a6GszUraBgRmk= X-Google-Smtp-Source: ABdhPJxGcLAzrQgwKvNu11FIUyfGLlxp9yIxspbaMAzq/fEe8PyA36I7EqiZuKip1up7il9XQ2DOtw== X-Received: by 2002:a19:c74d:: with SMTP id x74mr289196lff.603.1633554981035; Wed, 06 Oct 2021 14:16:21 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id l24sm2361688lfh.8.2021.10.06.14.16.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 14:16:20 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <87zgrmxie9.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <770842e0-7bb6-1e53-737b-f9b444e8e05c@yandex.ru> Date: Thu, 7 Oct 2021 00:16:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87zgrmxie9.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 06.10.2021 19:29, Juri Linkov wrote: >>>> ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) >>> >>> This is fine too. >> >> Actually, the name 'project-fallback-ignores' would be to [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.52 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.52 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 06.10.2021 19:29, Juri Linkov wrote: >>>> ((nil . ((project-fallback-ignores . '("subdir1/" "subdir2/"))))) >>> >>> This is fine too. >> >> Actually, the name 'project-fallback-ignores' would be too weird >> when used in .dir-locals.el. The users will ask "Fall back from where?" >> >> Maybe a better name would be 'project-directory-ignores' >> with the directory-based backend name 'project-directory'? > > Or simply 'project-dir-ignores' where 'dir' refers to 'dir-locals'. Wouldn't that imply that it would apply to every backend, as long as the entry is in .dir-locals.el? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 06 22:27:52 2021 Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 02:27:52 +0000 Received: from localhost ([127.0.0.1]:45739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYJ8S-0001EN-32 for submit@debbugs.gnu.org; Wed, 06 Oct 2021 22:27:52 -0400 Received: from mail-lf1-f45.google.com ([209.85.167.45]:42709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYJ8M-0001E0-Ef for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 22:27:50 -0400 Received: by mail-lf1-f45.google.com with SMTP id x27so18290732lfa.9 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 19:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CF63bVNaGCXVB1JXL51VgDjvaxJA2XwX7ewLROuZBWg=; b=BSXKY9KmcvxzVKiYHfUwl85vgF/szWjTdHoK/jr2RU4QxPVvBrrYukGPt1v8dPOe0w wwaQq5yiK2yO1ZlhrphQGB+zNf1+ofpKJru3tDs8EV/SFoNMHonl4j1Y5bsNbHhZHBqg ShIyeoF91gZ4u298Yy39hjjT8Vh6MQVWmGXxEEKPyJORejNTTV+hJJile9s0hk+DGq/r o5Fs9RMW/7SXdGaj0RX+VC6L0GBwjU9nXG1BouyuRtUyaa9KzlACDktM2eW75Nzz1qh4 xhyOrspfwQATjzzasJFmLb6hq4Ege1PdovmFZI5n7Es69T+zh9jsrF/lXG2QufiqvfnW oCwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CF63bVNaGCXVB1JXL51VgDjvaxJA2XwX7ewLROuZBWg=; b=JkWMNXWs/N3VAMojtetA8EBPo9UZu6g20mjXS/tCMzRSbDoVx5el4lJBS3bSK5q81L byFca36pda7zTM8svmDFWPfEFG2BZrLXM0RFQg2HIGms+0RxJ6ATHaY4ZNSX0gfvK1XX 4ugngh3N1w/V/4y8+mn2v/qDHCd+0BQWZQsxiW+GW1RXPPIWMvU2k7HKM7ApwpI+4V1v +3CJCcEcTlyzlnQ9C1NHZxUXupt4c/dX44e/UCdziZa9/IYTsaV0Qq1EF/8KJmReE2mN hHHWhkRUnEZQjfK3uMawA1x510TOo1vYT152yf0wUutAkDgycAR3srWkc5A25Kf9itdD Ltag== X-Gm-Message-State: AOAM533f9eKHbKErzWdC0Ey/nnKmvCkb3UcMGBVzGS7E8MbtWW+7PLuP o2NNUaJS6sOxEd1Ocn0Dbkw= X-Google-Smtp-Source: ABdhPJxZ5NJmXTir0dR0oc59iufj5jh8AQrjcgvx1slO89GEuuBOTIYvO99vzrJSWwuLicOrrOWe+A== X-Received: by 2002:a05:6512:3da3:: with SMTP id k35mr1558110lfv.137.1633573660017; Wed, 06 Oct 2021 19:27:40 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id m6sm269156lfb.190.2021.10.06.19.27.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 19:27:39 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> From: Dmitry Gutov Message-ID: <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> Date: Thu, 7 Oct 2021 05:27:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.9 (/) On 06.10.2021 17:09, Nikolay Kudryavtsev wrote: >> But when we go up a directory, "./project/". And when asked to list >> its files, how do we avoid including "./project/foo/a" in that list? >> It would make sense to exclude any nested projects, right? > Not necessarily. It may be a useful thing to do for some projects, but > it does not follow from anything that it should be the only or the > default option. When should we not do it? > The correct solution here is IMHO implementing some kind > of .project-settings.el file in which you can set > hide-nested-project-files. You can already specify ignored files in a project through .dir-locals.el. But then you will end up specifying the same information twice. Once when setting up those new backends -- and the second time when configuring the parent project to ignore particular subdirectories. And that seems problematic from the usability standpoint. Also, that information can easily get out of sync. >> Setting project-find-functions in a major mode is a questionable thing >> to do, because then you end up with Emacs where files in the same >> directory belong to different projects. > I'm not talking about setting it locally in the mode, more about modes > providing such functions on load. That's another important question. > More backends are more functions to test, so it's reasonable to add > backends only when they're needed. I may avoid programming in language X > from some months so no reason to keep that backed on, but when I start > editing a file in that language, the major mode loads and so should the > backend. If the only piece of information such modes intend to provide is the name, or multiple names, of "marker" files which indicate that their containing directory is the root, and if this information should be applied by the user manually anyway, why not have a single backend for that purpose, with a custom var containing the list of files names? The major modes can tell the users to modify that variable. And this backend is in the proposed 'fallback' backend. >> If there is a next backend which indicates the same root, why do we >> need the first one? > We don't know what the next backend in line indicates. Nor do we care > about it since the current one already gives us something. We just try > to find backends until we find one in the order of priority and then stop. That didn't really answer my question. >> Suppose I call project-find-file, meaning to jump to another file in >> the same Git repository. And instead I am shown only a list of files >> in the current subdirectory because it contains, say, a Makefile. Is >> that a good idea to enact this kind of behavior automatically? > If a user believes that it looks like a duck, it should squeak like one. > Sure you personally may want to suppress some possible project backends > from firing, but someone may want the opposite. I'm not sure how I would suppress "possible project backends" from firing. That's the rub: the configuration is global, and whatever backend ends up being used, should be the most fitting to the total set of possible user's needs. Meaning, it should correspond to the user's view of the project to the best possible ability: point out the root, exclude the files that need to be excluded, and ideally fetch the list of files quickly as well. > I want to remind you of this recent-ish thread on HGE: > > https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00045.html > > Lets take the maven example presented there. We have a project > containing modules. The user wants to compile both independently. We can > write two different compilation commands, one that works on the project > and one that works on the module. Or we can just have a single command, > since the compilation process is not different in any way for both. Then > we can give that command some prefix that would make it work not on the > project itself but on the root project of that project. Either you have a compilation command that is Maven-aware (and thus can find the module root directory on its own), or we add an extension of the project API, with generic like project-modules, where modules behave like projects themselves (can implement the 'root' and 'files' methods). And maybe with a project-current-module generic as well, though it could easily be implemented with a linear search across a small list (with file-in-directory-p check). But if the command creates a Maven-specific invocation, it doesn't need the above abstraction -- it works with Maven, so it knows Maven, it can look for the current module directly. Or just use the project root, if the appropriate value of prefix was specified. I don't see where your approach would make things simpler/more predictable/reliable. > The Makefile example is your strongest argument here, but we can define > find functions for it recursively. That is until you find a Makefile > that does not have a dominating Makefile of it's own. And if all else > fails you can just use the proposed plain project mark. That's possible, but it's not at all a guarantee that in every big project every Makefile will have a "dominating" Makefile of its own. The above is just a particular GNU convention. But Makefiles are also used for quick scripting in projects that are actually built with other tools. >> What user-level commands are going to benefit from this setup? > It seems that we somewhat differ in our priorities for project > treatment. You seem to prioritize the logical grouping of files for > editing operations, while I prioritize "actionability". I'm prioritizing "universality", so to speak. And predictability. So that a certain class of commands (or several classes, actually) can use "current project" and be reliably certain of what it is. > If a certain > directory has a set of unique actions that can be performed on it, then > it's a project for me. It would seem like your vision of the project could benefit from a notion like "facet". E.g. a project lookup would search for not just "the current project", but "the current build project" or "current file listing project", or... I don't know what else, actually. But I'm sure there can be other additions (something test-framework related, maybe). But unless I'm missing something major, the same goal could be served by an addition of a new hook. Like 'buildtool-find-functions'. Which would return, for example, new kind of object, and that object could tell the parent directory of its build file, and the list of the tasks described in it, and... perhaps something about how those tasks should be invoked. That new abstraction could be used by commands that want to interact with build files in an abstract fashion and to launch build tasks. It might also have a problem choosing which Makefile to use, out of a hierarchy of Makefiles, though. Requiring similar customization capability. > And while your observation that such emphasis on > actionability may result in worse logical grouping is broadly true, it > is not necessarily true that a blind reliance on VC backend would result > in proper logical grouping. Sure, that would be true for most projects, > but oftentimes you have multiple independent, but related projects > sharing the same repository. There are two patches in this bug report. Have you looked at the other one? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 07 03:31:24 2021 Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 07:31:24 +0000 Received: from localhost ([127.0.0.1]:45853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYNsC-0000eS-Ez for submit@debbugs.gnu.org; Thu, 07 Oct 2021 03:31:24 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:47745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYNsB-0000e9-2g for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 03:31:23 -0400 Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 49DA8FF80E; Thu, 7 Oct 2021 07:31:13 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> Date: Thu, 07 Oct 2021 10:17:12 +0300 In-Reply-To: <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> (Dmitry Gutov's message of "Thu, 7 Oct 2021 00:13:58 +0300") Message-ID: <87wnmppdmr.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) >> Maybe a better name would be 'project-directory-ignores' >> with the directory-based backend name 'project-directory'? > > I don't know if it's better. What does "directory" mean? Every backend, > every project has directories. Then maybe the backend could be named 'project-file' since a special file defines the project root. > As mentioned previously, the other option I had considered was 'novc'. Then > the variable would be called project-novc-ignores. "novc" is the worst variant. It's not obvious that it means "no-version-control", and also will make no sense when more backends will be added. Or no more backends are planned, and all other possible roots should be handled by the same fallback backend? Or would it be possible that more backends could be added in project-find-functions after the file-based fallback backend? Then the name "fallback" will make no sense if it will not be the last in project-find-functions. > This is not a done deal, just what seems the most optimal to me at the > moment. But opinions welcome. Maybe it will help to choose a better name while thinking about more possible backends that could be added later. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 07 09:08:57 2021 Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:08:57 +0000 Received: from localhost ([127.0.0.1]:46371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYT8q-0001QP-PM for submit@debbugs.gnu.org; Thu, 07 Oct 2021 09:08:57 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:39509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYT8l-0001QA-1w for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 09:08:53 -0400 Received: by mail-lf1-f53.google.com with SMTP id n8so23652119lfk.6 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 06:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=S8GP5c2+dpXydXxEET9xo5kyYtvlEg0ww9SlUgtE6LA=; b=Cd1VwODVcHjTdnV2YJdbhfINAXTvZB41drrVnuMVAqyz5QRl6eDYsKW01TJ6xTBuGs Yy0jorYiWwddNPSjqiQsmAFgWfhA3qi+2cQQuyOE1i46YDV79pJaVxpw8M5MDGYfpEG7 oor9u5WUYx59NHh9/jWDKxHO2WPq/Lm7gpWSYighicjF79zcjZBK/MceXQCwp3WDkk5B t/4Vg5J2gVh+FtA47V4+R1uUwPmXLWrYl62KgE9bWEpmd18PnmCdslPUL8Wosz6P1FI3 Gvxx3CepwB7TF16P2laD0+LI0aEPfOk4Z4Y4LjNwl4uGR1vTK3ugnVLFUMR3qCArC7BQ 3pUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=S8GP5c2+dpXydXxEET9xo5kyYtvlEg0ww9SlUgtE6LA=; b=4XvCp+LDhkTxTL3Ibl657EPD2j+b+6cl6HIk0NLpmwTOy8gOAKF9z+ErN5pT0QfaMK Mt6uaGkVpaUgChhE6685WmRHJ0X4YyZi6yGxJp+ubEAtfUqancTUcrZ4gqvdhKyCwyIy FwUbi02YBPqiw0FVTQNXO6nOE2qc/kedsH9rpY2Kp1v62ucH0sUFmPfA3HcpqVzKnjMM WODhZ1mDn3+En+hHK3rZWclg4/xWQuvAhnXzMqz6h6/tOQvnxQcBXcglZ3BKCxXgTzDB lXTrgXU2dGSQumc8OcKS0rjVv4oiQe3z7IDP6+Ohw+iU7BuIibCJKq4Rgg7juO9QcNpk wj4w== X-Gm-Message-State: AOAM530dpM09Hl0rR9pgNRdC9KX6s9CXKlK6iaPrjLwypV7E9zVviQkM Cy9ab28f3e5zxB3bZXpP5Bc= X-Google-Smtp-Source: ABdhPJyHhoH6j0BM8f6vubrW2xJXhenaivVdrqvdXH6PV05MjGW1BmWHODOfAoJfFZV5JYg9N6MNQA== X-Received: by 2002:a05:6512:13a0:: with SMTP id p32mr4311143lfa.492.1633612117520; Thu, 07 Oct 2021 06:08:37 -0700 (PDT) Received: from ?IPv6:2a02:2168:b115:9d00:64e8:b71e:7b35:5bbc? ([2a02:2168:b115:9d00:64e8:b71e:7b35:5bbc]) by smtp.gmail.com with ESMTPSA id g9sm510794ljk.80.2021.10.07.06.08.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 06:08:36 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> Message-ID: Date: Thu, 7 Oct 2021 16:08:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> Content-Type: multipart/alternative; boundary="------------78F2A7CAFC7AF51B310FFF41" Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) This is a multi-part message in MIME format. --------------78F2A7CAFC7AF51B310FFF41 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > When should we not do it? Personal preference. I'd probably never hide subproject files in 99% of the projects I work on. > But then you will end up specifying the same information twice. Once > when setting up those new backends -- and the second time when > configuring the parent project to ignore particular subdirectories. You can have a `project-hide-nested-project-files' variable, set it once for all backends. Maybe per backend version too. For me personally, if I ever were to hide subproject files it would be on a rare project and it would be on the same backend, in which I would normally never hide them, so for my workflow this is a per project setting only. > why not have a single backend for that purpose, with a custom var > containing the list of files names? Right, so remember, I said we can use this to realize most of the Projectile backends? Well, the ones we can't realize would require regexps, usually of the "\\.ext$" kind. So you have to account for those too. Then there may be some other possible cases requiring custom function. So we have at least two reasons to prefer adding actual separate backends over one catch-all filename based. Orderability and customizability. Lets say I have this structure: VC root, subfolders containing multiple related, but independent projects in some programming language, backend for which exists; deeper in one of the subfolders I have a GTAGS file, assume GTAGS backend exists in one form or another. GTAGS file is placed in this location because elsewhere in the repo there are symbol names that are too close to each other and it's more convenient not having them show up when I lookup something. I don't want VC backend to define the project root here for obvious reasons. The major mode build tool backend should do OK and I may or may not want GTAGS to define the project root. Having one find-function list which the user can reorder as he sees fit and that list may contain not just filenames, but regexps and custom functions too. As for customizability: we're already discussing at least 2 backend settings: hide-nested-project-files and recursivity. Those settings require a backend to be something more than a filename string in a secondary list. > That didn't really answer my question. All right, lets rephrase the answer. At the moment in time a backend is defined we do not know every single exact situation that backend would have to operate in, because that would require the ability to predict time, which we technologically do not have at the current moment. Lets say I add a backend for my major mode. Someone in exactly 18 days, 6 hours, 5 minutes and 3 seconds decides to use it to work on his project. Unfortunately I do not know whether his project is in VCd and if VC project backend returns the same root. If I could predict time and my prediction of all possible future use cases would show that VC backend returns the same root for every single one of them, I of course would not bother adding mine. But because my imperfect human understanding makes me think that it won't, I have to add a backend of my own. > I'm not sure how I would suppress "possible project backends" from > firing. Since you believe that VC backend gives you the best result, you can always ensure on your end that you never get, say a Makefile backend in your project-find-functions. Probably the best route here globally, is changing project-find-functions to a list with numerical priorities, so that you could set VC backend to priority 0 in your init and instruct mode developers to never put anything with the same priority or higher in the docstring. > That's possible, but it's not at all a guarantee that in every big > project every Makefile will have a "dominating" Makefile of its own. Yes, but we can define a list of possible parent backends for every backend. For example you could set VC as possible parent backend for Makefile. Would probably not be a good idea in general, but for your VC-first workflow, should be fine. > It would seem like your vision of the project could benefit from a > notion like "facet". E.g. a project lookup would search for not just > "the current project", but "the current build project" or "current > file listing project", or... I don't know what else, actually. But I'm > sure there can be other additions (something test-framework related, > maybe). Or a "module" right? I was thinking about this too, and could not find a good name for it either. Such a solution would be a reliable working compromise between our schools of thought. You get your project-root untouched, I get my own project root to do whatever I please with it. The problem with it is that it's really overengineered. For most projects there would be a 1 to 1 relationship between the project and the module(artifact?) and even if it's not 1 to 1, there's a root module most of the time. That's why it feels inferior to me in comparison to just treating everything as projects and going bottom up. > Which would return, for example, new kind of object, and that object > could tell the parent directory of its build file, and the list of the > tasks described in it, and... perhaps something about how those tasks > should be invoked. That new abstraction could be used by commands that > want to interact with build files in an abstract fashion and to launch > build tasks. After studying Projectile build commands I found them inadequate, since it provides just two, compile and build, while even my simple major mode requires a separate debugging command too. This solution suffers from the same lack of flexibility. Take for example unit testing. It's not necessarily build tool subservient and can be independent from it, but it is situated in relation to the build tool root. The maven hierarchy is problematic for this too, while my "treat everything as projects" paradigm has an elegant solution in which you can use a numerical prefix to launch a build command on the Nth parent of the current project. > There are two patches in this bug report. Have you looked at the other > one? You mean the original patch? Well it is IMHO better than yours since it's less ambitious and does not go in what I believe to be the wrong direction. --------------78F2A7CAFC7AF51B310FFF41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

When should we not do it?
Personal preference. I'd probably never hide subproject files in 99% of the projects I work on.

But then you will end up specifying the same information twice. Once when setting up those new backends -- and the second time when configuring the parent project to ignore particular subdirectories.
You can have a `project-hide-nested-project-files' variable, set it once for all backends. Maybe per backend version too. For me personally, if I ever were to hide subproject files it would be on a rare project and it would be on the same backend, in which I would normally never hide them, so for my workflow this is a per project setting only.

why not have a single backend for that purpose, with a custom var containing the list of files names?
Right, so remember, I said we can use this to realize most of the Projectile backends? Well, the ones we can't realize would require regexps, usually of the "\\.ext$" kind. So you have to account for those too. Then there may be some other possible cases requiring custom function.

So we have at least two reasons to prefer adding actual separate backends over one catch-all filename based. Orderability and customizability.

Lets say I have this structure: VC root, subfolders containing multiple related, but independent projects in some programming language, backend for which exists; deeper in one of the subfolders I have a GTAGS file, assume GTAGS backend exists in one form or another. GTAGS file is placed in this location because elsewhere in the repo there are symbol names that are too close to each other and it's more convenient not having them show up when I lookup something. I don't want VC backend to define the project root here for obvious reasons. The major mode build tool backend should do OK and I may or may not want GTAGS to define the project root.

Having one find-function list which the user can reorder as he sees fit and that list may contain not just filenames, but regexps and custom functions too.

As for customizability: we're already discussing at least 2 backend settings: hide-nested-project-files and recursivity. Those settings require a backend to be something more than a filename string in a secondary list.

That didn't really answer my question.
All right, lets rephrase the answer. At the moment in time a backend is defined we do not know every single exact situation that backend would have to operate in, because that would require the ability to predict time, which we technologically do not have at the current moment. Lets say I add a backend for my major mode. Someone in exactly 18 days, 6 hours, 5 minutes and 3 seconds decides to use it to work on his project. Unfortunately I do not know whether his project is in VCd and if VC project backend returns the same root. If I could predict time and my prediction of all possible future use cases would show that VC backend returns the same root for every single one of them, I of course would not bother adding mine. But because my imperfect human understanding makes me think that it won't, I have to add a backend of my own.

I'm not sure how I would suppress "possible project backends" from firing.
Since you believe that VC backend gives you the best result, you can always ensure on your end that you never get, say a Makefile backend in your project-find-functions.

Probably the best route here globally, is changing project-find-functions to a list with numerical priorities, so that you could set VC backend to priority 0 in your init and instruct mode developers to never put anything with the same priority or higher in the docstring.

That's possible, but it's not at all a guarantee that in every big project every Makefile will have a "dominating" Makefile of its own.
Yes, but we can define a list of possible parent backends for every backend. For example you could set VC as possible parent backend for Makefile. Would probably not be a good idea in general, but for your VC-first workflow, should be fine.

It would seem like your vision of the project could benefit from a notion like "facet". E.g. a project lookup would search for not just "the current project", but "the current build project" or "current file listing project", or... I don't know what else, actually. But I'm sure there can be other additions (something test-framework related, maybe).
Or a "module" right? I was thinking about this too, and could not find a good name for it either. Such a solution would be a reliable working compromise between our schools of thought. You get your project-root untouched, I get my own project root to do whatever I please with it. The problem with it is that it's really overengineered. For most projects there would be a 1 to 1 relationship between the project and the module(artifact?) and even if it's not 1 to 1, there's a root module most of the time. That's why it feels inferior to me in comparison to just treating everything as projects and going bottom up.

Which would return, for example, new kind of object, and that object could tell the parent directory of its build file, and the list of the tasks described in it, and... perhaps something about how those tasks should be invoked. That new abstraction could be used by commands that want to interact with build files in an abstract fashion and to launch build tasks.
After studying Projectile build commands I found them inadequate, since it provides just two, compile and build, while even my simple major mode requires a separate debugging command too. This solution suffers from the same lack of flexibility. Take for example unit testing. It's not necessarily build tool subservient and can be independent from it, but it is situated in relation to the build tool root. The maven hierarchy is problematic for this too, while my "treat everything as projects" paradigm has an elegant solution in which you can use a numerical prefix to launch a build command on the Nth parent of the current project.

There are two patches in this bug report. Have you looked at the other one?
You mean the original patch? Well it is IMHO better than yours since it's less ambitious and does not go in what I believe to be the wrong direction.

--------------78F2A7CAFC7AF51B310FFF41-- From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 07 09:41:42 2021 Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:41:42 +0000 Received: from localhost ([127.0.0.1]:46465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYTeX-0002Jg-W5 for submit@debbugs.gnu.org; Thu, 07 Oct 2021 09:41:42 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:39903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYTeU-0002JS-9U for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 09:41:40 -0400 Received: by mail-lf1-f53.google.com with SMTP id n8so24010626lfk.6 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 06:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=D7CPLNB+cWEUx41i72Sd08ZbSYZlc95gSkXaTyZrqK4=; b=iOffxm0yJn3DbRhHAcveje+UdCaQHb5pQo1k5KaqGlzlaET5b3csatLL1utUh7NBGe 9jrtrjcHkfAHHpVjonMRHx5UVZInrLN6ifOEqqchHv6TTG5QvpvuuzDZefReh3OXbiCJ XXNP24gmM9jZskcDG1/350qTYwyoCtlGOS8UDplhBtbql0CvZjNddLvPBKx4H/Pb328W A4jiWoaBb892ro6QCt+b6ewvTVjXM3X4MKmJi6cRnP7zRIKGahiGfmTCj4CkAAfCOuT0 Its/a4VDvDqPJdGzMlQA4lmaoqvHo3iiUG426mmpZ7Rov3pk646K9vdj+aBgHu2mEnoe akZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=D7CPLNB+cWEUx41i72Sd08ZbSYZlc95gSkXaTyZrqK4=; b=gxuVx7RZsrW3uEGx/fjeW/XmG0IyZx4+JMMUHHpU/XOxUkZsjBekAQSDJo74K/gg7O TFtft9Us1b9K6kr6irYXiCYjtJV527tX6zF2ajAjRi49PJlfPgZkB5mcFhymxd6qEUOg fBNg0NPlDYgAngrCBaatEkcpnmkTxZiuwj6h5go8wHXAvlKiuwkT1I3GerkF1OSzRhSv 95VPw82IiqrllrKSMCqHtoyj9uwWrsvZhuRtPtJhVP+HrHPCt0J9FI8UKKTLIL2/l0NW LG8Dd+JDjEkA7HT0WQ5xAbcnv79Ure+cjYP1mSftLU1wTb1BqErVrZdpwCL+Tv8f07/z BFhw== X-Gm-Message-State: AOAM530R0amIWRlQC53E8rFWynt6MDyQti3yJId0Zv1ujw3P6u7b/IHN 2HvwF/jOmRX4VRs4A6KIJYsgcwWmUIk= X-Google-Smtp-Source: ABdhPJxYtZ6lUZeC96pQtdmYmuH4TnPMxsFAXmvz3mRg/u3o2Ex9ivcUQFAq12ZqJ31vhuRHsIsQ5w== X-Received: by 2002:ac2:5fef:: with SMTP id s15mr4182390lfg.190.1633614084620; Thu, 07 Oct 2021 06:41:24 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id s14sm62591lfr.40.2021.10.07.06.41.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 06:41:24 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> <87wnmppdmr.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <966ef00b-fc7a-cd52-5fd8-600842797f65@yandex.ru> Date: Thu, 7 Oct 2021 16:41:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87wnmppdmr.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 07.10.2021 10:17, Juri Linkov wrote: >>> Maybe a better name would be 'project-directory-ignores' >>> with the directory-based backend name 'project-directory'? >> >> I don't know if it's better. W [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.53 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.53 listed in list.dnswl.org] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.9 (/) On 07.10.2021 10:17, Juri Linkov wrote: >>> Maybe a better name would be 'project-directory-ignores' >>> with the directory-based backend name 'project-directory'? >> >> I don't know if it's better. What does "directory" mean? Every backend, >> every project has directories. > > Then maybe the backend could be named 'project-file' > since a special file defines the project root. That's a little more meaningful, though too close to 'project-files'. 'project-markered' or 'project-markerfile' would probably be less ambiguous. But... (*) >> As mentioned previously, the other option I had considered was 'novc'. Then >> the variable would be called project-novc-ignores. > > "novc" is the worst variant. It's not obvious that it means > "no-version-control", and also will make no sense when more backends > will be added. Might not be obvious, but when you know what 'vc' stands for, 'novc' should at least be a strong hint. And then you could reach for documentation. But indeed it's very short and might make less sense if more backends are configured. > Or no more backends are planned, and all other possible > roots should be handled by the same fallback backend? Or would it be > possible that more backends could be added in project-find-functions > after the file-based fallback backend? Then the name "fallback" > will make no sense if it will not be the last in project-find-functions. I don't know about the case of adding more backends at the end of project-find-functions (are there any people who have done this?), but otherwise, 'fallback' is both an indication that the backend is at the end, and a strong hint to avoid moving it to the front. Suppose somebody puts it before 'vc' to use if for a purpose we did not design it for: make sure that some subproject 'foo' in their monorepo is considered a separate project. 'foo/Makefile' exists, so they add "Makefile" to project-fallback-markers, and it kind of seems to work. But! File listing performance becomes worse: we didn't optimize this backend for use inside of (e.g.) Git repositories, we don't take advantage of 'git ls-files'. More than that, it doesn't honor the ignore instructions from .gitignore. Whereas, in a lot of cases, it would be helpful (and even necessary for good performance) to honor them. But on the other hand, why would a 'project-fallback', or 'project-file', or 'project-markerfile', honor .gitignore contents? Semantically, that doesn't make much sense. And yet, I'd wager like a half of the users would implicitly expect it to do so, and another half -- would not. That's doesn't seem like a great design. >> This is not a done deal, just what seems the most optimal to me at the >> moment. But opinions welcome. > > Maybe it will help to choose a better name while thinking about > more possible backends that could be added later. (*) ...it doesn't seem compatible with being used in arbitrary order with arbitrary backends. Perhaps, if we change our mind on the overall design later, we could create a new backend, with a different name and more complex implementation logic. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 07 22:12:55 2021 Received: (at 41572) by debbugs.gnu.org; 8 Oct 2021 02:12:55 +0000 Received: from localhost ([127.0.0.1]:48739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYfNW-00078z-Ka for submit@debbugs.gnu.org; Thu, 07 Oct 2021 22:12:55 -0400 Received: from mail-lf1-f47.google.com ([209.85.167.47]:43706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYfNR-00078e-N7 for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 22:12:52 -0400 Received: by mail-lf1-f47.google.com with SMTP id r19so31048785lfe.10 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 19:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vRw3QTBKqZE06CFMSmlYB+KI0YmReSTMNUmTbEUTHyg=; b=qUwOLtEDJ65gaEukDrvvjJgflTOJIYG1/+1DPKV+JvilzAhYN+vl75rOdpYjSsorZn vuEZgn3V19Khz+25iqtxFJ1/Eb49lypp2Zz9b+VFOva3ZRlAw5H9mVmIXcsxX2fDCSQ7 /8AiHfP1ErnzxSRKyJ2o11EGYxkbunCDux1UqCpjDhw6DFj1tN9lJYj4hXJe68gyZb1u eCZzZBk1Gf14SfJKc5NoEESF1dxOlmPvJGcydrNZKgM9ogLvR5saWcTfpytuuJZ5Omdx FWqIMpRPCMe7JFwNJhXYtYS7hFfnkmy5So6KXBdYHSaUNqmQJO0pePsSVFYLVPlmZGTC DIig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vRw3QTBKqZE06CFMSmlYB+KI0YmReSTMNUmTbEUTHyg=; b=DsFEBWdJMt5RjTnEXmGlWz0qtOikw1BxD1JnD9GDeDwz4HGlsN8mgT4N1VZEPJ7+aj X4MKxEddDzjL/tZCCrc/5DqM9ikv/m+9uIS0WNEaulwHCc4h5R5CkhFF7YldHMYJFCfN AnUSzistOtj9It/Tp5R2U46guWDpXa2Gy3oUMwS5w1+FWfNJAX60Z18+x7c59AIKg30a Kx4bazWZ2bkjhTgzWs3CnSlWTwM97y8OUMTFg6DUWT5SJ7FF4JwSE2ioazcqzoJjQ20i XWtoMTXJJbNjJipCp3tZfy51emYi33PzUb536nL4J3gXGZzlddu2RFHCDTOmcFsKEjpK R6dw== X-Gm-Message-State: AOAM533hZKxgiAPR48TWxdWpZgcPuUEJ56+158cLNX85WHUdu/tVNWxd umibBtpXQqLaebc/lE9zBwI= X-Google-Smtp-Source: ABdhPJwAVs27Yj2s/o3l8BNa8BzTMg+thi+xoQEv7m6OgkOPhmaUNyO9ugex+EEUoALpugbCm/d0SQ== X-Received: by 2002:ac2:5978:: with SMTP id h24mr7866296lfp.426.1633659163457; Thu, 07 Oct 2021 19:12:43 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id z14sm124211lji.102.2021.10.07.19.12.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 19:12:42 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> From: Dmitry Gutov Message-ID: <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> Date: Fri, 8 Oct 2021 05:12:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 07.10.2021 16:08, Nikolay Kudryavtsev wrote: >> When should we not do it? > Personal preference. I'd probably never hide subproject files in 99% of > the projects I work on. All right. So you might like the possible alternative approach to this problem. Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.47 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.47 listed in list.dnswl.org] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.9 (/) On 07.10.2021 16:08, Nikolay Kudryavtsev wrote: >> When should we not do it? > Personal preference. I'd probably never hide subproject files in 99% of > the projects I work on. All right. So you might like the possible alternative approach to this problem. What's your stance of having "filemarker" projects honor (or not honor) .gitignore instructions from the containing VCS repo? >> But then you will end up specifying the same information twice. Once >> when setting up those new backends -- and the second time when >> configuring the parent project to ignore particular subdirectories. > You can have a `project-hide-nested-project-files' variable, set it once > for all backends. Maybe per backend version too. The problem is not being able to invent a variable, but how to honor it when listing project files. If the same backend doesn't have the information about the contained projects. >> why not have a single backend for that purpose, with a custom var >> containing the list of files names? > Right, so remember, I said we can use this to realize most of the > Projectile backends? Well, the ones we can't realize would require > regexps, usually of the "\\.ext$" kind. So you have to account for those > too. Then there may be some other possible cases requiring custom function. project-fallback-markers can easily support globs (I didn't add the support initially because the naive implementation of checking for files including globs is slower). Support for predicate functions among its entries is pretty trivial to do. OTOH, when we only have a list of project-finding functions (one per project marker, say), it's pretty difficult to find the deepest enclosing project directory without running them all, and having them traverse the parent directories up until /. This is an inevitably slow approach. Can be bearable in a local filesystem; might be fatal over Tramp. > Lets say I have this structure: VC root, subfolders containing multiple > related, but independent projects in some programming language, backend > for which exists; deeper in one of the subfolders I have a GTAGS file, > assume GTAGS backend exists in one form or another. GTAGS file is placed > in this location because elsewhere in the repo there are symbol names > that are too close to each other and it's more convenient not having > them show up when I lookup something. I don't want VC backend to define > the project root here for obvious reasons. The major mode build tool > backend should do OK and I may or may not want GTAGS to define the > project root. It doesn't seem like you want GTAGS to define project root; you'll only want certain commands, like xref-find-definitions, to use the closes GTAGS file. Good thing xref-find-definitions doesn't use the project.el infrastructure at all. > Having one find-function list which the user can reorder as he sees fit > and that list may contain not just filenames, but regexps and custom > functions too. I'm not seeing the concrete usage scenarios yet. > As for customizability: we're already discussing at least 2 backend > settings: hide-nested-project-files and recursivity. Those settings > require a backend to be something more than a filename string in a > secondary list. These settings, as I see it, will be on the project-vc backend. >> That didn't really answer my question. > All right, lets rephrase the answer. At the moment in time a backend is > defined we do not know every single exact situation that backend would > have to operate in, because that would require the ability to predict > time, which we technologically do not have at the current moment. Lets > say I add a backend for my major mode. Someone in exactly 18 days, 6 > hours, 5 minutes and 3 seconds decides to use it to work on his project. > Unfortunately I do not know whether his project is in VCd and if VC > project backend returns the same root. If I could predict time and my > prediction of all possible future use cases would show that VC backend > returns the same root for every single one of them, I of course would > not bother adding mine. But because my imperfect human understanding > makes me think that it won't, I have to add a backend of my own. Okay, but we need both correctness and speed. Answering "see if there is a fast backend behind this one with the same root" is not very useful, since in this scenario we seemingly (!) don't need the first backend anyway. But perhaps you meant we should always scan the full list of backends, and we should not only accept a "fast" backend with the same root, but with root in any parent directory as well. Which would correspond to the popular situation with the monorepo. Setting aside the performance concerns of always scanning for all backends in project-find-functions, what do we do with the ignore entries? A backend is (very roughly) defined as (root . ignores), to be able to only list and work with a subset of files from its root's directory tree. The VC backend traditionally includes .gitignore entries in its list of ignores. So its project-ignores method includes them, and its project-files method implicitly uses them. But what if your first detected backend has a different list of ignores configured? Or none? Do we account for the latter's (fast) backend ignores when asking it for the list of files in the first backend's detected root directory. In practical terms, as just one example, that would mean honoring .gitignore at the top of a monorepo. Which might seem like a good thing to do, but also a somewhat unexpected behavior, conceptually. > Probably the best route here globally, is changing > project-find-functions to a list with numerical priorities, so that you > could set VC backend to priority 0 in your init and instruct mode > developers to never put anything with the same priority or higher in the > docstring. That's quite easy to do already: project-find-functions is a hook, and 'add-hook' has a DEPTH argument. Since Emacs 27, I think. >> That's possible, but it's not at all a guarantee that in every big >> project every Makefile will have a "dominating" Makefile of its own. > Yes, but we can define a list of possible parent backends for every > backend. For example you could set VC as possible parent backend for > Makefile. Would probably not be a good idea in general, but for your > VC-first workflow, should be fine. I think it's apparent at this point that we are venturing into the territory of pretty invasive, backward-incompatible changes to the existing project.el API. >> It would seem like your vision of the project could benefit from a >> notion like "facet". E.g. a project lookup would search for not just >> "the current project", but "the current build project" or "current >> file listing project", or... I don't know what else, actually. But I'm >> sure there can be other additions (something test-framework related, >> maybe). > Or a "module" right? I was thinking about this too, and could not find a > good name for it either. Right, yeah. Having module detection on a hook seems more flexible than putting it on a method dispatches by project type, because then the Maven extension can work with any project backend, not just some specific Maven-supporting one. > Such a solution would be a reliable working > compromise between our schools of thought. You get your project-root > untouched, I get my own project root to do whatever I please with it. > The problem with it is that it's really overengineered. For most > projects there would be a 1 to 1 relationship between the project and > the module(artifact?) and even if it's not 1 to 1, there's a root module > most of the time. That's why it feels inferior to me in comparison to > just treating everything as projects and going bottom up. I don't know if it's really overengineered, especially compared to certain proposals in your previous email. FWIW, Steinar asked for being able to choose whether to act on a module or on a project, and for that such separation seems to be necessary. Thanks for the reminder about that thread, BTW. Speaking of build tools -- just as well, if the tool is in the same directory as the project root, you don't need any additional backends. But if you do need extra detection, file-finding logic, that could be put into buildtool-find-functions. >> Which would return, for example, new kind of object, and that object >> could tell the parent directory of its build file, and the list of the >> tasks described in it, and... perhaps something about how those tasks >> should be invoked. That new abstraction could be used by commands that >> want to interact with build files in an abstract fashion and to launch >> build tasks. > After studying Projectile build commands I found them inadequate, since > it provides just two, compile and build, while even my simple major mode > requires a separate debugging command too. Debugging seems to be a separate feature from build tools (requiring its own information, and a fair amount of it). Although, depending on a language and environment, it might require integration with build tools as well. > This solution suffers from > the same lack of flexibility. Take for example unit testing. It's not > necessarily build tool subservient and can be independent from it, but > it is situated in relation to the build tool root. So what's the problem with this approach, then? The run-tests command can for example run the buildtool-find-functions, take the appropriate one, search its parent directory for the presence of testing frameworks, and launch it. > The maven hierarchy > is problematic for this too, while my "treat everything as projects" > paradigm has an elegant solution in which you can use a numerical prefix > to launch a build command on the Nth parent of the current project. It sounds like this approach, at the very least, doesn't go through 'project-current'? Are there other advantages, rather than being able to choose the project parent nesting depth with the prefix argument? >> There are two patches in this bug report. Have you looked at the other >> one? > You mean the original patch? Well it is IMHO better than yours since > it's less ambitious and does not go in what I believe to be the wrong > direction. The 'project-vc-subprojects' patch. Here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 08 12:24:17 2021 Received: (at 41572) by debbugs.gnu.org; 8 Oct 2021 16:24:17 +0000 Received: from localhost ([127.0.0.1]:51808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYsfR-0002Qy-30 for submit@debbugs.gnu.org; Fri, 08 Oct 2021 12:24:17 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:38693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYsfO-0002Qk-P9 for 41572@debbugs.gnu.org; Fri, 08 Oct 2021 12:24:15 -0400 Received: by mail-lf1-f48.google.com with SMTP id x27so41611258lfu.5 for <41572@debbugs.gnu.org>; Fri, 08 Oct 2021 09:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=szSbqd8xeuTIJBlSI9L2ncWKSMfPHqrUZVu+y6sVOEU=; b=UIp8yyqyyxPtWqKUPdJfTXAfzyWuXDar3jJ6pDUhnYw72FVHLgdkYib/wA6btK62qC Smmsea/LQbq7KAZDQr5+h7OvhEe5pQEWm3ARVQBt4v+3sE0tK+JuhwMRuqaMd+taVZe9 Ws7DmuQ1TLriS/YhIKxYTSvPpk11AOO2pCNA4tWLBRKnlBynXmB4lxOp2RkMn+M4tl0F /Me3nxIYWmjCo0o0KvJDIagZpiFAVEw1OfPtvZqN+IsJarHGUkpRQ3eLM+/zXSKkMUW3 2gQdDYUVZSkq+HhbhSMhGvLPakqRvTfCExO+JWno4LyjIg3NWCkeK211iQe3Z6JY4vO0 F0GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=szSbqd8xeuTIJBlSI9L2ncWKSMfPHqrUZVu+y6sVOEU=; b=7ld7KrJfb4+aXwQIwYj2ZLz1KI3S7B/N0MEx9T68g+cOPPrIHDKDfoMo6f33JWUvn3 KyrsFXaj6PLq5xiLn+rANZEH5LhU3qFIkhjrbbUSWbVhCTmsskQ20hab1p+EdA4rjKb2 GFNlN6a9z4ZfT5EsIlakCR7Oq59gkZJs/fW3z87h7/9KbkjQzB8gn0czjrbIG/O8caGu ErzM2OJ4A/pR8HcyAULEba4HY9LcsmZ10//kGXJBrSrRaRpVcY5h29KWcI4i0LmLy1T9 U+8Ed6aUScS7PVX6w0e3TQRKHwYqwPp2Ewe0NIYCSRpLBykUyCVs+VsGVioQlAfoWsrk 1BRQ== X-Gm-Message-State: AOAM5331ZzB0A/HnTGZ341ZuBIaQB1a1adFz8OtbnI6N/P+SJ2oaTMMw Uy7/10gYNsSDXf2/G+xqeOc= X-Google-Smtp-Source: ABdhPJy/hYMkdh9bkfG6enUxLmIq4UDe/50SOxFWI+7yC1Nh7/vjeAp+4lQmQ7tNOL800kDzeiPnfg== X-Received: by 2002:a2e:7502:: with SMTP id q2mr4396404ljc.493.1633710248708; Fri, 08 Oct 2021 09:24:08 -0700 (PDT) Received: from ?IPv6:2a02:2168:b115:9d00:e1eb:c368:1759:ab9a? ([2a02:2168:b115:9d00:e1eb:c368:1759:ab9a]) by smtp.gmail.com with ESMTPSA id d19sm280784lfv.74.2021.10.08.09.24.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 09:24:07 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> Message-ID: Date: Fri, 8 Oct 2021 19:24:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) > What's your stance of having "filemarker" projects honor (or not > honor) .gitignore instructions from the containing VCS repo? That's a good question. I think at any non-VC project it is fine that it does not honor it, since you get what you've signed up for. I'll come back to this later in this letter, since another part of this conversation sort of gives the answer to it. > The problem is not being able to invent a variable, but how to honor > it when listing project files. If the same backend doesn't have the > information about the contained projects. Yes, but at this point it's a separate feature request for a problem that already exists at this point, it's just that we rely on other tools to solve it for us. Let's say I maintain an application, except for a module maintained by my colleague Bob. And since that module may be be shared by multiple applications, it is version controlled separately. I also may or may not want it to be considered a part of my project for the sake of project utility commands. Here we rely on .gitignore and the like. Lets say with GTAGS I can decide whether to include the bob module too. But all of this works only because those backended tools happen to implement this ignore functionality. Lets say your VC is broken and just won't ignore some files(happend before in practice with VC) even though it ordered to? So any such project-level ignore functionality, while useful and would be even more useful with more weaker custom backends, is not that important in the context of this discussion in my opinion. > This is an inevitably slow approach. Can be bearable in a local > filesystem; might be fatal over Tramp. Yes. That's sort of the unfortunate price we have to pay here. I think some caching can be implemented, to limit directory reading operations to 1 per level. > It doesn't seem like you want GTAGS to define project root; you'll > only want certain commands, like xref-find-definitions, to use the > closes GTAGS file. If I've made a GTAGS file at this level with the explicit intention to exclude everything else I might as well be be interested in running project-find-regexp and the like here, right? > I'm not seeing the concrete usage scenarios yet. Well think more about either the 3 marker(vc, build-tool, GTAGS) example or the Bob module example. Lets try to put it in your terms of "correctness". Is me wanting the build tool to define the project boundary over VC "correct"? Is me possibly wanting GTAGS backend to define the project boundary "correct"? Is me wanting to possibly NOT exclude the Bob module from the project "correct"? Lets say I've found a broken function in the general application and I now want to see whether the Bob module uses it too along with any other code by calling project-find-regexp. You may answer no to all of those and say that Holy Correctness can be only provided by the Holy VC backend, but I don't think it's a reasonable approach. > These settings, as I see it, will be on the project-vc backend. Are you saying that if I want to declare that my make projects can be subordinate to another build tool, I have to declare that in the project-vc-backend of all places? > Okay, but we need both correctness and speed. Lets for a moment assume that my use cases are "correct". Meaning that relying on VC here would be doing the wrong thing fast. Is doing the wrong thing fast a good idea? > Answering "see if there is a fast backend behind this one with the > same root" is not very useful, since in this scenario we seemingly (!) > don't need the first backend anyway. There are two possible scenarios. A. Backend project marker has the same root as VC. B. Backend project marker has a different root. You look ONLY at the scenario A and say "why do we need a new backend"? Well we need it ONLY for the scenario B, which you are ignoring. Again, not gonna repeat, myself on the ignore issue, apart from "you get what you've signed up for". > I think it's apparent at this point that we are venturing into the > territory of pretty invasive, backward-incompatible changes to the > existing project.el API. True, but currently the project.el is underutilized due to its simplicity and due to this we can still do reasonable invasive changes to the API. > Right, yeah. Having module detection on a hook seems more flexible > than putting it on a method dispatches by project type, because then > the Maven extension can work with any project backend, not just some > specific Maven-supporting one. The possible actions for Maven would already work any project backend, it's the question of how to ensure the proper root for it. > FWIW, Steinar asked for being able to choose whether to act on a > module or on a project, and for that such separation seems to be > necessary. I don't think he cares about Emacs having a distinction, more about the abiilty to independently act on(compile) those parts. > Speaking of build tools -- just as well, if the tool is in the same > directory as the project root, you don't need any additional backends. > But if you do need extra detection, file-finding logic, that could be > put into buildtool-find-functions. That's the thing, you would always need one. > Debugging seems to be a separate feature from build tools (requiring > its own information, and a fair amount of it). Although, depending on > a language and environment, it might require integration with build > tools as well. Yeah, and that's one of the conceptual problems with that approach: assuming too much. Project markers(or "build-tools" markers in your paradigm) are not limited to build tools, it may be a tags tool for example. > So what's the problem with this approach, then? The main problem is that it's conceptually wrong IMHO. In trying to make anything not VC have a subservient status you're actually elevating it to a special one. Not any project backend needs build-tools, for example possible GTAGS won't, while it is quite fine that any project is aware of its VC regardless of the backend. So the user defined backends should be given primacy and VC should enjoy that (elevated secondary subservient) special status, with the fallback VC backend staying there too of course. And that's also the answer to your original question about honoring .gitignore. If VC is always available regardless of the backend, we can surely honor it and also use it for whichever optimizations are possible. Even take Zhou's patch. Lets operate on the assumption that we cannot let anyone go astray from the paradise of the Holy VCs correctness. Every single problem you've mentioned would befall on those trying to use a plain project. Adding a new backend would just let the heathens win, since they can add those files anywhere and stray away from the light. From such point of view, you can never add new backends, you can only add new build tools. Or to put it another way, whenever people want to mess with project backends, what they want is to define a scope in which they want to operate. That scope may differ from the scope defined by VC. Also there's nothing wrong in VC scope being available at the same time at the user declared project scope. What I mean by that is that nobody would complain if every project-* utility commands gets a sister named project-vc-* that would allow you to the same operation, but explicitly within the VC scope of the current project. > The 'project-vc-subprojects' patch. This a solution to the subprojects hiding problem discussed earlier, perfectly acceptable for me, but as I mentioned before is not something I'd use much personally. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 10 13:33:14 2021 Received: (at 41572) by debbugs.gnu.org; 10 Oct 2021 17:33:14 +0000 Received: from localhost ([127.0.0.1]:55768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZchG-0001ol-2g for submit@debbugs.gnu.org; Sun, 10 Oct 2021 13:33:14 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:48239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZchB-0001oQ-Qx for 41572@debbugs.gnu.org; Sun, 10 Oct 2021 13:33:10 -0400 Received: (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 9FA2B240005; Sun, 10 Oct 2021 17:33:00 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Organization: LINKOV.NET References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> <87wnmppdmr.fsf@mail.linkov.net> <966ef00b-fc7a-cd52-5fd8-600842797f65@yandex.ru> Date: Sun, 10 Oct 2021 19:47:37 +0300 In-Reply-To: <966ef00b-fc7a-cd52-5fd8-600842797f65@yandex.ru> (Dmitry Gutov's message of "Thu, 7 Oct 2021 16:41:23 +0300") Message-ID: <87v925f6ee.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.7 (-) >> Then maybe the backend could be named 'project-file' >> since a special file defines the project root. > > That's a little more meaningful, though too close to > 'project-files'. 'project-markered' or 'project-markerfile' would probably > be less ambiguous. In 'project-filemarker' I misread "filemarker" as "filmmaker" :-) Another possible name would be "fileroot". > Suppose somebody puts it before 'vc' to use if for a purpose we did not > design it for: make sure that some subproject 'foo' in their monorepo is > considered a separate project. 'foo/Makefile' exists, so they add > "Makefile" to project-fallback-markers, and it kind of seems to work. There are two contradictory needs: 1. When a marker list contains both ".dir-locals.el" and "Makefile", it should ignore Makefile files in vc-based project subdirs, e.g. emacs/lisp/Makefile, etc. 2. OTOH, I often type 'C-x p g' to search all gems of the same ruby version in e.g. ~/.rbenv/versions/2.7.4/lib/ruby/gems But it finds ~/.rbenv/.git and tries to search all ruby versions. I could manually add .dir-locals.el only to a particular version's subdir. But how to override ~/.rbenv/.git? Maybe by changing the order of backends in project-find-functions? Then the fallback won't be the last backend anymore. Also the backend priorities will be changed globally for all other projects, and 'C-x p g' in emacs/lisp will find emacs/lisp/Makefile to override emacs/.git. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 10 20:40:59 2021 Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 00:40:59 +0000 Received: from localhost ([127.0.0.1]:56119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZjNC-0000BJ-TU for submit@debbugs.gnu.org; Sun, 10 Oct 2021 20:40:59 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:33316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZjN9-0000B2-5T for 41572@debbugs.gnu.org; Sun, 10 Oct 2021 20:40:57 -0400 Received: by mail-lf1-f53.google.com with SMTP id j21so48457362lfe.0 for <41572@debbugs.gnu.org>; Sun, 10 Oct 2021 17:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qIliTL0cIqgA1UGFsyOf/KbZIejwSEtSADCmlmijcKw=; b=SnbIyCcJZkjfHhCZZ55fMblfn9NnZ3JwjO9mJ2UPBfE8dZV2g59rZwy8QufIaC4nfQ G1zQuHRqldoQqEd/pV8mOkZ9OI3LTedYrS0+AyHeE2fs8gWVyN2YbGRJgxVV7x14HTxZ oc9Q0QzVbDGqDAmEWAOuNEgnBlAXEX+wsGYdUdQuv4Ypa9nP8O8EWFu0N1hSNtRSfcp2 RkR8LSIQI889yP4FKyHWOrNrXeLgeHlKcR9MlI0BTbvIXHEKt4WNdAvmg6kZTGBPiOgY iROrCXCG+dcwOF8b0fRpWYJRBUJCI3ynx8gccV+wzioIhqbJyCs1qVcWLJmQ3bd3OtN2 LiZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qIliTL0cIqgA1UGFsyOf/KbZIejwSEtSADCmlmijcKw=; b=sSILdvw3TrZuYaaHdEtaYeJ1b/C49eXojxRxpX813dz6BADADKrDptRKuCTMYpdN6G zdUW828NXGmH5S2MR5pnYPBmWO2IDRVmexyvk8kwgXv4ARSkDRMfDiMI8mwS1Fd3a0qA HuFdGmwpxcLBnGHNf8v7B/BeAvK8FmU10sWDZ3asvgy/OO252JutDlg7LgG0gjuBnydt l/BqumcfzhCJP98+sv7NOHhHOP7UNL5VPyGBG+sC/U/VO4E7bc2kW5QSARafj998dCd5 yyQ3AtglszYywrvQeg0kcfYzGPZnH7idH6fBELCDR9doPfn2/rEHtykln9+5m9CQUXlG /pbQ== X-Gm-Message-State: AOAM531CtTbPvEvip9twND0HjXDwuWnMMVrtkYe2yV8nwM0QGPuzPMyc LzEoGuYLnZFzhBOV5tz/65Zq+DyxefU= X-Google-Smtp-Source: ABdhPJwlCmVdoBtzbZjF5CW8g+1ZWgsU+zoeqz+iKbNg9VFO43/oGuc2DrrBG3aVfv4uOloqdmJpXQ== X-Received: by 2002:a05:6512:ba6:: with SMTP id b38mr8228808lfv.355.1633912849007; Sun, 10 Oct 2021 17:40:49 -0700 (PDT) Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id q187sm661974ljb.6.2021.10.10.17.40.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Oct 2021 17:40:48 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Juri Linkov References: <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> <87wnmppdmr.fsf@mail.linkov.net> <966ef00b-fc7a-cd52-5fd8-600842797f65@yandex.ru> <87v925f6ee.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <564eb0ed-21c0-f298-a7e9-30d7caf7517f@yandex.ru> Date: Mon, 11 Oct 2021 03:40:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87v925f6ee.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Lars Ingebrigtsen , Theodor Thornhill , 41572@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.6 (/) On 10.10.2021 19:47, Juri Linkov wrote: >>> Then maybe the backend could be named 'project-file' >>> since a special file defines the project root. >> >> That's a little more meaningful, though too close to >> 'project-files'. 'project-markered' or 'project-markerfile' would probably >> be less ambiguous. > > In 'project-filemarker' I misread "filemarker" as "filmmaker" :-) Right. :-) > Another possible name would be "fileroot". Also sounds more like a method than a project type name. Maybe project-markered or project-marked, or project-dominated (along the lines of 'locate-dominating-file'?). Or something noncommittal like project-dirtee. But all of those sounds like one could put them at any position in project-find-functions, which project-fallback explicitly discourages. >> Suppose somebody puts it before 'vc' to use if for a purpose we did not >> design it for: make sure that some subproject 'foo' in their monorepo is >> considered a separate project. 'foo/Makefile' exists, so they add >> "Makefile" to project-fallback-markers, and it kind of seems to work. > > There are two contradictory needs: > > 1. When a marker list contains both ".dir-locals.el" and "Makefile", > it should ignore Makefile files in vc-based project subdirs, e.g. > emacs/lisp/Makefile, etc. Right. That says project-try-fallback going after project-try-vc is a good thing. > 2. OTOH, I often type 'C-x p g' to search all gems of the same > ruby version in e.g. ~/.rbenv/versions/2.7.4/lib/ruby/gems > But it finds ~/.rbenv/.git and tries to search all ruby versions. > I could manually add .dir-locals.el only to a particular version's > subdir. I'm using this setup, FWIW: (defun project-try-gem (dir) (when (string-match "/\\.rbenv/versions/.*/gems/.*/gems/[^/]+/" dir) (cons 'rubygem (substring dir 0 (match-end 0))))) (cl-defmethod project-root ((project (head rubygem))) (cdr project)) (with-eval-after-load 'project (add-hook 'project-find-functions #'project-try-gem)) Which avoids the whole directory-walking routine, probably saving on a number of CPU cycles. > But how to override ~/.rbenv/.git? Maybe by changing > the order of backends in project-find-functions? > Then the fallback won't be the last backend anymore. > Also the backend priorities will be changed globally > for all other projects, and 'C-x p g' in emacs/lisp > will find emacs/lisp/Makefile to override emacs/.git. If we keep the same tool to ensure the priorities (order of functions in project-try-vc), that would seem like we should use two different backends for these two different purposes. Say, the first one would be called project-dominating, and the other one - still project-fallback. project-find-functions will be '(project-try-dominating project-try-vc project-try-fallback Alternatively, one backend could combine these, but it would have, like, configurable logic with two different sets of predicates -- one universal (whether the file is inside a VCS repo or not), and another for when the file is strictly outside of VCS repos. But that sounds trickier, both to configure and to understand. Also, it seems like with this approach the backend *should* ignore the .gitignore entires, which is fine for .rbenv/versions/.*/gems, but it's bound not to work for some other purposes some users are going to try to use it for. So, since I don't know of any other use cases for the project-dominating code path rather than Ruby gems inside ~/.rbenv, I figured not to try to solve this use case yet. But we can catalogue similar use cases (maybe other versions switchers, for Ruby and other languages?; not sure if installed libraries for other languages also fit this approach) and add another backend for them later. Help welcome, of course. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 10 21:57:16 2021 Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 01:57:16 +0000 Received: from localhost ([127.0.0.1]:56165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZkZ1-000282-W8 for submit@debbugs.gnu.org; Sun, 10 Oct 2021 21:57:16 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]:39625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZkYz-00027o-O6 for 41572@debbugs.gnu.org; Sun, 10 Oct 2021 21:57:14 -0400 Received: by mail-lf1-f43.google.com with SMTP id n8so64459889lfk.6 for <41572@debbugs.gnu.org>; Sun, 10 Oct 2021 18:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gB8TfhIG++uz4ECgzrh0F5LlXO4/RYB99X5ziBFdQL8=; b=RyP1UlC2z1wMh4MFf9WPlwxC+O6gDFaoFKuySixsrV7zEXeMHqad9eh8CqaGh44CCZ dk2lXj2CPeJbIyFeHXdnTcOvX92IZ6AFnVq8b7TTokfnxHXLwYH/bHD10r72n/jBfcqh kc2MRPCsLm/yJvIPScWdwGfALTmXWlEylT7H71UTsENNeGnT53NlZitWLiZdTLXsr7+M TX0eEUFcKnbQweLEo1akoRGZ962kjO6/L9C7YG1wTqArcVDpHQiTiPdjd/+AGkcK5Ops h2GMxsys5+nTjN+UimskRv+RItdd0uMpmtngzlDDvjUk5DyA/u7cBooLwZ2B+St5GM3D Lb4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gB8TfhIG++uz4ECgzrh0F5LlXO4/RYB99X5ziBFdQL8=; b=AA3BNvwWiW0kBDWeMSbrpFShyBPrmn/4AE/3148X7BnKg6JOS+7VxOeegntm32OOUS 26M14VzWURAfKRlTaBI5l6qjm4c5MVZHw9H/YQyWE3UB+IKHrK7KtMY1PyIE0WepIVS/ +A9DghXp+6IstJOvsTj+OH+t0o/N+ApfbNQiENBJR/1zRBdANbHnwzmZ/hUrd7wyShqw KRZ5jjB+5+9sAq8mrOWaH84l1VzvEiwSVxbsr92W6FKECA0jCzJ7X0orZS7vptuytj5X vjkKRnA1l11Rv9biil/NKyLMBT8SNlIIK3b5c0iRI5knF8E4FYc4klDazGAhtx9nZVwr FJOA== X-Gm-Message-State: AOAM531+CRD38vJYynqqQOorgo9xJu0xGs1uJ01VmdFpwD2V6ffbaepV pYp9a+u9+DfY9GQ8Ant4qHw= X-Google-Smtp-Source: ABdhPJzSt+XNwsPdg4v785+vUL7od0sWzkBbHcPdGAXPcrCzeRZClyAWaOJe0/x+/XIR1NUXiCj+/g== X-Received: by 2002:a05:6512:68b:: with SMTP id t11mr26321135lfe.625.1633917427259; Sun, 10 Oct 2021 18:57:07 -0700 (PDT) Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id u21sm674362lju.26.2021.10.10.18.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Oct 2021 18:57:06 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> From: Dmitry Gutov Message-ID: Date: Mon, 11 Oct 2021 04:57:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.6 (/) On 08.10.2021 19:24, Nikolay Kudryavtsev wrote: >> What's your stance of having "filemarker" projects honor (or not >> honor) .gitignore instructions from the containing VCS repo? > That's a good question. I think at any non-VC project it is fine that it > does not honor it, since you get what you've signed up for. I'll come > back to this later in this letter, since another part of this > conversation sort of gives the answer to it. I didn't find a definite answer in the rest of the email, so I'll continue this thread here. This is the problem: semantically, it makes sense for filemarker backends not to honor VC ignores. But in practice, people will often (probably most often) want it to, or implicitly expect it to. Because when you are working on a subproject in a big monorepo, you might want to focus on its directory tree, sure, but you also expect that the global .gitignore settings are honored (where build artefacts, temporary files, etc, are configured to be skipped). You might also have additional per-directory .gitignore files which, again, are even more pertinent to the subproject, but semantically would not be expected to be honored. It's not good to have conflicts like that, between semantics and practical requirements. >> The problem is not being able to invent a variable, but how to honor >> it when listing project files. If the same backend doesn't have the >> information about the contained projects. > Yes, but at this point it's a separate feature request for a problem > that already exists at this point, it's just that we rely on other tools > to solve it for us. Let's say I maintain an application, except for a > module maintained by my colleague Bob. And since that module may be be > shared by multiple applications, it is version controlled separately. I > also may or may not want it to be considered a part of my project for > the sake of project utility commands. Here we rely on .gitignore and the > like. Lets say with GTAGS I can decide whether to include the bob module > too. But all of this works only because those backended tools happen to > implement this ignore functionality. So you want to add a new backend based on GTAGS which also lists files by calling 'global -P' or something. It's not enough to configure the root-finding logic for it, you also need to implement 'project-files' with the above process call. I also wouldn't want to enable such backend by default because it will only list files from a manually generated index, but not, say, a file that the user just created and saved. Not very user-friendly. But enable or not, that's beside the point: such backend fits the current approach well; whoever writes it can distribute it, and the users who want to prioritize GTAGS over .git can put it in front. It doesn't seem pertinent to what project-fallback should do. > Lets say your VC is broken and just > won't ignore some files(happend before in practice with VC) even though > it ordered to? So any such project-level ignore functionality, while > useful and would be even more useful with more weaker custom backends, > is not that important in the context of this discussion in my opinion. It doesn't really match my experience. Some VCS can be "broken" -- then we can ignore their equivalent of 'git ls-files' and use 'find'. We only have optimized paths for Git and Hg anyway. But even when we use 'find', we try to pick up the ignores configuration from the repo. >> This is an inevitably slow approach. Can be bearable in a local >> filesystem; might be fatal over Tramp. > Yes. That's sort of the unfortunate price we have to pay here. I think > some caching can be implemented, to limit directory reading operations > to 1 per level. "Some caching" has been lying around in TODO for years. >> I'm not seeing the concrete usage scenarios yet. > Well think more about either the 3 marker(vc, build-tool, GTAGS) example > or the Bob module example. Lets try to put it in your terms of > "correctness". Is me wanting the build tool to define the project > boundary over VC "correct"? Is me possibly wanting GTAGS backend to > define the project boundary "correct"? Is me wanting to possibly NOT > exclude the Bob module from the project "correct"? Lets say I've found a > broken function in the general application and I now want to see whether > the Bob module uses it too along with any other code by calling > project-find-regexp. You may answer no to all of those and say that Holy > Correctness can be only provided by the Holy VC backend, but I don't > think it's a reasonable approach. I want all of those capabilities to be reachable, but we also need to decide which project backends configuration is on by default. >> These settings, as I see it, will be on the project-vc backend. > Are you saying that if I want to declare that my make projects can be > subordinate to another build tool, I have to declare that in the > project-vc-backend of all places? What is a 'make project'? If you have 'Makefile' inside a subdirectory of a GGTAGS project, do you expect the said 'make project' only to include the files that GGTAGS has indexed? If yes, you need to have to integration with GGTAGS, one way or another. Maybe simply go through the GGTAGS backend to configure said 'make project', since that is the backend which is expected to honor the GGTAGS index. If no, sure, have a 'make project' entry in front of 'ggtags project' entry in project-find-functions. That fits the current approach well. > Again, not gonna repeat, myself on the ignore issue, apart from "you get > what you've signed up for". And going back to the ignores issue: I think we shouldn't expect the users to know the intricacies and the semantics of the project backend configuration before they can use the corresponding features productively. The default config should fit the majority use cases in a predictable way. OTOH, when you are well-acquainted with the nuts and bolts, you can built your own backend configuration, and you wouldn't care about the default setup. For such a user the current project-fallback definition is unnecessary: it is pretty trivial after all. >> I think it's apparent at this point that we are venturing into the >> territory of pretty invasive, backward-incompatible changes to the >> existing project.el API. > True, but currently the project.el is underutilized due to its > simplicity and due to this we can still do reasonable invasive changes > to the API. Not sure if that's true. According to the feedback, it covers the use cases of like 80% of the users. And the patches in this discussions should cover the remaining big holes which have been reported a few times. So... I'm fine discussing additions and even big remodels, but it would be better to consider those piece-by-piece, and probably in separate bug reports. We should still keep an eye out for performance, though, and the OOtB experience. >> Right, yeah. Having module detection on a hook seems more flexible >> than putting it on a method dispatches by project type, because then >> the Maven extension can work with any project backend, not just some >> specific Maven-supporting one. > The possible actions for Maven would already work any project backend, > it's the question of how to ensure the proper root for it. Yes. >> FWIW, Steinar asked for being able to choose whether to act on a >> module or on a project, and for that such separation seems to be >> necessary. > > I don't think he cares about Emacs having a distinction, more about the > abiilty to independently act on(compile) those parts. If the user wants to choose what to act on (whole project or current module), the information about modules needs to be discovered as a separate semantic unit. Not sure how else it would be possible to implement such choice in user interaction. >> Debugging seems to be a separate feature from build tools (requiring >> its own information, and a fair amount of it). Although, depending on >> a language and environment, it might require integration with build >> tools as well. > Yeah, and that's one of the conceptual problems with that approach: > assuming too much. Project markers(or "build-tools" markers in your > paradigm) are not limited to build tools, it may be a tags tool for > example. Only if you intend to use the 'tags tool' as a build tool, e.g. list the available tasks or invoke one (for example, to rebuild the index). Then said tags tool can be put into build-tools-functions, with appropriate implementations for 'list tasks' and 'run task'. > Even take Zhou's patch. Lets operate on the assumption that we cannot > let anyone go astray from the paradise of the Holy VCs correctness. > Every single problem you've mentioned would befall on those trying to > use a plain project. Adding a new backend would just let the heathens > win, since they can add those files anywhere and stray away from the > light. From such point of view, you can never add new backends, you can > only add new build tools. You can add new backends: you can add a bridge to Projectile, for example (there is one inside one of the reports in its issue tracker). Or you can create the backend based on GGTAGS, the one you described. As long as it's feature-rich enough, and the behaviors are documented, so the users know what to expect from it, it's totally fine. But both of those are more complex than the project-plain backend Zhou originally proposed, and the project-fallback in the latest patch. > Or to put it another way, whenever people want to mess with project > backends, what they want is to define a scope in which they want to > operate. That scope may differ from the scope defined by VC. I'd like to point out that this is already easy to do. > Also > there's nothing wrong in VC scope being available at the same time at > the user declared project scope. What I mean by that is that nobody > would complain if every project-* utility commands gets a sister named > project-vc-* that would allow you to the same operation, but explicitly > within the VC scope of the current project. Do we really want to ask everyone to use a separate set of commands to apply the 'ignores' config from the current VCS repo? I mean, it's nice to have the option for certain cases, but one would imagine this behavior would be more desirable by default, no? >> The 'project-vc-subprojects' patch. > This a solution to the subprojects hiding problem discussed earlier, > perfectly acceptable for me, but as I mentioned before is not something > I'd use much personally. FWIW, a user option 'do not exclude subprojects' could very easily be added as well. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 11 14:06:15 2021 Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 18:06:15 +0000 Received: from localhost ([127.0.0.1]:60869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZzgh-0004Fm-Fo for submit@debbugs.gnu.org; Mon, 11 Oct 2021 14:06:15 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:46015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZzgb-0004F9-9L for 41572@debbugs.gnu.org; Mon, 11 Oct 2021 14:06:09 -0400 Received: by mail-lf1-f48.google.com with SMTP id u18so76783128lfd.12 for <41572@debbugs.gnu.org>; Mon, 11 Oct 2021 11:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4a1aOAWE1Cvue3PlD2lW0+MXmJWE+IR2lRg8BeSDyFw=; b=H37h94WQQWPRvmgfLUbRIzp+WZbAtu2I178CQd0LnVEdJlxnopI5XTInNDZwMpAJtd WlS93p9BkCgu0k5oHR3Qo16wNiMYAP5vDfxEta1KZZ95gpqFpFLzu2XqpzjYheoUvVpT tfSRvHvF2pjmPUAxqFouJfoxC/pAJ32Q+6l89Oc01H5GXnmbx10r+TPoeeuy5mFCmHYf r54fLkGSm4LfZBLe9+jT/oRYVT++/0sAg/5DF/GQpXgy2D801jiYM/Bj7Q/9A6pbLk5C ZWv3Y07wb1hbN/5r4m9WzvMFNRfVmhqyaP8DjhfZraW/mkhTlensr9TIkcF0+gmiMcBd AvQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4a1aOAWE1Cvue3PlD2lW0+MXmJWE+IR2lRg8BeSDyFw=; b=qlFeMsCx8I6UpPSydIFFy2HduuvHjdRhfGRd1cn5T+sz3H0MkUFTx2mvuzv+Du0WCw tJcdSZ63NUtEeNlB5lW/SD1xMovxLMtfQS8nhNsp4m3gbk3z9KCc2Nf2zE729dR5oX7/ nDll5VzLV8X5yMJbl8g1BehZeRFZcw9INMyPQ8VJxOZvoXgXBZqhUfm5MaYB7kBeZEL2 yEEIoVgMWlF1IZOpx6diJ+WCpboI1uz/pHaKgybF9APqTsLttVUx5XVTuRAsxiFlj0Ba WakL/f+tofoSAkWmMBM5pyydnGvK3fm1IGUhj3SkmYZJnCeLtjyvlPj0O9M+eNJSfa15 8+wg== X-Gm-Message-State: AOAM532fJJOBa9Yw5WGhgcc0oNKC11mhr/paauEmcY0/iwTN0FoF0lpD t6V7r7do0qq40rvUUqtv5sI= X-Google-Smtp-Source: ABdhPJwu4aF06c/6S2eZoSsen3scaMYmsuqnJ1bOT3NvKJ0bhl0gJ7jlXJWThu9kYHB+SkZQy1Og2g== X-Received: by 2002:a05:6512:3981:: with SMTP id j1mr28227501lfu.417.1633975558878; Mon, 11 Oct 2021 11:05:58 -0700 (PDT) Received: from ?IPv6:2a02:2168:b115:9d00:e427:25ae:e312:5fb9? ([2a02:2168:b115:9d00:e427:25ae:e312:5fb9]) by smtp.gmail.com with ESMTPSA id m14sm909748ljp.12.2021.10.11.11.05.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 11:05:58 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> Message-ID: Date: Mon, 11 Oct 2021 21:05:57 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) > I didn't find a definite answer in the rest of the email, so I'll > continue this thread here. Lets restate the answer: VC should be available to the user regardless of the current project backend. When it is so, you can use whatever defaults you deem reasonable, with ignores being respected probably being a good choice. > So you want to add a new backend based on GTAGS which also lists files > by calling 'global -P' or something. > I want all of those capabilities to be reachable, but we also need to > decide which project backends configuration is on by default. The question of default project backends is pretty irrelevant here. I'm not suggesting adding anything there. I'm just saying that when the user adds something, it should not be reduced to the second class citizenship. The reason I've jumped in against your patch in particular is because that's what it does. It makes a distinction between the (possibly) full fledged function backends and the inferior marker file backends, which get their own little ghetto. While I believe that we should treat such marker file backends as first class citizens that are equal to any other backend. > If the user wants to choose what to act on (whole project or current > module), the information about modules needs to be discovered as a > separate semantic unit.  I don't think so. We have two options: 1. Nestable projects. In this paradigm any project can have however many other projects in each subdirectories. You can go from child project to a parent project pretty easily. Going from parent project to child projects is a little bit harder, but still possible. So I can compile(use custom action on) the parent projects from a child one, or a particular(or all) child projects from parent. 2. Project units. Not gonna use the word "module" here, because we've already used it for a different thing in this discussion. So one project can have 0 or more units. Units cannot exist outside of a project and are in turn are not projects themselves. Except that they can completely look like projects, in cases like Maven or Makefiles. Option 1 is simpler because it has only 1 concept. Option 2 introduces a second separate semantic unit, but I don't see any benefit from introducing it. > Only if you intend to use the 'tags tool' as a build tool, e.g. list > the available tasks or invoke one (for example, to rebuild the index). > Then said tags tool can be put into build-tools-functions, with > appropriate implementations for 'list tasks' and 'run task'. I don't like such over-engineering, due to conceptually assuming that all projects are build tool projects, all actions being connected to 1 particular tool and each tool necessarily having multiple actions. I believe all of this is better left to users and backend developers. With just actions and maybe action groups, if we want them. > Do we really want to ask everyone to use a separate set of commands to > apply the 'ignores' config from the current VCS repo? No? Separate commands is just another advantage of VC being always there(if it's there). Maybe I'm maintaining a certain part of the repository, be it a module or whatever, and that's why I'm treating that part as a project, since that's the scope I normally care about. But then I notice a buggy function and use those commands to look whether anything else apart from my code uses it in the wider repo. P.S. Sorry for the terrible amount of typing errors in my previous letter, too much writing for me last week. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 16 22:48:17 2021 Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 02:48:17 +0000 Received: from localhost ([127.0.0.1]:43327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbwDh-00042R-1r for submit@debbugs.gnu.org; Sat, 16 Oct 2021 22:48:17 -0400 Received: from mail-lj1-f171.google.com ([209.85.208.171]:39625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbwDf-00042D-0P for 41572@debbugs.gnu.org; Sat, 16 Oct 2021 22:48:15 -0400 Received: by mail-lj1-f171.google.com with SMTP id r6so1757872ljg.6 for <41572@debbugs.gnu.org>; Sat, 16 Oct 2021 19:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e9dobGJOQh/GBOm/lG57DXoxlTBoEr2SCcgIevyQ0k0=; b=p9HejXQLNPieKPwhNb2u+ML4Vy5qvPEs43R13yp0pcLHudpjLol3zPg4GAOl5X+pit eF+P+7QmcOeOiV71IRJ3/k+H48IfBXf87yGnQnlZaTNyxKvi8O4/soAITdgJ4PytIWuU cBd/P8Uzntu/SH4nX4+WI1ukUQXHxeG8xSqKYBS54wQEffcDajiweKaZFUWBM8xHUrwM /oIvGNoL8lwZDqCksBPvPkisQhMMmP/krHHa/CFVHKa2m1DjR/Q/rxbndqN9DrPkSLJx BQUTQ4WlelXjqjpYQkLHDHRgff3GvsGkYiZPNKY3qr35VXsAHE+tayJCVSbCZaKo2Fg/ DonQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e9dobGJOQh/GBOm/lG57DXoxlTBoEr2SCcgIevyQ0k0=; b=VMApCZkDus6P/aRPHsQmMbhXUYW5H48Kjr0TdAslA1VEBqk4bhPPvLQz32lOlb/zKh lnkoxwKIhN3fdbK3cqInvZf2fPTh4goqxbQqV4B4IPp1DmPPcIj9G3F64atNWDZkkGfP pEYb3LBotVr9ZOZkVSFPlrxPE+ltHZeEaEjtI1laccxLTSJLTEpCCl0g/HwcXcXb8TL5 WbZA7AXRtdIyBZK0d5rWpe7lci2ifsIaPq8N+kk4IG0Xz9xx3XUPGPYbGQwLAdP7kzTI YR37I8wvDUwxI11YQ37owwMHYu50KdbEN2eQ05rRZn2VtgqexhYpcMOKhFm6s08/zjCV aCSA== X-Gm-Message-State: AOAM531wa+kP3nAUKIroi83kqCXAaltSlr7gYOYA/UdcoJrkQJszmVrH P+UZJ+qFV5yx6hflbkS8MGE= X-Google-Smtp-Source: ABdhPJwaCmPE8MG8tV1Q+/rlSIag9Y3m3/8YV6bA648Skfpm5cKlLtxPDKSUy7fHTLxoot0mxkg03w== X-Received: by 2002:a2e:8793:: with SMTP id n19mr488571lji.176.1634438888897; Sat, 16 Oct 2021 19:48:08 -0700 (PDT) Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id x195sm1026137lff.28.2021.10.16.19.48.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Oct 2021 19:48:08 -0700 (PDT) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Nikolay Kudryavtsev , Lars Ingebrigtsen References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> From: Dmitry Gutov Message-ID: Date: Sun, 17 Oct 2021 05:48:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.6 (/) On 11.10.2021 21:05, Nikolay Kudryavtsev wrote: >> I didn't find a definite answer in the rest of the email, so I'll >> continue this thread here. > Lets restate the answer: VC should be available to the user regardless > of the current project backend. When it is so, you can use whatever > defaults you deem reasonable, with ignores being respected probably > being a good choice. Available how? Through a certain keymap, or a specially named set of commands? These issues matter. >> So you want to add a new backend based on GTAGS which also lists files >> by calling 'global -P' or something. >> I want all of those capabilities to be reachable, but we also need to >> decide which project backends configuration is on by default. > The question of default project backends is pretty irrelevant here. If you don't care about the defaults, why argue on this bug tracker at all? By similar logic, you can just go and write your own backends/apis/etc. > I'm > not suggesting adding anything there. I'm just saying that when the user > adds something, it should not be reduced to the second class citizenship. But it's not reduced: quite the opposite, whatever the user adds (to the beginning of the list) takes up a significant responsibility. That can be tough, however, so the first recommendation is to avoid doing it. And solve the immediate goals using something else. > The reason I've jumped in against your patch in particular is because > that's what it does. It makes a distinction between the (possibly) full > fledged function backends and the inferior marker file backends, which > get their own little ghetto. While I believe that we should treat such > marker file backends as first class citizens that are equal to any other > backend. They are treated just as any backend in the list. According to its modest capabilities, however, the backend is placed at the end. It's not the only possible solution to the problem, but I have yet to see a complete design of some alternative being presented. >> If the user wants to choose what to act on (whole project or current >> module), the information about modules needs to be discovered as a >> separate semantic unit. >  I don't think so. We have two options: > > 1. Nestable projects. In this paradigm any project can have however many > other projects in each subdirectories. You can go from child project to > a parent project pretty easily. Going from parent project to child > projects is a little bit harder, but still possible. Possible how? > So I can > compile(use custom action on) the parent projects from a child one, or a > particular(or all) child projects from parent. > > 2. Project units. Not gonna use the word "module" here, because we've > already used it for a different thing in this discussion. So one project > can have 0 or more units. Units cannot exist outside of a project and > are in turn are not projects themselves. Except that they can completely > look like projects, in cases like Maven or Makefiles. > > Option 1 is simpler because it has only 1 concept. Option 2 introduces a > second separate semantic unit, but I don't see any benefit from > introducing it. For instance, Maven modules can be reliably discovered from the parent project's root directory, unlike the potential discovery logic for arbitrarily nested projects (which seems like it will require a costly directory tree walk). >> Only if you intend to use the 'tags tool' as a build tool, e.g. list >> the available tasks or invoke one (for example, to rebuild the index). >> Then said tags tool can be put into build-tools-functions, with >> appropriate implementations for 'list tasks' and 'run task'. > I don't like such over-engineering, due to conceptually assuming that > all projects are build tool projects, all actions being connected to 1 > particular tool and each tool necessarily having multiple actions. I > believe all of this is better left to users and backend developers. With > just actions and maybe action groups, if we want them. Over-engineering? It was just an example for what a "build tool API" could look like. If you know better, try to propose a different one. >> Do we really want to ask everyone to use a separate set of commands to >> apply the 'ignores' config from the current VCS repo? > No? Separate commands is just another advantage of VC being always > there(if it's there). Maybe I'm maintaining a certain part of the > repository, be it a module or whatever, and that's why I'm treating that > part as a project, since that's the scope I normally care about. But > then I notice a buggy function and use those commands to look whether > anything else apart from my code uses it in the wider repo. I meant a separate set of commands which would apply VCS's ignores to the project operations, which the "current" VC-unrelated backend apparently might not do, according to how I understood your explanations. Overall, the idea about a separate keymap that will allow the user to act on the "parent" project is valid. Though it can be implemented on top of the current approach just as well. Treating Maven modules as separate sub-projects *might* fit well with that as well. But the overall idea of having lots of backends in the list, each describing a particular project type (marked by a particular filename) still look problematic to me from the practical standpoint (1. lower performance, 2. the problem of following .gitignore and the associated semantics seems unsolved). From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 17 07:53:00 2021 Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 11:53:00 +0000 Received: from localhost ([127.0.0.1]:43674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc4iq-0002z5-Bp for submit@debbugs.gnu.org; Sun, 17 Oct 2021 07:53:00 -0400 Received: from mail-lj1-f174.google.com ([209.85.208.174]:33749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc4in-0002yq-M8 for 41572@debbugs.gnu.org; Sun, 17 Oct 2021 07:52:58 -0400 Received: by mail-lj1-f174.google.com with SMTP id d13so3352192ljg.0 for <41572@debbugs.gnu.org>; Sun, 17 Oct 2021 04:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=f0b9KbXWDtSVlnu7TuvRGzPU8wZ8oNCVp4+vziGUAVg=; b=qgomuDCUzum8KM5+1T86+T1TLQ2sGX9AoG9lmxq3B43+1Zb2uZ9mMPUSyDV1V5LVV0 1uZ1Cerlp5Tg/y1VdbZzNUoxb/hB8N3RBD1pp0WWWS3kv0VWEYPsDyWRkKi1mQ1/G9FC 1+6oEvQYgixYCbViWIDdg0hpyq3fDJuudfWQoV6tkCzKNW4qk/nvduFAIVN2NihrgNVd 05KbbsbmD5EnwYVrBJj/SorRsRRDEzjmCa2JjXmyWQzMU0R0bQdxG9CxJTJ6wHnQBhAo yMgW4iOby3Vq8qak/po31EVKH8HwAPFmpdGFkCR+6rrxp+XMUMoM3G24GLpTWuuUlYe8 4Mkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=f0b9KbXWDtSVlnu7TuvRGzPU8wZ8oNCVp4+vziGUAVg=; b=vG009y9nN6G49lMnSh75UQ7Pxr4NtAIthwns4HTej9NyVoQbEP2UnVpSSBIslMTSG1 KJuvcn2vhV2L9v3b2gy8Uders/DzvbFAOw55X8Z+wnNejqMRf+t+h4OvV7kk0dZ0uGb9 +Jh7ckBFu2fx7gGeXRjkzUtFzdqfPZzLIpXmny3zW9k0jSNFta+v0x+e8FCTJbmhrzSr 4djDGyjh4Nn+F94iGH3XRgBKL96KIAgTVoGfX8R/SBhw3QZ7j50Mg/IYXCJ/jrHxpGH7 6KDsy5x/S72ZcUYA6VPXxsG0t2yCoV8M51zPOigVtqBrSIoWwpNLmxaLb/ECclWHcdZi RIaw== X-Gm-Message-State: AOAM530a2AC5CrLeIIDfofduPKcqab4YeB2TtaYVkRaQ7rjhuQym6WqU 5SbeLF5rtGSsXXtz4mpeTAo= X-Google-Smtp-Source: ABdhPJwmH4bLkpt1eBpCGMGZoXrDs6vFSQTmFYJ/VDi7shYUqDAESG/dmPRGM87+zYGIjqsD86xkEg== X-Received: by 2002:a2e:3011:: with SMTP id w17mr24906873ljw.87.1634471571567; Sun, 17 Oct 2021 04:52:51 -0700 (PDT) Received: from ?IPv6:2a02:2168:b115:9d00:6a3b:c091:5cdd:1851? ([2a02:2168:b115:9d00:6a3b:c091:5cdd:1851]) by smtp.gmail.com with ESMTPSA id b27sm1135306lfq.162.2021.10.17.04.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 04:52:51 -0700 (PDT) From: Nikolay Kudryavtsev X-Google-Original-From: Nikolay Kudryavtsev Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov , Lars Ingebrigtsen References: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> Message-ID: <444b6c1f-00f1-54ef-f692-cc3d6f30b93e@gmail.com> Date: Sun, 17 Oct 2021 14:52:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 41572 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov 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.1 (-) > Available how? Through a certain keymap, or a specially named set of > commands? These issues matter. Available through a function project-current-vc. On top of that you can implement (global, per backend, per project) setting project-honour-vc-ignores. Then project-vc-* utility functions. > If you don't care about the defaults, why argue on this bug tracker at > all? Because when you're discussing multiple complicated interconnected issues, it's nice to spot one you don't have to discuss. > But it's not reduced: quite the opposite, whatever the user adds (to > the beginning of the list) takes up a significant responsibility. It is relegated to the second class citizenship. Remember, here I was talking about your patch in particular. It puts file marker backends into a separate list, not the generic case of users adding new backends. > It's not the only possible solution to the problem, but I have yet to > see a complete design of some alternative being presented. I've already presented what I'm proposing in previous emails: (register-project-backend "project.file" priority :optimizes-file-listing nil :honuor-vc-ignores t) Instead of adding any separate lists the same marker find functionality can be implemented in a backend registration function and this would allow people needing file marker backends to implement them on the fly, whenever they need one. Also it's not touching the defaults in any way, leaving the decision about the backend priority to the user. > For instance, Maven modules can be reliably discovered from the parent > project's root directory, unlike the potential discovery logic for > arbitrarily nested projects (which seems like it will require a costly > directory tree walk). Yes. At the basic level it's a directory tree walk. But that's not a drawback of my particular proposal, since any attempt to implement the project unit functionality would suffer from this, regardless of the design chosen. You can implement any discovery strategy with any design. > It was just an example for what a "build tool API" could look like. If > you know better, try to propose a different one. I've already proposed one. Each project backend has a set of actions. An action is just a function. Since most would probably be simple shell commands in the project-root, some easier way to define those should implemented. You can see whichever actions are available in some interactive dispatch function or the menu. Actions can be grouped into action groups. This is better in my opinion due to not presuming anything, so if you need to group by a build tool or by multiple, you can, but you don't have to. > I meant a separate set of commands which would apply VCS's ignores to > the project operations, which the "current" VC-unrelated backend > apparently might not do, according to how I understood your explanations. That would a bit clunky. Just honoring VC ignores by default is much better, with an option to do the opposite. > Treating Maven modules as separate sub-projects *might* fit well with > that as well. If you can act on parent and child projects of the current, there's even less of a point to implement project units as a separate semantic unit(concept) from the project itself. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 15:47:26 2022 Received: (at control) by debbugs.gnu.org; 9 Mar 2022 20:47:26 +0000 Received: from localhost ([127.0.0.1]:60865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS3DS-0000Hd-Eq for submit@debbugs.gnu.org; Wed, 09 Mar 2022 15:47:26 -0500 Received: from relay11.mail.gandi.net ([217.70.178.231]:42933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS3DQ-0000HF-DJ for control@debbugs.gnu.org; Wed, 09 Mar 2022 15:47:25 -0500 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id AC579100007 for ; Wed, 9 Mar 2022 20:47:16 +0000 (UTC) From: Juri Linkov To: control@debbugs.gnu.org Subject: Re: bug#54228: 29.0.50; project.el: Support local projects Organization: LINKOV.NET References: <564b8ac4-3d6f-3c7f-15ac-7dc661a18868@inventati.org> Date: Wed, 09 Mar 2022 22:45:17 +0200 In-Reply-To: (Dmitry Gutov's message of "Sat, 5 Mar 2022 03:31:18 +0200") Message-ID: <86r17b6mty.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control 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 (-) forcemerge 41572 54228 thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 06 07:25:11 2022 Received: (at control) by debbugs.gnu.org; 6 Sep 2022 11:25:11 +0000 Received: from localhost ([127.0.0.1]:49858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWha-0000YF-U6 for submit@debbugs.gnu.org; Tue, 06 Sep 2022 07:25:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVWhZ-0000Xz-0Z for control@debbugs.gnu.org; Tue, 06 Sep 2022 07:25:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZQ8KD3MndawQs1cBcbLCz9N4b0WWO8WUMWFXCcLW6Qg=; b=Dq//vSODYjI8PAgejZnh0AYUdK hLXvDw5YEtRRv/6fe9C2qSuBrl2GAWQwCo1swbPgTjUeWZ/2TFV0+1GqXZE1S6OfNP9wahjBiGAqr m9flcw/bI+tE3E3PyrmVaUd6EIpbN/wF9jzQAcDZf+eFPGF60FpXmbOUF2PoDSOdvcmY=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVWhR-00043S-Gk for control@debbugs.gnu.org; Tue, 06 Sep 2022 13:25:03 +0200 Date: Tue, 06 Sep 2022 13:25:01 +0200 Message-Id: <87wnagsq2a.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #54228 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 54228 - patch quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) tags 54228 - patch quit From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 25 20:49:52 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 01:49:52 +0000 Received: from localhost ([127.0.0.1]:37493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oykKF-00040P-U0 for submit@debbugs.gnu.org; Fri, 25 Nov 2022 20:49:52 -0500 Received: from mail-wm1-f42.google.com ([209.85.128.42]:52916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oykK9-000402-W3 for 41572@debbugs.gnu.org; Fri, 25 Nov 2022 20:49:49 -0500 Received: by mail-wm1-f42.google.com with SMTP id o30so4634837wms.2 for <41572@debbugs.gnu.org>; Fri, 25 Nov 2022 17:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=uNmMGgMfMSdb5PU7T46rk0C89XNASn6D9JlO/oRSlnI=; b=cdBf5TY1uTMnldKSuYlBDmks/wHgfBLZpI/Lgq4nQrhlGZLoieBhjQwLxV5eE5H0A3 zBfEUhSbPQABSqomC9BXt+LELpo/PRpsEd0VRzwIyysh7GEHQ5Gx0+oJ6XOAQgUwzo0D yui0Xv7IX4yAn9TPq/rYTH4ZWD4Htl/mOGumyQr1Yy2vYuRjbOuXPXh0IJaXbbuh2y0R Rx75LnjoW8E2YX+ojt7TkSxDlcPqZjF11SlJ4MCayQRPG+u/RXEvMYubMA5DAFXqqqiG j5xaxQ+uhM2wi/EJoGJIByhYokqYfzPMK0ohi0Lh38qe2yFlzFTmJi3MuMP3OMyC1G3V LRqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:cc:to:from:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uNmMGgMfMSdb5PU7T46rk0C89XNASn6D9JlO/oRSlnI=; b=nfTVySlqGhl+2pfLTXLCHNCPKBXgDyKMMPCJyZ3b7vRE+79fag4/uVTcX2B5rhriqZ O2m2RoRFjTMmKwKzokWHTTJ1SRz9P80PIV6zMmhfUBgnsWeQ4goa78+nfhSEmQVX258b nmhAxtJvpLHMIobZ1bkA8p4sVPq3MWG39TTKgPRaJXfvqNuSiBszVHl4IOFJ1lniUU38 Caz06QvHoocc2gFhBr0EA+sAJI86eCmOQzMdbSj7WM78fPQ8/fF4ez/sEmazd0oeO0lW bF9SWxU6PIWa4QVSaW9DvqF1h5CFd6nAbj6orT3TSNQHNHRgwX6huQUKK5Cp6xF1IWc/ ZmMw== X-Gm-Message-State: ANoB5plnoXGLwmptN2WCIph+4KeOw9umhV6sriTIdVsYF/9PmQSnEmyb yLoid61MkJSPPet2vZVayXQtIW0SU3s= X-Google-Smtp-Source: AA0mqf7PUnaVVE6U9dtURRSXRA0+MYuWgHSFMOaT6m4nO6wYDrMvvA7t8uQMdyl5bqzsvtpY1Eh53A== X-Received: by 2002:a05:600c:4a99:b0:3cf:91e5:3d69 with SMTP id b25-20020a05600c4a9900b003cf91e53d69mr34245945wmp.160.1669427379811; Fri, 25 Nov 2022 17:49:39 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p11-20020a05600c358b00b003cf71b1f66csm7510304wmq.0.2022.11.25.17.49.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Nov 2022 17:49:38 -0800 (PST) Content-Type: multipart/mixed; boundary="------------vw1C1bo8xHDjcjJU6Bcg2FPH" Message-ID: <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> Date: Sat, 26 Nov 2022 03:49:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US From: Dmitry Gutov To: 41572@debbugs.gnu.org References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> In-Reply-To: X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/9/21 03:22, Dmitry Gutov wrote: > Another issue is people working on monorepos (often backed by Git) > sometimes want to split them into separate projects. The latter > capability (excluding sub [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.42 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.42 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=c3=adn?= , Eric Abrahamsen , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Manuel Uberti , Juri Linkov , =?UTF-8?Q?Rudolf_Adamkovi=c4=8d?= 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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/9/21 03:22, Dmitry Gutov wrote: > Another issue is people working on monorepos (often backed by Git) > sometimes want to split them into separate projects. The latter > capability (excluding sub [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.42 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.42 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) This is a multi-part message in MIME format. --------------vw1C1bo8xHDjcjJU6Bcg2FPH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 26/9/21 03:22, Dmitry Gutov wrote: > Another issue is people working on monorepos (often backed by Git) > sometimes want to split them into separate projects. The latter > capability (excluding subproject's files) informed the choice of the > approach. Which is altering the vc project backend's behavior, rather > that offering this feature through another backend, like the one added > in the previous patch, for example. > > I don't know if all users of this feature will want them excluded, > though. The attached implementation does, and maybe another option could > be added to disable this. > > Or we could drop this part of the behavior, insisting that users who > want it could add the corresponding entries to project-vc-ignores. This > way they would be listing the subprojects twice, however. And the > project-vc-merge-submodules=nil behavior matches the other option > (submodule files are excluded from the parent). Here's a third approach, which now seems to me the most approachable. It solves the semantic problems by having the new "plain" projects also belong to the same type (which is still called project-vc, but means something more now). The backend's variables are adhered to, and 'git ls-files' is used for file listing in Git-backend subprojects still. The subprojects' files are not excluded from the parent project, but as long as the format of markers stays with wildcards, it at least remains feasible to do, though with some extra expense at runtime. We'll see if people really want this. It will probably also improve performance over Tramp compared to the current. Does this work for everybody? --------------vw1C1bo8xHDjcjJU6Bcg2FPH Content-Type: text/x-patch; charset=UTF-8; name="project-vc-extra-root-markers.diff" Content-Disposition: attachment; filename="project-vc-extra-root-markers.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IDcxMDYxZTYxMzlkLi4xOTQyNGE3MzQzZCAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC02Niw2ICs2Niw5IEBACiA7OyBmaWxlcywgYnV0IHN1cHBvcnRzIGFkZGl0 aW9ucyB0byB0aGUgbGlzdCB1c2luZyB0aGUgdXNlciBvcHRpb24KIDs7IGBwcm9qZWN0LXZj LWlnbm9yZXMnICh1c3VhbGx5IHRocm91Z2ggLmRpci1sb2NhbHMuZWwpLgogOzsKKzs7IEF0 IHRoaXMgcG9pbnQgdGhlIG5hbWUgbWlnaHQgYXMgd2VsbCBiZSBhbiBhYmJyZXZpYXRpb24g Zm9yICJWQyBhbmQKKzs7IEV0YyIsIHNlZSB0aGUgdmFyaWFibGUgYHByb2plY3QtdmMtZXh0 cmEtcm9vdC1tYXJrZXJzJy4KKzs7CiA7OyBVdGlsczoKIDs7CiA7OyBgcHJvamVjdC1jb21i aW5lLWRpcmVjdG9yaWVzJyBhbmQgYHByb2plY3Qtc3VidHJhY3QtZGlyZWN0b3JpZXMnLApA QCAtNDExLDYgKzQxNCwyNyBAQCBwcm9qZWN0LXZjLW5hbWUKICAgOnZlcnNpb24gIjI5LjEi CiAgIDpzYWZlICMnc3RyaW5ncCkKIAorOzsgTm90IHVzaW5nIHJlZ2V4cHMgYmVjYXVzZSB0 aGVzZSB3b3VsZG4ndCB3b3JrIGluIEdpdCBwYXRoc3BlY3MsIGluCis7OyBjYXNlIHdlIGRl Y2lkZSB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gbGlzdCBzdWJwcm9qZWN0cy4KKyhkZWZjdXN0 b20gcHJvamVjdC12Yy1leHRyYS1yb290LW1hcmtlcnMgbmlsCisgICJMaXN0IG9mIGFkZGl0 aW9uYWwgXCJtYXJrZXJzXCIgdG8gc2lnbmFsIHByb2plY3Qgcm9vdHMuCisKK0EgbWFya2Vy IGlzIGVpdGhlciBhIGJhc2UgZmlsZSBuYW1lIG9yIGEgZ2xvYiBwYXR0ZXJuIGZvciBzdWNo LgorCitUaGVzZSB3aWxsIGJlIHVzZWQgaW4gYWRkaXRpb24gdG8gcmVndWxhciBkaXJlY3Rv cnkgbWFya2VycyBzdWNoCithcyAuZ2l0LCAuaGcsIGFuZCBzbyBvbiwgZGVwZW5kZW50IG9u IHRoZSB2YWx1ZSBvZgorYHZjLWhhbmRsZWQtYmFja2VuZHMnLiAgVGhleSBhcmUgbW9zdCB1 c2VmdWwgd2hlbiBhIFZDIHByb2plY3QKK2hhcyBzdWJkaXJlY3RvcmllcyBpbnNpZGUgaXQg dGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMKK3NlcGFyYXRlIHByb2plY3RzLCBidXQg c3RpbGwgdXNlIHRoZSBwYXJlbnQncyBpZ25vcmUgcnVsZXMgYW5kCitnZW5lcmFsIGJlaGF2 aW9ycy4KKworSXQgY2FuIGFsc28gYmUgdXNlZCBmb3IgcHJvamVjdHMgb3V0c2lkZSBvZiBW QyByZXBvc2l0b3JpZXMuCitUaGVpciBiZWhhdmlvciB3aWxsIHN0aWxsIG9iZXkgdGhlIHJl bGV2YW50IHZhcmlhYmxlcywgc3VjaCBhcworYHByb2plY3QtdmMtaWdub3Jlcycgb3IgYHBy b2plY3QtdmMtbmFtZScuIgorICA6dHlwZSAnbGlzdAorICA6dmVyc2lvbiAiMjkuMSIKKyAg OnNhZmUgKGxhbWJkYSAodmFsKSAoYW5kIChsaXN0cCB2YWwpIChjbC1ldmVyeSAjJ3N0cmlu Z3AgdmFsKSkpKQorCiA7OyBGSVhNRTogVXNpbmcgdGhlIGN1cnJlbnQgYXBwcm9hY2gsIG1h am9yIG1vZGVzIGFyZSBzdXBwb3NlZCB0byBzZXQKIDs7IHRoaXMgdmFyaWFibGUgdG8gYSBi dWZmZXItbG9jYWwgdmFsdWUuICBTbyB3ZSBkb24ndCBoYXZlIGFjY2VzcyB0bwogOzsgdGhl ICJleHRlcm5hbCByb290cyIgb2YgbGFuZ3VhZ2UgQSBmcm9tIGJ1ZmZlcnMgb2YgbGFuZ3Vh Z2UgQiwgd2hpY2gKQEAgLTQ0NywyOCArNDcxLDUwIEBAIHByb2plY3QtdmMtZXh0ZXJuYWwt cm9vdHMtZnVuY3Rpb24KIGJhY2tlbmQgaW1wbGVtZW50YXRpb24gb2YgYHByb2plY3QtZXh0 ZXJuYWwtcm9vdHMnLiIpCiAKIChkZWZ1biBwcm9qZWN0LXRyeS12YyAoZGlyKQorICAoZGVm dmFyIHZjLXN2bi1hZG1pbi1kaXJlY3RvcnkpCisgIChyZXF1aXJlICd2Yy1zdm4pCisgIDs7 IEZJWE1FOiBMZWFybiB0byBpbnZhbGlkYXRlIHdoZW4gdGhlIHZhbHVlIG9mCisgIDs7IGBw cm9qZWN0LXZjLW1lcmdlLXN1Ym1vZHVsZXMnIG9yIGBwcm9qZWN0LXZjLWV4dHJhLXJvb3Qt bWFya2VycycKKyAgOzsgY2hhbmdlcy4KICAgKG9yICh2Yy1maWxlLWdldHByb3AgZGlyICdw cm9qZWN0LXZjKQotICAgICAgKGxldCogKChiYWNrZW5kIChpZ25vcmUtZXJyb3JzICh2Yy1y ZXNwb25zaWJsZS1iYWNrZW5kIGRpcikpKQorICAgICAgKGxldCogKChiYWNrZW5kLW1hcmtl cnMtYWxpc3QgYCgoR2l0IC4gIi5naXQiKQorICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoSGcgLiAiLmhnIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKEJ6ciAuICIuYnpyIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKFNWTiAuICx2Yy1zdm4tYWRtaW4tZGlyZWN0b3J5KQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoREFSQ1MgLiAiX2RhcmNzIikKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEZvc3NpbCAuICIuZnNsY2tvdXQiKSkp CisgICAgICAgICAgICAgKGJhY2tlbmQtbWFya2VycworICAgICAgICAgICAgICAoZGVsZXRl CisgICAgICAgICAgICAgICBuaWwKKyAgICAgICAgICAgICAgIChtYXBjYXIKKyAgICAgICAg ICAgICAgICAobGFtYmRhIChiKSAoYXNzb2MtZGVmYXVsdCBiIGJhY2tlbmQtbWFya2Vycy1h bGlzdCkpCisgICAgICAgICAgICAgICAgdmMtaGFuZGxlZC1iYWNrZW5kcykpKQorICAgICAg ICAgICAgIChtYXJrZXItcmUKKyAgICAgICAgICAgICAgKG1hcGNvbmNhdAorICAgICAgICAg ICAgICAgKGxhbWJkYSAobSkgKGZvcm1hdCAiXFwoJXNcXCkiICh3aWxkY2FyZC10by1yZWdl eHAgbSkpKQorICAgICAgICAgICAgICAgKGFwcGVuZCBiYWNrZW5kLW1hcmtlcnMgcHJvamVj dC12Yy1leHRyYS1yb290LW1hcmtlcnMpCisgICAgICAgICAgICAgICAiXFx8IikpCisgICAg ICAgICAgICAgKGxvY2F0ZS1kb21pbmF0aW5nLXN0b3AtZGlyLXJlZ2V4cAorICAgICAgICAg ICAgICAob3IgdmMtaWdub3JlLWRpci1yZWdleHAgbG9jYXRlLWRvbWluYXRpbmctc3RvcC1k aXItcmVnZXhwKSkKKyAgICAgICAgICAgICBsYXN0LW1hdGNoZXMKICAgICAgICAgICAgICAo cm9vdAotICAgICAgICAgICAgICAocGNhc2UgYmFja2VuZAotICAgICAgICAgICAgICAgICgn R2l0Ci0gICAgICAgICAgICAgICAgIDs7IERvbid0IHN0b3AgYXQgc3VibW9kdWxlIGJvdW5k YXJ5LgotICAgICAgICAgICAgICAgICAob3IgKHZjLWZpbGUtZ2V0cHJvcCBkaXIgJ3Byb2pl Y3QtZ2l0LXJvb3QpCi0gICAgICAgICAgICAgICAgICAgICAobGV0ICgocm9vdCAodmMtY2Fs bC1iYWNrZW5kIGJhY2tlbmQgJ3Jvb3QgZGlyKSkpCi0gICAgICAgICAgICAgICAgICAgICAg ICh2Yy1maWxlLXNldHByb3AKLSAgICAgICAgICAgICAgICAgICAgICAgIGRpciAncHJvamVj dC1naXQtcm9vdAotICAgICAgICAgICAgICAgICAgICAgICAgKGlmIChhbmQKLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgOzsgRklYTUU6IEludmFsaWRhdGUgdGhlIGNhY2hlIHdo ZW4gdGhlIHZhbHVlCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IG9mIHRoaXMg dmFyaWFibGUgY2hhbmdlcy4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvamVj dC12Yy1tZXJnZS1zdWJtb2R1bGVzCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIChw cm9qZWN0LS1zdWJtb2R1bGUtcCByb290KSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobGV0KiAoKHBhcmVudCAoZmlsZS1uYW1lLWRpcmVjdG9yeQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZGlyZWN0b3J5LWZpbGUtbmFtZSByb290 KSkpKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHZjLWNhbGwtYmFja2VuZCBi YWNrZW5kICdyb290IHBhcmVudCkpCi0gICAgICAgICAgICAgICAgICAgICAgICAgIHJvb3Qp KSkpKQotICAgICAgICAgICAgICAgICgnbmlsIG5pbCkKLSAgICAgICAgICAgICAgICAoXyAo aWdub3JlLWVycm9ycyAodmMtY2FsbC1iYWNrZW5kIGJhY2tlbmQgJ3Jvb3QgZGlyKSkpKSkK KyAgICAgICAgICAgICAgKGxvY2F0ZS1kb21pbmF0aW5nLWZpbGUKKyAgICAgICAgICAgICAg IGRpcgorICAgICAgICAgICAgICAgKGxhbWJkYSAoZCkKKyAgICAgICAgICAgICAgICAgKHNl dHEgbGFzdC1tYXRjaGVzIChkaXJlY3RvcnktZmlsZXMgZCBuaWwgbWFya2VyLXJlIHQgMTAw KSkpKSkKKyAgICAgICAgICAgICAoYmFja2VuZAorICAgICAgICAgICAgICAoY2wtZmluZC1p ZgorICAgICAgICAgICAgICAgKGxhbWJkYSAoYikKKyAgICAgICAgICAgICAgICAgKG1lbWJl ciAoYXNzb2MtZGVmYXVsdCBiIGJhY2tlbmQtbWFya2Vycy1hbGlzdCkKKyAgICAgICAgICAg ICAgICAgICAgICAgICBsYXN0LW1hdGNoZXMpKQorICAgICAgICAgICAgICAgdmMtaGFuZGxl ZC1iYWNrZW5kcykpCiAgICAgICAgICAgICAgcHJvamVjdCkKKyAgICAgICAgKHdoZW4gKGFu ZAorICAgICAgICAgICAgICAgKGVxIGJhY2tlbmQgJ0dpdCkKKyAgICAgICAgICAgICAgIHBy b2plY3QtdmMtbWVyZ2Utc3VibW9kdWxlcworICAgICAgICAgICAgICAgKHByb2plY3QtLXN1 Ym1vZHVsZS1wIHJvb3QpKQorICAgICAgICAgIChsZXQqICgocGFyZW50IChmaWxlLW5hbWUt ZGlyZWN0b3J5IChkaXJlY3RvcnktZmlsZS1uYW1lIHJvb3QpKSkpCisgICAgICAgICAgICAo c2V0cSByb290ICh2Yy1jYWxsLWJhY2tlbmQgJ0dpdCAncm9vdCBwYXJlbnQpKSkpCiAgICAg ICAgICh3aGVuIHJvb3QKICAgICAgICAgICAoc2V0cSBwcm9qZWN0IChsaXN0ICd2YyBiYWNr ZW5kIHJvb3QpKQogICAgICAgICAgIDs7IEZJWE1FOiBDYWNoZSBmb3IgYSBzaG9ydGVyIHRp bWUuCkBAIC02MjYsNyArNjcyLDggQEAgcHJvamVjdC1pZ25vcmVzCiAgIChsZXQqICgocm9v dCAobnRoIDIgcHJvamVjdCkpCiAgICAgICAgICBiYWNrZW5kKQogICAgIChhcHBlbmQKLSAg ICAgKHdoZW4gKGZpbGUtZXF1YWwtcCBkaXIgcm9vdCkKKyAgICAgKHdoZW4gKGFuZCBiYWNr ZW5kCisgICAgICAgICAgICAgICAgKGZpbGUtZXF1YWwtcCBkaXIgcm9vdCkpCiAgICAgICAg KHNldHEgYmFja2VuZCAoY2FkciBwcm9qZWN0KSkKICAgICAgICAoZGVscQogICAgICAgICBu aWwK --------------vw1C1bo8xHDjcjJU6Bcg2FPH-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 02:47:45 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 07:47:45 +0000 Received: from localhost ([127.0.0.1]:37699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oypua-0000Qx-Jk for submit@debbugs.gnu.org; Sat, 26 Nov 2022 02:47:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oypuW-0000Q6-ES for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 02:47:43 -0500 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 1oypuN-0006Zm-KK; Sat, 26 Nov 2022 02:47:31 -0500 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=1Lx+zu6hvTjIsRxAVzevhohe6xY8/EzDElLJEQ0jK4k=; b=ce1pedJ2QMHaTClfy2hA vgICeQ+iu0qv7mfvWo6vvxpz4s8Cy4T+kxzDgGmCEnOkN3N/H7tgTGc60Vidngb8ftuTXQPB+Gf7y O7JMhNX+9NapDswQhGHE7LNtxCoyg1Q2SFCo1rUZcKyttiBlv+gKRx9O6g17W9CHLR6Hq3hP9aPzy GImh0l8DwMZ+aD2zmf7WIa+WKIGfufr62kCZukpaVcmx+AZThrvTO93XebhptQ1HZr0Oe7oCrImiI 5Y7ouB74p+fOrD4zyOhqtnp7AMFOmW9y6mrBCbxcXyS6ABC95WF4K4SdJkPte0eRqPt9WUWrJTNVJ QKuaLChrXM87EQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oypuM-00050I-3L; Sat, 26 Nov 2022 02:47:30 -0500 Date: Sat, 26 Nov 2022 09:47:53 +0200 Message-Id: <83sfi6tavq.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> (message from Dmitry Gutov on Sat, 26 Nov 2022 03:49:36 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, salutis@me.com, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, arstoffel@gmail.com, 41572@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 (/) > Cc: "Philip K." , Rudi Schlatte , > Augusto Stoffel , Zhu Zihao , > Theodor Thornhill , > Daniel Martín , > Eric Abrahamsen , > João Távora , > Manuel Uberti , Juri Linkov , > Rudolf Adamkovič > Date: Sat, 26 Nov 2022 03:49:36 +0200 > From: Dmitry Gutov > > Does this work for everybody? Hard to say, because: > +(defcustom project-vc-extra-root-markers nil > + "List of additional \"markers\" to signal project roots. > + > +A marker is either a base file name or a glob pattern for such. > + > +These will be used in addition to regular directory markers such > +as .git, .hg, and so on, dependent on the value of > +`vc-handled-backends'. "These will be used" how? This crucial information is sorely missing from this description. Likewise, how "markers" that are not files are used and are useful? > They are most useful when a VC project > +has subdirectories inside it that need to be considered as > +separate projects, but still use the parent's ignore rules and > +general behaviors. How are "markers" useful in this scenario? > +It can also be used for projects outside of VC repositories. > +Their behavior will still obey the relevant variables, such as > +`project-vc-ignores' or `project-vc-name'." And in this one? IOW, please describe the main ideas of this approach instead of relying on use immediately gleaning that from a patch with incomplete documentation. TIA From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 04:51:38 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 09:51:38 +0000 Received: from localhost ([127.0.0.1]:37858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyrqT-0003Tg-VJ for submit@debbugs.gnu.org; Sat, 26 Nov 2022 04:51:38 -0500 Received: from mail-wr1-f54.google.com ([209.85.221.54]:38674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyrqR-0003TS-GJ for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 04:51:36 -0500 Received: by mail-wr1-f54.google.com with SMTP id n3so9902369wrp.5 for <41572@debbugs.gnu.org>; Sat, 26 Nov 2022 01:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1JA1zGfm0lLVAWJch+Vhb/q8TdekEgxGHrV2ZvsT6uE=; b=V4INusuODaSrzvKCzX0VcUCW+8H7fxMK7AXD5CWTBXBb7j09Ww9VZcGFmvVXAUir01 hwN/V1PB2pkiRIA1b/kq8mXCK/9NaBYiVpR+St6hevDNg+RofybdZO9uiofrzriv/n2E wE6K0YUTHZUvMYWbvfc6p7l/49szvWAVjdyun4+jaL88tq0VFACTFQwkLiEyrH2cIYG8 3orCR9qVQZ2+9V2gY/a69746fznNb0Edw1WJ53VB9G2//4avnlISRZM9yzh1kRYh52zu agfKzPWpCFVD/lH40DIjSt3gvGu7PIvWAkZD/iVDYwEOpasJIEYHBk5CIoqUf+tTYLiW fG+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1JA1zGfm0lLVAWJch+Vhb/q8TdekEgxGHrV2ZvsT6uE=; b=jk3Bo7VLRW/v/S+upqFjFvcyLSMbmC7jxDB4KENrUgxEQ6zjucv+UgWNBlRCz+Ho8O +iR0iMl1ZZQaIOd7wJQc9S0OWkapT8p15JEvdZD9a30iSEtkY9I5B/QX+48LiMWOqRkn vIjl25i7eiM7iD/MuCXbVqe88VtciiDSGFxbWqWa1nUJ5y927DwF+kY/CN2vI6e8nvq3 EY59UZH5SutieHAckHrUVwRgiRJqAQJfdjFLurYxjXQdjYtMscHRzlxMIQMhnBdXEvF5 k/X4GEK5mdpwfJDUGUZPzIEC6/8+WcoLz7FDsWQfZFiUgcPpnNEym4c710gQ8ZKC+n8w OC2g== X-Gm-Message-State: ANoB5pnch/72GCgrWF1X1TlCMzOSZdM6+gvunrT934TN88XThghZAX+j OHdaPweaI0BPn56fi255CtY= X-Google-Smtp-Source: AA0mqf4pPNoYDimIGoDgbSix9uUpgafnUJxzTZkKk6W/DcxRIKnf3tPXtMLdF9ENUygZIAn6tf1GVQ== X-Received: by 2002:adf:f10d:0:b0:241:c0e3:ad9d with SMTP id r13-20020adff10d000000b00241c0e3ad9dmr18937350wro.338.1669456289686; Sat, 26 Nov 2022 01:51:29 -0800 (PST) Received: from krug (87-196-72-177.net.novis.pt. [87.196.72.177]) by smtp.gmail.com with ESMTPSA id u26-20020a7bcb1a000000b003cfd42821dasm7960722wmj.3.2022.11.26.01.51.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Nov 2022 01:51:29 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project In-Reply-To: <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> (Dmitry Gutov's message of "Sat, 26 Nov 2022 03:49:36 +0200") References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> Date: Sat, 26 Nov 2022 09:52:45 +0000 Message-ID: <877czirqj6.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > Does this work for everybody? I was pointed to this thread and asked to comment on this patch. Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.54 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.54 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , Daniel =?utf-8?Q?Mart=C3=ADn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , Rudolf =?utf-8?Q?Adamkovi=C4=8D?= , 41572@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: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > Does this work for everybody? I was pointed to this thread and asked to comment on this patch. Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.54 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.54 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Dmitry Gutov writes: > Does this work for everybody? I was pointed to this thread and asked to comment on this patch. My use case is the following: I'm interested in being able to designate projects (through various means, not only marker files) that may only exist inside other projects. I then want the C-x p family of commands to allow a choice of inner project or any of the associated super-projects. I can't understand from the patch alone if it solves this case, but it seems that it doesn't come near. If not for any other reason, I can't always use marker files. I do see that in your patch more and more things appeari under the existing VC type, which I think is growing too much. The comment itself admits that "VC" becomes "VC and etc." -- this is not a good sign. The patch seems to be trying very hard not to create a new project type. But if a new subproject type was created with a link to a previously found super-project. One could easily e.g. reuse the super-project's ignore rules etc in the sub-project. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 07:30:08 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 12:30:08 +0000 Received: from localhost ([127.0.0.1]:38092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyuJr-0001oi-JJ for submit@debbugs.gnu.org; Sat, 26 Nov 2022 07:30:08 -0500 Received: from mail-wr1-f44.google.com ([209.85.221.44]:36685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyuJp-0001Xn-V3 for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 07:30:07 -0500 Received: by mail-wr1-f44.google.com with SMTP id z4so10255522wrr.3 for <41572@debbugs.gnu.org>; Sat, 26 Nov 2022 04:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=pFNtEWiLS46fbmVvRLYzI45SA6X5AEoVQw/ThYlm0kw=; b=OPXVSOACpBS+zyzjcv7icR/9dYmfMQKjOmisC2HwKp3NgeBKKDnwKdYuOnGRUspdYj Jxa184rWv3/dIxqkzs4VMZJ1YN8XBQlJh4uF+WGGXzTGTmFlJpTC+3F7l0tnUQsI8qt9 lERXgBI/0TUD3xH+6kQ1cnat4NoN6OpnQIqHXmLyLaBF346lpugFmjJWGPdUkcUfjkUZ 6Sw3PpVPYx0ebt8BAxHlr8QxBpwFf8ikPtGa1/kfzKC11C2Ewrav6ZWnJrHbLFmP46iY 0x53Twt4TmXMYH8x5EZ2TW1m+LSShJafRKA101yPfeLGOjUudY2rN+lINzTEBP5FTBj3 xkcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pFNtEWiLS46fbmVvRLYzI45SA6X5AEoVQw/ThYlm0kw=; b=IjAl46rMR7vOTp4Wl/ceObeQ2sU5ZYCvdB4q963B3v0BWn3aFqQkJQZ7+h/RyFqp2+ BUQvTdf22uJQsdf7uxSsG/EWWp5pDBxOahaWRfL3Jyz3NZJf2YjiaMuAE7ffaKcue95p EcYPrzrE6Ofh+n39XhQWAIdIR/ujrJZJXmdh7DOAshMNWWOe2g1vWftnzqp6FlWQLpkT iC5Vf/GcRdVoCh2Fps7xpoLaHmFfajXK4bMDk10YGmy9ncpgqVyARMeqDoRTatV8TDH5 DeE1PY5CCkjcPwczICmkUROH2Rtf8DTutO89veO1wAX7AtEJ7PEXu3Qggp1Lpnn5zM+w Gd3A== X-Gm-Message-State: ANoB5pkAbWbjpa9jLbcZpFgDgEAK8M4SsSUBsAVs8oFtcSAaYqibwHWL H5oB5Y/56H2JAdxTvSLqRCM= X-Google-Smtp-Source: AA0mqf7zATYrmQJchVLOdCtzcj8H++e6TONtnMXcTI9+VuvDKuFUO9lFh0PinfeKcST2Rn/zwbQzew== X-Received: by 2002:adf:ec84:0:b0:241:c36f:c3b1 with SMTP id z4-20020adfec84000000b00241c36fc3b1mr23404080wrn.310.1669465800121; Sat, 26 Nov 2022 04:30:00 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h16-20020a05600c315000b003cfb7c02542sm9152774wmo.11.2022.11.26.04.29.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Nov 2022 04:29:59 -0800 (PST) Message-ID: <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> Date: Sat, 26 Nov 2022 14:29:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> From: Dmitry Gutov In-Reply-To: <877czirqj6.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 11:52, João Távora wrote: > Dmitry Gutov writes: > >> Does this work for everybody? > > I was pointed to this thread and asked to comment on this patch. > > My use case is the followin [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.44 listed in list.dnswl.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.44 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=c3=adn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , =?UTF-8?Q?Rudolf_Adamkovi=c4=8d?= , 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 11:52, João Távora wrote: > Dmitry Gutov writes: > >> Does this work for everybody? > > I was pointed to this thread and asked to comment on this patch. > > My use case is the followin [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.44 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.44 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 26/11/22 11:52, João Távora wrote: > Dmitry Gutov writes: > >> Does this work for everybody? > > I was pointed to this thread and asked to comment on this patch. > > My use case is the following: I'm interested in being able to designate > projects (through various means, not only marker files) that may only > exist inside other projects. You previously described your super-project and how you handled it using project-find-functions hook with a new element that looked for file markers. Does this patch make that easier to do? Without writing custom functions? > I then want the C-x p family of commands > to allow a choice of inner project or any of the associated > super-projects. Please avoid mixing feature requests. I already said that "choice of inner or outer" is out of scope for this, but it's easily implemented on top. > I can't understand from the patch alone if it solves this case, but it > seems that it doesn't come near. If not for any other reason, I can't > always use marker files. Did you prefer the other patch in this report? Or do you perhaps see an easy way to augment this patch to cover the remaining cases? Perhaps of project-vc-extra-root-markers also accepted absolute directory names, or if an additional variable did that. > I do see that in your patch more and more things appeari under the > existing VC type, which I think is growing too much. The comment itself > admits that "VC" becomes "VC and etc." -- this is not a good sign. > > The patch seems to be trying very hard not to create a new project type. That's called "tradeoffs". Previous patches, if you saw them, made different tradeoffs with different downsides. > But if a new subproject type was created with a link to a previously > found super-project. One could easily e.g. reuse the super-project's > ignore rules etc in the sub-project. For us to be able to discuss the alternatives, you'd have to read the previous comments on this report. Or I guess you can post a reasonably complete and functional alternative patch and we'd discuss the tradeoffs there. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 08:22:50 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 13:22:50 +0000 Received: from localhost ([127.0.0.1]:38189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyv8q-0001JA-KJ for submit@debbugs.gnu.org; Sat, 26 Nov 2022 08:22:50 -0500 Received: from mail-wr1-f46.google.com ([209.85.221.46]:42546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyv8n-0001Iv-KE for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 08:22:47 -0500 Received: by mail-wr1-f46.google.com with SMTP id cl5so10345302wrb.9 for <41572@debbugs.gnu.org>; Sat, 26 Nov 2022 05:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=yURVvs8Ds4s/E3Cl5rsOtHy+QeyLqyegCuwCI5mKnjs=; b=aWsO9okbBSpF/LWppAyZY1ptvCHzlTnx8MJiMnWpfnEsojw4dCfxTa1Kt6URvMWTCW zA/3YL6yoZvY6UBNaf7oPgXG5rC31PtyYQw8CF/MsHTEXQPHzoqug0sLn25hgfITiYrz bTiJ4zUjiF9rYHTayEsDQWt0uG9KCIyUTPCaCLAYJO/nJYWvIq16LpNH1SpLFBRnykLf rDQHr71WARHxtGWGyqRMxmAtCHq8aZ07FQjUaZtC8dOutIjlZfGMcZZZXH2vUJdiKxMG 3wNF2hIaqc9Ma8zcLDkKzMC33IaI5VK63ZL/YRHvQO4WPnMdxGIv0fv7VMqUgvzy1aPd 08qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yURVvs8Ds4s/E3Cl5rsOtHy+QeyLqyegCuwCI5mKnjs=; b=7fwF+pCvvM8HtIuBTUqPvfOJ5z1TOIwO81hUWhzo/KRcd1L1xbDbr11T8Hs9p3l0qn ogwSEboBHfbR7MWDH6HDiOP/TP2hwU7YDAKl5qoCAEEcEjF1h1xFWY0eM/UHhIskVSII P4UidFXOifVoonYfYlfzVMz8YvKFi3Gi1qBUBvgbiw4phnTGJ3CZcQAGgUO+I2ccmdqb PBIOTtdx1rz0kf3ssJ+22pFvyzTEh6ElD8S7x+Rq55yAXsglsR4Dh2Kfz5fYi2W8j0T4 7j51qrDaq04bz9i/ESRTIaeHAwwxs+aQAKTshmtWaDJk3oTE9rKnbey4hR14O9fuMZ4a qquw== X-Gm-Message-State: ANoB5pma24nxZhPJaTk7nqD9W6G5/OmDZhUfaa6u0ZOMudmHeHFqdWod MTZjXA3mXi8FbcceYEMU3kw= X-Google-Smtp-Source: AA0mqf43yPpG7dKHbTWCTN8ihuJw3li6tHYrQz2xaqvrEOqnLy+LGpTzKHhx2417rmUWutpGlYshPg== X-Received: by 2002:a5d:68c1:0:b0:236:8a38:4deb with SMTP id p1-20020a5d68c1000000b002368a384debmr26378341wrw.487.1669468960012; Sat, 26 Nov 2022 05:22:40 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j2-20020a5d6e42000000b0024194bba380sm6005784wrz.22.2022.11.26.05.22.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Nov 2022 05:22:39 -0800 (PST) Message-ID: Date: Sat, 26 Nov 2022 15:22:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83sfi6tavq.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 09:47, Eli Zaretskii wrote: >> +(defcustom project-vc-extra-root-markers nil >> + "List of additional \"markers\" to signal project roots. >> + >> +A marker is either a base file name or a glob pattern for such. >> + >> +These w [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.46 listed in list.dnswl.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.46 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 09:47, Eli Zaretskii wrote: >> +(defcustom project-vc-extra-root-markers nil >> + "List of additional \"markers\" to signal project roots. >> + >> +A marker is either a base file name or a glob pattern for such. >> + >> +These w [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.46 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.46 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 26/11/22 09:47, Eli Zaretskii wrote: >> +(defcustom project-vc-extra-root-markers nil >> + "List of additional \"markers\" to signal project roots. >> + >> +A marker is either a base file name or a glob pattern for such. >> + >> +These will be used in addition to regular directory markers such >> +as .git, .hg, and so on, dependent on the value of >> +`vc-handled-backends'. > > "These will be used" how? This crucial information is sorely missing from > this description. Likewise, how "markers" that are not files are used and > are useful? Not files, meaning, markers which are globs with wildcards? >> They are most useful when a VC project >> +has subdirectories inside it that need to be considered as >> +separate projects, but still use the parent's ignore rules and >> +general behaviors. > > How are "markers" useful in this scenario? As mentioned in e.g. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#11, monorepos often contain subdirectories which one might want to handle separately. Those subdirectories often come in standard structures, e.g. a frontend subdirectory might contain a file called "package.json", a backend subdirectory might contain "Gemfile" or "build.gradle", or perhaps "autogen.sh", and so on. Adding those to the markers list will tag those subdirectories as projects on their own. People can also use the file names special to their particular organization instead of those above. >> +It can also be used for projects outside of VC repositories. >> +Their behavior will still obey the relevant variables, such as >> +`project-vc-ignores' or `project-vc-name'." > > And in this one? This covers the use cases described in the first messages of this and the merged bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#5 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#5 People would add ".project" or ".emacs-project" to project-vc-extra-root-markers and see things work. Might have to restart Emacs, though, if they already called project commands in the given directory, because the current project info is cached. > IOW, please describe the main ideas of this approach instead of relying on > use immediately gleaning that from a patch with incomplete documentation. If you have further questions, please ask. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 09:27:24 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 14:27:24 +0000 Received: from localhost ([127.0.0.1]:38316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyw9K-0005CK-Ih for submit@debbugs.gnu.org; Sat, 26 Nov 2022 09:27:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyw9H-0005C7-M4 for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 09:27:21 -0500 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 1oyw97-0002S2-8r; Sat, 26 Nov 2022 09:27:10 -0500 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=f6nXTEVsXhvSG6MEfrW5SxHjywbdfxseLBXtzb8wsLY=; b=CGhCBReDlNKX V3bGcLC2YbuO17RrbqRsHsdkVTDWHsAMJDM/veVI0RlS4vydNDsrfwkWrYWHKuADsmLxPj/vDIleB 64sOXXkNaBe2Zbd0Yijp2yIj2k4Zu+GGkZ0RzK6sSdzuIAwTqXeLumVsxCtzjfcY6FrmJj5eOVivk VO2cc63pjJ3zqBbSfMtrV0Cl3Euz/0JSYcqo1J/6BvPgtdNOwfeQoZi+yFs7iwJsEdFHY8E38fTpS bwnI6NEqoreVAdwQ0FyREU+HH6vQdG7wa2b1cIMy88g1FIJR+J1Ez1uOwIgdtD0t8JRM2wi+0STib L/at4/KIRLzZp6EiCwGuqg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyw96-0003Pc-KY; Sat, 26 Nov 2022 09:27:08 -0500 Date: Sat, 26 Nov 2022 16:27:32 +0200 Message-Id: <83mt8dssdn.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sat, 26 Nov 2022 15:22:36 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Sat, 26 Nov 2022 15:22:36 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > salutis@me.com, joaotavora@gmail.com, manuel.uberti@inventati.org, > juri@linkov.net, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > On 26/11/22 09:47, Eli Zaretskii wrote: > > >> +(defcustom project-vc-extra-root-markers nil > >> + "List of additional \"markers\" to signal project roots. > >> + > >> +A marker is either a base file name or a glob pattern for such. > >> + > >> +These will be used in addition to regular directory markers such > >> +as .git, .hg, and so on, dependent on the value of > >> +`vc-handled-backends'. > > > > "These will be used" how? This crucial information is sorely missing from > > this description. Likewise, how "markers" that are not files are used and > > are useful? > > Not files, meaning, markers which are globs with wildcards? > > >> They are most useful when a VC project > >> +has subdirectories inside it that need to be considered as > >> +separate projects, but still use the parent's ignore rules and > >> +general behaviors. > > > > How are "markers" useful in this scenario? > > As mentioned in e.g. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#11, monorepos often > contain subdirectories which one might want to handle separately. > > Those subdirectories often come in standard structures, e.g. a frontend > subdirectory might contain a file called "package.json", a backend > subdirectory might contain "Gemfile" or "build.gradle", or perhaps > "autogen.sh", and so on. > > Adding those to the markers list will tag those subdirectories as > projects on their own. People can also use the file names special to > their particular organization instead of those above. > > >> +It can also be used for projects outside of VC repositories. > >> +Their behavior will still obey the relevant variables, such as > >> +`project-vc-ignores' or `project-vc-name'." > > > > And in this one? > > This covers the use cases described in the first messages of this and > the merged bug report: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#5 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#5 > > People would add ".project" or ".emacs-project" to > project-vc-extra-root-markers and see things work. > > Might have to restart Emacs, though, if they already called project > commands in the given directory, because the current project info is cached. > > > IOW, please describe the main ideas of this approach instead of relying on > > use immediately gleaning that from a patch with incomplete documentation. > > If you have further questions, please ask. Thanks, but I meant for at least some of the above to be in the doc strings and/or explained here in plain English. Readers aren't supposed to search bug reports for relevant information. (And for me personally, this means I won't be able to look up the relevant information before at least another week or two, which is a pity.) From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 14:23:50 2022 Received: (at 41572) by debbugs.gnu.org; 26 Nov 2022 19:23:50 +0000 Received: from localhost ([127.0.0.1]:41457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz0mE-000401-En for submit@debbugs.gnu.org; Sat, 26 Nov 2022 14:23:50 -0500 Received: from mail-oi1-f171.google.com ([209.85.167.171]:39804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz0mB-0003zv-Hw for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 14:23:49 -0500 Received: by mail-oi1-f171.google.com with SMTP id m204so7667338oib.6 for <41572@debbugs.gnu.org>; Sat, 26 Nov 2022 11:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wvtE47qc36Zi7jG6KASl+f4mbQBeVlQ5Sxzl0bhd4i8=; b=NMn9/UsWkm3liYtaB8kIaF3yC1xNsbqj72BwZ5oJCk5OPo+MiFIz3PK2BwMplkqdo8 HxEcTy6maPKimIBIKYW50BhMWiShLtWvo87oP6nHyEF/MBn/BFg/Y2CfHnlH9atGhJSg eAe/cadUROF7xg+xnNyPcJ980r3BAZLWJRNOEYbuXZtEDjKykq5Vqjr4GRCc7ulY3DnL pHYbdC+IKpnAH4sbKhWnO480ymg9fBIYFZmYeN6M4SO2vzrrzBeMGK3Dt7iFSZlRO7ng jQ4RSHvibCamanT3M+ImO0Gu1rko0w7FZ/O+40ZYB9UVr6cJqbENRHUK9vSy4KQrkRZH bEsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=wvtE47qc36Zi7jG6KASl+f4mbQBeVlQ5Sxzl0bhd4i8=; b=Ep7ReTAmqaY5y59An5YmwMGAOzilnegbOlE4ZhScc12ALzhOWMHPZQ79IifFLMXpl1 K2tip7x0OQgpXKgKlDtHOinIhR2++Ko5BwHVqr3ZKc4VmvZVeL7RLhxvMBFElDAimPmG 59sEhIqATSAK4KEUuOyrSOBPHUsJhBXJKHvhb236pIDs0kEErib9qVz1APLaORfLVN0r uw8vYIWKLrYCn3xizmSSRQM4bkMiZAA95t0GQPlK2ypkoHzcD9UiCBhVTkX8ejLJE5ep y+i+jTfy5+Fsfq3lN+VWgKcCuR8JkEsO/awYoTbIqqRk1ocAdpxedW/+gJejskin9KPo TjdQ== X-Gm-Message-State: ANoB5pkYGjlB3mtcBZhTn6vna8Fl80tWxoyQC5nrSiXgHHLlz8vU9E4X mPTsYK4iJ7w1Kzj76D/Gu+LuNBnV/DGrMw0fIuw= X-Google-Smtp-Source: AA0mqf6bpUhJK+Po2oPmm3K6i7aHSLmFYUFEiPCD3Hv4VRoXak/CWa0FyzWMaxXbD81IagGQzRLxEEhu5qbBqYJ6jKU= X-Received: by 2002:a05:6808:2c3:b0:35b:a1b7:fb0f with SMTP id a3-20020a05680802c300b0035ba1b7fb0fmr1493258oid.215.1669490621687; Sat, 26 Nov 2022 11:23:41 -0800 (PST) MIME-Version: 1.0 References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> In-Reply-To: <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 26 Nov 2022 19:23:29 +0000 Message-ID: Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Dmitry Gutov Content-Type: multipart/alternative; boundary="000000000000762d3505ee6493af" X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sat, Nov 26, 2022, 12:30 Dmitry Gutov wrote: > > > My use case is the following: I'm interested in being able to designate > > projects (through various means, not only marker files) that may only > > exist inside other projects. > > You previou [...] Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.171 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.171 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=C3=ADn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , =?UTF-8?Q?Rudolf_Adamkovi=C4=8D?= , 41572@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: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sat, Nov 26, 2022, 12:30 Dmitry Gutov wrote: > > > My use case is the following: I'm interested in being able to designate > > projects (through various means, not only marker files) that may only > > exist inside other projects. > > You previou [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.171 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.171 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --000000000000762d3505ee6493af Content-Type: text/plain; charset="UTF-8" On Sat, Nov 26, 2022, 12:30 Dmitry Gutov wrote: > > > My use case is the following: I'm interested in being able to designate > > projects (through various means, not only marker files) that may only > > exist inside other projects. > > You previously described your super-project and how you handled it using > project-find-functions hook with a new element that looked for file > markers. Does this patch make that easier to do? Without writing custom > functions? > The example i gave did _not_ use file markers. Personally, I can't use them. I need some elisp way. > I then want the C-x p family of commands > > to allow a choice of inner project or any of the associated > > super-projects. > > Please avoid mixing feature requests. I already said that "choice of > inner or outer" is out of scope for this, but it's easily implemented on > top. > What good are sub and super projects without a way to take advantage of them? If anything we should focus on the operations first. I have not seen your other patch. I take it it must have had some drawback since you superseded it with something else. But post the link, this thread is too long. I'll look at it on Monday if I have time. --000000000000762d3505ee6493af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 26, 2022, 12:30 Dmitry Gutov <dgutov@yandex.ru> wrote:

> My use case is the following: I'm interested in being able to desi= gnate
> projects (through various means, not only marker files) that may only<= br> > exist inside other projects.

You previously described your super-project and how you handled it using project-find-functions hook with a new element that looked for file
markers. Does this patch make that easier to do? Without writing custom functions?

The example i gave did _not_ use file markers. Personally, I can&= #39;t use them. I need some elisp way.

> I then want the C-x p family of commands
> to allow a choice of inner project or any of the associated
> super-projects.

Please avoid mixing feature requests. I already said that "choice of <= br> inner or outer" is out of scope for this, but it's easily implemen= ted on
top.

What good are sub and super projects without a way to take advantage of= them? If anything we should focus on the operations first.

I have not seen your other patch. I t= ake it it must have had some drawback since you superseded it with somethin= g else. But post the link, this thread is too long. I'll look at it on = Monday if I have time.
--000000000000762d3505ee6493af-- From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 20:08:20 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 01:08:20 +0000 Received: from localhost ([127.0.0.1]:41742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz69a-00018B-Uk for submit@debbugs.gnu.org; Sat, 26 Nov 2022 20:08:20 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:52812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oz69W-000184-3e for 41572@debbugs.gnu.org; Sat, 26 Nov 2022 20:08:17 -0500 Received: by mail-wm1-f53.google.com with SMTP id o30so6080691wms.2 for <41572@debbugs.gnu.org>; Sat, 26 Nov 2022 17:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=TIFd0F8XsEncmchsa0klNr6RKtOlR777Vu2PzmU5Dgg=; b=avT3WKvZUH5YTi6Q7RTzVoHiKC/5CqFfUBQkgQ6Qr/C1xr3UP/SBdXI+4HczeiN62k VbLzVDzhLCuUkaZo9cOqNq0tsH/gDj5s8b9a3JoQON6JVE3wP/jh1CSYgXw8qkrAhRYc R5RWg9ol9Nek6xKvuzKt54HN37VAbJbMeXW38uGKV80397SCmTNIimmE+Xehoi6rXk0L lFGeDgCwnor9+jsK2kXmVU773cawE8GqXQj+hP1+nyyDFl8Bi9l4T4OEV9veitjs/zFV UBhLg/+Ve7wCGLxPivMKXH3MCZumBURenwsHjV8bXiLiO2mFyqVx4oNcjzJsX5vFHjgu wZQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=TIFd0F8XsEncmchsa0klNr6RKtOlR777Vu2PzmU5Dgg=; b=xxqTIt6fjDccwDL24aQiGnsa3cWfC9Enty6it9GP7RyGSqUZZdT4IOJYjduptiyynh eh4VhDRS0Van/CsWQMTvZcEPRhqbBPFUrsq5pLlPbp2FZjgUR0dhC0PRFs5Zr4bnQarR CTuo9oS30TFAC86pTwa6oq6rGXZc194OsCYol5jT9ilhI2PnMMSLktB6m7avIzDnZqiH 7Xoq6M/WG38LSz3eKDARTEcDj+Lq8VKi7prJS1BIt9galLUwjoKr5HlOW8kn4uiV7i5H ZOR7/3enoQ1t3G+S5Ziy4FQitA3avLLauiaZ3x5w43NhqDzssjFVC2HUBBf7xh5xGQEy rsZg== X-Gm-Message-State: ANoB5pm1CK2LcUwLW3zWHV/2SzWsjDQJXUO4tIvPCmZ1gFhXe/bY9Ik7 jLelG6X//jYFe81xdIQRA+U= X-Google-Smtp-Source: AA0mqf5yB9y6leAPbJt6x1NDtCfTUKu5WkXnhejFVoygJmYaVJZ6m4w0FbHSxuPjN5D/qXC9RUBPhA== X-Received: by 2002:a05:600c:2212:b0:3cf:8aa0:cbec with SMTP id z18-20020a05600c221200b003cf8aa0cbecmr22232595wml.161.1669511287830; Sat, 26 Nov 2022 17:08:07 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p11-20020a05600c468b00b003cfd10a33afsm15036718wmo.11.2022.11.26.17.08.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Nov 2022 17:08:06 -0800 (PST) Content-Type: multipart/mixed; boundary="------------lmSlsjVzAZCnaqu0tS0FAyys" Message-ID: <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> Date: Sun, 27 Nov 2022 03:08:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83mt8dssdn.fsf@gnu.org> X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 16:27, Eli Zaretskii wrote: >> Date: Sat, 26 Nov 2022 15:22:36 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, m [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.53 listed in list.dnswl.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.53 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 16:27, Eli Zaretskii wrote: >> Date: Sat, 26 Nov 2022 15:22:36 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, m [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.53 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.53 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) This is a multi-part message in MIME format. --------------lmSlsjVzAZCnaqu0tS0FAyys Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 26/11/22 16:27, Eli Zaretskii wrote: >> Date: Sat, 26 Nov 2022 15:22:36 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, >> salutis@me.com, joaotavora@gmail.com, manuel.uberti@inventati.org, >> juri@linkov.net, arstoffel@gmail.com, 41572@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 26/11/22 09:47, Eli Zaretskii wrote: >> >>>> +(defcustom project-vc-extra-root-markers nil >>>> + "List of additional \"markers\" to signal project roots. >>>> + >>>> +A marker is either a base file name or a glob pattern for such. >>>> + >>>> +These will be used in addition to regular directory markers such >>>> +as .git, .hg, and so on, dependent on the value of >>>> +`vc-handled-backends'. >>> >>> "These will be used" how? This crucial information is sorely missing from >>> this description. Likewise, how "markers" that are not files are used and >>> are useful? >> >> Not files, meaning, markers which are globs with wildcards? >> >>>> They are most useful when a VC project >>>> +has subdirectories inside it that need to be considered as >>>> +separate projects, but still use the parent's ignore rules and >>>> +general behaviors. >>> >>> How are "markers" useful in this scenario? >> >> As mentioned in e.g. >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#11, monorepos often >> contain subdirectories which one might want to handle separately. >> >> Those subdirectories often come in standard structures, e.g. a frontend >> subdirectory might contain a file called "package.json", a backend >> subdirectory might contain "Gemfile" or "build.gradle", or perhaps >> "autogen.sh", and so on. >> >> Adding those to the markers list will tag those subdirectories as >> projects on their own. People can also use the file names special to >> their particular organization instead of those above. >> >>>> +It can also be used for projects outside of VC repositories. >>>> +Their behavior will still obey the relevant variables, such as >>>> +`project-vc-ignores' or `project-vc-name'." >>> >>> And in this one? >> >> This covers the use cases described in the first messages of this and >> the merged bug report: >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#5 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54228#5 >> >> People would add ".project" or ".emacs-project" to >> project-vc-extra-root-markers and see things work. >> >> Might have to restart Emacs, though, if they already called project >> commands in the given directory, because the current project info is cached. >> >>> IOW, please describe the main ideas of this approach instead of relying on >>> use immediately gleaning that from a patch with incomplete documentation. >> >> If you have further questions, please ask. > > Thanks, but I meant for at least some of the above to be in the doc strings > and/or explained here in plain English. Readers aren't supposed to search > bug reports for relevant information. (And for me personally, this means I > won't be able to look up the relevant information before at least another > week or two, which is a pity.) The links were meant to illustrate that most people Cc'd probably understand the context already (modulo some forgetting because time has passed). And either way I'm probably too close to the problem to understand easily what is clear to the average user and what is not. That's why questions are always useful. I've added the examples to the docstring and rephrased it a little. Does it read better now? --------------lmSlsjVzAZCnaqu0tS0FAyys Content-Type: text/x-patch; charset=UTF-8; name="project-vc-extra-root-markers-v2.diff" Content-Disposition: attachment; filename="project-vc-extra-root-markers-v2.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IDViODY0ODAzMWZiLi5iNGQ1YjRiMGM5ZSAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC02Niw2ICs2Niw5IEBACiA7OyBmaWxlcywgYnV0IHN1cHBvcnRzIGFkZGl0 aW9ucyB0byB0aGUgbGlzdCB1c2luZyB0aGUgdXNlciBvcHRpb24KIDs7IGBwcm9qZWN0LXZj LWlnbm9yZXMnICh1c3VhbGx5IHRocm91Z2ggLmRpci1sb2NhbHMuZWwpLgogOzsKKzs7IEF0 IHRoaXMgcG9pbnQgdGhlIG5hbWUgbWlnaHQgYXMgd2VsbCBiZSBhbiBhYmJyZXZpYXRpb24g Zm9yICJWQyBhbmQKKzs7IEV0YyIsIHNlZSB0aGUgdmFyaWFibGUgYHByb2plY3QtdmMtZXh0 cmEtcm9vdC1tYXJrZXJzJy4KKzs7CiA7OyBVdGlsczoKIDs7CiA7OyBgcHJvamVjdC1jb21i aW5lLWRpcmVjdG9yaWVzJyBhbmQgYHByb2plY3Qtc3VidHJhY3QtZGlyZWN0b3JpZXMnLApA QCAtNDExLDYgKzQxNCwyOSBAQCBwcm9qZWN0LXZjLW5hbWUKICAgOnZlcnNpb24gIjI5LjEi CiAgIDpzYWZlICMnc3RyaW5ncCkKIAorOzsgTm90IHVzaW5nIHJlZ2V4cHMgYmVjYXVzZSB0 aGVzZSB3b3VsZG4ndCB3b3JrIGluIEdpdCBwYXRoc3BlY3MsIGluCis7OyBjYXNlIHdlIGRl Y2lkZSB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gbGlzdCBzdWJwcm9qZWN0cy4KKyhkZWZjdXN0 b20gcHJvamVjdC12Yy1leHRyYS1yb290LW1hcmtlcnMgbmlsCisgICJMaXN0IG9mIGFkZGl0 aW9uYWwgbWFya2VycyB0byBzaWduYWwgcHJvamVjdCByb290cy4KKworQSBtYXJrZXIgaXMg ZWl0aGVyIGEgYmFzZSBmaWxlIG5hbWUgb3IgYSBnbG9iIHBhdHRlcm4gZm9yIHN1Y2guCisK K0V4YW1wbGUgdmFsdWVzOiBcIi5kaXItbG9jYWxzLmVsXCIsIFwicGFja2FnZS5qc29uXCIs IFwicG9tLnhtbFwiLAorXCJyZXF1aXJlbWVudHMudHh0XCIsIFwiR2VtZmlsZVwiLCBcIiou Z2Vtc3BlY1wiLCBcImF1dG9nZW4uc2hcIi4KKworVGhlc2Ugd2lsbCBiZSB1c2VkIGluIGFk ZGl0aW9uIHRvIHJlZ3VsYXIgZGlyZWN0b3J5IG1hcmtlcnMgc3VjaAorYXMgLmdpdCwgLmhn LCBhbmQgc28gb24sIGRlcGVuZGVudCBvbiB0aGUgdmFsdWUgb2YKK2B2Yy1oYW5kbGVkLWJh Y2tlbmRzJy4gIFRoZXkgYXJlIG1vc3QgdXNlZnVsIHdoZW4gYSBWQyBwcm9qZWN0CitoYXMg c3ViZGlyZWN0b3JpZXMgaW5zaWRlIGl0IHRoYXQgbmVlZCB0byBiZSBjb25zaWRlcmVkIGFz CitzZXBhcmF0ZSBwcm9qZWN0cy4gIEl0IGNhbiBhbHNvIGJlIHVzZWQgZm9yIHByb2plY3Rz IG91dHNpZGUgb2YKK1ZDIHJlcG9zaXRvcmllcy4KKworRWl0aGVyIHdheSwgdGhlaXIgYmVo YXZpb3Igd2lsbCBzdGlsbCBvYmV5IHRoZSByZWxldmFudAordmFyaWFibGVzLCBzdWNoIGFz IGBwcm9qZWN0LXZjLWlnbm9yZXMnIG9yIGBwcm9qZWN0LXZjLW5hbWUnLiIKKyAgOnR5cGUg J2xpc3QKKyAgOnZlcnNpb24gIjI5LjEiCisgIDpzYWZlIChsYW1iZGEgKHZhbCkgKGFuZCAo bGlzdHAgdmFsKSAoY2wtZXZlcnkgIydzdHJpbmdwIHZhbCkpKSkKKwogOzsgRklYTUU6IFVz aW5nIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBtYWpvciBtb2RlcyBhcmUgc3VwcG9zZWQgdG8g c2V0CiA7OyB0aGlzIHZhcmlhYmxlIHRvIGEgYnVmZmVyLWxvY2FsIHZhbHVlLiAgU28gd2Ug ZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8KIDs7IHRoZSAiZXh0ZXJuYWwgcm9vdHMiIG9mIGxhbmd1 YWdlIEEgZnJvbSBidWZmZXJzIG9mIGxhbmd1YWdlIEIsIHdoaWNoCkBAIC00NDcsMjggKzQ3 Myw1MCBAQCBwcm9qZWN0LXZjLWV4dGVybmFsLXJvb3RzLWZ1bmN0aW9uCiBiYWNrZW5kIGlt cGxlbWVudGF0aW9uIG9mIGBwcm9qZWN0LWV4dGVybmFsLXJvb3RzJy4iKQogCiAoZGVmdW4g cHJvamVjdC10cnktdmMgKGRpcikKKyAgKGRlZnZhciB2Yy1zdm4tYWRtaW4tZGlyZWN0b3J5 KQorICAocmVxdWlyZSAndmMtc3ZuKQorICA7OyBGSVhNRTogTGVhcm4gdG8gaW52YWxpZGF0 ZSB3aGVuIHRoZSB2YWx1ZSBvZgorICA7OyBgcHJvamVjdC12Yy1tZXJnZS1zdWJtb2R1bGVz JyBvciBgcHJvamVjdC12Yy1leHRyYS1yb290LW1hcmtlcnMnCisgIDs7IGNoYW5nZXMuCiAg IChvciAodmMtZmlsZS1nZXRwcm9wIGRpciAncHJvamVjdC12YykKLSAgICAgIChsZXQqICgo YmFja2VuZCAoaWdub3JlLWVycm9ycyAodmMtcmVzcG9uc2libGUtYmFja2VuZCBkaXIpKSkK KyAgICAgIChsZXQqICgoYmFja2VuZC1tYXJrZXJzLWFsaXN0IGAoKEdpdCAuICIuZ2l0IikK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKEhnIC4gIi5oZyIpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChCenIgLiAiLmJ6ciIpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChTVk4gLiAsdmMtc3ZuLWFk bWluLWRpcmVjdG9yeSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KERBUkNTIC4gIl9kYXJjcyIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChGb3NzaWwgLiAiLmZzbGNrb3V0IikpKQorICAgICAgICAgICAgIChiYWNrZW5kLW1h cmtlcnMKKyAgICAgICAgICAgICAgKGRlbGV0ZQorICAgICAgICAgICAgICAgbmlsCisgICAg ICAgICAgICAgICAobWFwY2FyCisgICAgICAgICAgICAgICAgKGxhbWJkYSAoYikgKGFzc29j LWRlZmF1bHQgYiBiYWNrZW5kLW1hcmtlcnMtYWxpc3QpKQorICAgICAgICAgICAgICAgIHZj LWhhbmRsZWQtYmFja2VuZHMpKSkKKyAgICAgICAgICAgICAobWFya2VyLXJlCisgICAgICAg ICAgICAgIChtYXBjb25jYXQKKyAgICAgICAgICAgICAgIChsYW1iZGEgKG0pIChmb3JtYXQg IlxcKCVzXFwpIiAod2lsZGNhcmQtdG8tcmVnZXhwIG0pKSkKKyAgICAgICAgICAgICAgIChh cHBlbmQgYmFja2VuZC1tYXJrZXJzIHByb2plY3QtdmMtZXh0cmEtcm9vdC1tYXJrZXJzKQor ICAgICAgICAgICAgICAgIlxcfCIpKQorICAgICAgICAgICAgIChsb2NhdGUtZG9taW5hdGlu Zy1zdG9wLWRpci1yZWdleHAKKyAgICAgICAgICAgICAgKG9yIHZjLWlnbm9yZS1kaXItcmVn ZXhwIGxvY2F0ZS1kb21pbmF0aW5nLXN0b3AtZGlyLXJlZ2V4cCkpCisgICAgICAgICAgICAg bGFzdC1tYXRjaGVzCiAgICAgICAgICAgICAgKHJvb3QKLSAgICAgICAgICAgICAgKHBjYXNl IGJhY2tlbmQKLSAgICAgICAgICAgICAgICAoJ0dpdAotICAgICAgICAgICAgICAgICA7OyBE b24ndCBzdG9wIGF0IHN1Ym1vZHVsZSBib3VuZGFyeS4KLSAgICAgICAgICAgICAgICAgKG9y ICh2Yy1maWxlLWdldHByb3AgZGlyICdwcm9qZWN0LWdpdC1yb290KQotICAgICAgICAgICAg ICAgICAgICAgKGxldCAoKHJvb3QgKHZjLWNhbGwtYmFja2VuZCBiYWNrZW5kICdyb290IGRp cikpKQotICAgICAgICAgICAgICAgICAgICAgICAodmMtZmlsZS1zZXRwcm9wCi0gICAgICAg ICAgICAgICAgICAgICAgICBkaXIgJ3Byb2plY3QtZ2l0LXJvb3QKLSAgICAgICAgICAgICAg ICAgICAgICAgIChpZiAoYW5kCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IEZJ WE1FOiBJbnZhbGlkYXRlIHRoZSBjYWNoZSB3aGVuIHRoZSB2YWx1ZQotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA7OyBvZiB0aGlzIHZhcmlhYmxlIGNoYW5nZXMuCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHByb2plY3QtdmMtbWVyZ2Utc3VibW9kdWxlcwotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAocHJvamVjdC0tc3VibW9kdWxlLXAgcm9vdCkp Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxldCogKChwYXJlbnQgKGZpbGUtbmFt ZS1kaXJlY3RvcnkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGRpcmVjdG9yeS1maWxlLW5hbWUgcm9vdCkpKSkKLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICh2Yy1jYWxsLWJhY2tlbmQgYmFja2VuZCAncm9vdCBwYXJlbnQpKQotICAg ICAgICAgICAgICAgICAgICAgICAgICByb290KSkpKSkKLSAgICAgICAgICAgICAgICAoJ25p bCBuaWwpCi0gICAgICAgICAgICAgICAgKF8gKGlnbm9yZS1lcnJvcnMgKHZjLWNhbGwtYmFj a2VuZCBiYWNrZW5kICdyb290IGRpcikpKSkpCisgICAgICAgICAgICAgIChsb2NhdGUtZG9t aW5hdGluZy1maWxlCisgICAgICAgICAgICAgICBkaXIKKyAgICAgICAgICAgICAgIChsYW1i ZGEgKGQpCisgICAgICAgICAgICAgICAgIChzZXRxIGxhc3QtbWF0Y2hlcyAoZGlyZWN0b3J5 LWZpbGVzIGQgbmlsIG1hcmtlci1yZSB0IDEwMCkpKSkpCisgICAgICAgICAgICAgKGJhY2tl bmQKKyAgICAgICAgICAgICAgKGNsLWZpbmQtaWYKKyAgICAgICAgICAgICAgIChsYW1iZGEg KGIpCisgICAgICAgICAgICAgICAgIChtZW1iZXIgKGFzc29jLWRlZmF1bHQgYiBiYWNrZW5k LW1hcmtlcnMtYWxpc3QpCisgICAgICAgICAgICAgICAgICAgICAgICAgbGFzdC1tYXRjaGVz KSkKKyAgICAgICAgICAgICAgIHZjLWhhbmRsZWQtYmFja2VuZHMpKQogICAgICAgICAgICAg IHByb2plY3QpCisgICAgICAgICh3aGVuIChhbmQKKyAgICAgICAgICAgICAgIChlcSBiYWNr ZW5kICdHaXQpCisgICAgICAgICAgICAgICBwcm9qZWN0LXZjLW1lcmdlLXN1Ym1vZHVsZXMK KyAgICAgICAgICAgICAgIChwcm9qZWN0LS1zdWJtb2R1bGUtcCByb290KSkKKyAgICAgICAg ICAobGV0KiAoKHBhcmVudCAoZmlsZS1uYW1lLWRpcmVjdG9yeSAoZGlyZWN0b3J5LWZpbGUt bmFtZSByb290KSkpKQorICAgICAgICAgICAgKHNldHEgcm9vdCAodmMtY2FsbC1iYWNrZW5k ICdHaXQgJ3Jvb3QgcGFyZW50KSkpKQogICAgICAgICAod2hlbiByb290CiAgICAgICAgICAg KHNldHEgcHJvamVjdCAobGlzdCAndmMgYmFja2VuZCByb290KSkKICAgICAgICAgICA7OyBG SVhNRTogQ2FjaGUgZm9yIGEgc2hvcnRlciB0aW1lLgpAQCAtNjI2LDcgKzY3NCw4IEBAIHBy b2plY3QtaWdub3JlcwogICAobGV0KiAoKHJvb3QgKG50aCAyIHByb2plY3QpKQogICAgICAg ICAgYmFja2VuZCkKICAgICAoYXBwZW5kCi0gICAgICh3aGVuIChmaWxlLWVxdWFsLXAgZGly IHJvb3QpCisgICAgICh3aGVuIChhbmQgYmFja2VuZAorICAgICAgICAgICAgICAgIChmaWxl LWVxdWFsLXAgZGlyIHJvb3QpKQogICAgICAgIChzZXRxIGJhY2tlbmQgKGNhZHIgcHJvamVj dCkpCiAgICAgICAgKGRlbHEKICAgICAgICAgbmlsCg== --------------lmSlsjVzAZCnaqu0tS0FAyys-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 01:45:51 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 06:45:51 +0000 Received: from localhost ([127.0.0.1]:41945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozBQF-0006qk-7Q for submit@debbugs.gnu.org; Sun, 27 Nov 2022 01:45:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozBQB-0006qe-Ly for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 01:45:49 -0500 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 1ozBQ1-0004a4-Kg; Sun, 27 Nov 2022 01:45:38 -0500 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=CrpYgqfmHIRO76+VLHi9Nlc86h2xS3iupvsgrbc+Dlo=; b=IYQMzsmGbHKG TPnakNEwkQwQVBWB2nqQ/pty665KbKFJH4dQ9A/M2G31eu94h75fCp7JzfAcGpTEDhn3/oLSxK/6u uQMsmqZK4qzVRBAKRVUCoPnYUmv05UaUQ9MPFy3GfQ8IhbndRyCbXIfjQPEuoPDgRx0P9JQaMIrSm br61gXxPAeJSxyjqBGn8k4pp5UOdVcSkaOs92c6kBV70hEOLoobWgCT/bHHw5XY/7XB8Z2D6rM9fZ CAZ+yGqNdD+S7tzfDnGWTEJVo/PvXsKb0/sECZ4zIlGeFxtX81ybZ0fqxqFWsBdc2Fqx/Cmsi24IQ j0q6bueqPNgMjUSSta4+9w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozBQ0-0006E5-PY; Sun, 27 Nov 2022 01:45:37 -0500 Date: Sun, 27 Nov 2022 08:46:03 +0200 Message-Id: <83fse4rj2s.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> (message from Dmitry Gutov on Sun, 27 Nov 2022 03:08:04 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Sun, 27 Nov 2022 03:08:04 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > salutis@me.com, joaotavora@gmail.com, manuel.uberti@inventati.org, > juri@linkov.net, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > >>> "These will be used" how? This crucial information is sorely missing from > >>> this description. Likewise, how "markers" that are not files are used and > >>> are useful? > >> > > [...] > > Thanks, but I meant for at least some of the above to be in the doc strings > > and/or explained here in plain English. Readers aren't supposed to search > > bug reports for relevant information. (And for me personally, this means I > > won't be able to look up the relevant information before at least another > > week or two, which is a pity.) > > The links were meant to illustrate that most people Cc'd probably > understand the context already (modulo some forgetting because time has > passed). > > And either way I'm probably too close to the problem to understand > easily what is clear to the average user and what is not. That's why > questions are always useful. > > I've added the examples to the docstring and rephrased it a little. Does > it read better now? Sorry, no. My basic question "how are these markers used?" is still unanswered. You seem to assume that saying "in addition to regular directory markers such as .git, .hg" explains it, but it doesn't, because how the "regular directory markers" are used is still a mystery. And the purpose of the markers according to the doc string, viz.: List of additional markers to signal project roots. doesn't help enough, since "signal project roots" is too vague and abstract. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 09:10:13 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 14:10:13 +0000 Received: from localhost ([127.0.0.1]:42325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozIMH-00057X-F4 for submit@debbugs.gnu.org; Sun, 27 Nov 2022 09:10:13 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:47013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozIMF-00057Q-FB for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 09:10:11 -0500 Received: by mail-wr1-f51.google.com with SMTP id h11so5783875wrw.13 for <41572@debbugs.gnu.org>; Sun, 27 Nov 2022 06:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=CNFzc7YqNZ0wDYrGfRA7frXcT0D97Pb1qiEANKlPWGc=; b=bPRZHznPEQ+WPDDuguNCmJxvH0ic108bbyR2QwV2Mjh51AcJCH/5qSdDVcFMUXXoma pB76R0UlDfSUie9dJVGK3VMVZ6RFTLO2LxAI/dH2wsYbqjJOrXUyr6d6vYs9EAjVen+v yEyhiKlr5LDthg726V2Zg6pzUwN6Bnd88eVqiQ46Io3kkkHfdRjwxH+KUidyRDe6uMwp IWHFglZBgG/ipq4rfM5fK3VDRyg5kLuGn89NN2GAFYEC7yebOzNSwcNlhM6DjwiRKF/6 aQN6/UkRSCWfkZz0w4tRCnHVCqgnJ6XWmMurA6gj+O6OnHcVnINv1DIw8bLwYqIcuMN5 RUMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CNFzc7YqNZ0wDYrGfRA7frXcT0D97Pb1qiEANKlPWGc=; b=CvSoG7Q1x+pYRzmFIJYSe5CJU9IZU8feehEn+gHxzomwSQcQo4ItJJ+nR1RMqvhoMB HWpj5IOLtZO7jfcIds0B0xkGFkfAbHQS9wI8zE9oghv1MNHEG7qrRw/3dxSjnt6/vSLh sdWyVj2J0P5DDSBHpV5RHeHu4qdifLOpIty5/EwGlqaylZeZkMbfyiYXuUV126wu6C+V WN4dhRd3lsulXC5Mv8gZlC0Y3X/KNpnuLCEw3OuXBX03tUxmNMRutnkbfuXtLg63M0kH J54XZenn0Ol8V6Ovicnza5fyN1Gzji0L8q/vRxvi5IrtRWSVq8mxCo4u4+Z7bBkRhru/ Tmeg== X-Gm-Message-State: ANoB5pnBoQQkDjhv2amYeMNGta8Hpoox7Zt4mbGGeI1D/WB6gN3U6Q42 nsoQY0QMxPJc0iczB3jsw8k= X-Google-Smtp-Source: AA0mqf65xNlodHFPfrAg/XHz3bTMfaPk7tC2towdXF52NRFLGSJPlZFBrL5NGxwJBB5TkN3ca3Y4lw== X-Received: by 2002:adf:e105:0:b0:236:73af:f9ad with SMTP id t5-20020adfe105000000b0023673aff9admr27765158wrz.225.1669558205657; Sun, 27 Nov 2022 06:10:05 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o33-20020a05600c512100b003cf5ec79bf9sm13120816wms.40.2022.11.27.06.10.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 06:10:04 -0800 (PST) Message-ID: <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> Date: Sun, 27 Nov 2022 16:10:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83fse4rj2s.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 08:46, Eli Zaretskii wrote: > Sorry, no. My basic question "how are these markers used?" is still > unanswered. You seem to assume that saying "in addition to regular > directory markers s [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.51 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.51 listed in list.dnswl.org] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 08:46, Eli Zaretskii wrote: > Sorry, no. My basic question "how are these markers used?" is still > unanswered. You seem to assume that saying "in addition to regular > directory markers s [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.51 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.51 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 27/11/22 08:46, Eli Zaretskii wrote: > Sorry, no. My basic question "how are these markers used?" is still > unanswered. You seem to assume that saying "in addition to regular > directory markers such as .git, .hg" explains it, but it doesn't, because > how the "regular directory markers" are used is still a mystery. And the > purpose of the markers according to the doc string, viz.: > > List of additional markers to signal project roots. > > doesn't help enough, since "signal project roots" is too vague and abstract. How about this, then? To borrow the phrasing from the very first patch in this bug: "List of additional markers to signal project roots. A marker is either a base file name or a glob pattern for such. A drectory containing such file or a file matching the pattern will be recognized as a VC project. Example values: \".dir-locals.el\", \"package.json\", \"pom.xml\", \"requirements.txt\", \"Gemfile\", \"*.gemspec\", \"autogen.sh\". These will be used in addition to regular directory markers such as \".git\", \".hg\", and so on, depending on the value of `vc-handled-backends'. It is most useful when a VC project has subdirectories inside it that need to be considered as separate projects. It can also be used for projects outside of VC repositories. In either case, their behavior will still obey the relevant variables, such as `project-vc-ignores' or `project-vc-name'." From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 09:27:08 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 14:27:08 +0000 Received: from localhost ([127.0.0.1]:42356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozIcd-0005Gb-I2 for submit@debbugs.gnu.org; Sun, 27 Nov 2022 09:27:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozIca-0005GO-Qd for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 09:27:05 -0500 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 1ozIcR-0004mR-Gf; Sun, 27 Nov 2022 09:26:55 -0500 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=sPkDBN7B+Q+vvv/5wuXpe+4YLRnB/yvZYiN1VwbK0Dg=; b=JcZN2Jb9qyhr FjaZD/arTL82EL/rYJHZ9iLb6Pd7+eK7kTPS+WTwp2AOXb9RNgHRO032Yn7BTCpkkrF7C3E8mcnbW FdcFpx+/BEVQDy/9thxOPqYNw+Rz1Sk5Qqx6Pxp8oTSWY7NS9ApU/wRSYK6Rtj8/KSfK537DGhs2f 6TDeshyA11SOvVvICKR2gAnbASXCNG2ctxODzIy3VXxvZcOwlVOid4aISkLF3JkvpU6xuRd5yD29u gxEHdxpiKwL5KT2uGU7HktgtNN7Wkp3zXZPRHl2QPpbRchnxXEhAL1ewuwCon5hrw0oGuV56CtO+s Q1nDkcKC4ddN5MmWwT+CsA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozIcO-00082H-Uc; Sun, 27 Nov 2022 09:26:53 -0500 Date: Sun, 27 Nov 2022 16:27:19 +0200 Message-Id: <83lenwpj5k.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> (message from Dmitry Gutov on Sun, 27 Nov 2022 16:10:02 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Sun, 27 Nov 2022 16:10:02 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > salutis@me.com, joaotavora@gmail.com, manuel.uberti@inventati.org, > juri@linkov.net, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > On 27/11/22 08:46, Eli Zaretskii wrote: > > Sorry, no. My basic question "how are these markers used?" is still > > unanswered. You seem to assume that saying "in addition to regular > > directory markers such as .git, .hg" explains it, but it doesn't, because > > how the "regular directory markers" are used is still a mystery. And the > > purpose of the markers according to the doc string, viz.: > > > > List of additional markers to signal project roots. > > > > doesn't help enough, since "signal project roots" is too vague and abstract. > > How about this, then? To borrow the phrasing from the very first patch > in this bug: > > "List of additional markers to signal project roots. > > A marker is either a base file name or a glob pattern for such. > > A drectory containing such file or a file matching the pattern > will be recognized as a VC project. Better, but the last sentence above should say A directory containing such a marker file or a file matching a marker pattern will be recognized as the root of a VC project. (Btw, why "VC project"? can't I use marker files for non-VC projects?) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 10:51:56 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 15:51:56 +0000 Received: from localhost ([127.0.0.1]:42795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozJwh-00067w-Rn for submit@debbugs.gnu.org; Sun, 27 Nov 2022 10:51:56 -0500 Received: from mail-wm1-f47.google.com ([209.85.128.47]:54052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozJwg-00067q-Iz for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 10:51:54 -0500 Received: by mail-wm1-f47.google.com with SMTP id p16so6868437wmc.3 for <41572@debbugs.gnu.org>; Sun, 27 Nov 2022 07:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=AeQEAb6xupqSR20hRfAetuMnFrDY+7XK5MwpUhq5Gd0=; b=jAR5a1yzWJnkmaRQuyRLO2C10lkUXz98bIOw0Ua8DQtt+gQ9MYWydr8Zu01qU1c7CQ avm6KHJg1iSyKln7PO07WA5c8GqDnKrfxhL+wwQrPGQjua1fmVH3/cFK+BiiNcBc/hhm EXnIgFjg/fDvkKUPQ30M4j5wO5SPxcKhnUhOQgK914tW7W07lRbxZhHhuDuGJVoEiAB4 umWWeZ7FGym6jGels2j+toh2svIol9cYXTdtqopKjw5i2xbYuE8TnMqH55uT376Hs2b4 qXZlDqb6deGDm0arTQSzQQiB2RU8BzPD00sL8m/4Z+7t8NGEJh2gie3ygqJkGlSfaEY8 pYNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AeQEAb6xupqSR20hRfAetuMnFrDY+7XK5MwpUhq5Gd0=; b=QxEYzZMJY3tMgGL2uesluQMwlUTEwNDdGIw1kuT7hv5lfEL9GPrzp022N39y/H24hX zuzXOplvgb52b/jU6oZOtkr85Xh4KiFbmobV+LnK/pQSZMR+/v00ltL+fHQD4RUrbcWY /SLiqJ4pu99AxegLRsbm0o2djfLObB316DYP3qCeP1E1De4pQYREQP1WQ6DHcxV2292Z VHzpz+ZqRAWiGUcCqFgDPN1v8HWbBhX6kNRtVtb/OKMtILU6brT2IuTnxXyDUddAXBNv 6ReA7RLfUJdk69G+YjZ4BiW4kCUfPLS1kIbazflqZxJaP0J29luLOUgm5ockDLDbyItF i7OQ== X-Gm-Message-State: ANoB5pkqMFh3SX6TZ3t8C20WSYi+2mZxcokFrc55owzrqwIenP3pxhvn OPiDMGMAon42X9acVDbkfog= X-Google-Smtp-Source: AA0mqf6d9HfooZ7tMyCa3acjh+e8Ne5DC0w1s0ndJopDAeDjnxRnHQPjy40PC9N5oFuZvxq2ZhYfrg== X-Received: by 2002:a05:600c:c3:b0:3c6:c0e7:88b9 with SMTP id u3-20020a05600c00c300b003c6c0e788b9mr34333145wmm.47.1669564308591; Sun, 27 Nov 2022 07:51:48 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v11-20020a5d4b0b000000b002368f6b56desm10123021wrq.18.2022.11.27.07.51.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 07:51:47 -0800 (PST) Message-ID: Date: Sun, 27 Nov 2022 17:51:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83lenwpj5k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 16:27, Eli Zaretskii wrote: > Better, but the last sentence above should say > > A directory containing such a marker file or a file matching a marker > pattern will be recognized as the r [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.47 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.47 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 16:27, Eli Zaretskii wrote: > Better, but the last sentence above should say > > A directory containing such a marker file or a file matching a marker > pattern will be recognized as the r [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.47 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.47 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 27/11/22 16:27, Eli Zaretskii wrote: > Better, but the last sentence above should say > > A directory containing such a marker file or a file matching a marker > pattern will be recognized as the root of a VC project. Okay. > (Btw, why "VC project"? can't I use marker files for non-VC projects?) Yes, you can. That's what the docstring says: "can also be used for projects outside of VC repositories". But "VC project" is a proper noun in this usage. Basically, a "VC project" is whatever value (if non-nil) that is returned by project-try-vc. It's meaningful to have some proper noun for this, because this project type has customization variables, and it's handy to be able to use them for projects outside of VC repositories as well, recognized according to the new option. Like the patch also says (and what's given me a pause in the past), that also makes "VC project" somewhat a misnomer. But I'm not sure what to call them better, and renaming a whole bunch of symbols creates a backward incompatibility after all. Even though, luckily, we've asked people not to rely on that object's internals. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 11:09:44 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 16:09:44 +0000 Received: from localhost ([127.0.0.1]:42873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozKDw-0006HZ-6C for submit@debbugs.gnu.org; Sun, 27 Nov 2022 11:09:44 -0500 Received: from mail-wr1-f43.google.com ([209.85.221.43]:44926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozKDt-0006HT-9o for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 11:09:42 -0500 Received: by mail-wr1-f43.google.com with SMTP id v1so13309300wrt.11 for <41572@debbugs.gnu.org>; Sun, 27 Nov 2022 08:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=YhRTxqaJWmqRtGVjdrM5s0MVzwlZ7yVsOw0fKuVQyJI=; b=LQkgzoGIDYfsqPpxjX9Ab2/fgReyiEiR78gWcg4D8mnLlCOofSfSl+bz5C4q8tsKmp 5NMJwkpgudpsS7RbFDwCKdekYhawXNF5QtS8fJ2fMawVaiPKlMSTHo140v/jRkkcdudu KcjHTIIr9qc7GsiHNmxbG8LeJw2wkrbF+Vqgd6YAoSMYRSmixZ6iuzCnSJowpJOSahQ5 +0f1ONYheZ44eKzWkgecRrbqaas9G/wEcwpEdlAHT/UTxqszbEc7INvw+i39YL4XAUWE /RpsVX2SGulqo6RvVS6S5qSWVXGPbfKX0GOyXg+oxwmEmz1u2sjkH2D5fj8eZh/d/UGO 9vvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YhRTxqaJWmqRtGVjdrM5s0MVzwlZ7yVsOw0fKuVQyJI=; b=fsdl8AJisXvDkhG5hdyf7qhZ6GWP3Nh32m4UXfXUCI14QDGznTM18buL1EWURGKGmO YIs/1XAiLUMt06clttEo9spFzyxJhBEeQ+eHuE6GzVjYY4bfu/EHpJiu+fuoHGIK/qE9 kbQM9R5ZWpXdFv7Im83vcxOEx87dnOqahSmCwO5PpK/gUqJBkLfZ7n5vSyocvh6Mk9sd gxYVeLDY/c8pONCO1Pe62/jkScPug2Fs6zLR51IJ40OZTAa9XMzIRF5OXVUb5Fxisien ra3Fjd4AnHIS19BBUt5PEZLx/2LZNNXE07Ro2LH1wsRLujc6BqHu+5nie5q3lDw+FNev hi5A== X-Gm-Message-State: ANoB5pmscKIdUc9Krwgirz8BRPSAqo4JnWjd+iFF2CmJOkit+cSPmoKq iKlGX1O3IkQ8a0VyAZkYYJE= X-Google-Smtp-Source: AA0mqf7jP5vvUIMHBwYjUWzQl/hEZLVsUnSAojmVw+CCtKSZwyCHtPS9IO5RRT0oHyS6NtYWe/p9lQ== X-Received: by 2002:a05:6000:60c:b0:242:10ac:6ab2 with SMTP id bn12-20020a056000060c00b0024210ac6ab2mr2947680wrb.552.1669565375357; Sun, 27 Nov 2022 08:09:35 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y7-20020a1c4b07000000b003b4c979e6bcsm15429859wma.10.2022.11.27.08.09.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 08:09:34 -0800 (PST) Content-Type: multipart/mixed; boundary="------------Lx2UeKX7OAodeSP1sCR8uITe" Message-ID: Date: Sun, 27 Nov 2022 18:09:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> From: Dmitry Gutov In-Reply-To: X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 21:23, João Távora wrote: > On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > wrote: > > > > My use case is the following: I'm interested in being a [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.43 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.43 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=c3=adn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , =?UTF-8?Q?Rudolf_Adamkovi=c4=8d?= , 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 26/11/22 21:23, João Távora wrote: > On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > wrote: > > > > My use case is the following: I'm interested in being a [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.43 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.43 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) This is a multi-part message in MIME format. --------------Lx2UeKX7OAodeSP1sCR8uITe Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 26/11/22 21:23, João Távora wrote: > On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > wrote: > > > > My use case is the following: I'm interested in being able to > designate > > projects (through various means, not only marker files) that may only > > exist inside other projects. > > You previously described your super-project and how you handled it > using > project-find-functions hook with a new element that looked for file > markers. Does this patch make that easier to do? Without writing custom > functions? > > > The example i gave did _not_ use file markers. Personally, I can't use > them. I need some elisp way. Please elaborate. Does it mean that those subprojects are chosen manually and don't have "packages.jon" or etc exactly (or that too many subprojects in that same project would, undesirably, contain the same files)? Would being able to set to absolute file names (directories) help? Or is that too awkward? Worst case, we could also add the new option from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85, the result see attached. > > I then want the C-x p family of commands > > to allow a choice of inner project or any of the associated > > super-projects. > > Please avoid mixing feature requests. I already said that "choice of > inner or outer" is out of scope for this, but it's easily > implemented on > top. > > > What good are sub and super projects without a way to take advantage of > them? If anything we should focus on the operations first. As I have demonstrated, the features are orthogonal. Let's do it piece by piece, otherwise this bug might stay open another couple of years. > I have not seen your other patch. I take it it must have had some > drawback since you superseded it with something else. But post the link, > this thread is too long. I'll look at it on Monday if I have time. That would be https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85 The downsides we have already discussed: having to customize every "super" project individually is a pain, people more often seem to prefer to use "markers", the set of which is customized once. So we have to support "markers" anyway, hence it makes sense to try to make do with them only. But here's how it would look if we try to support both approaches. --------------Lx2UeKX7OAodeSP1sCR8uITe Content-Type: text/x-patch; charset=UTF-8; name="project-vc-extra-root-markers-and-subprojects.diff" Content-Disposition: attachment; filename="project-vc-extra-root-markers-and-subprojects.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IDViODY0ODAzMWZiLi4wNWJhNjMxZTUyZiAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC02Niw2ICs2Niw5IEBACiA7OyBmaWxlcywgYnV0IHN1cHBvcnRzIGFkZGl0 aW9ucyB0byB0aGUgbGlzdCB1c2luZyB0aGUgdXNlciBvcHRpb24KIDs7IGBwcm9qZWN0LXZj LWlnbm9yZXMnICh1c3VhbGx5IHRocm91Z2ggLmRpci1sb2NhbHMuZWwpLgogOzsKKzs7IEF0 IHRoaXMgcG9pbnQgdGhlIG5hbWUgbWlnaHQgYXMgd2VsbCBiZSBhbiBhYmJyZXZpYXRpb24g Zm9yICJWQyBhbmQKKzs7IEV0YyIsIHNlZSB0aGUgdmFyaWFibGUgYHByb2plY3QtdmMtZXh0 cmEtcm9vdC1tYXJrZXJzJy4KKzs7CiA7OyBVdGlsczoKIDs7CiA7OyBgcHJvamVjdC1jb21i aW5lLWRpcmVjdG9yaWVzJyBhbmQgYHByb2plY3Qtc3VidHJhY3QtZGlyZWN0b3JpZXMnLApA QCAtNDExLDYgKzQxNCw1MSBAQCBwcm9qZWN0LXZjLW5hbWUKICAgOnZlcnNpb24gIjI5LjEi CiAgIDpzYWZlICMnc3RyaW5ncCkKIAorOzsgTm90IHVzaW5nIHJlZ2V4cHMgYmVjYXVzZSB0 aGVzZSB3b3VsZG4ndCB3b3JrIGluIEdpdCBwYXRoc3BlY3MsIGluCis7OyBjYXNlIHdlIGRl Y2lkZSB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gbGlzdCBzdWJwcm9qZWN0cy4KKyhkZWZjdXN0 b20gcHJvamVjdC12Yy1leHRyYS1yb290LW1hcmtlcnMgbmlsCisgICJMaXN0IG9mIGFkZGl0 aW9uYWwgbWFya2VycyB0byBzaWduYWwgcHJvamVjdCByb290cy4KKworQSBtYXJrZXIgaXMg ZWl0aGVyIGEgYmFzZSBmaWxlIG5hbWUgb3IgYSBnbG9iIHBhdHRlcm4gZm9yIHN1Y2guCisK K0EgZGlyZWN0b3J5IGNvbnRhaW5pbmcgc3VjaCBhIG1hcmtlciBmaWxlIG9yIGEgZmlsZSBt YXRjaGluZyBhCittYXJrZXIgcGF0dGVybiB3aWxsIGJlIHJlY29nbml6ZWQgYXMgdGhlIHJv b3Qgb2YgYSBWQyBwcm9qZWN0LgorCitFeGFtcGxlIHZhbHVlczogXCIuZGlyLWxvY2Fscy5l bFwiLCBcInBhY2thZ2UuanNvblwiLCBcInBvbS54bWxcIiwKK1wicmVxdWlyZW1lbnRzLnR4 dFwiLCBcIkdlbWZpbGVcIiwgXCIqLmdlbXNwZWNcIiwgXCJhdXRvZ2VuLnNoXCIuCisKK1Ro ZXNlIHdpbGwgYmUgdXNlZCBpbiBhZGRpdGlvbiB0byByZWd1bGFyIGRpcmVjdG9yeSBtYXJr ZXJzIHN1Y2gKK2FzIFwiLmdpdFwiLCBcIi5oZ1wiLCBhbmQgc28gb24sIGRlcGVuZGluZyBv biB0aGUgdmFsdWUgb2YKK2B2Yy1oYW5kbGVkLWJhY2tlbmRzJy4gIEl0IGlzIG1vc3QgdXNl ZnVsIHdoZW4gYSBWQyBwcm9qZWN0IGhhcworc3ViZGlyZWN0b3JpZXMgaW5zaWRlIGl0IHRo YXQgbmVlZCB0byBiZSBjb25zaWRlcmVkIGFzIHNlcGFyYXRlCitwcm9qZWN0cy4gIEl0IGNh biBhbHNvIGJlIHVzZWQgZm9yIHByb2plY3RzIG91dHNpZGUgb2YgVkMKK3JlcG9zaXRvcmll cy4KKworSW4gZWl0aGVyIGNhc2UsIHRoZWlyIGJlaGF2aW9yIHdpbGwgc3RpbGwgb2JleSB0 aGUgcmVsZXZhbnQKK3ZhcmlhYmxlcywgc3VjaCBhcyBgcHJvamVjdC12Yy1pZ25vcmVzJyBv ciBgcHJvamVjdC12Yy1uYW1lJy4iCisgIDp0eXBlICdsaXN0CisgIDp2ZXJzaW9uICIyOS4x IgorICA6c2FmZSAobGFtYmRhICh2YWwpIChhbmQgKGxpc3RwIHZhbCkgKGNsLWV2ZXJ5ICMn c3RyaW5ncCB2YWwpKSkpCisKKyhkZWZjdXN0b20gcHJvamVjdC12Yy1zdWJwcm9qZWN0cyBu aWwKKyAgIkxpc3Qgb2YgcmVsYXRpdmUgZGlyZWN0b3J5IG5hbWVzIHRvIGNvbnNpZGVyIHNl cGFyYXRlIHByb2plY3RzLgorRWFjaCBlbnRyeSBzaG91bGQgYSBzdHJpbmcsIG5hbWUgb2Yg YSBzdWJwcm9qZWN0IHJvb3QgZGlyZWN0b3J5CityZWxhdGl2ZSB0byB0aGUgVkMgcHJvamVj dCByb290LgorCitXaGVuZXZlciBhIFZDIHByb2plY3Qgcm9vdCBkZXRlY3RlZCBhY2NvcmRp bmcgdG8gdGhlIHVzdWFsCitjb25kaXRpb25zIGNvbnRhaW5zIGEgc3ViZGlyZWN0b3J5IGZy b20gdGhhdCBsaXN0LCB0aGF0CitzdWJkaXJlY3Rvcnkgd2lsbCBiZSByZWNvZ25pemVkIGFz IHRoZSByb290IG9mIGEgc2VwYXJhdGUgVkMKK3Byb2plY3QgYXMgd2VsbC4KKworT25lIHdv dWxkIHVzdWFsbHkgc2V0IHRoaXMgdmFyaWFibGUgdGhyb3VnaCB0aGUgZGlyLWxvY2Fscwor bWVjaGFuaXNtLgorCitJZiBzdWJwcm9qZWN0cyBhcmUgR2l0IHN1Ym1vZHVsZXMsIHlvdSBj YW4gdXNlIHRoZSB2YXJpYWJsZQorYHByb2plY3QtdmMtbWVyZ2Utc3VibW9kdWxlcycgaW5z dGVhZC4iCisgIDp0eXBlICdsaXN0CisgIDp2ZXJzaW9uICIyOS4xIgorICA6c2FmZSAobGFt YmRhICh2YWwpIChhbmQgKGxpc3RwIHZhbCkgKHNlcS1ldmVyeS1wICMnc3RyaW5ncCB2YWwp KSkpCisKIDs7IEZJWE1FOiBVc2luZyB0aGUgY3VycmVudCBhcHByb2FjaCwgbWFqb3IgbW9k ZXMgYXJlIHN1cHBvc2VkIHRvIHNldAogOzsgdGhpcyB2YXJpYWJsZSB0byBhIGJ1ZmZlci1s b2NhbCB2YWx1ZS4gIFNvIHdlIGRvbid0IGhhdmUgYWNjZXNzIHRvCiA7OyB0aGUgImV4dGVy bmFsIHJvb3RzIiBvZiBsYW5ndWFnZSBBIGZyb20gYnVmZmVycyBvZiBsYW5ndWFnZSBCLCB3 aGljaApAQCAtNDQ3LDI5ICs0OTUsNTkgQEAgcHJvamVjdC12Yy1leHRlcm5hbC1yb290cy1m dW5jdGlvbgogYmFja2VuZCBpbXBsZW1lbnRhdGlvbiBvZiBgcHJvamVjdC1leHRlcm5hbC1y b290cycuIikKIAogKGRlZnVuIHByb2plY3QtdHJ5LXZjIChkaXIpCisgIChkZWZ2YXIgdmMt c3ZuLWFkbWluLWRpcmVjdG9yeSkKKyAgKHJlcXVpcmUgJ3ZjLXN2bikKKyAgOzsgRklYTUU6 IExlYXJuIHRvIGludmFsaWRhdGUgd2hlbiB0aGUgdmFsdWUgb2YKKyAgOzsgYHByb2plY3Qt dmMtbWVyZ2Utc3VibW9kdWxlcycgb3IgYHByb2plY3QtdmMtZXh0cmEtcm9vdC1tYXJrZXJz JworICA7OyBjaGFuZ2VzLgogICAob3IgKHZjLWZpbGUtZ2V0cHJvcCBkaXIgJ3Byb2plY3Qt dmMpCi0gICAgICAobGV0KiAoKGJhY2tlbmQgKGlnbm9yZS1lcnJvcnMgKHZjLXJlc3BvbnNp YmxlLWJhY2tlbmQgZGlyKSkpCisgICAgICAobGV0KiAoKGJhY2tlbmQtbWFya2Vycy1hbGlz dCBgKChHaXQgLiAiLmdpdCIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChIZyAuICIuaGciKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoQnpyIC4gIi5ienIiKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoU1ZOIC4gLHZjLXN2bi1hZG1pbi1kaXJlY3RvcnkpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIChEQVJDUyAuICJfZGFyY3MiKQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoRm9zc2lsIC4gIi5mc2xja291dCIpKSkKKyAgICAg ICAgICAgICAoYmFja2VuZC1tYXJrZXJzCisgICAgICAgICAgICAgIChkZWxldGUKKyAgICAg ICAgICAgICAgIG5pbAorICAgICAgICAgICAgICAgKG1hcGNhcgorICAgICAgICAgICAgICAg IChsYW1iZGEgKGIpIChhc3NvYy1kZWZhdWx0IGIgYmFja2VuZC1tYXJrZXJzLWFsaXN0KSkK KyAgICAgICAgICAgICAgICB2Yy1oYW5kbGVkLWJhY2tlbmRzKSkpCisgICAgICAgICAgICAg KG1hcmtlci1yZQorICAgICAgICAgICAgICAobWFwY29uY2F0CisgICAgICAgICAgICAgICAo bGFtYmRhIChtKSAoZm9ybWF0ICJcXCglc1xcKSIgKHdpbGRjYXJkLXRvLXJlZ2V4cCBtKSkp CisgICAgICAgICAgICAgICAoYXBwZW5kIGJhY2tlbmQtbWFya2VycyBwcm9qZWN0LXZjLWV4 dHJhLXJvb3QtbWFya2VycykKKyAgICAgICAgICAgICAgICJcXHwiKSkKKyAgICAgICAgICAg ICAobG9jYXRlLWRvbWluYXRpbmctc3RvcC1kaXItcmVnZXhwCisgICAgICAgICAgICAgIChv ciB2Yy1pZ25vcmUtZGlyLXJlZ2V4cCBsb2NhdGUtZG9taW5hdGluZy1zdG9wLWRpci1yZWdl eHApKQorICAgICAgICAgICAgIGxhc3QtbWF0Y2hlcwogICAgICAgICAgICAgIChyb290Ci0g ICAgICAgICAgICAgIChwY2FzZSBiYWNrZW5kCi0gICAgICAgICAgICAgICAgKCdHaXQKLSAg ICAgICAgICAgICAgICAgOzsgRG9uJ3Qgc3RvcCBhdCBzdWJtb2R1bGUgYm91bmRhcnkuCi0g ICAgICAgICAgICAgICAgIChvciAodmMtZmlsZS1nZXRwcm9wIGRpciAncHJvamVjdC1naXQt cm9vdCkKLSAgICAgICAgICAgICAgICAgICAgIChsZXQgKChyb290ICh2Yy1jYWxsLWJhY2tl bmQgYmFja2VuZCAncm9vdCBkaXIpKSkKLSAgICAgICAgICAgICAgICAgICAgICAgKHZjLWZp bGUtc2V0cHJvcAotICAgICAgICAgICAgICAgICAgICAgICAgZGlyICdwcm9qZWN0LWdpdC1y b290Ci0gICAgICAgICAgICAgICAgICAgICAgICAoaWYgKGFuZAotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA7OyBGSVhNRTogSW52YWxpZGF0ZSB0aGUgY2FjaGUgd2hlbiB0aGUg dmFsdWUKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOzsgb2YgdGhpcyB2YXJpYWJs ZSBjaGFuZ2VzLgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9qZWN0LXZjLW1l cmdlLXN1Ym1vZHVsZXMKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHByb2plY3Qt LXN1Ym1vZHVsZS1wIHJvb3QpKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsZXQq ICgocGFyZW50IChmaWxlLW5hbWUtZGlyZWN0b3J5Ci0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChkaXJlY3RvcnktZmlsZS1uYW1lIHJvb3QpKSkpCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodmMtY2FsbC1iYWNrZW5kIGJhY2tlbmQg J3Jvb3QgcGFyZW50KSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgcm9vdCkpKSkpCi0g ICAgICAgICAgICAgICAgKCduaWwgbmlsKQotICAgICAgICAgICAgICAgIChfIChpZ25vcmUt ZXJyb3JzICh2Yy1jYWxsLWJhY2tlbmQgYmFja2VuZCAncm9vdCBkaXIpKSkpKQorICAgICAg ICAgICAgICAobG9jYXRlLWRvbWluYXRpbmctZmlsZQorICAgICAgICAgICAgICAgZGlyCisg ICAgICAgICAgICAgICAobGFtYmRhIChkKQorICAgICAgICAgICAgICAgICAoc2V0cSBsYXN0 LW1hdGNoZXMgKGRpcmVjdG9yeS1maWxlcyBkIG5pbCBtYXJrZXItcmUgdCAxMDApKSkpKQor ICAgICAgICAgICAgIChiYWNrZW5kCisgICAgICAgICAgICAgIChjbC1maW5kLWlmCisgICAg ICAgICAgICAgICAobGFtYmRhIChiKQorICAgICAgICAgICAgICAgICAobWVtYmVyIChhc3Nv Yy1kZWZhdWx0IGIgYmFja2VuZC1tYXJrZXJzLWFsaXN0KQorICAgICAgICAgICAgICAgICAg ICAgICAgIGxhc3QtbWF0Y2hlcykpCisgICAgICAgICAgICAgICB2Yy1oYW5kbGVkLWJhY2tl bmRzKSkKICAgICAgICAgICAgICBwcm9qZWN0KQorICAgICAgICAod2hlbiAoYW5kCisgICAg ICAgICAgICAgICAoZXEgYmFja2VuZCAnR2l0KQorICAgICAgICAgICAgICAgcHJvamVjdC12 Yy1tZXJnZS1zdWJtb2R1bGVzCisgICAgICAgICAgICAgICAocHJvamVjdC0tc3VibW9kdWxl LXAgcm9vdCkpCisgICAgICAgICAgKGxldCogKChwYXJlbnQgKGZpbGUtbmFtZS1kaXJlY3Rv cnkgKGRpcmVjdG9yeS1maWxlLW5hbWUgcm9vdCkpKSkKKyAgICAgICAgICAgIChzZXRxIHJv b3QgKHZjLWNhbGwtYmFja2VuZCAnR2l0ICdyb290IHBhcmVudCkpKSkKICAgICAgICAgKHdo ZW4gcm9vdAorICAgICAgICAgIChsZXQqICgocmVsYXRpdmUtZGlyIChmaWxlLXJlbGF0aXZl LW5hbWUgZGlyIHJvb3QpKQorICAgICAgICAgICAgICAgICAoc3VicHJvamVjdCAoc2VxLWZp bmQKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHN1Yi1kaXIpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmctcHJlZml4LXAgKGZpbGUt bmFtZS1hcy1kaXJlY3Rvcnkgc3ViLWRpcikKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZWxhdGl2ZS1kaXIpKQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJvamVjdC12Yy1zdWJwcm9qZWN0cykpKQorICAgICAgICAgICAg KGFuZCBzdWJwcm9qZWN0CisgICAgICAgICAgICAgICAgIChzZXRxIHJvb3QgKGNvbmNhdCBy b290IHN1YnByb2plY3QpKSkpCiAgICAgICAgICAgKHNldHEgcHJvamVjdCAobGlzdCAndmMg YmFja2VuZCByb290KSkKICAgICAgICAgICA7OyBGSVhNRTogQ2FjaGUgZm9yIGEgc2hvcnRl ciB0aW1lLgogICAgICAgICAgICh2Yy1maWxlLXNldHByb3AgZGlyICdwcm9qZWN0LXZjIHBy b2plY3QpCkBAIC02MjYsNyArNzA0LDggQEAgcHJvamVjdC1pZ25vcmVzCiAgIChsZXQqICgo cm9vdCAobnRoIDIgcHJvamVjdCkpCiAgICAgICAgICBiYWNrZW5kKQogICAgIChhcHBlbmQK LSAgICAgKHdoZW4gKGZpbGUtZXF1YWwtcCBkaXIgcm9vdCkKKyAgICAgKHdoZW4gKGFuZCBi YWNrZW5kCisgICAgICAgICAgICAgICAgKGZpbGUtZXF1YWwtcCBkaXIgcm9vdCkpCiAgICAg ICAgKHNldHEgYmFja2VuZCAoY2FkciBwcm9qZWN0KSkKICAgICAgICAoZGVscQogICAgICAg ICBuaWwK --------------Lx2UeKX7OAodeSP1sCR8uITe-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 11:43:45 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 16:43:45 +0000 Received: from localhost ([127.0.0.1]:43017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozKkr-0006XV-Cr for submit@debbugs.gnu.org; Sun, 27 Nov 2022 11:43:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozKko-0006XO-FX for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 11:43:43 -0500 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 1ozKke-0003IV-EP; Sun, 27 Nov 2022 11:43:32 -0500 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=49+EjfpdHVFHFhwLL1E2eJAcy6nXoZOhT4T1W9pxSDE=; b=f4kBbhKkhw3I AYqP4jcrkjS4bn3cpMGTR+zJfuAci2AQe2xRhCKpqOwh4LfsTpQOffkbvqZrTHGCLWVBZbI2C97Tv 9rwLVxWohviC0h3r6vVJkm2yh8Yl01f5RNkzXi7eG6R1+BK/OdOtwRVBJQGHnup/MRcx8h81g6QyQ od+KJ9pLVxdSxeisQdMabVzGlflQPh12+HsNgIfsjgqfiPZ1a6Z8GeAovG8HW8/iKvVAcn1wO20EJ xka5CcpEs1e9wWh/ZEKSG3aWn+MJsSNFxJY0S5G6SP1RZrQEY5zUAqCkfFtFlyeGT+Hh3eyXGPwSO tymhU8OcMixeC7MGILKf0Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozKkd-0002tn-Ub; Sun, 27 Nov 2022 11:43:32 -0500 Date: Sun, 27 Nov 2022 18:43:58 +0200 Message-Id: <83fse4pctt.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 27 Nov 2022 17:51:45 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Sun, 27 Nov 2022 17:51:45 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > On 27/11/22 16:27, Eli Zaretskii wrote: > > > (Btw, why "VC project"? can't I use marker files for non-VC projects?) > > Yes, you can. That's what the docstring says: "can also be used for > projects outside of VC repositories". > > But "VC project" is a proper noun in this usage. Basically, a "VC > project" is whatever value (if non-nil) that is returned by project-try-vc. Then maybe change that to something like A directory containing such a marker file or a file matching a marker pattern will be recognized as the root of a project whose type is "VC project". The point of this is to tell that those markers indicate projects whose type just happens to be "VC project". Otherwise the above could be interpreted that the markers can be used only inside VC projects. > Like the patch also says (and what's given me a pause in the past), that > also makes "VC project" somewhat a misnomer. But I'm not sure what to > call them better How about VC-backed project? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 27 16:42:11 2022 Received: (at 41572) by debbugs.gnu.org; 27 Nov 2022 21:42:11 +0000 Received: from localhost ([127.0.0.1]:44369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozPPe-00013z-Pw for submit@debbugs.gnu.org; Sun, 27 Nov 2022 16:42:11 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozPPc-00013t-0G for 41572@debbugs.gnu.org; Sun, 27 Nov 2022 16:42:09 -0500 Received: by mail-wr1-f45.google.com with SMTP id q7so13171330wrr.8 for <41572@debbugs.gnu.org>; Sun, 27 Nov 2022 13:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=N4FK65tX1hdX+aU3FxjL+17rkN5jp2jzHtwkpdTOKNU=; b=arSflOq9AcsIUGzTlNMgPPtmcckZqfb9xyUPd27OfcTSm7ZEibDk37oRacCq2MGuCx AVgH03baLKZDfMXGVUeiybNxviNsGJIx9fgwZf/8iHpXrSmOIoVvHdzdBoEvjYGEHcja oGBfYo1xpzmG+dCIDsk9G6o7vWhv05gToxQWgMP7F4j7DAFP5mqvBVPf7sPpioEhVj0P iaF8mbnlkoZSjcly6mj7PYNw/PM0mRTUa0fzxtQP+bL+JkWzvidmQcXeGO4T8U0hC0YE xu6NM2T1/oYURpa6qPIvMHoUKzREXEzDU6qBsWggINFauPfXkxrXbai22eObb8HEtYtU XmmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N4FK65tX1hdX+aU3FxjL+17rkN5jp2jzHtwkpdTOKNU=; b=E5BJcBfFA2cMeGOmPbw9mfSCgUhydcBneGZ1Cx3ooZ8l0Tl66/AOiu4r7CkkNg7gVa uinQlBGwYzcDOdpjS2D5hN+Y3pgcRiOLT9u9xna6RUHKWCZk8tqoK0mrg/LtXPfG6MJH BaputiFVNFveAiXEwXIFA1eZks+0qfsaqMjRrQv8LBC1BLZwV6yySzELHzWKgQ7gOJcH C9OvXEFoHLYdq3BkDcxr0le/PzHX+dpK2M3dxwXtrHUqN3HqaIbf6khaVPoW+vtgY9G2 1bLZTa+XlnXUoruv8HSbkDui7XcP1Rkwm3TbCil6p4SdCRCmq6Dx4nbgBJWizy9R2wa/ cWvQ== X-Gm-Message-State: ANoB5pmqhMGmx7LYJFn3LbjqREJoQuNDNs7zjaw6C6mNpw3pvROSEQFN CYtOqxYmGiPTjv/Lws7fPa8= X-Google-Smtp-Source: AA0mqf4do0aPYsV3elFKHAbFW8H4EbGYUCf2TxRg362Z2cfMBkCMPyNOZ8dJAcliRXMuHWeAFd0vig== X-Received: by 2002:adf:f352:0:b0:241:fd11:dcd with SMTP id e18-20020adff352000000b00241fd110dcdmr10716134wrp.706.1669585321967; Sun, 27 Nov 2022 13:42:01 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n16-20020a05600c501000b003c21ba7d7d6sm12869838wmr.44.2022.11.27.13.42.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Nov 2022 13:42:01 -0800 (PST) Message-ID: Date: Sun, 27 Nov 2022 23:41:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83fse4pctt.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 18:43, Eli Zaretskii wrote: >> Date: Sun, 27 Nov 2022 17:51:45 +0200 >> Cc:philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardan [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 27/11/22 18:43, Eli Zaretskii wrote: >> Date: Sun, 27 Nov 2022 17:51:45 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardan [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 27/11/22 18:43, Eli Zaretskii wrote: >> Date: Sun, 27 Nov 2022 17:51:45 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardani29@yahoo.es, >> joaotavora@gmail.com,manuel.uberti@inventati.org,juri@linkov.net, >> salutis@me.com,arstoffel@gmail.com,41572@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 27/11/22 16:27, Eli Zaretskii wrote: >> >>> (Btw, why "VC project"? can't I use marker files for non-VC projects?) >> Yes, you can. That's what the docstring says: "can also be used for >> projects outside of VC repositories". >> >> But "VC project" is a proper noun in this usage. Basically, a "VC >> project" is whatever value (if non-nil) that is returned by project-try-vc. > Then maybe change that to something like > > A directory containing such a marker file or a file matching a marker > pattern will be recognized as the root of a project whose type is > "VC project". If you say quote help, it's fine by me. > The point of this is to tell that those markers indicate projects whose type > just happens to be "VC project". Otherwise the above could be interpreted > that the markers can be used only inside VC projects. Sure. >> Like the patch also says (and what's given me a pause in the past), that >> also makes "VC project" somewhat a misnomer. But I'm not sure what to >> call them better > How about VC-backed project? Is that different? I would say it might be worse: "VC-backed" sounds like a project that must correspond to a VC repository (be "backed" by it). OTOH a new term we could use would stand for something like: a project type which will recognize the enabled kinds of VC repositories and use their roots as project root, and knows how to use certain VC systems to speed up the fetching of files, and knows about Git submodules, but also recognizes other directories (inside or outside of VC repositories) based on configurable conditions. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 06:58:20 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 11:58:20 +0000 Received: from localhost ([127.0.0.1]:48126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozcmB-00019k-GI for submit@debbugs.gnu.org; Mon, 28 Nov 2022 06:58:20 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozcm9-00019e-Q8 for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 06:58:18 -0500 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 1ozcly-00041E-Sf; Mon, 28 Nov 2022 06:58:06 -0500 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=R39K3Q5rWHUcc9aLSp4jgnzjDZFel98uxKR31x4LG+I=; b=ro9bUWCTzv1u atTsLTkvJFDdyuOBgqkqgHHON8i/0R1Y0YVZ9Y/fvylEMUgBuq3ORm4b3sbzJfOIDm4W5wDuUkI10 zeyCJBsyRLZkVeXd9mAKV3MRIaA6vs+3A5ZqAR4y/oR5rn8HjRsTTys5DER2xzthyd83lLU39PZjI wsrGqCFEV+IVlDYZtsOm+RdsCrw5+Gg36VygEiN9xdxZCrk0FDKFwbRFP2vJhmULdyjLDRgh4W4md IQWTNrq0F4F6OwfpsTwx9vZl2e2ViVxZRuRIqiy3QMYDKImZL6vpoM4mN/ozN8hoaQmckXP2W+GEr pecXxjCdSIhR8HUZVLK/LQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozclx-0007g6-5e; Mon, 28 Nov 2022 06:58:05 -0500 Date: Mon, 28 Nov 2022 13:58:33 +0200 Message-Id: <8335a3p9xy.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Sun, 27 Nov 2022 23:41:59 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Sun, 27 Nov 2022 23:41:59 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > > A directory containing such a marker file or a file matching a marker > > pattern will be recognized as the root of a project whose type is > > "VC project". > > If you say quote help, it's fine by me. > > > The point of this is to tell that those markers indicate projects whose type > > just happens to be "VC project". Otherwise the above could be interpreted > > that the markers can be used only inside VC projects. > > Sure. > > >> Like the patch also says (and what's given me a pause in the past), that > >> also makes "VC project" somewhat a misnomer. But I'm not sure what to > >> call them better > > How about VC-backed project? > > Is that different? I don't know. You asked for alternatives, and that is what I could think of. > I would say it might be worse: "VC-backed" sounds > like a project that must correspond to a VC repository (be "backed" by it). It usually is, isn't it? If it doesn't have to, then we should look for a different name ASAP, one that doesn't include "VC" at all. > OTOH a new term we could use would stand for something like: a project > type which will recognize the enabled kinds of VC repositories and use > their roots as project root, and knows how to use certain VC systems to > speed up the fetching of files, and knows about Git submodules, but also > recognizes other directories (inside or outside of VC repositories) > based on configurable conditions. If this type of project doesn't have to be "backed by a VCS", then what does distinguish it from other types of projects? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 07:30:27 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 12:30:28 +0000 Received: from localhost ([127.0.0.1]:48307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozdHH-0002tl-FQ for submit@debbugs.gnu.org; Mon, 28 Nov 2022 07:30:27 -0500 Received: from mail-wm1-f46.google.com ([209.85.128.46]:52889) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozdHF-0002aT-V4 for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 07:30:26 -0500 Received: by mail-wm1-f46.google.com with SMTP id o30so8336842wms.2 for <41572@debbugs.gnu.org>; Mon, 28 Nov 2022 04:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=v7ItwFr+0qnu4MDMznCLqLa48SMOFlCzNKT+JdNVeIk=; b=H3go7euF6iGSM0IpDn54Ksxqgaz0mvwKbIaeYJEanvLll2TaprdPjlFaA1wclmicEq WBsd6oQ8vhNXWZVbaaAKw3rokOraFtzdBjF0JgojqxBStAs12by485qQLl0iITpMOAgL 2/oZwTNvwDXQkhxf1rplUNJREgAX4IjlLrmVwxwvl9IGEjb8y6Y9RRate0pLN7Cwb9R0 H/IGCodnWvkdx/dIHuxZpY+81D/To5xUar8/XmRQm5eo/xsAYFQYGUyFWMk/a3Ml8+OJ Gv9e1XzZ9PqePqlNI7PmlVOOi1469J8HL1Ot0etFnMYp5kRdvgJIDWiJprvzbwkc3eIW DMpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=v7ItwFr+0qnu4MDMznCLqLa48SMOFlCzNKT+JdNVeIk=; b=NPjdb8TYeIPNDZUVKN62n5KjZy4p/pwYxSSCDyH6JXvBU7XDN2+WdsL4QHFR6FSbN7 vk2uXoxBNfmseLBVyc/5akgfjJjSqD9JfermuvSNdYi2f9T8pZSG5g3Qdzf4FISfLofh egKJk3iFE0Dw9Z6UOLTtNn630HmDSma6Ec90PyTB7pqkaRRuoIzgWhXC3QvOZTQhXbz9 +Ub24FbkbMh2aAoXhQ+jNDkMg0tvHf6rGjZRY4cSaUAIJFnoyCedZ8yT0JDQkSvUsjqK etog7bRN+egMldGee8JCFzmstx7xP8ewoJlbE4cMyuTZID9frKeZpzKMf0EwPoVrzpNx x48w== X-Gm-Message-State: ANoB5pmpKAjy9nrqWzUtvoxHZbLYIN2JOfSDa32oRrRWk6bAKuKKMy0S Jue/TeVKO74mWfr6FTnYQ7E= X-Google-Smtp-Source: AA0mqf7KKirHzt08KEQCKSvwBLzvrVQcHnmCIUzLnrH2LxFdGDdZ2OEwzc5SvlnFO0XP3GCauxIA8Q== X-Received: by 2002:a05:600c:35cf:b0:3cf:aa11:93a8 with SMTP id r15-20020a05600c35cf00b003cfaa1193a8mr41158822wmq.31.1669638619908; Mon, 28 Nov 2022 04:30:19 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n14-20020a5d660e000000b00241bee11825sm10595181wru.103.2022.11.28.04.30.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 04:30:18 -0800 (PST) Message-ID: <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> Date: Mon, 28 Nov 2022 14:30:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project To: Eli Zaretskii References: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <8335a3p9xy.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 13:58, Eli Zaretskii wrote: >>>> Like the patch also says (and what's given me a pause in the past), that >>>> also makes "VC project" somewhat a misnomer. But I'm not sure what to >>>> call them better >>> How about VC-backed p [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.46 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.46 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 13:58, Eli Zaretskii wrote: >>>> Like the patch also says (and what's given me a pause in the past), that >>>> also makes "VC project" somewhat a misnomer. But I'm not sure what to >>>> call them better >>> How about VC-backed p [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.46 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.46 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 28/11/2022 13:58, Eli Zaretskii wrote: >>>> Like the patch also says (and what's given me a pause in the past), that >>>> also makes "VC project" somewhat a misnomer. But I'm not sure what to >>>> call them better >>> How about VC-backed project? >> >> Is that different? > > I don't know. You asked for alternatives, and that is what I could think > of. > >> I would say it might be worse: "VC-backed" sounds >> like a project that must correspond to a VC repository (be "backed" by it). > > It usually is, isn't it? Usually -- yes, the default ootb configuration will have projects backed by VC repositories, because the default set of markers is determined by the value of 'vc-handled-backends'. But now the users will be able to extend that set of markers through customization. > If it doesn't have to, then we should look for a different name ASAP, one > that doesn't include "VC" at all. I haven't been able to come up with anything more concrete than "builtin", and that's both a non-name and not exactly true since 'transient' also exists. But "VC aware" might also fit the bill. It sounds more like an adjective, though, than a proper noun. >> OTOH a new term we could use would stand for something like: a project >> type which will recognize the enabled kinds of VC repositories and use >> their roots as project root, and knows how to use certain VC systems to >> speed up the fetching of files, and knows about Git submodules, but also >> recognizes other directories (inside or outside of VC repositories) >> based on configurable conditions. > > If this type of project doesn't have to be "backed by a VCS", then what does > distinguish it from other types of projects? It difficult to come up with a name using a principle like that when the preceding effort was made to be able to accommodate the projects of different users with new usage patterns. It is "VC aware" or maybe "VC friendly", and it works with projects in the shape of directory trees. But both characterizations can apply to e.g. Projectile as well. Except the latter is probably more flexible, and our backend is probably faster, especially over Tramp. But if we just compare with the other builtin ('transient'), then its VC awareness is probably the key thing. And the customization options it has (which 'transient' doesn't). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 08:22:55 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 13:22:55 +0000 Received: from localhost ([127.0.0.1]:48580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oze63-0004Ht-6Z for submit@debbugs.gnu.org; Mon, 28 Nov 2022 08:22:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oze5t-0004HY-JR for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 08:22:49 -0500 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 1oze5l-0003Ku-2B; Mon, 28 Nov 2022 08:22:37 -0500 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=Pv/BcJ0fR5Bbe9Nj1kSg0sW6dkvBEWBMsafq2XOuSZk=; b=PKLEqcNL4zJM +MAmaYcLL/KLJCZMslxwpMM/tTAwYJmX0uXJhRsgFdPZl4a97dKkh39utckuWGmi0/KiFQmPGqLvX B2pi3o0r3qgmiervThJsGa8n1H71fQ6YJpY5zRaiilJSyjGbnkdzUo5py2hVFZ5HizInjSPuIhhsR nTv5HJ2118wb8jcngFcwRXdEjaDTKOzBF3cik7izMbBRCw61KTMkGhR3QfaLh3ml8Vl+wplohdVKO DIGHxWS5SAndod5wnmY9WbdVktD7jJZ3z9+65ZIrjj4DVFKillNyMxgIe4jG/vuliTZdC2+SZ64v/ KRyhFHfmU7hbwsPWeDhbaA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oze5e-000739-DL; Mon, 28 Nov 2022 08:22:35 -0500 Date: Mon, 28 Nov 2022 15:22:59 +0200 Message-Id: <83lenvnrgs.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> (message from Dmitry Gutov on Mon, 28 Nov 2022 14:30:15 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Mon, 28 Nov 2022 14:30:15 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > > If this type of project doesn't have to be "backed by a VCS", then what does > > distinguish it from other types of projects? > > It difficult to come up with a name using a principle like that when the > preceding effort was made to be able to accommodate the projects of > different users with new usage patterns. > > It is "VC aware" or maybe "VC friendly", and it works with projects in > the shape of directory trees. But both characterizations can apply to > e.g. Projectile as well. Except the latter is probably more flexible, > and our backend is probably faster, especially over Tramp. > > But if we just compare with the other builtin ('transient'), then its > VC awareness is probably the key thing. And the customization options it > has (which 'transient' doesn't). AFAIU, the 'transient' builtin also works with projects whose shape is a directory tree, right? If so, how is 'transient' different from the 'VC-aware' type? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 09:29:26 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 14:29:26 +0000 Received: from localhost ([127.0.0.1]:48921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozf8Q-0004rk-5m for submit@debbugs.gnu.org; Mon, 28 Nov 2022 09:29:26 -0500 Received: from mail-wr1-f50.google.com ([209.85.221.50]:38505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozf8O-0004re-KM for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 09:29:25 -0500 Received: by mail-wr1-f50.google.com with SMTP id n3so17118880wrp.5 for <41572@debbugs.gnu.org>; Mon, 28 Nov 2022 06:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=BvI70/xpmUBLKMX4Wjz/wnlUz4zeVZ+ASe7rfX+ooOQ=; b=odtAJqXHlbDZn658Pky54qfEUzPrBVtXwSurul0dDl2RNVvClYenJ47w+Ns5PTzkvL +TIF7DJMmGmmQrdzFBbcUoUvB1Nbj8B84rfisxqY29qxuUpSF6JjzOogp0VA+N4WPmlt iY0PgwfMDQ/OymLUNscfzKSLk04gaYkWGZRiOXexHRZqZXrqikyQTMjRSj+MEpb+HQsc KLsfvjbR6Yisjec3e85dT0cpamdHwSdILhVwtXTnimKghuWb2sTKP+lshWPPGT2CY6Yx 7F1FM59DresEufxxZjwaD7Dsq7vTXULGigceHEwtIebjFnt9sW3IVgFuRarxybWznuET 01ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BvI70/xpmUBLKMX4Wjz/wnlUz4zeVZ+ASe7rfX+ooOQ=; b=OFe0AICPj1Q/66tA/rleTw3zbkzev4LNqacyhLvz8p+nD4i9EOSMrwacNtf8PyR5fr ZTtSSMNxOcrekOcLTRYac6Jxt+VrxUrypWRrv/EFXjWt1Tunfva9OQTj8gP4dFXJpr+7 fka7+hu00e09SUI6UD10W0quVOkjB5v1D2SMw8KwFDUDmG+EDMj88Z03iZ5BZE3OWR0g Op9tOa69HkYy6Eb0O1I3pAcup4Q35Ph7MpDarMyZDmf98My4KSECT4BugdxBlZzyYaxi 6nE84l1fY8JK8eLByvxL3FfVlP9SAhnYPv79cs9gpgD+cmJNaD5lVdVcKTQi2fQe/Ej3 4JZw== X-Gm-Message-State: ANoB5pkQc96k3GsufRceWEVpPGLCKkAX3gqHtxOUeUJMKa7bb2fRztxo qIDOaTYq98Qr2w8NDdFtrgU= X-Google-Smtp-Source: AA0mqf5Hbq6zswgp14rVUwYBPs/b4B11Mr1zD3voeEhKyhGVtpHtx6FX2zNVYx031BbTjUpaLFFp7g== X-Received: by 2002:adf:f60d:0:b0:22e:d91a:231b with SMTP id t13-20020adff60d000000b0022ed91a231bmr32501802wrp.78.1669645758670; Mon, 28 Nov 2022 06:29:18 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j14-20020a05600c190e00b003b47e75b401sm22171170wmq.37.2022.11.28.06.29.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 06:29:17 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 16:29:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83lenvnrgs.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 15:22, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 14:30:15 +0200 >> Cc:philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.50 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.50 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 15:22, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 14:30:15 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.50 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.50 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 28/11/2022 15:22, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 14:30:15 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardani29@yahoo.es, >> joaotavora@gmail.com,manuel.uberti@inventati.org,juri@linkov.net, >> salutis@me.com,arstoffel@gmail.com,41572@debbugs.gnu.org >> From: Dmitry Gutov >> >>> If this type of project doesn't have to be "backed by a VCS", then what does >>> distinguish it from other types of projects? >> It difficult to come up with a name using a principle like that when the >> preceding effort was made to be able to accommodate the projects of >> different users with new usage patterns. >> >> It is "VC aware" or maybe "VC friendly", and it works with projects in >> the shape of directory trees. But both characterizations can apply to >> e.g. Projectile as well. Except the latter is probably more flexible, >> and our backend is probably faster, especially over Tramp. >> >> But if we just compare with the other builtin ('transient'), then its >> VC awareness is probably the key thing. And the customization options it >> has (which 'transient' doesn't). > AFAIU, the 'transient' builtin also works with projects whose shape is a > directory tree, right? If so, how is 'transient' different from the > 'VC-aware' type? That's right. So if we are comparing against 'transient' only, then VC awareness is probably the key thing. And the customization options. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 09:49:09 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 14:49:09 +0000 Received: from localhost ([127.0.0.1]:49014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozfRV-000523-AM for submit@debbugs.gnu.org; Mon, 28 Nov 2022 09:49:09 -0500 Received: from eggs.gnu.org ([209.51.188.92]:32916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozfRT-00051x-Uo for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 09:49:08 -0500 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 1ozfRM-0003HJ-MB; Mon, 28 Nov 2022 09:49:00 -0500 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=DTzbEQj6+76/NH6bSaBkkX1zBxyeyoePpEipuuhzFpc=; b=F8f+R0kLR8+V bKycq/FNldc5YUbKmna52LQswaWtG6cuub7nb9+V0DACU0VynOWlA3V5O0sdDR92QfSRqIXc1leTs 6udN0n3pzwJFNATXR9117JSFHSbKXAzvIpI6Z1To62ArNXcKyEhbsgW3ISx/HiuGn9BFnq3KBpbDC the8hRkXF+2OzAu/4TrgK3Byo54RBfLsnW0NW2ligmAHV9I0d45XxKxRkCIVPQ3WIZXbO6RM952UM yxOcEl6YmrauT26OBi+55BfPBncVYQMP0GSP07Zt3iqiNm1iNe5tPcjlhJqueS/os4R/CVsMOUEuW W/deoF4oNQ0NhZVkxbl8DQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozfRM-0008A9-2s; Mon, 28 Nov 2022 09:49:00 -0500 Date: Mon, 28 Nov 2022 16:49:29 +0200 Message-Id: <83a64bnngm.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 28 Nov 2022 16:29:15 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Mon, 28 Nov 2022 16:29:15 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > >> But if we just compare with the other builtin ('transient'), then its > >> VC awareness is probably the key thing. And the customization options it > >> has (which 'transient' doesn't). > > AFAIU, the 'transient' builtin also works with projects whose shape is a > > directory tree, right? If so, how is 'transient' different from the > > 'VC-aware' type? > > That's right. So you are saying that 'VC-aware' is like 'transient', but it will use a VCS if it's available? Then I guess 'VC-aware' is a good name for it. > So if we are comparing against 'transient' only, then VC awareness is > probably the key thing. And the customization options. Do we have other types to compare against? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 10:31:25 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 15:31:25 +0000 Received: from localhost ([127.0.0.1]:49256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozg6P-0005SM-6j for submit@debbugs.gnu.org; Mon, 28 Nov 2022 10:31:25 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:46067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozg6N-0005SG-5G for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 10:31:23 -0500 Received: by mail-wr1-f45.google.com with SMTP id d1so17440604wrs.12 for <41572@debbugs.gnu.org>; Mon, 28 Nov 2022 07:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=oK2+CF/secE9vycwGb0GN3kujcEMesD0BPY2lW/JfpE=; b=Pr1alEAVAG27HjsXvP7uAyZoOjY5BpYben0ar87KgWZpuRRFcSi4tib2p+4R2bt3IT qzjXA4CLA6lfTPeH0o5wV5eNzpijFHqAmNmCd4uXA17tD16+hnnpfht1PcLWYp3FJ9h6 a3SUTfsN2lVn8O+BWhxUVfIbPKBhZ+KZ20Znuv4+rK6fsieUBBSIUsRI4jb1sXZhInqH BOO3AUG0oK5MmFCE39yyMZt38qD5p2pLRgI62bYa9Q7H5U8r0MAq9KN7Crddp2MsTNz0 rnAbEOHegP5juo9kpEbtbkI2Ub44eBjOXE0I/0yaRE7C0C9Ir8Jd/BbknbGJJGWwpL9k 9h9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oK2+CF/secE9vycwGb0GN3kujcEMesD0BPY2lW/JfpE=; b=f/0Tzrofe2lnkuHWCgt+p1UJs7g2Ba1TwTIA+i06o2+GJBL5YItDtE6TYVU4qnzMEE WMlScS6TdX5pXOwiFyg6WHS/e0Fd+vz7g8R4FA6O46IX2aNsUAzAGfDUBCR6tph0ipms /enFjVtsbPx5t3b6/MmC6ZByYDrWeDBejIt8ymALacDw0hS2ocA6SBCirFdDBPnQvnih bggKCzzGMMSjiMp8A5TDpe2Uwmy6BpVCYHpWjtfsb+T/4hNzUE20NXvA95LR4jJaVNLZ q9XsgRUjldaD7zUD5OOpj9vQ2xdKx7n8YsTH5a5wQ2w9WNADmGFe0orvFtG7DaLnCY92 36nw== X-Gm-Message-State: ANoB5plLsUxOPzJBi/qTYsGBGzfVSLlgoXtojIiawOzqNrfxZAPyEagZ EisXW5eoOaRs4+mbtGDLYUI= X-Google-Smtp-Source: AA0mqf70n40+Ayclls/RZOFzhwil4vF9cYJpoYXUonuaXtxAJ1WWQ45T9SfLQapN2uSr42OBG7QMYQ== X-Received: by 2002:a5d:5445:0:b0:242:c41:c880 with SMTP id w5-20020a5d5445000000b002420c41c880mr7240433wrv.469.1669649474800; Mon, 28 Nov 2022 07:31:14 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x16-20020a5d6b50000000b0022a3a887ceasm10992063wrw.49.2022.11.28.07.31.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 07:31:14 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 17:31:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83a64bnngm.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 16:49, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 16:29:15 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 16:49, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 16:29:15 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 28/11/2022 16:49, Eli Zaretskii wrote: >> Date: Mon, 28 Nov 2022 16:29:15 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, >> joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, >> salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org >> From: Dmitry Gutov >> >>>> But if we just compare with the other builtin ('transient'), then its >>>> VC awareness is probably the key thing. And the customization options it >>>> has (which 'transient' doesn't). >>> AFAIU, the 'transient' builtin also works with projects whose shape is a >>> directory tree, right? If so, how is 'transient' different from the >>> 'VC-aware' type? >> >> That's right. > > So you are saying that 'VC-aware' is like 'transient', but it will use a VCS > if it's available? Then I guess 'VC-aware' is a good name for it. I suppose so. Great! >> So if we are comparing against 'transient' only, then VC awareness is >> probably the key thing. And the customization options. > > Do we have other types to compare against? I mentioned Projectile a few messages ago. It's a popular alternative that, with the last release, also plugs into project-find-functions and thus works as a new project.el backend. But it's third-party. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 11:50:57 2022 Received: (at 41572) by debbugs.gnu.org; 28 Nov 2022 16:50:57 +0000 Received: from localhost ([127.0.0.1]:49660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozhLN-00069a-9q for submit@debbugs.gnu.org; Mon, 28 Nov 2022 11:50:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozhLL-00069U-7l for 41572@debbugs.gnu.org; Mon, 28 Nov 2022 11:50:55 -0500 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 1ozhLD-0006bI-IT; Mon, 28 Nov 2022 11:50:47 -0500 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=OAOJ2E6tqkAH1B7xQl5jP5I7e4/TcMOkrXH7EJmx7g0=; b=Q3CFfDspPfr6 jfhKoI/EHAg/I7zl35r36EgqeinQdnNXxQU4mftNg0FMKhDVvju++bxrdzHJI3fWw01Lgi6URX8KF 0Bmcdt8WBQwXMObB9r1VmfIbuJQrAXfdiRxwFxgLKJVEiLPpxwz3/dqZas3n0AAN9N4b/u3LzAb6j LB3D6alAw4nxy1o5CI5zp9lB3xBL4w4N4KmzJfYcQEEe4qOWczWTpaRXYF11zKdbOtLwbhLXG02aw y/ZtdYdbIoo5iwY9CIjn1kH7cD2f4dc0YBbw4hZ9JmT0hqScXrcSB/rwWaAz/yhPsb/vxXrJHrRgC JfSIdkAlqr/kBLJauFLsJA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozhL9-0000zC-7Y; Mon, 28 Nov 2022 11:50:47 -0500 Date: Mon, 28 Nov 2022 18:51:12 +0200 Message-Id: <834jujnhtr.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Mon, 28 Nov 2022 17:31:11 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Mon, 28 Nov 2022 17:31:11 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > > So you are saying that 'VC-aware' is like 'transient', but it will use a VCS > > if it's available? Then I guess 'VC-aware' is a good name for it. > > I suppose so. Great! > > >> So if we are comparing against 'transient' only, then VC awareness is > >> probably the key thing. And the customization options. > > > > Do we have other types to compare against? > > I mentioned Projectile a few messages ago. > > It's a popular alternative that, with the last release, also plugs into > project-find-functions and thus works as a new project.el backend. > > But it's third-party. Well, we can only compare to objects we manage ourselves, so Projectile is not relevant. Then okay, we have 2 built-in project types, and the difference is that one will use a VCS when available, the other won't. That's clear enough to have in the docs, I think. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 04:45:15 2022 Received: (at 41572) by debbugs.gnu.org; 29 Nov 2022 09:45:15 +0000 Received: from localhost ([127.0.0.1]:54186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozxAx-0006LR-2s for submit@debbugs.gnu.org; Tue, 29 Nov 2022 04:45:15 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:46983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozxAv-0006LH-25 for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 04:45:13 -0500 Received: by mail-wr1-f48.google.com with SMTP id h11so13849700wrw.13 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 01:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DUALrQv5nruDKKtTs8GRSB8dMCzLUO719zzBQUBGcI4=; b=o2hj2wQzOlzsPyLgfV4p4CpwfKXZ50i/YVP0Q6evLzyXqTHtdVt+Ibg49Ra59Y9JW7 NoQgaJDjGU+rEwy/VTDzstdgAHRQLj8Upwh43RK61+7yF/XzFtNcRZVE7f1O6tdMdLMf LGAiRZXPFb4XycEpqFjWNqPQfjpjXyPKNkrmU0DqxyUf/3gRQPZ/kB2qQj+qF10WqIOX xUbVfkOavHqWxc+/3Lw0D0orYYrjt0lBP1mwaUC1TLYkaa/IZV4KB/EZxoGXyhWwstdw plFsBSjWl0/o8uwN7gKQs0TsaVZDiFvLf9cztihdY2HNTF6kVD1CHTpAWWAL2eY3ufcG X9gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DUALrQv5nruDKKtTs8GRSB8dMCzLUO719zzBQUBGcI4=; b=WkVgbkmSXFwsFR+RwVF+ehUb7jMV3dcD1S1HTk+AVdx9wht2sR+geDZiqNzHvnqnYb sDwT+g9GRC2Bw4yvPOS20kAvUFOJQvQhSJhiOAKhhd2ZGzGG6keLhuBZ4waEaEcZ+DOF uueq+zP1ufqqxnY5oWolXuAMSwl+62ue/ZrDQcf7kJpAZNVJ5YoYZtciLxdPXMFYXMhn ouEUgN7OPBdxs73E3noLzwWneTS3xMNwrSmJ8+DV+Z5KZvR4VxsiGNa+YVCz1tfqtiUs rkEbXbYbRbpkCJyKVHpI727CberCF7CSfFYmX1nuJIr0R//lKrx3nPCMo7+hJv0Q2ui+ yS1w== X-Gm-Message-State: ANoB5pnGrX65kMk7OD3p6hBbgajvvrXYN9lbBxIOI0utn/yC2SRqjyfP hR4nnA6iwTkBWsW/+zM6WGo= X-Google-Smtp-Source: AA0mqf5zKSm2BAOycHCshkZyoGMMkEFTbXEPTt+cFVPPVCaZRi96FELH6o2E83aT1cdYj/RPL1lYKg== X-Received: by 2002:a5d:4e43:0:b0:241:d029:e98b with SMTP id r3-20020a5d4e43000000b00241d029e98bmr26560611wrt.551.1669715107080; Tue, 29 Nov 2022 01:45:07 -0800 (PST) Received: from krug ([87.196.72.71]) by smtp.gmail.com with ESMTPSA id f18-20020a05600c4e9200b003c6c182bef9sm1884271wmq.36.2022.11.29.01.45.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 01:45:06 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project In-Reply-To: (Dmitry Gutov's message of "Sun, 27 Nov 2022 18:09:32 +0200") References: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@yandex.ru> <87pnahjgdr.fsf@linkov.net> <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> Date: Tue, 29 Nov 2022 09:46:22 +0000 Message-ID: <8735a2rt3l.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.0 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > On 26/11/22 21:23, João Távora wrote: >> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > > wrote: >> > My use case is the following: I'm interested in being [...] Content analysis details: (4.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.48 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.48 listed in wl.mailspike.net] 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , Daniel =?utf-8?Q?Mart=C3=ADn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , Rudolf =?utf-8?Q?Adamkovi=C4=8D?= , 41572@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: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > On 26/11/22 21:23, João Távora wrote: >> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > > wrote: >> > My use case is the following: I'm interested in being [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.48 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.48 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Dmitry Gutov writes: > On 26/11/22 21:23, Jo=C3=A3o T=C3=A1vora wrote: >> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov > > wrote: >> > My use case is the following: I'm interested in being able to >> designate >> > projects (through various means, not only marker files) that may = only >> > exist inside other projects. >> You previously described your super-project and how you handled >> it >> using >> project-find-functions hook with a new element that looked for file >> markers. Does this patch make that easier to do? Without writing cus= tom >> functions? >> The example i gave did _not_ use file markers. Personally, I can't >> use them. I need some elisp way. > > Please elaborate. I've already elaborated, with actual code. https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html > Does it mean that those subprojects are chosen manually and don't have > "packages.jon" or etc exactly (or that too many subprojects in that > same project would, undesirably, contain the same files)? OK, one last time: packages.json and i.e. monorepos that have a developing collection of similarly structured NPM packages that move around is good case for marker files, undoubtedly. I'm not putting that into question. But many times that's not the case and you have a big project in which a mostly fixed heterogenous collection of sub-hierarchies exist and you would like to designate as those as subprojects. In the latter case, marker files are useless, uselessly slow and perhaps even impossible. In _both_ cases, it's very useful to have project operations let the user choose the target: super-project or sub-project (or "parent project", "outer project", "nested project", "inner project": I don't care too much about the nomenclature). > Would being able to set to absolute file names (directories) help? Or > would that be too awkward? That's more or less the idea, but they don't need to be absolute file names which is indeed awkward See project-sub-project-prefixes in the code I posted. project-sub-project-prefixes can even be a regex pattern applied on the super-project's root. This describes the heterogenous collection economically and robustly. It is then typically set dir-locally, with either a .dir-locals.el file or with dir-locals-set-class-variables. Of course, the member of project-find-functions that consults project-sub-project-prefixes needs to be aware of containing super-projects found by some other means (marker files included). See the code I posted to emacs-devel for a possible implementation. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 13:52:05 2022 Received: (at 41572) by debbugs.gnu.org; 29 Nov 2022 18:52:05 +0000 Received: from localhost ([127.0.0.1]:55670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p05i9-0005bu-36 for submit@debbugs.gnu.org; Tue, 29 Nov 2022 13:52:05 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:43593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p05i5-0005bW-CZ for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 13:52:04 -0500 Received: by mail-wm1-f51.google.com with SMTP id ay27-20020a05600c1e1b00b003d070f4060bso76154wmb.2 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 10:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=9d3Nk11cDhMVbrGMuLmGAg5WFKZ0IbgYUtKIx+N5x4Q=; b=hRY5nidImFdIQHe4xXgM8YNTJHgGesS356GlvEHyfZcOAyywrip/0K2rw5wUPdd6VZ VqxqUgsk6yxv1+TwNqWMYQ/LLp3+87xYwZxPQNuP3ve7F0MBQCZeZvodHQ3qiRTKcXaH znHTTGJjHuuQWUGxgqFmyj7vf8MvLMTbVrgUsHWeu60O9rDzvoTmy7xG0cQOOUajeFBq zQlsfq3afkelWq7aapjbegbdxPaJccFGCXaEXebl1ucEgT0mu0/M9kWJX93g1F5s28W2 kvjMlQkWNJgQXQmV7+aszylhJ/hMkjOUqPv+6ucAnV71fkOVVBREopxEvewqvCXym9ra PDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9d3Nk11cDhMVbrGMuLmGAg5WFKZ0IbgYUtKIx+N5x4Q=; b=xs47wEejJVUaPJmQ3NJINk840c/6o7L3+bMg7+gowXZs7eVFM17B0xnStYTFStrPrx Z05rcBhu8MYK4BNYha8GYUNwnKkBbqtRT4LDD7dUmd9mPZ8La9G3mBRJXiTrGdZ2n0Vw 8x4n2+Dd6c5FCZwoW8Y/ptXa1fnkuk0iMzOvwYhVRrRMegETuc0EAwrtWh0k0XPZCARo fuZb9nrZ1xSnzxsM6UJn8kcGO9IqoSLuXrJqzLYakvQpOOA1r/+DYOGHg6czbsUq5HI7 F08tBj2skZmgwtXefTVSkT7fdyKgA5REA1H1A2zdr8hyNxhRY11DLYzXIfDVqQW3/4f4 cZ6g== X-Gm-Message-State: ANoB5pk9FN3RibC7WzcIofAbUfbBHO+Xi5mDJFIaJn1131AhegGkPHaz texb7lsTrKz1qgDf9uQh0TA= X-Google-Smtp-Source: AA0mqf5DXHtBil/T/b0UirmxODr3pK4EGP7RaBtcXd91x5lgoAXvO7w/WOo2aOVRhMGhhg7mjfK2XQ== X-Received: by 2002:a7b:cb91:0:b0:3c6:cb54:ef66 with SMTP id m17-20020a7bcb91000000b003c6cb54ef66mr32119657wmi.90.1669747915324; Tue, 29 Nov 2022 10:51:55 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m9-20020a05600c3b0900b003c5571c27a1sm4296498wms.32.2022.11.29.10.51.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 10:51:54 -0800 (PST) Message-ID: Date: Tue, 29 Nov 2022 20:51:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> <8735a2rt3l.fsf@gmail.com> From: Dmitry Gutov In-Reply-To: <8735a2rt3l.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 29/11/2022 11:46, João Távora wrote: > Dmitry Gutov writes: > >> On 26/11/22 21:23, João Távora wrote: >>> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov >> , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=c3=adn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , =?UTF-8?Q?Rudolf_Adamkovi=c4=8d?= , 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 29/11/2022 11:46, João Távora wrote: > Dmitry Gutov writes: > >> On 26/11/22 21:23, João Távora wrote: >>> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov >> Dmitry Gutov writes: > >> On 26/11/22 21:23, João Távora wrote: >>> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov >> > wrote: >>> > My use case is the following: I'm interested in being able to >>> designate >>> > projects (through various means, not only marker files) that may only >>> > exist inside other projects. >>> You previously described your super-project and how you handled >>> it >>> using >>> project-find-functions hook with a new element that looked for file >>> markers. Does this patch make that easier to do? Without writing custom >>> functions? >>> The example i gave did _not_ use file markers. Personally, I can't >>> use them. I need some elisp way. >> >> Please elaborate. > > I've already elaborated, with actual code. > > https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html > https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html These answered the question of *what* you want to do, not *why*. >> Does it mean that those subprojects are chosen manually and don't have >> "packages.jon" or etc exactly (or that too many subprojects in that >> same project would, undesirably, contain the same files)? > > OK, one last time: packages.json and i.e. monorepos that have a > developing collection of similarly structured NPM packages that move > around is good case for marker files, undoubtedly. I'm not putting that > into question. > > But many times that's not the case and you have a big project in which a > mostly fixed heterogenous collection of sub-hierarchies exist and you > would like to designate as those as subprojects. In the latter case, > marker files are useless, uselessly slow and perhaps even impossible. I understand that in theory, it's just it's often possible to solve the problem with the tools at hand (see my latest reply on emacs-devel about the Emacs doc/ subdirectory). So I figured to ask about your particulars. > In _both_ cases, it's very useful to have project operations let the > user choose the target: super-project or sub-project (or "parent > project", "outer project", "nested project", "inner project": I don't > care too much about the nomenclature). Yes. But separate feature. >> Would being able to set to absolute file names (directories) help? Or >> would that be too awkward? > > That's more or less the idea, but they don't need to be absolute file > names which is indeed awkward See project-sub-project-prefixes in the > code I posted. project-sub-project-prefixes can even be a regex pattern > applied on the super-project's root. This describes the heterogenous > collection economically and robustly. It is then typically set > dir-locally, with either a .dir-locals.el file or with > dir-locals-set-class-variables. I asked about absolute file names because those would be easier (semantically) to cram into the same user option as the markers. Otherwise we'd need a separate option for those. Although... if we insisted on using the format like "./abc/def/", that would also put those values into a different category. The handling logic would need to be different just the same. > Of course, the member of project-find-functions that consults > project-sub-project-prefixes needs to be aware of containing > super-projects found by some other means (marker files included). See > the code I posted to emacs-devel for a possible implementation. Have you tried the patch that I sent in the GP email? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 17:05:09 2022 Received: (at 41572) by debbugs.gnu.org; 29 Nov 2022 22:05:09 +0000 Received: from localhost ([127.0.0.1]:56713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p08iy-0001Wm-S2 for submit@debbugs.gnu.org; Tue, 29 Nov 2022 17:05:09 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:53006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p08iv-0001WK-D4 for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 17:05:07 -0500 Received: by mail-wm1-f44.google.com with SMTP id o30so11958668wms.2 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 14:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hOgoyB4ayj9OXBM4a9Mat9ANLYF6J0o+/FFpFwilzOY=; b=fDm8HMYdrC4QZMOL5KoF89v4X8Mg3zyedvY0GB/0gl5QQvIqKu+41z9CWHTQD3mM+E mzFfN++TwJX+e4fkMOVrwpGT5g+AIa0IbmE7T8RwpOJWRDMTxaFHI3oScJzS0mJQh9oe VzkQh0vBd+kwwGWbIYBtGDnp+Xd4xtRt2LksX2bsVkTpUUDsM/CfzuM/2Mtbohtsi6/g Df3Q8Kht35m0lIGsxhHa2kR8IO1G622uWEg0DgZe5Pq9JGoDlzfLfy+n5ew9KJoODS6j N3yvkzMKsSYIyLpqewW8bSmrKPri57rSKlNNVo8hzb5oSqwSOwwMHCpTBjGYL9YCYw5U xn6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hOgoyB4ayj9OXBM4a9Mat9ANLYF6J0o+/FFpFwilzOY=; b=Kn+WtkDJarrNHZoCPCBEyf1rPt3f9l5t0cQwOiQydOjdvX4gpZh+MZbNx31Hv/mGdu FRUcfOB+F4Q+MxhUamcNGM6QG/mQ64ibwmd87BnDcc6stUO+AeeMEQygXW49yp7TXRza vkk+NNMjDKSJ79urNZ+V6Tg6duZKbHsCw5u2NTCU5o/OYjgprwW3Jh5g1LUlbREQQ3q6 dbPuCl0nAg0ioEyYKkG5+7vyaIrjgojjp/zx5F/NlvstGyy5TRqAeAwk1eIhfFgOC4Vp gekvYnfvNknkRGkn0cAwgnTcNwkpxTyCWMXeDk6+VsIobXdIE6onqSKuJr9dNSTtrt9Q LcWQ== X-Gm-Message-State: ANoB5plk+6Tyg7qm+ebi3k5mn7iD6YNs4wRO9dD8ljTPDNoon0ZyOdK9 Or/ELsPXpCujeGLrmyhd4qw= X-Google-Smtp-Source: AA0mqf5nzpwem4V0PyxQ6simI0HzycTg5zZPacUJFL1GYleHknShIdTsYEnhNUk1fm6pl0X1yLpJWw== X-Received: by 2002:a05:600c:540a:b0:3d0:50c4:432c with SMTP id he10-20020a05600c540a00b003d050c4432cmr13005794wmb.67.1669759499505; Tue, 29 Nov 2022 14:04:59 -0800 (PST) Received: from krug (87-196-72-71.net.novis.pt. [87.196.72.71]) by smtp.gmail.com with ESMTPSA id z6-20020adfe546000000b0023655e51c33sm14986609wrm.4.2022.11.29.14.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 14:04:58 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Dmitry Gutov Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project In-Reply-To: (Dmitry Gutov's message of "Tue, 29 Nov 2022 20:51:52 +0200") References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> <8735a2rt3l.fsf@gmail.com> Date: Tue, 29 Nov 2022 22:06:15 +0000 Message-ID: <87mt89quug.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: >>> Please elaborate. >> I've already elaborated, with actual code. >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/ms [...] Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.44 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.44 listed in list.dnswl.org] X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , Daniel =?utf-8?Q?Mart=C3=ADn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , Rudolf =?utf-8?Q?Adamkovi=C4=8D?= , 41572@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: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: >>> Please elaborate. >> I've already elaborated, with actual code. >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/ms [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.44 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.44 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joaotavora[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Dmitry Gutov writes: >>> Please elaborate. >> I've already elaborated, with actual code. >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html >> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html > > These answered the question of *what* you want to do, not *why*. I've described that numerous times as well. I want to be able to grep, compile, etc in the either the super or the sub project. I've described this to you so many times it's astonishing you keep asking me to elaborate. > I understand that in theory, Thank heavens for that! > it's just it's often possible to solve the problem with the tools at > hand (see my latest reply on emacs-devel about the Emacs doc/ > subdirectory). I've seen it, and it's not a good solution. Will reply there. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 19:10:30 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 00:10:30 +0000 Received: from localhost ([127.0.0.1]:57321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0AgI-0004zH-88 for submit@debbugs.gnu.org; Tue, 29 Nov 2022 19:10:30 -0500 Received: from mail-wr1-f47.google.com ([209.85.221.47]:47039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0AgC-0004zB-Fr for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 19:10:28 -0500 Received: by mail-wr1-f47.google.com with SMTP id h11so17365086wrw.13 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 16:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=pfH9BenD9Uf/GuAVMw4i2AbAGnW7fm74X7nPuit6nAE=; b=TLdIdTejQSk/OIUknGKyZspnJfHOdaGxl3PJxJK0VhyhJppiri7+80vdpNd9MXWVXJ 93ZKQo44YyxVEA39ep5ZJtUXKKP+V56vIvK0A9l6LaPPhgGwTQiI99FopryZGs0Hso95 ZP8yHoPIsP57sQIojiIsvX1MPj8knXjhaTXalhrqCOVen/nP1a1Rvbzk70AERuHaUOAw 3MaHFm40Hm+GCvqgpM+StL05O5uw/wh+2hf4blL/VkTQQsYbQ8AaIjq0Bg5bci9c3iii MMdEUNW+pIyFILnFliwzL/ckmIyZF+87IK0nQ+VGG2o9mEV9f/N/R85WBIHmkRpFRGW8 Gd+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pfH9BenD9Uf/GuAVMw4i2AbAGnW7fm74X7nPuit6nAE=; b=cc+s6riLZyH8+o7kNV3I9Hck0UD4N/6L+J/dHsj0kdF0mTwHe91f2ejnWaD/5GLBm5 lNwOhIM7adawIaW8kTFGoogIg4ad7KyKm9/M+AmifMJRmZRRomilePCfyqXYrId0pYjJ xaorORDMcZ5kxO+X8N/1uHUOz6yirZMZrhcPUaMnp5AJ0M4AK1aprCnnIamYybce67MC 225xbiY1PqAV4dKKZ5bWM9BjqLNCXMa3PhJsMfwk440EgiitQrVslV9WJwcIOdnnju3y o158k/sIN6NZvWl5m6zontcKnOPoiTTAmRFkf52q7kjhwIWGYbMSNnzi18dKZfAlieDQ RJ0Q== X-Gm-Message-State: ANoB5pk390cHK+DRBZMYwlQoUmdGauAPZMBxcs8Ow2DJI3Gw2EKF5z20 BFqMIhB55lp1c36kGDFg8a4= X-Google-Smtp-Source: AA0mqf69OZnsnsMvl6a9fGhsIaArgrg70La2cwGG2wU4oSSFzmBp1Rw84n7ktV4pU7yVCcB4uekfmw== X-Received: by 2002:adf:f981:0:b0:242:8c1:601 with SMTP id f1-20020adff981000000b0024208c10601mr14120820wrr.339.1669767018358; Tue, 29 Nov 2022 16:10:18 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r4-20020a0560001b8400b00241bd7a7165sm14953282wru.82.2022.11.29.16.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 16:10:17 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 02:10:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= References: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> <8735a2rt3l.fsf@gmail.com> <87mt89quug.fsf@gmail.com> From: Dmitry Gutov In-Reply-To: <87mt89quug.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 00:06, João Távora wrote: > Dmitry Gutov writes: > >>>> Please elaborate. >>> I've already elaborated, with actual code. >>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/ms [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.47 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.47 listed in list.dnswl.org] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: "Philip K." , Rudi Schlatte , Eric Abrahamsen , Zhu Zihao , Theodor Thornhill , =?UTF-8?Q?Daniel_Mart=c3=adn?= , =?UTF-8?Q?Rudolf_Adamkovi=c4=8d?= , Manuel Uberti , Juri Linkov , Augusto Stoffel , 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 00:06, João Távora wrote: > Dmitry Gutov writes: > >>>> Please elaborate. >>> I've already elaborated, with actual code. >>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/ms [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.47 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.47 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 30/11/2022 00:06, João Távora wrote: > Dmitry Gutov writes: > >>>> Please elaborate. >>> I've already elaborated, with actual code. >>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html >>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html >> >> These answered the question of *what* you want to do, not *why*. > > I've described that numerous times as well. I want to be able to grep, > compile, etc in the either the super or the sub project. I've described > this to you so many times it's astonishing you keep asking me to > elaborate. Should I repeat, for the 1000th time, that it will be possible to add no matter which of the "subproject" approaches we take? I've even posted the patch. >> I understand that in theory, > > Thank heavens for that! > >> it's just it's often possible to solve the problem with the tools at >> hand (see my latest reply on emacs-devel about the Emacs doc/ >> subdirectory). > > I've seen it, and it's not a good solution. Will reply there. Okay. Should I wait for you to finally try the patch from the GGP email? Or is that too much to ask? From what I see of your responses, you didn't read it either. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 29 21:26:50 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 02:26:50 +0000 Received: from localhost ([127.0.0.1]:57928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0CoE-0008W3-Cj for submit@debbugs.gnu.org; Tue, 29 Nov 2022 21:26:50 -0500 Received: from mail-wm1-f52.google.com ([209.85.128.52]:36442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0CoA-0008Vx-9H for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 21:26:48 -0500 Received: by mail-wm1-f52.google.com with SMTP id c65-20020a1c3544000000b003cfffd00fc0so394026wma.1 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 18:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=wArOa4JEU2Hr8al7Z8FYK1gqXagTWHL+GYyUSb4U5KE=; b=aBrhHJVd2ShoeNucc2UPwUGylzOyed6hnwfQAUcXYduJBc+MR1Hc5Bu888TTDKulKV yoPR+K0Q67EwOn+9MyJG9JfHIuSkXhvipbZdc9/qWTjl5LHv+V5hLPLGd+9kenHvuw9u 89Dsw/rFpRdr3GplixPu3oEFI+34h55juF6B+PWLtmttDikaiCDSuA7Rx6ZYj+mIqCbC uS0LIEhnV5eHdgfyTX0SlBcEr2quLOR4GnwQdx1aprmyZY03g6qHDy/m2ePaFfvduKRg iJ1OfnXC7L2aeteVhjOCOvM/9jNfaqhCXAxDCq+7atrHgH/lF+8CV9HaOLQqkGsFxR8y H08w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wArOa4JEU2Hr8al7Z8FYK1gqXagTWHL+GYyUSb4U5KE=; b=KThCYuQfC4VjIS6gLZMcv4ff/2dt4rgX7wtx0JDFOHWOzMGe0kL3qGMfZLK95DJvOx O5z3d7JZu6IJJjD0hLv9gPc/r8VvZ/eyGddQJuly2T/VXvNeJC5vAll7ogIbxyy7ad/9 wP+ZnoVPW1NiT6rKBO4klz6j9GUI+D6/3U0gtYgUg0vF0eVYluOeRJ/2kaMYPXwMDmwZ 42L5WL6aafReTgPnptaBM3+paIZjoXMUkTUiM1g3vYMofWh9c1ZWTLcGSClV8i4tTGal CH+mxHLIsZtcbLUUwkwbL7j6glEY7/FixbvMNfPiBQWYmyJPAXjP/ZXVmY06eeWrxwaA E/AQ== X-Gm-Message-State: ANoB5pmosJtT4Fxf4D5gwss9Vnm+TOIXEwAafo/pJeSRlaMLLGhZfWI5 Gv00ngZ1aSthuRjwTccy/U0= X-Google-Smtp-Source: AA0mqf7pKVpcP+p7H9XpAmefgtKlcMf9VJS6LyRtbGOf7NPRkFIdf9lmgeFsqmsOl+At7fEp8IGC3g== X-Received: by 2002:a7b:c84a:0:b0:3cf:5d41:b74b with SMTP id c10-20020a7bc84a000000b003cf5d41b74bmr28473803wml.184.1669775200212; Tue, 29 Nov 2022 18:26:40 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n3-20020a05600c3b8300b003cfbbd54178sm2366688wms.2.2022.11.29.18.26.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 18:26:39 -0800 (PST) Message-ID: <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> Date: Wed, 30 Nov 2022 04:26:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <834jujnhtr.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 18:51, Eli Zaretskii wrote: > Then okay, we have 2 built-in project types, and the difference is that one > will use a VCS when available, the other won't. That's clear enough to have > [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.52 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.52 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 28/11/2022 18:51, Eli Zaretskii wrote: > Then okay, we have 2 built-in project types, and the difference is that one > will use a VCS when available, the other won't. That's clear enough to have > [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.52 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.52 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 28/11/2022 18:51, Eli Zaretskii wrote: > Then okay, we have 2 built-in project types, and the difference is that one > will use a VCS when available, the other won't. That's clear enough to have > in the docs, I think. Very good. Eli, what do you think about this feature (project-vc-extra-root-markers) for emacs-29? This bug has been open a while. I'm not seeing much user feedback now, but that's probably because everyone has been living with their own custom solution for all this time. And we'll still have time for people to report any bugs before the release. Further, I've done some testing over Tramp, and the new approach improves the performance of the default implementation significantly. Like with a remote host over 200ms ping, with clear Tramp cache, "cold" project-current call is down from 3-6s to 1.9-3.3s (depending on the directory depth). Not sure how many are working over such a slow connection, but that could be a nice bump. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 08:30:24 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 13:30:24 +0000 Received: from localhost ([127.0.0.1]:32795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0NAN-0005EO-Sz for submit@debbugs.gnu.org; Wed, 30 Nov 2022 08:30:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0NAM-0005EI-IK for 41572@debbugs.gnu.org; Wed, 30 Nov 2022 08:30:23 -0500 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 1p0NAE-0007VT-Bi; Wed, 30 Nov 2022 08:30:14 -0500 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=xPduOt4Jbq8an7PLACeV1Xf2V8YXT3jkVqFiUae4ia4=; b=ekjVRJBV6bbS TKQjz7AFQJXrbmYsi08P9bFbOYLszscVpU+sB3GvVZEXWldo1GaZ94Kfzh87FbY+aD1oCCNrzV7dn n14114jQ6EVHaQB7Gr226/YbPliXxTsjFNaDFfh2etBxT8OpNAvNph8Z8f4myS9Nyn8V7t+VIl4U5 yOtkjjJE/OqiZuyHN3ajaim4GntXOD7IdiizcC7KIgl4aPdrVVDaJFxK6rG1BGdqRrQ92P4Lhm+02 jmMxvPOYOPrCJYa6KIYmGcdl1Bk8TFwOe8D1cmVOsYGBwNwCM2C5nHHPigHw8hFHw0v4QwJGJdOMm CAkYCofk30pguW6UDuVg+w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0NAC-0004YY-Lp; Wed, 30 Nov 2022 08:30:14 -0500 Date: Wed, 30 Nov 2022 15:29:41 +0200 Message-Id: <83edtklge2.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> (message from Dmitry Gutov on Wed, 30 Nov 2022 04:26:36 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Wed, 30 Nov 2022 04:26:36 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > On 28/11/2022 18:51, Eli Zaretskii wrote: > > Then okay, we have 2 built-in project types, and the difference is that one > > will use a VCS when available, the other won't. That's clear enough to have > > in the docs, I think. > > Very good. > > Eli, what do you think about this feature > (project-vc-extra-root-markers) for emacs-29? Where can I see the code that you are proposing? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 13:52:46 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 18:52:46 +0000 Received: from localhost ([127.0.0.1]:34484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0SCL-00029l-FQ for submit@debbugs.gnu.org; Wed, 30 Nov 2022 13:52:46 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0SCI-00029e-79 for 41572@debbugs.gnu.org; Wed, 30 Nov 2022 13:52:43 -0500 Received: by mail-wr1-f45.google.com with SMTP id q7so27714370wrr.8 for <41572@debbugs.gnu.org>; Wed, 30 Nov 2022 10:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=rRdlE2S+flIiY7Ix9v+jzNnHSuEyUA1iUWOcMQThet0=; b=mupcqmwzu7PuP86G9S8VGfoLXtKccEcZP0g7d8kwWwD8QGOPCrRKv62vmMOJCBohg8 Qkgk/rAujIQ8YtytAAwkTso4QSwvuNRnAQt+bu4UZYJ1eltoh74tKlPNgS+yr1c0gFe6 ybwIuK4PPR+StMzdIui6HT15Pq47BjIZx0GPvlI0o5gSw/VYPvfr61QasNRCs0/rJC4V g3pLfw/J+OQ8Q+q3vweDu2sfDKAX5ZI9DEzpyZULMnqAEg0QHwnSsjTKa8O9IcPObYI8 yTKitRM+bpwYhsJiqqbo9u/YhfQ4wFnyoP/T3n6ZvXbRBX9mNMdyVgfPcu8ohDTSPv7t L3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rRdlE2S+flIiY7Ix9v+jzNnHSuEyUA1iUWOcMQThet0=; b=OUluYwwcSuOW1S474TO0JoRJwFILmBoz3Fz8Nct1l50yB8SOsm+FZi7eBetzyFEvUu xibpM2A/2j+aktv9WgB88K4xCfrF+Ycot3bWD9DER/+llfGoXUN7ySP82H7stEWCz+Sp 16dRXqYRcXIXV0exbHM36A2jwiR3SgXL26tA2yr4UDHX+lSeXbKLX8OBbP5beygyf84J PvRcKTeQySHsQX4RDteva5vSs4BsKl9Wp4QQ2VSLTvbD9cugSh8ZOsrDuk/WYVlkptYe 4LzOr0L5TryZFPvGOl0r1XE2TmzHNttl0fLFY0Ugl7WgfPKS1HUSG8PHrCLw7769E07/ RZ4w== X-Gm-Message-State: ANoB5plo9lrEowX1ozyvAkq1DjQdJCfccFCx0MKBKs/I4k4QrFRqVcuL 61LCGaVLtOX4jhHkIL4eGP0= X-Google-Smtp-Source: AA0mqf7bLZ9SOr6wLGgNs4hXjmeIAzKfKyaxkihEGBF4J915SU2SxRd4ODE9S/azijhSVJNuDDiNgg== X-Received: by 2002:a5d:4d51:0:b0:242:1bad:6f79 with SMTP id a17-20020a5d4d51000000b002421bad6f79mr9359038wru.342.1669834356225; Wed, 30 Nov 2022 10:52:36 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e14-20020adff34e000000b0024228b0b932sm2757882wrp.27.2022.11.30.10.52.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 10:52:35 -0800 (PST) Content-Type: multipart/mixed; boundary="------------003oVGRm91FttH49rl1nD5mM" Message-ID: <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> Date: Wed, 30 Nov 2022 20:52:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83edtklge2.fsf@gnu.org> X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 15:29, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 04:26:36 +0200 >> Cc:philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 15:29, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 04:26:36 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.45 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) This is a multi-part message in MIME format. --------------003oVGRm91FttH49rl1nD5mM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 30/11/2022 15:29, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 04:26:36 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardani29@yahoo.es, >> joaotavora@gmail.com,manuel.uberti@inventati.org,juri@linkov.net, >> salutis@me.com,arstoffel@gmail.com,41572@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 28/11/2022 18:51, Eli Zaretskii wrote: >>> Then okay, we have 2 built-in project types, and the difference is that one >>> will use a VCS when available, the other won't. That's clear enough to have >>> in the docs, I think. >> Very good. >> >> Eli, what do you think about this feature >> (project-vc-extra-root-markers) for emacs-29? > Where can I see the code that you are proposing? Here you go, I also added some documentation updates and 2 tests. --------------003oVGRm91FttH49rl1nD5mM Content-Type: text/x-patch; charset=UTF-8; name="project-vc-extra-root-markers-v3.diff" Content-Disposition: attachment; filename="project-vc-extra-root-markers-v3.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IGNjMjhiZGRmZjIyLi5hZjEzNmFiNjBlOSAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC0xLDcgKzEsNyBAQAogOzs7IHByb2plY3QuZWwgLS0tIE9wZXJhdGlvbnMg b24gdGhlIGN1cnJlbnQgcHJvamVjdCAgLSotIGxleGljYWwtYmluZGluZzogdDsgLSotCiAK IDs7IENvcHlyaWdodCAoQykgMjAxNS0yMDIyIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwg SW5jLgotOzsgVmVyc2lvbjogMC44LjMKKzs7IFZlcnNpb246IDAuOS4wCiA7OyBQYWNrYWdl LVJlcXVpcmVzOiAoKGVtYWNzICIyNi4xIikgKHhyZWYgIjEuNC4wIikpCiAKIDs7IFRoaXMg aXMgYSBHTlUgRUxQQSA6Y29yZSBwYWNrYWdlLiAgQXZvaWQgdXNpbmcgZnVuY3Rpb25hbGl0 eSB0aGF0CkBAIC01OCwxMyArNTgsMzAgQEAKIDs7CiA7OyBUaGlzIGxpc3QgY2FuIGNoYW5n ZSBpbiBmdXR1cmUgdmVyc2lvbnMuCiA7OwotOzsgVkMgcHJvamVjdDoKKzs7IFRyYW5zaWVu dCBwcm9qZWN0OgorOzsKKzs7IEFuIGluc3RhbmNlIG9mIHRoaXMgdHlwZSBjYW4gYmUgcmV0 dXJuZWQgYnkgYHByb2plY3QtY3VycmVudCcgaWYgbm8KKzs7IHByb2plY3Qgd2FzIGRldGVj dGVkIGF1dG9tYXRpY2FsbHksIGFuZCB0aGUgdXNlciBoYWQgdG8gcGljayBhCis7OyBkaXJl Y3RvcnkgbWFudWFsbHkuICBUaGUgZmlsZXNldCBpdCBkZXNjcmliZXMgaXMgdGhlIHdob2xl Cis7OyBkaXJlY3RvcnksIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBzb21lIHN0YW5kYXJkIGln bm9yZWQgZmlsZXMgYW5kCis7OyBkaXJlY3Rvcmllcy4gIFRoaXMgdHlwZSBoYXMgbGl0dGxl IHB1cnBvc2Ugb3RoZXJ3aXNlLCBhcyB0aGUgb25seQorOzsgZ2VuZXJpYyBmdW5jdGlvbiBp dCBwcm92aWRlcyBhbiBvdmVycmlkZSBmb3IgaXMgYHByb2plY3Qtcm9vdCcuCis7OworOzsg VkMtYXdhcmUgcHJvamVjdDoKIDs7CiA7OyBPcmlnaW5hbGx5IGNvbmNlaXZlZCBhcyBhbiBl eGFtcGxlIGltcGxlbWVudGF0aW9uLCBub3cgaXQncyBhCiA7OyByZWxhdGl2ZWx5IGZhc3Qg YmFja2VuZCB0aGF0IGRlbGVnYXRlcyB0byAnZ2l0IGxzLWZpbGVzJyBvciAnaGcKIDs7IHN0 YXR1cycgdG8gbGlzdCB0aGUgcHJvamVjdCdzIGZpbGVzLiAgSXQgaG9ub3JzIHRoZSBWQyBp Z25vcmUKIDs7IGZpbGVzLCBidXQgc3VwcG9ydHMgYWRkaXRpb25zIHRvIHRoZSBsaXN0IHVz aW5nIHRoZSB1c2VyIG9wdGlvbgotOzsgYHByb2plY3QtdmMtaWdub3JlcycgKHVzdWFsbHkg dGhyb3VnaCAuZGlyLWxvY2Fscy5lbCkuCis7OyBgcHJvamVjdC12Yy1pZ25vcmVzJyAodXN1 YWxseSB0aHJvdWdoIC5kaXItbG9jYWxzLmVsKS4gIFNlZSB0aGUKKzs7IGN1c3RvbWl6YXRp b24gZ3JvdXAgYHByb2plY3QtdmMnIGZvciBvdGhlciBvcHRpb25zIHRoYXQgY29udHJvbCBp dHMKKzs7IGJlaGF2aW9yLgorOzsKKzs7IElmIHRoZSByZXBvc2l0b3J5IGlzIHVzaW5nIGFu eSBvdGhlciBWQ1MgdGhhbiBHaXQgb3IgSGcsIHRoZSBmaWxlCis7OyBsaXN0aW5nIHVzZXMg dGhlIGRlZmF1bHQgbWVjaGFuaXNtIGJhc2VkIG9uICdmaW5kJy4KKzs7Cis7OyBUaGlzIHBy b2plY3QgdHlwZSBjYW4gYWxzbyBiZSB1c2VkIGZvciBub24tVkNTIGNvbnRyb2xsZWQKKzs7 IGRpcmVjdG9yaWVzLCBzZWUgdGhlIHZhcmlhYmxlIGBwcm9qZWN0LXZjLWV4dHJhLXJvb3Qt bWFya2VycycuCiA7OwogOzsgVXRpbHM6CiA7OwpAQCAtMzc3LDcgKzM5NCw3IEBAIHByb2pl Y3QtYnVmZmVycwogICAgIChucmV2ZXJzZSBidWZzKSkpCiAKIChkZWZncm91cCBwcm9qZWN0 LXZjIG5pbAotICAiUHJvamVjdCBpbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiB0aGUgVkMgcGFj a2FnZS4iCisgICJWQy1hd2FyZSBwcm9qZWN0IGltcGxlbWVudGF0aW9uLiIKICAgOnZlcnNp b24gIjI1LjEiCiAgIDpncm91cCAncHJvamVjdCkKIApAQCAtMzk3LDIxICs0MTQsNDggQEAg cHJvamVjdC12Yy1tZXJnZS1zdWJtb2R1bGVzCiAgIDpzYWZlICMnYm9vbGVhbnApCiAKIChk ZWZjdXN0b20gcHJvamVjdC12Yy1pbmNsdWRlLXVudHJhY2tlZCB0Ci0gICJXaGVuIG5vbi1u aWwsIHRoZSBWQyBwcm9qZWN0IGJhY2tlbmQgaW5jbHVkZXMgdW50cmFja2VkIGZpbGVzLiIK KyAgIldoZW4gbm9uLW5pbCwgdGhlIFZDLWF3YXJlIHByb2plY3QgYmFja2VuZCBpbmNsdWRl cyB1bnRyYWNrZWQgZmlsZXMuIgogICA6dHlwZSAnYm9vbGVhbgogICA6dmVyc2lvbiAiMjku MSIKICAgOnNhZmUgIydib29sZWFucCkKIAogKGRlZmN1c3RvbSBwcm9qZWN0LXZjLW5hbWUg bmlsCi0gICJXaGVuIG5vbi1uaWwsIHRoZSBuYW1lIG9mIHRoZSBjdXJyZW50IFZDIHByb2pl Y3QuCisgICJXaGVuIG5vbi1uaWwsIHRoZSBuYW1lIG9mIHRoZSBjdXJyZW50IFZDLWF3YXJl IHByb2plY3QuCiAKLVRoZSBiZXN0IHdheSB0byBjaGFuZ2UgdGhlIHZhbHVlIGEgVkMgcHJv amVjdCByZXBvcnRzIGFzIGl0cwotbmFtZSwgaXMgYnkgc2V0dGluZyB0aGlzIGluIC5kaXIt bG9jYWxzLmVsLiIKK1RoZSBiZXN0IHdheSB0byBjaGFuZ2UgdGhlIHZhbHVlIGEgVkMtYXdh cmUgcHJvamVjdCByZXBvcnRzIGFzCitpdHMgbmFtZSwgaXMgYnkgc2V0dGluZyB0aGlzIGlu IC5kaXItbG9jYWxzLmVsLiIKICAgOnR5cGUgJyhjaG9pY2UgKGNvbnN0IDp0YWcgIkRlZmF1 bHQgdG8gdGhlIGJhc2UgbmFtZSIgbmlsKQogICAgICAgICAgICAgICAgICAoc3RyaW5nIDp0 YWcgIkN1c3RvbSBuYW1lIikpCiAgIDp2ZXJzaW9uICIyOS4xIgogICA6c2FmZSAjJ3N0cmlu Z3ApCiAKKzs7IE5vdCB1c2luZyByZWdleHBzIGJlY2F1c2UgdGhlc2Ugd291bGRuJ3Qgd29y ayBpbiBHaXQgcGF0aHNwZWNzLCBpbgorOzsgY2FzZSB3ZSBkZWNpZGUgd2UgbmVlZCB0byBi ZSBhYmxlIHRvIGxpc3QgbmVzdGVkIHByb2plY3RzLgorKGRlZmN1c3RvbSBwcm9qZWN0LXZj LWV4dHJhLXJvb3QtbWFya2VycyBuaWwKKyAgIkxpc3Qgb2YgYWRkaXRpb25hbCBtYXJrZXJz IHRvIHNpZ25hbCBwcm9qZWN0IHJvb3RzLgorCitBIG1hcmtlciBpcyBlaXRoZXIgYSBiYXNl IGZpbGUgbmFtZSBvciBhIGdsb2IgcGF0dGVybiBmb3Igc3VjaC4KKworQSBkaXJlY3Rvcnkg Y29udGFpbmluZyBzdWNoIGEgbWFya2VyIGZpbGUgb3IgYSBmaWxlIG1hdGNoaW5nIGEKK21h cmtlciBwYXR0ZXJuIHdpbGwgYmUgcmVjb2duaXplZCBhcyB0aGUgcm9vdCBvZiBhIFZDLWF3 YXJlCitwcm9qZWN0LgorCitFeGFtcGxlIHZhbHVlczogXCIuZGlyLWxvY2Fscy5lbFwiLCBc InBhY2thZ2UuanNvblwiLCBcInBvbS54bWxcIiwKK1wicmVxdWlyZW1lbnRzLnR4dFwiLCBc IkdlbWZpbGVcIiwgXCIqLmdlbXNwZWNcIiwgXCJhdXRvZ2VuLnNoXCIuCisKK1RoZXNlIHdp bGwgYmUgdXNlZCBpbiBhZGRpdGlvbiB0byByZWd1bGFyIGRpcmVjdG9yeSBtYXJrZXJzIHN1 Y2gKK2FzIFwiLmdpdFwiLCBcIi5oZ1wiLCBhbmQgc28gb24sIGRlcGVuZGluZyBvbiB0aGUg dmFsdWUgb2YKK2B2Yy1oYW5kbGVkLWJhY2tlbmRzJy4gIEl0IGlzIG1vc3QgdXNlZnVsIHdo ZW4gYSBwcm9qZWN0IGhhcworc3ViZGlyZWN0b3JpZXMgaW5zaWRlIGl0IHRoYXQgbmVlZCB0 byBiZSBjb25zaWRlcmVkIGFzIHNlcGFyYXRlCitwcm9qZWN0cy4gIEl0IGNhbiBhbHNvIGJl IHVzZWQgZm9yIHByb2plY3RzIG91dHNpZGUgb2YgVkMKK3JlcG9zaXRvcmllcy4KKworSW4g ZWl0aGVyIGNhc2UsIHRoZWlyIGJlaGF2aW9yIHdpbGwgc3RpbGwgb2JleSB0aGUgcmVsZXZh bnQKK3ZhcmlhYmxlcywgc3VjaCBhcyBgcHJvamVjdC12Yy1pZ25vcmVzJyBvciBgcHJvamVj dC12Yy1uYW1lJy4iCisgIDp0eXBlICdsaXN0CisgIDp2ZXJzaW9uICIyOS4xIgorICA6c2Fm ZSAobGFtYmRhICh2YWwpIChhbmQgKGxpc3RwIHZhbCkgKGNsLWV2ZXJ5ICMnc3RyaW5ncCB2 YWwpKSkpCisKIDs7IEZJWE1FOiBVc2luZyB0aGUgY3VycmVudCBhcHByb2FjaCwgbWFqb3Ig bW9kZXMgYXJlIHN1cHBvc2VkIHRvIHNldAogOzsgdGhpcyB2YXJpYWJsZSB0byBhIGJ1ZmZl ci1sb2NhbCB2YWx1ZS4gIFNvIHdlIGRvbid0IGhhdmUgYWNjZXNzIHRvCiA7OyB0aGUgImV4 dGVybmFsIHJvb3RzIiBvZiBsYW5ndWFnZSBBIGZyb20gYnVmZmVycyBvZiBsYW5ndWFnZSBC LCB3aGljaApAQCAtNDIwLDcgKzQ2NCw3IEBAIHByb2plY3QtdmMtbmFtZQogOzsKIDs7IFdl IGNvdWxkIGFkZCBhIHNlY29uZCBhcmd1bWVudCB0byB0aGlzIGZ1bmN0aW9uOiBhIGZpbGUg ZXh0ZW5zaW9uLAogOzsgb3IgYSBsYW5ndWFnZSBuYW1lLiAgU29tZSBwcm9qZWN0cyB3aWxs IGtub3cgdGhlIHNldCBvZiBsYW5ndWFnZXMKLTs7IHVzZWQgaW4gdGhlbTsgZm9yIG90aGVy cywgbGlrZSBWQy1iYXNlZCBwcm9qZWN0cywgd2UnbGwgbmVlZAorOzsgdXNlZCBpbiB0aGVt OyBmb3Igb3RoZXJzLCBsaWtlIHRoZSBWQy1hd2FyZSB0eXBlLCB3ZSdsbCBuZWVkCiA7OyBh dXRvLWRldGVjdGlvbi4gIEkgc2VlIHR3byBvcHRpb25zOgogOzsKIDs7IC0gVGhhdCBjb3Vs ZCBiZSBpbXBsZW1lbnRlZCBhcyBhIHNlcGFyYXRlIHNlY29uZCBob29rLCB3aXRoIGEKQEAg LTQ0NCwzMiArNDg4LDU0IEBAIHByb2plY3QtdmMtZXh0ZXJuYWwtcm9vdHMtZnVuY3Rpb24K IEl0IHNob3VsZCByZXR1cm4gYSBsaXN0IG9mIGRpcmVjdG9yeSByb290cyB0aGF0IGNvbnRh aW4gc291cmNlCiBmaWxlcyByZWxhdGVkIHRvIHRoZSBjdXJyZW50IGJ1ZmZlci4KIAotVGhl IGRpcmVjdG9yeSBuYW1lcyBzaG91bGQgYmUgYWJzb2x1dGUuICBVc2VkIGluIHRoZSBWQyBw cm9qZWN0Ci1iYWNrZW5kIGltcGxlbWVudGF0aW9uIG9mIGBwcm9qZWN0LWV4dGVybmFsLXJv b3RzJy4iKQorVGhlIGRpcmVjdG9yeSBuYW1lcyBzaG91bGQgYmUgYWJzb2x1dGUuICBVc2Vk IGluIHRoZSBWQy1hd2FyZQorcHJvamVjdCBiYWNrZW5kIGltcGxlbWVudGF0aW9uIG9mIGBw cm9qZWN0LWV4dGVybmFsLXJvb3RzJy4iKQogCiAoZGVmdW4gcHJvamVjdC10cnktdmMgKGRp cikKKyAgKGRlZnZhciB2Yy1zdm4tYWRtaW4tZGlyZWN0b3J5KQorICAocmVxdWlyZSAndmMt c3ZuKQorICA7OyBGSVhNRTogTGVhcm4gdG8gaW52YWxpZGF0ZSB3aGVuIHRoZSB2YWx1ZSBv ZgorICA7OyBgcHJvamVjdC12Yy1tZXJnZS1zdWJtb2R1bGVzJyBvciBgcHJvamVjdC12Yy1l eHRyYS1yb290LW1hcmtlcnMnCisgIDs7IGNoYW5nZXMuCiAgIChvciAodmMtZmlsZS1nZXRw cm9wIGRpciAncHJvamVjdC12YykKLSAgICAgIChsZXQqICgoYmFja2VuZCAoaWdub3JlLWVy cm9ycyAodmMtcmVzcG9uc2libGUtYmFja2VuZCBkaXIpKSkKKyAgICAgIChsZXQqICgoYmFj a2VuZC1tYXJrZXJzLWFsaXN0IGAoKEdpdCAuICIuZ2l0IikKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKEhnIC4gIi5oZyIpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIChCenIgLiAiLmJ6ciIpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIChTVk4gLiAsdmMtc3ZuLWFkbWluLWRpcmVjdG9yeSkKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKERBUkNTIC4gIl9kYXJjcyIp CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChGb3NzaWwgLiAiLmZz bGNrb3V0IikpKQorICAgICAgICAgICAgIChiYWNrZW5kLW1hcmtlcnMKKyAgICAgICAgICAg ICAgKGRlbGV0ZQorICAgICAgICAgICAgICAgbmlsCisgICAgICAgICAgICAgICAobWFwY2Fy CisgICAgICAgICAgICAgICAgKGxhbWJkYSAoYikgKGFzc29jLWRlZmF1bHQgYiBiYWNrZW5k LW1hcmtlcnMtYWxpc3QpKQorICAgICAgICAgICAgICAgIHZjLWhhbmRsZWQtYmFja2VuZHMp KSkKKyAgICAgICAgICAgICAobWFya2VyLXJlCisgICAgICAgICAgICAgIChtYXBjb25jYXQK KyAgICAgICAgICAgICAgIChsYW1iZGEgKG0pIChmb3JtYXQgIlxcKCVzXFwpIiAod2lsZGNh cmQtdG8tcmVnZXhwIG0pKSkKKyAgICAgICAgICAgICAgIChhcHBlbmQgYmFja2VuZC1tYXJr ZXJzIHByb2plY3QtdmMtZXh0cmEtcm9vdC1tYXJrZXJzKQorICAgICAgICAgICAgICAgIlxc fCIpKQorICAgICAgICAgICAgIChsb2NhdGUtZG9taW5hdGluZy1zdG9wLWRpci1yZWdleHAK KyAgICAgICAgICAgICAgKG9yIHZjLWlnbm9yZS1kaXItcmVnZXhwIGxvY2F0ZS1kb21pbmF0 aW5nLXN0b3AtZGlyLXJlZ2V4cCkpCisgICAgICAgICAgICAgbGFzdC1tYXRjaGVzCiAgICAg ICAgICAgICAgKHJvb3QKLSAgICAgICAgICAgICAgKHBjYXNlIGJhY2tlbmQKLSAgICAgICAg ICAgICAgICAoJ0dpdAotICAgICAgICAgICAgICAgICA7OyBEb24ndCBzdG9wIGF0IHN1Ym1v ZHVsZSBib3VuZGFyeS4KLSAgICAgICAgICAgICAgICAgKG9yICh2Yy1maWxlLWdldHByb3Ag ZGlyICdwcm9qZWN0LWdpdC1yb290KQotICAgICAgICAgICAgICAgICAgICAgKGxldCAoKHJv b3QgKHZjLWNhbGwtYmFja2VuZCBiYWNrZW5kICdyb290IGRpcikpKQotICAgICAgICAgICAg ICAgICAgICAgICAodmMtZmlsZS1zZXRwcm9wCi0gICAgICAgICAgICAgICAgICAgICAgICBk aXIgJ3Byb2plY3QtZ2l0LXJvb3QKLSAgICAgICAgICAgICAgICAgICAgICAgIChpZiAoYW5k Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IEZJWE1FOiBJbnZhbGlkYXRlIHRo ZSBjYWNoZSB3aGVuIHRoZSB2YWx1ZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7 OyBvZiB0aGlzIHZhcmlhYmxlIGNoYW5nZXMuCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHByb2plY3QtdmMtbWVyZ2Utc3VibW9kdWxlcwotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAocHJvamVjdC0tc3VibW9kdWxlLXAgcm9vdCkpCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgKGxldCogKChwYXJlbnQgKGZpbGUtbmFtZS1kaXJlY3RvcnkKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGRpcmVjdG9yeS1maWxl LW5hbWUgcm9vdCkpKSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2Yy1jYWxs LWJhY2tlbmQgYmFja2VuZCAncm9vdCBwYXJlbnQpKQotICAgICAgICAgICAgICAgICAgICAg ICAgICByb290KSkpKSkKLSAgICAgICAgICAgICAgICAoJ25pbCBuaWwpCi0gICAgICAgICAg ICAgICAgKF8gKGlnbm9yZS1lcnJvcnMgKHZjLWNhbGwtYmFja2VuZCBiYWNrZW5kICdyb290 IGRpcikpKSkpCisgICAgICAgICAgICAgIChsb2NhdGUtZG9taW5hdGluZy1maWxlCisgICAg ICAgICAgICAgICBkaXIKKyAgICAgICAgICAgICAgIChsYW1iZGEgKGQpCisgICAgICAgICAg ICAgICAgIChzZXRxIGxhc3QtbWF0Y2hlcyAoZGlyZWN0b3J5LWZpbGVzIGQgbmlsIG1hcmtl ci1yZSB0IDEwMCkpKSkpCisgICAgICAgICAgICAgKGJhY2tlbmQKKyAgICAgICAgICAgICAg KGNsLWZpbmQtaWYKKyAgICAgICAgICAgICAgIChsYW1iZGEgKGIpCisgICAgICAgICAgICAg ICAgIChtZW1iZXIgKGFzc29jLWRlZmF1bHQgYiBiYWNrZW5kLW1hcmtlcnMtYWxpc3QpCisg ICAgICAgICAgICAgICAgICAgICAgICAgbGFzdC1tYXRjaGVzKSkKKyAgICAgICAgICAgICAg IHZjLWhhbmRsZWQtYmFja2VuZHMpKQogICAgICAgICAgICAgIHByb2plY3QpCisgICAgICAg ICh3aGVuIChhbmQKKyAgICAgICAgICAgICAgIChlcSBiYWNrZW5kICdHaXQpCisgICAgICAg ICAgICAgICBwcm9qZWN0LXZjLW1lcmdlLXN1Ym1vZHVsZXMKKyAgICAgICAgICAgICAgIChw cm9qZWN0LS1zdWJtb2R1bGUtcCByb290KSkKKyAgICAgICAgICAobGV0KiAoKHBhcmVudCAo ZmlsZS1uYW1lLWRpcmVjdG9yeSAoZGlyZWN0b3J5LWZpbGUtbmFtZSByb290KSkpKQorICAg ICAgICAgICAgKHNldHEgcm9vdCAodmMtY2FsbC1iYWNrZW5kICdHaXQgJ3Jvb3QgcGFyZW50 KSkpKQogICAgICAgICAod2hlbiByb290CiAgICAgICAgICAgKHNldHEgcHJvamVjdCAobGlz dCAndmMgYmFja2VuZCByb290KSkKICAgICAgICAgICA7OyBGSVhNRTogQ2FjaGUgZm9yIGEg c2hvcnRlciB0aW1lLgpAQCAtNjI3LDcgKzY5Myw4IEBAIHByb2plY3QtaWdub3JlcwogICAo bGV0KiAoKHJvb3QgKG50aCAyIHByb2plY3QpKQogICAgICAgICAgYmFja2VuZCkKICAgICAo YXBwZW5kCi0gICAgICh3aGVuIChmaWxlLWVxdWFsLXAgZGlyIHJvb3QpCisgICAgICh3aGVu IChhbmQgYmFja2VuZAorICAgICAgICAgICAgICAgIChmaWxlLWVxdWFsLXAgZGlyIHJvb3Qp KQogICAgICAgIChzZXRxIGJhY2tlbmQgKGNhZHIgcHJvamVjdCkpCiAgICAgICAgKGRlbHEK ICAgICAgICAgbmlsCg== --------------003oVGRm91FttH49rl1nD5mM-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 15:33:10 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 20:33:10 +0000 Received: from localhost ([127.0.0.1]:34950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0TlV-0005MP-RN for submit@debbugs.gnu.org; Wed, 30 Nov 2022 15:33:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0TlT-0005M5-3o for 41572@debbugs.gnu.org; Wed, 30 Nov 2022 15:33:08 -0500 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 1p0TlK-0001ht-Pe; Wed, 30 Nov 2022 15:32:58 -0500 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=iEcK5RkFp2ABJTVL+kC6vkEUPqX3c2GQCd8vGILm54U=; b=bqJpSjOdMux4 onDoKSR5Fr8wYIkR/bKBZyjhxSAaYbgqFQe7sfHL16fIMNFJW6mTs3QcE7OZQiKQyEJUGOjYGpE1B KLFFNd46j8LIHVRQ33j3f8464Cp48pn+QtWuCdl+NSD0x6/eOm1H4nK2KggS5qri81wszE9LnPRgX cMFvueCFggQJxgP1m4tTD2ByCiMccCDjk55+N2q/o0F/gaeIAq68K8AICJiZUVDTzhCvtjUVSruMZ AiuIJ+zMfulVZIlIn9rPnragnpASTEcHBaMtGvc03Fg2pSm0WspCC46J3VkGW694QF6KExKWLSUFp iuv6VFPHjRUahlKKwTMo+A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0TlJ-0008Lc-8N; Wed, 30 Nov 2022 15:32:58 -0500 Date: Wed, 30 Nov 2022 22:32:27 +0200 Message-Id: <83wn7ci3ok.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> (message from Dmitry Gutov on Wed, 30 Nov 2022 20:52:32 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Wed, 30 Nov 2022 20:52:32 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > >> Eli, what do you think about this feature > >> (project-vc-extra-root-markers) for emacs-29? > > Where can I see the code that you are proposing? > > Here you go, I also added some documentation updates and 2 tests. Thanks. But I don't see any tests... > +;; If the repository is using any other VCS than Git or Hg, the file > +;; listing uses the default mechanism based on 'find'. Instead of a literal 'find', this should probably say something like If the repository is using any other VCS than Git or Hg, the file listing uses the default mechanism based on the program specified by `find-program'. > (defun project-try-vc (dir) > + (defvar vc-svn-admin-directory) > + (require 'vc-svn) > + ;; FIXME: Learn to invalidate when the value of > + ;; `project-vc-merge-submodules' or `project-vc-extra-root-markers' > + ;; changes. > (or (vc-file-getprop dir 'project-vc) > - (let* ((backend (ignore-errors (vc-responsible-backend dir))) > + (let* ((backend-markers-alist `((Git . ".git") > + (Hg . ".hg") > + (Bzr . ".bzr") > + (SVN . ,vc-svn-admin-directory) > + (DARCS . "_darcs") > + (Fossil . ".fslckout"))) > + (backend-markers > + (delete > + nil > + (mapcar > + (lambda (b) (assoc-default b backend-markers-alist)) > + vc-handled-backends))) > + (marker-re > + (mapconcat > + (lambda (m) (format "\\(%s\\)" (wildcard-to-regexp m))) > + (append backend-markers project-vc-extra-root-markers) > + "\\|")) > + (locate-dominating-stop-dir-regexp > + (or vc-ignore-dir-regexp locate-dominating-stop-dir-regexp)) > + last-matches > (root > - (pcase backend > - ('Git > - ;; Don't stop at submodule boundary. > - (or (vc-file-getprop dir 'project-git-root) > - (let ((root (vc-call-backend backend 'root dir))) > - (vc-file-setprop > - dir 'project-git-root > - (if (and > - ;; FIXME: Invalidate the cache when the value > - ;; of this variable changes. > - project-vc-merge-submodules > - (project--submodule-p root)) > - (let* ((parent (file-name-directory > - (directory-file-name root)))) > - (vc-call-backend backend 'root parent)) > - root))))) > - ('nil nil) > - (_ (ignore-errors (vc-call-backend backend 'root dir))))) > + (locate-dominating-file > + dir > + (lambda (d) > + (setq last-matches (directory-files d nil marker-re t 100))))) > + (backend > + (cl-find-if > + (lambda (b) > + (member (assoc-default b backend-markers-alist) > + last-matches)) > + vc-handled-backends)) > project) > + (when (and > + (eq backend 'Git) > + project-vc-merge-submodules > + (project--submodule-p root)) > + (let* ((parent (file-name-directory (directory-file-name root)))) > + (setq root (vc-call-backend 'Git 'root parent)))) > (when root > (setq project (list 'vc backend root)) > ;; FIXME: Cache for a shorter time. This is a significant change of the implementation of a public API. Isn't it risky to make such changes on the release branch? But if you are okay with that, it's fine by me. From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 15:44:12 2022 Received: (at 41572) by debbugs.gnu.org; 30 Nov 2022 20:44:12 +0000 Received: from localhost ([127.0.0.1]:34999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0TwB-0005Rq-Kw for submit@debbugs.gnu.org; Wed, 30 Nov 2022 15:44:12 -0500 Received: from mail-wr1-f47.google.com ([209.85.221.47]:38805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0Tw9-0005Rk-K5 for 41572@debbugs.gnu.org; Wed, 30 Nov 2022 15:44:10 -0500 Received: by mail-wr1-f47.google.com with SMTP id f18so6973097wrj.5 for <41572@debbugs.gnu.org>; Wed, 30 Nov 2022 12:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=tixdR0I/Qn9iWcg4LDBEG3dBaAPp4P1uj5vgOTFGVYo=; b=XPzt5OarCgFJn9/yiWaE13tFzCeOPO5bkgLKYuVg5rW8DYy34tzIIUVBu0tfDQO36h 0XjyiMo4diWMASEb+d1rFrb49qzaGwkI6nMsrea2SQZ973mqYT4dE9oif1Qjc4/vQmrk g7vQwIIL4auNlNuVmPFlQXgpZ5PjXp3NFm32JNlYO3k13fkelh6WhTSxAcUvx/lcfBNB Ll9NhXT6n2tyJEehZMN/I9yJqT5pp7LAUwKufJaL/brJ4PT6J3h5UkJLtR+UsTKKiPlp gUM2WAIE3vFy+/pfJvHoIr6K7o7HefktkFnxpmV37fOjgCaKyabZGP7OvQ3hI/6uzwfE x4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tixdR0I/Qn9iWcg4LDBEG3dBaAPp4P1uj5vgOTFGVYo=; b=KcNyeuto462wuA+R8RmY463x1xvCor5A9qH73ZtD0BILzAgPjlQydOGSEkag1o04Nj qfOF6tHrrA/34cy9enBuwJGmfNoRmpnR1l6zIuZFqdSoSLRXOoxA0uKfZQati1hHoAVS uxmKsqXipURdVF6ZfgJzlSZr3UNOVCSsFfXDEaf0c5godZaPu2PBQfFy0Qn26wa8h1g+ kbiRtRgkg9DsCtoFKLt7T0UO3wf6HxA9W7XYw+juS+xlDNUPkmmLymuNvjVpPf35VvBW 4A2tHhGR7Fb8VHiVccySARsjIn8ZYcH3v4oT9kJ6+zIEV6grN4DpIFv9U9mvZZOx3dk6 4F+g== X-Gm-Message-State: ANoB5pnYzTnefSn2YouPjqe2csG2SkbG55mEpwJ0Kk8sQUpwWeuFMAVD YohvL2ZqWSu2/3gEFvFJ/GY= X-Google-Smtp-Source: AA0mqf4sTB6HwrvMklxtiXdaSQb82tm85uohzJUITVsLK8yibV9VZlrO4tIlGEl7/FYj9YYdJHHILw== X-Received: by 2002:adf:f443:0:b0:242:eb1:5b78 with SMTP id f3-20020adff443000000b002420eb15b78mr13023976wrp.158.1669841043650; Wed, 30 Nov 2022 12:44:03 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c14-20020a05600c0a4e00b003cffd3c3d6csm3080104wmq.12.2022.11.30.12.44.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 12:44:03 -0800 (PST) Message-ID: <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> Date: Wed, 30 Nov 2022 22:43:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> <83wn7ci3ok.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83wn7ci3ok.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 22:32, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 20:52:32 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.47 listed in list.dnswl.org] 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.47 listed in wl.mailspike.net] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30/11/2022 22:32, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 20:52:32 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.47 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.47 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 30/11/2022 22:32, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 20:52:32 +0200 >> Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, >> joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, >> salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org >> From: Dmitry Gutov >> >>>> Eli, what do you think about this feature >>>> (project-vc-extra-root-markers) for emacs-29? >>> Where can I see the code that you are proposing? >> >> Here you go, I also added some documentation updates and 2 tests. > > Thanks. But I don't see any tests... Sorry, missed them in this patch. They don't really need an advance review, though, so just see them later. >> +;; If the repository is using any other VCS than Git or Hg, the file >> +;; listing uses the default mechanism based on 'find'. > > Instead of a literal 'find', this should probably say something like > > If the repository is using any other VCS than Git or Hg, the file > listing uses the default mechanism based on the program specified by > `find-program'. Sure, thanks. >> (defun project-try-vc (dir) >> + (defvar vc-svn-admin-directory) >> + (require 'vc-svn) >> + ;; FIXME: Learn to invalidate when the value of >> + ;; `project-vc-merge-submodules' or `project-vc-extra-root-markers' >> + ;; changes. >> (or (vc-file-getprop dir 'project-vc) >> - (let* ((backend (ignore-errors (vc-responsible-backend dir))) >> + (let* ((backend-markers-alist `((Git . ".git") >> + (Hg . ".hg") >> + (Bzr . ".bzr") >> + (SVN . ,vc-svn-admin-directory) >> + (DARCS . "_darcs") >> + (Fossil . ".fslckout"))) >> + (backend-markers >> + (delete >> + nil >> + (mapcar >> + (lambda (b) (assoc-default b backend-markers-alist)) >> + vc-handled-backends))) >> + (marker-re >> + (mapconcat >> + (lambda (m) (format "\\(%s\\)" (wildcard-to-regexp m))) >> + (append backend-markers project-vc-extra-root-markers) >> + "\\|")) >> + (locate-dominating-stop-dir-regexp >> + (or vc-ignore-dir-regexp locate-dominating-stop-dir-regexp)) >> + last-matches >> (root >> - (pcase backend >> - ('Git >> - ;; Don't stop at submodule boundary. >> - (or (vc-file-getprop dir 'project-git-root) >> - (let ((root (vc-call-backend backend 'root dir))) >> - (vc-file-setprop >> - dir 'project-git-root >> - (if (and >> - ;; FIXME: Invalidate the cache when the value >> - ;; of this variable changes. >> - project-vc-merge-submodules >> - (project--submodule-p root)) >> - (let* ((parent (file-name-directory >> - (directory-file-name root)))) >> - (vc-call-backend backend 'root parent)) >> - root))))) >> - ('nil nil) >> - (_ (ignore-errors (vc-call-backend backend 'root dir))))) >> + (locate-dominating-file >> + dir >> + (lambda (d) >> + (setq last-matches (directory-files d nil marker-re t 100))))) >> + (backend >> + (cl-find-if >> + (lambda (b) >> + (member (assoc-default b backend-markers-alist) >> + last-matches)) >> + vc-handled-backends)) >> project) >> + (when (and >> + (eq backend 'Git) >> + project-vc-merge-submodules >> + (project--submodule-p root)) >> + (let* ((parent (file-name-directory (directory-file-name root)))) >> + (setq root (vc-call-backend 'Git 'root parent)))) >> (when root >> (setq project (list 'vc backend root)) >> ;; FIXME: Cache for a shorter time. > > This is a significant change of the implementation of a public API. Isn't > it risky to make such changes on the release branch? > > But if you are okay with that, it's fine by me. A little bit, yeah. But I've done some dogfooding, and we have a couple of months before the release, right? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 30 21:20:27 2022 Received: (at 41572-done) by debbugs.gnu.org; 1 Dec 2022 02:20:27 +0000 Received: from localhost ([127.0.0.1]:36548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0ZBb-0000cv-AW for submit@debbugs.gnu.org; Wed, 30 Nov 2022 21:20:27 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:36708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0ZBa-0000cp-AW for 41572-done@debbugs.gnu.org; Wed, 30 Nov 2022 21:20:26 -0500 Received: by mail-wr1-f53.google.com with SMTP id z4so505795wrr.3 for <41572-done@debbugs.gnu.org>; Wed, 30 Nov 2022 18:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=NUtXHZ5LBLWMzCoGgo1YENkWOUVa0MB4zt3r6XujEFc=; b=q7VNRPII1Y0zHyOtPeED5J+OCZ4LCujUkxnOH6oyi2NXQslw4rcwiypsNHRxoLOw+D DWSBVhk3QnSCawXoDdSF4a8huE6nYdeYWfs8Tj+eVBt5QO4rraNtbeaeL2LT2COUTY3+ 9sj8xpvjjyVMR0iwrHFrWh/NtrHPNgXHoKbPX4iMCHEq2jym/b8zyIYJQe0Feub/Thf0 Arqo/AbsL6kjBBlZLs2sXbzal4DL6hLSUTFn5325+gicds9m6FlI22y4G4C/gu/G/K2X RTzm3zLcenvdK95fGRzHHkLH6R3Pd9hMWgdKBow4FV7f9mC9CZmEHUohdUC+3qiIFkTl ZKUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NUtXHZ5LBLWMzCoGgo1YENkWOUVa0MB4zt3r6XujEFc=; b=cUPR9b9lFQfzRlGFzSxMXzN32ujm5Ls8+3mqNULUmBUWzwAcqop4/T+2XajavhjDF0 Hc2y9OQVWu1b0uu7zhZV6NIPgMJZpA83pGa1QGR21eSc8E9f2vqJ1JqJbSKu5El6D/BR Y3LV3aY99fAZrihLWNdEqiL+xY2qHIE7BuoVfD2na2jXVSuneX75j8ZL+Ru5dk2uV6Lw 7skItQS0B8egDn7oGxjRmINabsZFdkvQqYmhi66CzreAKrUWdm0VjSkiMGX8kgablqto 7KbNNjp+mJXxYp/dD5LGk4f1hd/ucckatAmj9tWMDhDK8LlJ5NxGHerzMkOT1Xek5P/4 5z5w== X-Gm-Message-State: ANoB5pnmGNeY+Kr6k1gT6HmtPvw0xmvXZWVxUts/H8zaYsuahPw7/zaU wy6n9pB6pEPVkeWHakwPrvk= X-Google-Smtp-Source: AA0mqf4+JKKeMP7Lm6MPCsJxTbRn+Vny01m15wIgh9YQKWLOfzfBqllDXDTliuyOn9gtkkw8A3BmWg== X-Received: by 2002:a5d:44c4:0:b0:242:3140:54c6 with SMTP id z4-20020a5d44c4000000b00242314054c6mr2509408wrr.252.1669861220407; Wed, 30 Nov 2022 18:20:20 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n14-20020a05600c4f8e00b003c6f3f6675bsm8143614wmq.26.2022.11.30.18.19.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 18:19:58 -0800 (PST) Message-ID: <9a66f6fc-c08b-02b3-7780-e08a945a1751@yandex.ru> Date: Thu, 1 Dec 2022 04:19:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US From: Dmitry Gutov To: Eli Zaretskii References: <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> <83wn7ci3ok.fsf@gnu.org> <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> In-Reply-To: <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Version: 29.1 On 30/11/2022 22:43, Dmitry Gutov wrote: >> >> This is a significant change of the implementation of a public API. >> Isn't >> it risky to make such changes on the release branch? >> >> But if you are [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.53 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.53 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572-done Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, 41572-done@debbugs.gnu.org, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com 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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Version: 29.1 On 30/11/2022 22:43, Dmitry Gutov wrote: >> >> This is a significant change of the implementation of a public API. >> Isn't >> it risky to make such changes on the release branch? >> >> But if you are [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.221.53 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.221.53 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) Version: 29.1 On 30/11/2022 22:43, Dmitry Gutov wrote: >> >> This is a significant change of the implementation of a public API. >> Isn't >> it risky to make such changes on the release branch? >> >> But if you are okay with that, it's fine by me. > > A little bit, yeah. But I've done some dogfooding, and we have a couple > of months before the release, right? And now pushed to emacs-29. Looks like time to close this bug (and the merged one). The new user option project-vc-extra-root-markers should cover the described use cases in both feature requests. The default is nil, though, so people will need to customize. Not every idea from this discussion has made it in, but we can get back to them later. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 01 01:03:25 2022 Received: (at 41572) by debbugs.gnu.org; 1 Dec 2022 06:03:25 +0000 Received: from localhost ([127.0.0.1]:37520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0cfM-0004lh-UR for submit@debbugs.gnu.org; Thu, 01 Dec 2022 01:03:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0cfJ-0004lZ-ON for 41572@debbugs.gnu.org; Thu, 01 Dec 2022 01:03:22 -0500 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 1p0cfC-0000zi-Qj; Thu, 01 Dec 2022 01:03:14 -0500 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=nPEQnHgRxgoiXIxiHaumEonkU1EdbbHhtEY6T74XRvE=; b=eOYpKuUvF/hA U21E89qTOEb/RdhV1arqvmx7sb79ngBWjUhICBO2iKVOnLrLjDqAiUB4Y4+MZvwIcwgY7YfuoPwJA +X4ez24UT5i9WHsnpejKJ3e7bSIT5AlpSTxRTE8bHiKibGC/BApr0ynawLzH1ctY4fFooMSbZQuPf +tsVvKqSEkWXVzV3q5yZ8eqvNotwaA9evsApl/umcV1oqRfZmF2ix+uCeDzVu+BQB57jBxAG7lwn7 AvPu5gE3mZ2mpynQkOb1o6OsvpTsop30+43SomF8zVN87UPE4X4IlGxFODhZe+37/wW8ZVTIoGSX0 5RMafOGjCt3IkvAsbI/U7g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0cfA-00084k-TL; Thu, 01 Dec 2022 01:03:14 -0500 Date: Thu, 01 Dec 2022 08:02:42 +0200 Message-Id: <83v8mvirul.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> (message from Dmitry Gutov on Wed, 30 Nov 2022 22:43:59 +0200) Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project References: <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> <83wn7ci3ok.fsf@gnu.org> <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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 (/) > Date: Wed, 30 Nov 2022 22:43:59 +0200 > Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, > cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, > joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, > salutis@me.com, arstoffel@gmail.com, 41572@debbugs.gnu.org > From: Dmitry Gutov > > > This is a significant change of the implementation of a public API. Isn't > > it risky to make such changes on the release branch? > > > > But if you are okay with that, it's fine by me. > > A little bit, yeah. But I've done some dogfooding, and we have a couple > of months before the release, right? Yes. The question is, how much will this be used till then. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 01 10:08:26 2022 Received: (at 41572) by debbugs.gnu.org; 1 Dec 2022 15:08:26 +0000 Received: from localhost ([127.0.0.1]:40199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0lAo-0008Vq-9o for submit@debbugs.gnu.org; Thu, 01 Dec 2022 10:08:26 -0500 Received: from mail-wm1-f46.google.com ([209.85.128.46]:55205) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0lAm-0008Vk-Ep for 41572@debbugs.gnu.org; Thu, 01 Dec 2022 10:08:25 -0500 Received: by mail-wm1-f46.google.com with SMTP id t1so1369189wmi.4 for <41572@debbugs.gnu.org>; Thu, 01 Dec 2022 07:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=JqN8BCbBaXUCqN744yO+BnaE0tI9jcth3Ni/yPde050=; b=Ab8MWStiijoajpYzp1HCnpAeV2rAB6NwkOUhLOK/JsX+kkXsIzAnV60CTKDX9YYUVB qDgj2O82NA1zXWDhVHpze1Rq9ccRfkgR6PSbBB35vDbXstmGizF0RrHg8ySjftllZvFN 09C02Rn0EOhcUvfC1m++q65IR5Fd5dAAu80qr5+xV1WSz4vj6ijSpBmMKsBr6FNxpSds xjAQ+xaK58n5UkeJr5DTbt15I/B0CqXFqz264zL0K5TnD7X3Lov02hRy0qbl6T/yHvtx LkFEDC4XpwdLnYeLid+ci176SpiqkfgkYnwTEiea1Qq4mJ68u97LavaoA46y4cBV16KT 5LEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JqN8BCbBaXUCqN744yO+BnaE0tI9jcth3Ni/yPde050=; b=29U/xlwN5U2lIlapF+V7ikODM5lXJ0nstRNtJPytoQaVEP0KD3YmvMngfKUeRjyEU8 VGsUDXJNIaR3QPWb5JwPrawRN+NVb1EAVK5dtDfXoeD/LNYKjceZnQ2VJ5RRapyqmCYB KLqA2gKStNZ4WoOGGtz2kxzQUDn9gu4J2nFAFJKNs7XFEmnFAn2iuWQ8Gko0KOU4DNC5 4MuxFyajHuOUFmxmaF110yLlPvHpzJMc5CIFlHW/99PUubVMqQcMKkERRJN0+MyJY2FK BZ82w6fxebLVuc8eJ4BLNAP79yzb6V1SADivxkewGXODyTiJJp4e5embPnaoplznSY5l E/Bg== X-Gm-Message-State: ANoB5pmj4/S0uwAG0ZupRwqxO6h26plon+58phdlq4bkWBl+8ZAh/QL/ BZM2AhJamBcKTT32cb/Al1I= X-Google-Smtp-Source: AA0mqf6dZmu/0UMziBwELxQyB1I4Ag2DmmLoZLySf4Q2oN9XAa1eSo6JBkHkfu9K4tkl+xKv9liP0w== X-Received: by 2002:a1c:c918:0:b0:3cf:f2aa:3dc2 with SMTP id f24-20020a1cc918000000b003cff2aa3dc2mr39011089wmb.175.1669907298511; Thu, 01 Dec 2022 07:08:18 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id hg6-20020a05600c538600b003a6125562e1sm5581640wmb.46.2022.12.01.07.08.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Dec 2022 07:08:17 -0800 (PST) Message-ID: <92c4d773-9ce1-6ef9-5a58-96d7506a179c@yandex.ru> Date: Thu, 1 Dec 2022 17:08:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Content-Language: en-US To: Eli Zaretskii References: <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <83sfi6tavq.fsf@gnu.org> <83mt8dssdn.fsf@gnu.org> <29c1c5f3-b189-ff30-c5bc-92a4d35e0683@yandex.ru> <83fse4rj2s.fsf@gnu.org> <2bc8b5dd-83c9-8bbc-82d5-e296f60e47c3@yandex.ru> <83lenwpj5k.fsf@gnu.org> <83fse4pctt.fsf@gnu.org> <8335a3p9xy.fsf@gnu.org> <62aab865-7c71-8c12-9e51-688f588b1e51@yandex.ru> <83lenvnrgs.fsf@gnu.org> <83a64bnngm.fsf@gnu.org> <834jujnhtr.fsf@gnu.org> <14c44382-1c57-4c09-d9ae-7991b8296572@yandex.ru> <83edtklge2.fsf@gnu.org> <162e7230-8295-884f-6ed0-04920b8b5325@yandex.ru> <83wn7ci3ok.fsf@gnu.org> <70b78ec2-c74a-b4fc-a928-bbc1f2c567d5@yandex.ru> <83v8mvirul.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83v8mvirul.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/12/2022 08:02, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 22:43:59 +0200 >> Cc:philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.0 MANY_TO_CC Sent to 10+ recipients -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.46 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.46 listed in wl.mailspike.net] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 41572 Cc: philipk@posteo.net, rudi@constantly.at, eric@ericabrahamsen.net, cjpeople2013@gmail.com, theo@thornhill.no, mardani29@yahoo.es, joaotavora@gmail.com, manuel.uberti@inventati.org, juri@linkov.net, salutis@me.com, arstoffel@gmail.com, 41572@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: 2.2 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/12/2022 08:02, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 22:43:59 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mard [...] Content analysis details: (2.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.128.46 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.128.46 listed in wl.mailspike.net] 3.0 MANY_TO_CC Sent to 10+ recipients 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 01/12/2022 08:02, Eli Zaretskii wrote: >> Date: Wed, 30 Nov 2022 22:43:59 +0200 >> Cc:philipk@posteo.net,rudi@constantly.at,eric@ericabrahamsen.net, >> cjpeople2013@gmail.com,theo@thornhill.no,mardani29@yahoo.es, >> joaotavora@gmail.com,manuel.uberti@inventati.org,juri@linkov.net, >> salutis@me.com,arstoffel@gmail.com,41572@debbugs.gnu.org >> From: Dmitry Gutov >> >>> This is a significant change of the implementation of a public API. Isn't >>> it risky to make such changes on the release branch? >>> >>> But if you are okay with that, it's fine by me. >> A little bit, yeah. But I've done some dogfooding, and we have a couple >> of months before the release, right? > Yes. The question is, how much will this be used till then. True enough. I've updated the docs and NEWS in the meantime, this should help. On the bright side, though, the new feature uses the same code path as the core functionality, so it's still indirectly tested by anyone using the built-in project support. From unknown Wed Jun 18 00:21:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 30 Dec 2022 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator