From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nikolay Kudryavtsev Newsgroups: gmane.emacs.bugs Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Date: Thu, 7 Oct 2021 16:08:34 +0300 Message-ID: References: <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------78F2A7CAFC7AF51B310FFF41" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14077"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 07 15:28:30 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYTRm-0003VB-HI for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 15:28:30 +0200 Original-Received: from localhost ([::1]:50400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYTRl-0006de-Al for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 09:28:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYT8w-00067W-Gu for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYT8w-00082S-8q for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYT8v-0001Qk-TE for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nikolay Kudryavtsev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Oct 2021 13:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41572 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41572-submit@debbugs.gnu.org id=B41572.16336121375488 (code B ref 41572); Thu, 07 Oct 2021 13:09:01 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:08:57 +0000 Original-Received: from localhost ([127.0.0.1]:46371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYT8q-0001QP-PM for submit@debbugs.gnu.org; Thu, 07 Oct 2021 09:08:57 -0400 Original-Received: from mail-lf1-f53.google.com ([209.85.167.53]:39509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYT8l-0001QA-1w for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 09:08:53 -0400 Original-Received: by mail-lf1-f53.google.com with SMTP id n8so23652119lfk.6 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 06:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=S8GP5c2+dpXydXxEET9xo5kyYtvlEg0ww9SlUgtE6LA=; b=Cd1VwODVcHjTdnV2YJdbhfINAXTvZB41drrVnuMVAqyz5QRl6eDYsKW01TJ6xTBuGs Yy0jorYiWwddNPSjqiQsmAFgWfhA3qi+2cQQuyOE1i46YDV79pJaVxpw8M5MDGYfpEG7 oor9u5WUYx59NHh9/jWDKxHO2WPq/Lm7gpWSYighicjF79zcjZBK/MceXQCwp3WDkk5B t/4Vg5J2gVh+FtA47V4+R1uUwPmXLWrYl62KgE9bWEpmd18PnmCdslPUL8Wosz6P1FI3 Gvxx3CepwB7TF16P2laD0+LI0aEPfOk4Z4Y4LjNwl4uGR1vTK3ugnVLFUMR3qCArC7BQ 3pUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=S8GP5c2+dpXydXxEET9xo5kyYtvlEg0ww9SlUgtE6LA=; b=4XvCp+LDhkTxTL3Ibl657EPD2j+b+6cl6HIk0NLpmwTOy8gOAKF9z+ErN5pT0QfaMK Mt6uaGkVpaUgChhE6685WmRHJ0X4YyZi6yGxJp+ubEAtfUqancTUcrZ4gqvdhKyCwyIy FwUbi02YBPqiw0FVTQNXO6nOE2qc/kedsH9rpY2Kp1v62ucH0sUFmPfA3HcpqVzKnjMM WODhZ1mDn3+En+hHK3rZWclg4/xWQuvAhnXzMqz6h6/tOQvnxQcBXcglZ3BKCxXgTzDB lXTrgXU2dGSQumc8OcKS0rjVv4oiQe3z7IDP6+Ohw+iU7BuIibCJKq4Rgg7juO9QcNpk wj4w== X-Gm-Message-State: AOAM530dpM09Hl0rR9pgNRdC9KX6s9CXKlK6iaPrjLwypV7E9zVviQkM Cy9ab28f3e5zxB3bZXpP5Bc= X-Google-Smtp-Source: ABdhPJyHhoH6j0BM8f6vubrW2xJXhenaivVdrqvdXH6PV05MjGW1BmWHODOfAoJfFZV5JYg9N6MNQA== X-Received: by 2002:a05:6512:13a0:: with SMTP id p32mr4311143lfa.492.1633612117520; Thu, 07 Oct 2021 06:08:37 -0700 (PDT) Original-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) X-Google-Original-From: Nikolay Kudryavtsev In-Reply-To: <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:216658 Archived-At: This is a multi-part message in MIME format. --------------78F2A7CAFC7AF51B310FFF41 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > When should we not do it? Personal preference. I'd probably never hide subproject files in 99% of the projects I work on. > But then you will end up specifying the same information twice. Once > when setting up those new backends -- and the second time when > configuring the parent project to ignore particular subdirectories. You can have a `project-hide-nested-project-files' variable, set it once for all backends. Maybe per backend version too. For me personally, if I ever were to hide subproject files it would be on a rare project and it would be on the same backend, in which I would normally never hide them, so for my workflow this is a per project setting only. > why not have a single backend for that purpose, with a custom var > containing the list of files names? Right, so remember, I said we can use this to realize most of the Projectile backends? Well, the ones we can't realize would require regexps, usually of the "\\.ext$" kind. So you have to account for those too. Then there may be some other possible cases requiring custom function. So we have at least two reasons to prefer adding actual separate backends over one catch-all filename based. Orderability and customizability. Lets say I have this structure: VC root, subfolders containing multiple related, but independent projects in some programming language, backend for which exists; deeper in one of the subfolders I have a GTAGS file, assume GTAGS backend exists in one form or another. GTAGS file is placed in this location because elsewhere in the repo there are symbol names that are too close to each other and it's more convenient not having them show up when I lookup something. I don't want VC backend to define the project root here for obvious reasons. The major mode build tool backend should do OK and I may or may not want GTAGS to define the project root. Having one find-function list which the user can reorder as he sees fit and that list may contain not just filenames, but regexps and custom functions too. As for customizability: we're already discussing at least 2 backend settings: hide-nested-project-files and recursivity. Those settings require a backend to be something more than a filename string in a secondary list. > That didn't really answer my question. All right, lets rephrase the answer. At the moment in time a backend is defined we do not know every single exact situation that backend would have to operate in, because that would require the ability to predict time, which we technologically do not have at the current moment. Lets say I add a backend for my major mode. Someone in exactly 18 days, 6 hours, 5 minutes and 3 seconds decides to use it to work on his project. Unfortunately I do not know whether his project is in VCd and if VC project backend returns the same root. If I could predict time and my prediction of all possible future use cases would show that VC backend returns the same root for every single one of them, I of course would not bother adding mine. But because my imperfect human understanding makes me think that it won't, I have to add a backend of my own. > I'm not sure how I would suppress "possible project backends" from > firing. Since you believe that VC backend gives you the best result, you can always ensure on your end that you never get, say a Makefile backend in your project-find-functions. Probably the best route here globally, is changing project-find-functions to a list with numerical priorities, so that you could set VC backend to priority 0 in your init and instruct mode developers to never put anything with the same priority or higher in the docstring. > That's possible, but it's not at all a guarantee that in every big > project every Makefile will have a "dominating" Makefile of its own. Yes, but we can define a list of possible parent backends for every backend. For example you could set VC as possible parent backend for Makefile. Would probably not be a good idea in general, but for your VC-first workflow, should be fine. > It would seem like your vision of the project could benefit from a > notion like "facet". E.g. a project lookup would search for not just > "the current project", but "the current build project" or "current > file listing project", or... I don't know what else, actually. But I'm > sure there can be other additions (something test-framework related, > maybe). Or a "module" right? I was thinking about this too, and could not find a good name for it either. Such a solution would be a reliable working compromise between our schools of thought. You get your project-root untouched, I get my own project root to do whatever I please with it. The problem with it is that it's really overengineered. For most projects there would be a 1 to 1 relationship between the project and the module(artifact?) and even if it's not 1 to 1, there's a root module most of the time. That's why it feels inferior to me in comparison to just treating everything as projects and going bottom up. > Which would return, for example, new kind of object, and that object > could tell the parent directory of its build file, and the list of the > tasks described in it, and... perhaps something about how those tasks > should be invoked. That new abstraction could be used by commands that > want to interact with build files in an abstract fashion and to launch > build tasks. After studying Projectile build commands I found them inadequate, since it provides just two, compile and build, while even my simple major mode requires a separate debugging command too. This solution suffers from the same lack of flexibility. Take for example unit testing. It's not necessarily build tool subservient and can be independent from it, but it is situated in relation to the build tool root. The maven hierarchy is problematic for this too, while my "treat everything as projects" paradigm has an elegant solution in which you can use a numerical prefix to launch a build command on the Nth parent of the current project. > There are two patches in this bug report. Have you looked at the other > one? You mean the original patch? Well it is IMHO better than yours since it's less ambitious and does not go in what I believe to be the wrong direction. --------------78F2A7CAFC7AF51B310FFF41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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