GNU bug report logs - #41572
28.0.50; [PATCH] Support plain project marked with file .emacs-project

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Zhu Zihao <cjpeople2013@HIDDEN>; merged with #54228; dated Thu, 28 May 2020 04:46:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
Removed tag(s) patch. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Forcibly Merged 41572 54228. Request was from Juri Linkov <juri@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 11:53:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 17 07:53:00 2021
Received: from localhost ([127.0.0.1]:43674 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mc4iq-0002z5-Bp
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mc4in-0002yq-M8
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
 <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
 <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
 <a8681281-b33d-b1f1-a87d-92754b115b0e@HIDDEN>
 <f11b40c6-ec15-426b-d78c-f86085b4669d@HIDDEN>
 <cc8052d9-c53c-6bd9-5964-90a93132f519@HIDDEN>
Message-ID: <444b6c1f-00f1-54ef-f692-cc3d6f30b93e@HIDDEN>
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: <cc8052d9-c53c-6bd9-5964-90a93132f519@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 02:48:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 16 22:48:17 2021
Received: from localhost ([127.0.0.1]:43327 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mbwDh-00042R-1r
	for submit <at> 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 <raaahh@HIDDEN>) id 1mbwDf-00042D-0P
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
 <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
 <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
 <a8681281-b33d-b1f1-a87d-92754b115b0e@HIDDEN>
 <f11b40c6-ec15-426b-d78c-f86085b4669d@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <cc8052d9-c53c-6bd9-5964-90a93132f519@HIDDEN>
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: <f11b40c6-ec15-426b-d78c-f86085b4669d@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 18:06:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 11 14:06:15 2021
Received: from localhost ([127.0.0.1]:60869 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mZzgh-0004Fm-Fo
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mZzgb-0004F9-9L
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
 <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
 <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
 <a8681281-b33d-b1f1-a87d-92754b115b0e@HIDDEN>
Message-ID: <f11b40c6-ec15-426b-d78c-f86085b4669d@HIDDEN>
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: <a8681281-b33d-b1f1-a87d-92754b115b0e@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 01:57:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 10 21:57:16 2021
Received: from localhost ([127.0.0.1]:56165 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mZkZ1-000282-W8
	for submit <at> 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 <raaahh@HIDDEN>) id 1mZkYz-00027o-O6
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
 <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
 <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <a8681281-b33d-b1f1-a87d-92754b115b0e@HIDDEN>
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: <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 00:40:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 10 20:40:59 2021
Received: from localhost ([127.0.0.1]:56119 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mZjNC-0000BJ-TU
	for submit <at> 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 <raaahh@HIDDEN>) id 1mZjN9-0000B2-5T
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
 <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN>
 <87wnmppdmr.fsf@HIDDEN>
 <966ef00b-fc7a-cd52-5fd8-600842797f65@HIDDEN>
 <87v925f6ee.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <564eb0ed-21c0-f298-a7e9-30d7caf7517f@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 10 Oct 2021 17:33:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 10 13:33:14 2021
Received: from localhost ([127.0.0.1]:55768 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mZchG-0001ol-2g
	for submit <at> 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 <juri@HIDDEN>) id 1mZchB-0001oQ-Qx
 for 41572 <at> debbugs.gnu.org; Sun, 10 Oct 2021 13:33:10 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay10.mail.gandi.net (Postfix) with ESMTPSA id 9FA2B240005;
 Sun, 10 Oct 2021 17:33:00 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
 <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN>
 <87wnmppdmr.fsf@HIDDEN>
 <966ef00b-fc7a-cd52-5fd8-600842797f65@HIDDEN>
Date: Sun, 10 Oct 2021 19:47:37 +0300
In-Reply-To: <966ef00b-fc7a-cd52-5fd8-600842797f65@HIDDEN> (Dmitry Gutov's
 message of "Thu, 7 Oct 2021 16:41:23 +0300")
Message-ID: <87v925f6ee.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 8 Oct 2021 16:24:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 08 12:24:17 2021
Received: from localhost ([127.0.0.1]:51808 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYsfR-0002Qy-30
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mYsfO-0002Qk-P9
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
 <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
Message-ID: <d60e45bd-4ef4-545d-6099-6939abfea663@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 8 Oct 2021 02:12:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 07 22:12:55 2021
Received: from localhost ([127.0.0.1]:48739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYfNW-00078z-Ka
	for submit <at> 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 <raaahh@HIDDEN>) id 1mYfNR-00078e-N7
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
 <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <50249566-fc74-bed1-6a7d-52acc3876187@HIDDEN>
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: <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:41:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 07 09:41:42 2021
Received: from localhost ([127.0.0.1]:46465 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYTeX-0002Jg-W5
	for submit <at> 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 <raaahh@HIDDEN>) id 1mYTeU-0002JS-9U
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
 <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN>
 <87wnmppdmr.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <966ef00b-fc7a-cd52-5fd8-600842797f65@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:08:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 07 09:08:57 2021
Received: from localhost ([127.0.0.1]:46371 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYT8q-0001QP-PM
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mYT8l-0001QA-1w
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
 <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
Message-ID: <ad622b76-b650-80af-668f-f8f0de79f0d0@HIDDEN>
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@HIDDEN>
Content-Type: multipart/alternative;
 boundary="------------78F2A7CAFC7AF51B310FFF41"
Content-Language: en-US
X-Spam-Score: -0.1 (/)
X-Debbugs-Envelope-To: 41572
Cc: Zhu Zihao <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>
      <blockquote type="cite">When should we not do it?
      </blockquote>
      Personal preference. I'd probably never hide subproject files in
      99% of the projects I work on.</p>
    <p>
      <blockquote type="cite">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.</blockquote>
      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.</p>
    <p class="tableblock">
      <blockquote type="cite">why not have a single backend for that
        purpose, with a custom var containing the list of files names?</blockquote>
      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.</p>
    <p class="tableblock">So we have at least two reasons to prefer
      adding actual separate backends over one catch-all filename based.
      Orderability and customizability.</p>
    <p class="tableblock">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.</p>
    <p class="tableblock">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.</p>
    <p class="tableblock">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.<br>
    </p>
    <p class="tableblock">
      <blockquote type="cite">That didn't really answer my question.
      </blockquote>
      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.<br>
    </p>
    <p class="tableblock">
      <blockquote type="cite">I'm not sure how I would suppress
        "possible project backends" from firing. </blockquote>
      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.</p>
    <p class="tableblock">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.<br>
    </p>
    <p class="tableblock">
      <blockquote type="cite">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.
      </blockquote>
      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.</p>
    <p class="tableblock">
      <blockquote type="cite">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).
      </blockquote>
      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.</p>
    <p class="tableblock">
      <blockquote type="cite">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.
      </blockquote>
      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.</p>
    <p class="tableblock">
      <blockquote type="cite">There are two patches in this bug report.
        Have you looked at the other one?</blockquote>
      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.<br>
    </p>
  </body>
</html>

--------------78F2A7CAFC7AF51B310FFF41--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 07:31:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 07 03:31:24 2021
Received: from localhost ([127.0.0.1]:45853 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYNsC-0000eS-Ez
	for submit <at> 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 <juri@HIDDEN>) id 1mYNsB-0000e9-2g
 for 41572 <at> debbugs.gnu.org; Thu, 07 Oct 2021 03:31:23 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 49DA8FF80E;
 Thu,  7 Oct 2021 07:31:13 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
 <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN>
Date: Thu, 07 Oct 2021 10:17:12 +0300
In-Reply-To: <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN> (Dmitry Gutov's
 message of "Thu, 7 Oct 2021 00:13:58 +0300")
Message-ID: <87wnmppdmr.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 02:27:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 22:27:52 2021
Received: from localhost ([127.0.0.1]:45739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYJ8S-0001EN-32
	for submit <at> 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 <raaahh@HIDDEN>) id 1mYJ8M-0001E0-Ef
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
 <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <25a5eff6-3eed-92ad-7291-0b9c26f555c9@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 21:16:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 17:16:28 2021
Received: from localhost ([127.0.0.1]:45606 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYEH5-0005zm-Up
	for submit <at> 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 <raaahh@HIDDEN>) id 1mYEH4-0005zb-Sp
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
 <87zgrmxie9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <770842e0-7bb6-1e53-737b-f9b444e8e05c@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 21:14:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 17:14:09 2021
Received: from localhost ([127.0.0.1]:45601 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mYEEr-0005vp-J1
	for submit <at> 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 <raaahh@HIDDEN>) id 1mYEEn-0005vB-ON
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN> <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 16:39:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 12:39:49 2021
Received: from localhost ([127.0.0.1]:45374 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mY9xN-0007Jz-AM
	for submit <at> 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 <juri@HIDDEN>) id 1mY9xM-0007Jm-1t
 for 41572 <at> debbugs.gnu.org; Wed, 06 Oct 2021 12:39:48 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id DCB7620003;
 Wed,  6 Oct 2021 16:39:39 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN> <878rz6wrdp.fsf@HIDDEN>
Date: Wed, 06 Oct 2021 19:29:50 +0300
In-Reply-To: <878rz6wrdp.fsf@HIDDEN> (Juri Linkov's message of "Wed, 
 06 Oct 2021 10:21:06 +0300")
Message-ID: <87zgrmxie9.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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'.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 14:09:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 10:09:44 2021
Received: from localhost ([127.0.0.1]:45073 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mY7c7-0000x0-Mn
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mY7c5-0000wk-W4
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
 <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
Message-ID: <7814d113-5366-8614-8f5b-699800c303eb@HIDDEN>
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: <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 07:40:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 06 03:40:53 2021
Received: from localhost ([127.0.0.1]:42369 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mY1Xp-00025w-7X
	for submit <at> 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 <juri@HIDDEN>) id 1mY1Xn-00025i-4k
 for 41572 <at> debbugs.gnu.org; Wed, 06 Oct 2021 03:40:52 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 04B611BF203;
 Wed,  6 Oct 2021 07:40:42 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
 <87wnmr793j.fsf@HIDDEN>
Date: Wed, 06 Oct 2021 10:21:06 +0300
In-Reply-To: <87wnmr793j.fsf@HIDDEN> (Juri Linkov's message of "Tue, 
 05 Oct 2021 19:32:56 +0300")
Message-ID: <878rz6wrdp.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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'?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 00:11:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 20:11:15 2021
Received: from localhost ([127.0.0.1]:42129 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXuWg-0005DR-Th
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXuWe-0005DD-Fa
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN> <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
 <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <ac719eee-acf5-7bdf-5512-ea5881e84bfc@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 18:19:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 14:19:32 2021
Received: from localhost ([127.0.0.1]:41887 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXp2K-0006fz-1v
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mXp2H-0006fl-Bj
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
 <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
Message-ID: <0895f33c-dfff-135e-657a-fbcf4730b799@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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)





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 17:01:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 13:01:11 2021
Received: from localhost ([127.0.0.1]:41786 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXnoV-0003RW-Cx
	for submit <at> 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 <juri@HIDDEN>) id 1mXnoP-0003HI-OU
 for 41572 <at> debbugs.gnu.org; Tue, 05 Oct 2021 13:01:09 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id F2DA0C0002;
 Tue,  5 Oct 2021 17:00:56 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
 <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
Date: Tue, 05 Oct 2021 19:32:56 +0300
In-Reply-To: <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN> (Dmitry Gutov's
 message of "Tue, 5 Oct 2021 15:42:29 +0300")
Message-ID: <87wnmr793j.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 16:56:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 12:56:42 2021
Received: from localhost ([127.0.0.1]:41764 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXnk9-0002FO-QH
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXnk8-0002FA-DT
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
 <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <6f237243-8cd6-a22c-a5f5-d241d76ddd53@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 15:21:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 11:21:28 2021
Received: from localhost ([127.0.0.1]:41652 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXmG0-00061o-5z
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mXmFx-00061Y-96
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
 <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
Message-ID: <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 15:04:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 11:04:15 2021
Received: from localhost ([127.0.0.1]:41619 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXlzK-0005aA-Hr
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXlzD-0005Zi-SU
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>,
 Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <290a72b8-1e00-2e61-5665-a9bc2ca4289b@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 
> <https://docs.projectile.mx/projectile/projects.html#file-markers>, 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 14:39:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 10:39:19 2021
Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXlbD-0004wH-9x
	for submit <at> 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 <nikolay.kudryavtsev@HIDDEN>) id 1mXlbB-0004w1-93
 for 41572 <at> 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 <at> 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 <nikolay.kudryavtsev@HIDDEN>
X-Google-Original-From: Nikolay Kudryavtsev <Nikolay.Kudryavtsev@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
Message-ID: <11e8e147-092d-d840-4d55-005654ff603c@HIDDEN>
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: <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
Content-Type: multipart/alternative;
 boundary="------------6F17B8E38643BEF2C5BD653D"
Content-Language: en-US
X-Spam-Score: -0.1 (/)
X-Debbugs-Envelope-To: 41572
Cc: Zhu Zihao <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 
<https://docs.projectile.mx/projectile/projects.html#file-markers>, 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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello. I have some stake in this issue too.</p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>This function in turn can be used by major mode developers and
      users to implement project backends. If we look <a
        moz-do-not-send="true"
        href="https://docs.projectile.mx/projectile/projects.html#file-markers">at
        the list of projects supported by Projectile</a>, 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.</p>
    <p>As for whether there should be some kind of default file marked
      project, sure, the user can just remove it if he want to.<br>
    </p>
  </body>
</html>

--------------6F17B8E38643BEF2C5BD653D--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 12:42:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 08:42:39 2021
Received: from localhost ([127.0.0.1]:39320 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXjmI-0007Ba-R1
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXjmH-0007BL-LD
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
 <87r1d0at40.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <ec69913d-d1d6-63f2-0356-c26c6c29d393@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 06:58:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 05 02:58:47 2021
Received: from localhost ([127.0.0.1]:38871 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXePX-0001J5-36
	for submit <at> 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 <juri@HIDDEN>) id 1mXePU-0001If-06
 for 41572 <at> debbugs.gnu.org; Tue, 05 Oct 2021 02:58:45 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 48275FF810;
 Tue,  5 Oct 2021 06:58:34 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
Date: Tue, 05 Oct 2021 09:52:23 +0300
In-Reply-To: <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN> (Dmitry Gutov's
 message of "Tue, 5 Oct 2021 05:03:05 +0300")
Message-ID: <87r1d0at40.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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/")))))




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 02:08:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 04 22:08:58 2021
Received: from localhost ([127.0.0.1]:38654 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXZt4-0002Nn-Ag
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXZt1-0002NT-Rf
 for 41572 <at> 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 <at> 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 <dgutov@HIDDEN>
To: Juri Linkov <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
 <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
Message-ID: <0c74b78e-88a8-874d-7321-4fd2e3dc9ca7@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Oct 2021 02:03:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 04 22:03:13 2021
Received: from localhost ([127.0.0.1]:38650 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mXZnV-0002Fr-M9
	for submit <at> 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 <raaahh@HIDDEN>) id 1mXZnU-0002Fe-KP
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
 <87zgrq2ctj.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 3 Oct 2021 18:27:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 03 14:27:39 2021
Received: from localhost ([127.0.0.1]:34935 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mX6D5-0007I1-Cz
	for submit <at> 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 <juri@HIDDEN>) id 1mX6D3-0007Hj-0K
 for 41572 <at> debbugs.gnu.org; Sun, 03 Oct 2021 14:27:38 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 89A9460002;
 Sun,  3 Oct 2021 18:27:27 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
Organization: LINKOV.NET
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
Date: Sun, 03 Oct 2021 21:06:16 +0300
In-Reply-To: <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN> (Dmitry Gutov's
 message of "Sun, 26 Sep 2021 02:13:39 +0300")
Message-ID: <87zgrq2ctj.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
 Theodor Thornhill <theo@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.
Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
Removed tag(s) patch. Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 26 Sep 2021 06:38:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 26 02:38:42 2021
Received: from localhost ([127.0.0.1]:35568 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mUNoA-0000w4-F0
	for submit <at> 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 <larsi@HIDDEN>) id 1mUNo8-0000vo-FQ
 for 41572 <at> 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 <larsi@HIDDEN>)
 id 1mUNny-0006Do-PJ; Sun, 26 Sep 2021 08:38:33 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
 <871riitzch.fsf@HIDDEN>
 <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
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: <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN> (Dmitry Gutov's
 message of "Sun, 26 Sep 2021 02:13:39 +0300")
Message-ID: <87tui7suxo.fsf@HIDDEN>
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 <dgutov@HIDDEN> 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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Dmitry Gutov <dgutov@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 26 Sep 2021 00:22:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 25 20:22:45 2021
Received: from localhost ([127.0.0.1]:35146 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mUHwL-0001el-6H
	for submit <at> 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 <raaahh@HIDDEN>) id 1mUHwJ-0001eV-Dc
 for 41572 <at> 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 <at> 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 <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <ea360b6f-883a-8dd6-b7ad-ec82d810ed72@HIDDEN>
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@HIDDEN>
Content-Type: multipart/mixed; boundary="------------B58A981BA8E68E443A635214"
Content-Language: en-US
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 41572
Cc: Zhu Zihao <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 25 Sep 2021 23:13:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 25 19:13:50 2021
Received: from localhost ([127.0.0.1]:35096 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mUGrd-0008Lj-Tp
	for submit <at> 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 <raaahh@HIDDEN>) id 1mUGrc-0008LT-6m
 for 41572 <at> 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 <at> 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 <larsi@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN> <871riitzch.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <bbcebc55-906e-860a-73be-2c678a983883@HIDDEN>
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@HIDDEN>
Content-Type: multipart/mixed; boundary="------------8889971C46DE9C778BB18D39"
Content-Language: en-US
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 41572
Cc: Zhu Zihao <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.
Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <help-debbugs@HIDDEN> to internal_control <at> debbugs.gnu.org. Full text available.
bug unarchived. Request was from Dmitry Gutov <dgutov@HIDDEN> to control <at> debbugs.gnu.org. Full text available.
bug archived. Request was from Debbugs Internal Request <help-debbugs@HIDDEN> to internal_control <at> debbugs.gnu.org. Full text available.
bug closed, send any further explanations to 41572 <at> debbugs.gnu.org and Zhu Zihao <cjpeople2013@HIDDEN> Request was from Lars Ingebrigtsen <larsi@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 1 Oct 2020 03:11:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 30 23:11:23 2020
Received: from localhost ([127.0.0.1]:33683 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kNp06-00045T-Tm
	for submit <at> 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 <larsi@HIDDEN>) id 1kNp05-00045E-Mz
 for 41572 <at> 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 <larsi@HIDDEN>)
 id 1kNozw-0001K6-6G; Thu, 01 Oct 2020 05:11:15 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
 <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
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@HIDDEN> (Dmitry Gutov's
 message of "Mon, 20 Jul 2020 23:55:08 +0300")
Message-ID: <871riitzch.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, Theodor Thornhill <theo@HIDDEN>,
 41572 <at> debbugs.gnu.org, Juri Linkov <juri@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 20 Jul 2020 20:55:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 20 16:55:19 2020
Received: from localhost ([127.0.0.1]:36355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jxcog-0003y4-O8
	for submit <at> 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 <raaahh@HIDDEN>) id 1jxcof-0003xn-GA
 for 41572 <at> 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 <at> 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 <theo@HIDDEN>, Juri Linkov <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
 <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <2a70c748-e250-2f96-5d74-712b6d71e8be@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 13:37:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 09:37:25 2020
Received: from localhost ([127.0.0.1]:51081 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhZ0n-0006Hv-6i
	for submit <at> 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 <theo@HIDDEN>) id 1jhZ0k-0006Hf-Tn
 for 41572 <at> 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 <dgutov@HIDDEN>, Juri Linkov <juri@HIDDEN>
From: Theodor Thornhill <theo@HIDDEN>
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: <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
 <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Theodor Thornhill <theo@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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--





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 12:18:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 08:18:02 2020
Received: from localhost ([127.0.0.1]:51004 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhXlx-00025e-RY
	for submit <at> 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 <raaahh@HIDDEN>) id 1jhXlv-00025R-D9
 for 41572 <at> 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 <at> 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 <theo@HIDDEN>, Juri Linkov <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
 <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <c7f03b42-02eb-f115-2c9b-0a3697969403@HIDDEN>
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: <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 06.06.2020 14:53, Theodor Thornhill wrote:
> 
> 
> On Sat, Jun 6, 2020 at 13:15, Dmitry Gutov <dgutov@HIDDEN 
> <mailto:dgutov@HIDDEN>> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 11:53:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 07:53:52 2020
Received: from localhost ([127.0.0.1]:50957 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhXOa-0001U8-Ft
	for submit <at> 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 <theo@HIDDEN>) id 1jhXOW-0001Tn-Fb
 for 41572 <at> 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 <dgutov@HIDDEN>, Juri Linkov <juri@HIDDEN>
From: Theodor Thornhill <theo@HIDDEN>
Subject: Re: bug#41572: 28.0.50;
 [PATCH] Support plain project marked with file .emacs-project
Message-ID: <brR_kDZQ09RtUe3wCz-0Eanmee11ieN5HKAefhgL11Uxpo8issM_W-2TyMtt1vyQ93dsYyU1BktxSfQXeW9hGspbYr8m5ddgB_rvGloXeIk=@thornhill.no>
In-Reply-To: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
 <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Theodor Thornhill <theo@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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--





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 11:15:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 07:15:29 2020
Received: from localhost ([127.0.0.1]:50896 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhWnR-0006rz-Gs
	for submit <at> 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 <raaahh@HIDDEN>) id 1jhWnP-0006rl-T2
 for 41572 <at> 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 <at> 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 <theo@HIDDEN>, Juri Linkov <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
 <87d06ck2b0.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 6 Jun 2020 08:48:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 06 04:48:38 2020
Received: from localhost ([127.0.0.1]:50673 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhUVK-0006zQ-OX
	for submit <at> 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 <theo@HIDDEN>) id 1jhUVJ-0006zB-2q
 for 41572 <at> 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 <dgutov@HIDDEN>, Juri Linkov <juri@HIDDEN>
From: Theodor Thornhill <theo@HIDDEN>
Subject: Re: bug#41572: 28.0.50;
 [PATCH] Support plain project marked with file .emacs-project
Message-ID: <87d06ck2b0.fsf@HIDDEN>
In-Reply-To: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
 <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Theodor Thornhill <theo@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

      =20
"Dmitry Gutov" <dgutov@HIDDEN> writes:

Hi!

> "Dmitry Gutov" <dgutov@HIDDEN> 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






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 23:11:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 19:11:47 2020
Received: from localhost ([127.0.0.1]:50296 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhLV4-0001NH-Sv
	for submit <at> 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 <raaahh@HIDDEN>) id 1jhLV4-0001Mz-4P
 for 41572 <at> 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 <at> 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 <theo@HIDDEN>, Juri Linkov <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
 <87ftb92u8q.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <0ab90cf2-eab2-6fea-6698-4164d7753cd7@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Hi!

On 05.06.2020 22:22, Theodor Thornhill wrote:
> "Dmitry Gutov" <dgutov@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 19:47:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 15:47:29 2020
Received: from localhost ([127.0.0.1]:50011 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhIJM-0002n8-Ur
	for submit <at> 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 <theo@HIDDEN>) id 1jhHvE-00029F-81
 for 41572 <at> 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 <dgutov@HIDDEN>, Juri Linkov <juri@HIDDEN>
From: Theodor Thornhill <theo@HIDDEN>
Subject: Re: bug#41572: 28.0.50;
 [PATCH] Support plain project marked with file .emacs-project
Message-ID: <87ftb92u8q.fsf@HIDDEN>
In-Reply-To: <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <87pnahjgdr.fsf@HIDDEN>
 <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Theodor Thornhill <theo@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

      =20
Hello,      =20
      =20
"Dmitry Gutov" <dgutov@HIDDEN> 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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 5 Jun 2020 19:02:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 05 15:02:24 2020
Received: from localhost ([127.0.0.1]:49916 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhHbk-0001Jk-5x
	for submit <at> 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 <raaahh@HIDDEN>) id 1jhHbi-0001EO-8k
 for 41572 <at> 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 <at> 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 <juri@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> <87pnahjgdr.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <feebb665-a021-7b32-c528-579d9906a9f5@HIDDEN>
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@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 3 Jun 2020 11:04:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 03 07:04:28 2020
Received: from localhost ([127.0.0.1]:42153 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgRC8-0006KU-0P
	for submit <at> 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 <contovob@HIDDEN>) id 1jgRC5-0006KB-6F
 for 41572 <at> 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 <at> 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" <contovob@HIDDEN>
To: "Philip K." <philip@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <874ks0dz8b.fsf@HIDDEN>
Date: Wed, 03 Jun 2020 12:04:12 +0100
In-Reply-To: <874ks0dz8b.fsf@HIDDEN> (Philip K.'s message of "Thu, 28
 May 2020 14:24:04 +0200")
Message-ID: <87zh9k4dhv.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Philip K." <philip@HIDDEN> writes:

> Zihao Zhu <cjpeople2013@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 3 Jun 2020 00:28:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 02 20:28:29 2020
Received: from localhost ([127.0.0.1]:41355 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgHGf-0002yQ-6w
	for submit <at> 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 <juri@HIDDEN>) id 1jgHGd-0002y6-OS
 for 41572 <at> 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@HIDDEN)
 by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 16DCEC0009;
 Wed,  3 Jun 2020 00:28:18 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
Date: Wed, 03 Jun 2020 02:40:32 +0300
In-Reply-To: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN> (Dmitry Gutov's
 message of "Thu, 28 May 2020 15:35:55 +0300")
Message-ID: <87pnahjgdr.fsf@HIDDEN>
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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 29 May 2020 13:58:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 29 09:58:41 2020
Received: from localhost ([127.0.0.1]:55688 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jefWy-00047h-Jq
	for submit <at> 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 <raaahh@HIDDEN>) id 1jefWi-00046m-DP
 for 41572 <at> 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 <at> 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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
 <c7a38fab-d331-ed40-5a09-554ea097a31f@HIDDEN>
 <679e6ff0-b0e4-e212-34bc-60ff676d0b00@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <dc00d0b6-2a69-d4aa-3baf-a6353cdce1af@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 29 May 2020 07:11:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 29 03:11:33 2020
Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeZAy-0008Io-UO
	for submit <at> 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 <philip@HIDDEN>) id 1jeZAw-0008IZ-QT
 for 41572 <at> 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: <xms:nbXQXiSj1H2QiKCdOQPpukJj8LyZvDT5fdYxrDZkxsSPo3PFqvfhzA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvjedguddtlecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufhffjgfkfgggtgesthdtredttdertdenucfhrhhomhepfdfrhhhi
 lhhiphcumfdrfdcuoehphhhilhhiphesfigrrhhpmhgrihhlrdhnvghtqeenucggtffrrg
 htthgvrhhnpeeiudffuedvhfetfedvledtveektdehtdfgueekkedtkeefgedtheegieff
 leefleenucffohhmrghinheptghhihhsvghlrghpphdrtghomhdpihhrihhfrdhfrhenuc
 fkphepjeelrddvudelrddvtdeirddvvdefnecuvehluhhsthgvrhfuihiivgeptdenucfr
 rghrrghmpehmrghilhhfrhhomhepphhhihhlihhpseifrghrphhmrghilhdrnhgvth
X-ME-Proxy: <xmx:nbXQXnzqQYPB3d619OArQGdBNfh240EdZb0yOKtLXUkQ2XCbCTDRKw>
 <xmx:nbXQXv2WbMVD1tdPYrs-zUQaL9LOGIT_iKjYn-9hQYkPctpHSv_7-Q>
 <xmx:nbXQXuADA3vioudBXtjpcNWPaQEjRU0dJPxbmodhPLAx_kuW4dOefw>
 <xmx:nbXQXtdw0jNC9G36mHEj_piBafsZp8V0HWquxGvTjv_b2PQh3hn2xw>
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." <philip@HIDDEN>
To: Zihao Zhu <cjpeople2013@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
 <c7a38fab-d331-ed40-5a09-554ea097a31f@HIDDEN>
 <679e6ff0-b0e4-e212-34bc-60ff676d0b00@HIDDEN>
Date: Fri, 29 May 2020 09:11:22 +0200
In-Reply-To: <679e6ff0-b0e4-e212-34bc-60ff676d0b00@HIDDEN> (Zihao Zhu's
 message of "Fri, 29 May 2020 12:34:33 +0800")
Message-ID: <87k10vnrl1.fsf@HIDDEN>
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 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Zihao Zhu <cjpeople2013@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 29 May 2020 04:34:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 29 00:34:46 2020
Received: from localhost ([127.0.0.1]:53560 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeWjF-0004Lk-Sb
	for submit <at> 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 <cjpeople2013@HIDDEN>) id 1jeWjE-0004LY-2z
 for 41572 <at> 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 <at> 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 <dgutov@HIDDEN>, 41572 <at> debbugs.gnu.org
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
 <c7a38fab-d331-ed40-5a09-554ea097a31f@HIDDEN>
From: Zihao Zhu <cjpeople2013@HIDDEN>
Message-ID: <679e6ff0-b0e4-e212-34bc-60ff676d0b00@HIDDEN>
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: <c7a38fab-d331-ed40-5a09-554ea097a31f@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 19:59:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 15:59:09 2020
Received: from localhost ([127.0.0.1]:53127 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeOgH-0002Bp-6Z
	for submit <at> 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 <raaahh@HIDDEN>) id 1jeOgE-0002BE-SF
 for 41572 <at> 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 <at> 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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
 <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <c7a38fab-d331-ed40-5a09-554ea097a31f@HIDDEN>
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: <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:47:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 11:47:00 2020
Received: from localhost ([127.0.0.1]:52866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeKkG-0004RW-H0
	for submit <at> 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 <cjpeople2013@HIDDEN>) id 1jeKkE-0004RC-G2
 for 41572 <at> 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 <at> 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 <dgutov@HIDDEN>, 41572 <at> debbugs.gnu.org
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
From: Zihao Zhu <cjpeople2013@HIDDEN>
Message-ID: <ae0340ca-3889-b214-4536-327fedd19558@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:14:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 11:14:41 2020
Received: from localhost ([127.0.0.1]:52786 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeKEz-0003ap-8P
	for submit <at> 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 <cjpeople2013@HIDDEN>) id 1jeGhk-0001zH-9B
 for 41572 <at> 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 <at> 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: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <877dwweca3.fsf@HIDDEN>
In-Reply-To: <877dwweca3.fsf@HIDDEN>
From: Zhu Zihao <cjpeople2013@HIDDEN>
Date: Thu, 28 May 2020 19:27:48 +0800
Message-ID: <CA+rDc=AJU7Wt0_hUxaxhvLK08eXRGM0nuud4hL=dOq-fNii-dQ@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
To: "Philip K." <philip@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <cjpeople2013@HIDDEN> <cjpeople2013@HIDDEN> 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

<div dir=3D"ltr">
 =20
   =20
 =20
  <div>
    <p>IMO, it&#39;s not practical to use directory local variable</p>
    <p>1. directory local variable goes &quot;.dir-local.el&quot;. But we c=
an&#39;t
      mark every directory contain this file as project. We have to do
      extra search if we use directory local variable.</p>
    <p>2. If we have variable &quot;project-directory-plain-project-p&quot;=
, It&#39;s
      a problem for us to determine the root <br>
    </p>
    <p><br>
    </p>
    <div>On 2020/5/28 =E4=B8=8B=E5=8D=883:42, Philip K. wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>Zhu Zihao <a href=3D"mailto:cjpeople2013@HIDDEN" target=3D"_b=
lank">&lt;cjpeople2013@HIDDEN&gt;</a> writes:

</pre>
      <blockquote type=3D"cite">
        <pre>To mark a directoy as project, put an empty magic file .emacs-=
project under the
directory, and project.el should be responsible for it.
</pre>
      </blockquote>
      <pre>Is there any more standard name than &quot;.emacs-project&quot;?=
 Or could a
directory local-variable be used? I like the idea, but wouldn&#39;t want to
have so many &quot;.emacs-project&quot; files lying around in toy projects.

</pre>
    </blockquote>
  </div>

</div>

--00000000000012062a05a6b39f0f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 15:14:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 11:14:41 2020
Received: from localhost ([127.0.0.1]:52784 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeKEy-0003an-OX
	for submit <at> 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 <cjpeople2013@HIDDEN>) id 1jeGaj-0001mY-4Q
 for 41572 <at> 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 <at> 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." <philip@HIDDEN>
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 <877dwweca3.fsf@HIDDEN>
From: Zihao Zhu <cjpeople2013@HIDDEN>
Message-ID: <fc7bcdba-c401-292f-511d-d9af8225be20@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <cjpeople2013@HIDDEN> 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.
>




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 12:36:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 08:36:09 2020
Received: from localhost ([127.0.0.1]:51244 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeHlZ-0007wt-Lj
	for submit <at> 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 <raaahh@HIDDEN>) id 1jeHlU-0007wL-1U
 for 41572 <at> 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 <at> 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 <cjpeople2013@HIDDEN>, 41572 <at> debbugs.gnu.org
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <5f584d83-ef45-9912-bfbc-d2f00b24b9fd@HIDDEN>
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: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 12:24:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 08:24:26 2020
Received: from localhost ([127.0.0.1]:51231 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeHaD-0007ei-UW
	for submit <at> 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 <philip@HIDDEN>) id 1jeHaB-0007eU-7X
 for 41572 <at> 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: <xms:ca3PXvKSBFOHUpPcITzB6Yv04ZzfW1t1qvKTbF8hvke9Apd_c0OD5g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddviedgvdehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujgffkfggtgfgsehtqhertd
 dttdejnecuhfhrohhmpedfrfhhihhlihhpucfmrddfuceophhhihhlihhpseifrghrphhm
 rghilhdrnhgvtheqnecuggftrfgrthhtvghrnhephfdujeevuddvffetudfghfduvdfgve
 ffueefvdeljeeuffejheeludeftdduffefnecukfhppeejledrvdduledrvddtiedrvddv
 feenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphh
 hilhhiphesfigrrhhpmhgrihhlrdhnvght
X-ME-Proxy: <xmx:ca3PXjIZBhBj7t5kEBwR_EgTXqTWObgWkMtQXyPPZ-TWieLknHbNPQ>
 <xmx:ca3PXnv-s9pOyXACcZqImZ9iTHNQuIsIRPxcnQMhnsYXiMCkQ8tlpA>
 <xmx:ca3PXoZIjV30ebiXfYxGWT8bApILhWub7C37BXYwIdiNhDyYFmmAjw>
 <xmx:ca3PXvmpJaJrynsXkE2XE6ASCbU01fSLDQHVkjsFAAEdPU58cR61hA>
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." <philip@HIDDEN>
To: Zihao Zhu <cjpeople2013@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
In-Reply-To: <fc7bcdba-c401-292f-511d-d9af8225be20@HIDDEN> (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@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Zihao Zhu <cjpeople2013@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at 41572 <at> debbugs.gnu.org:


Received: (at 41572) by debbugs.gnu.org; 28 May 2020 07:42:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 03:42:27 2020
Received: from localhost ([127.0.0.1]:50871 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeDBI-0004Oa-6N
	for submit <at> 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 <philip@HIDDEN>) id 1jeDBF-0004OL-Vo
 for 41572 <at> 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: <xms:WGvPXiGhEksWILcl3my56-srav8feHbuWRRLagRo7KA64JhCRs_XEw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvhedguddtvdcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufhfffgjkfgfgggtsehttd
 ertddtredtnecuhfhrohhmpedfrfhhihhlihhpucfmrddfuceophhhihhlihhpseifrghr
 phhmrghilhdrnhgvtheqnecuggftrfgrthhtvghrnhepudekueevlefgfeeigefhgeelte
 evieehhfetjefgieduheegvdfhffejhfffleffnecukfhppeejledrvdduledrvddtjedr
 udefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
 hphhhilhhiphesfigrrhhpmhgrihhlrdhnvght
X-ME-Proxy: <xmx:WGvPXjVdFCTbJBfZ9Pi7g2nk1RXsW0S2n35LuSIN-5qNO6oYALc_YQ>
 <xmx:WGvPXsKlpYKycNDUBz5uaF7bHd7d1kG7bfb9oONHyZ5FjU2j5VpinA>
 <xmx:WGvPXsFLL8MhjqXNrgqMbpQyC7RZxDYSXa_bA3qckYYJ1O_kG9pwQA>
 <xmx:WGvPXgivj5Rrynw5hBMqINwNlE4WtRVl86UjAFVw_zqGPes4EE_NjA>
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." <philip@HIDDEN>
To: Zhu Zihao <cjpeople2013@HIDDEN>
Subject: Re: bug#41572: 28.0.50; [PATCH] Support plain project marked with
 file .emacs-project
References: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
Date: Thu, 28 May 2020 09:42:12 +0200
In-Reply-To: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
 (Zhu Zihao's message of "Thu, 28 May 2020 11:32:04 +0800")
Message-ID: <877dwweca3.fsf@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Zhu Zihao <cjpeople2013@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 28 May 2020 04:45:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 28 00:45:15 2020
Received: from localhost ([127.0.0.1]:50629 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jeAPr-0008GA-0h
	for submit <at> 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 <cjpeople2013@HIDDEN>) id 1je9HG-0006SU-VJ
 for submit <at> 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 <cjpeople2013@HIDDEN>)
 id 1je9HG-0007xS-PF
 for bug-gnu-emacs@HIDDEN; 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 <cjpeople2013@HIDDEN>)
 id 1je9HF-0000eZ-T9
 for bug-gnu-emacs@HIDDEN; Wed, 27 May 2020 23:32:18 -0400
Received: by mail-wr1-x430.google.com with SMTP id x13so11719813wrv.4
 for <bug-gnu-emacs@HIDDEN>; 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 <cjpeople2013@HIDDEN>
Date: Thu, 28 May 2020 11:32:04 +0800
Message-ID: <CA+rDc=C7Yp6tqc+h2O1W8Pbc0d6kA4LUgxmGXbE54vkeL+va0w@HIDDEN>
Subject: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary="00000000000096a7b705a6acf9c2"
Received-SPF: pass client-ip=2a00:1450:4864:20::430;
 envelope-from=cjpeople2013@HIDDEN; 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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <all_but_last@HIDDEN>
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

<div dir=3D"ltr"><p style=3D"margin:0px">This patch add support for &quot;p=
lain project&quot; in project.el. Plain project is a<br>kind of project wit=
hout any VC backend but should be.<br><br>To mark a directoy as project, pu=
t an empty magic file .emacs-project under the<br></p><div>directory, and p=
roject.el should be responsible for it.</div><div><br></div><div>~~~~</div>=
<div><br></div><div>From cb0a67cfacf141a8b1955c08c3f459bcac801a39 Mon Sep 1=
7 00:00:00 2001<br>From: Zhu Zihao &lt;<a href=3D"mailto:all_but_last@HIDDEN=
om">all_but_last@HIDDEN</a>&gt;<br>Date: Thu, 28 May 2020 11:04:44 +0800<b=
r>Subject: [PATCH] Support plain project marked with file .emacs-project<br=
><br>* lisp/progmodes/project.el (project-try-plain): New function<br>* lis=
p/progmodes/project.el (project-root): New dispatch variants<br>* lisp/prog=
modes/project.el (project-find-functions): Add project-try-plain<br>---<br>=
=C2=A0lisp/progmodes/project.el | 14 +++++++++++++-<br>=C2=A01 file changed=
, 13 insertions(+), 1 deletion(-)<br><br>diff --git a/lisp/progmodes/projec=
t.el b/lisp/progmodes/project.el<br>index 88f73e4fb31..4c1810aeb56 100644<b=
r>--- a/lisp/progmodes/project.el<br>+++ b/lisp/progmodes/project.el<br>@@ =
-94,7 +94,7 @@<br>=C2=A0<br>=C2=A0(require &#39;cl-generic)<br>=C2=A0<br>-(=
defvar project-find-functions (list #&#39;project-try-vc)<br>+(defvar proje=
ct-find-functions (list #&#39;project-try-plain #&#39;project-try-vc)<br>=
=C2=A0=C2=A0 &quot;Special hook to find the project containing a given dire=
ctory.<br>=C2=A0Each functions on this hook is called in turn with one<br>=
=C2=A0argument (the directory) and should return either nil to mean<br>@@ -=
194,6 +194,18 @@ project-files<br>=C2=A0=C2=A0=C2=A0 (or dirs<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (list (project-root project)))))<br>=C2=
=A0<br>+(defun project-try-plain (dir)<br>+=C2=A0 &quot;Return the plain pr=
oject instance of current DIR.<br>+<br>+A directory with magic file \&quot;=
.emacs-project\&quot; will be recognized as<br>+plain project.&quot;<br>+=
=C2=A0 (pcase (locate-dominating-file dir &quot;.emacs-project&quot;)<br>+=
=C2=A0=C2=A0=C2=A0 (`nil nil)<br>+=C2=A0=C2=A0=C2=A0 (root (cons &#39;plain=
 root))))<br>+<br>+(cl-defmethod project-root ((project (head plain)))<br>+=
=C2=A0 (cdr project))<br>+<br>=C2=A0(defun project--files-in-directory (dir=
 ignores &amp;optional files)<br>=C2=A0=C2=A0 (require &#39;find-dired)<br>=
=C2=A0=C2=A0 (require &#39;xref)<br>-- <br>2.26.2<br><br><br><br></div></di=
v>

--00000000000096a7b705a6acf9c2--




Acknowledgement sent to Zhu Zihao <cjpeople2013@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#41572; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 6 Sep 2022 11:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.