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--