bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emac


From: João Távora
Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
Date: Tue, 29 Nov 2022 09:46:22 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26/11/22 21:23, João Távora wrote:
>> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov <dgutov@yandex.ru
>> <mailto:dgutov@yandex.ru>> wrote:
>>      > My use case is the following: I'm interested in being able to
>>     designate
>>      > projects (through various means, not only marker files) that may only
>>      > exist inside other projects.
>>     You previously described your super-project and how you handled
>> it
>>     using
>>     project-find-functions hook with a new element that looked for file
>>     markers. Does this patch make that easier to do? Without writing custom
>>     functions?
>> The example i gave did _not_ use file markers. Personally, I can't
>> use them. I need some elisp way.
>
> Please elaborate.

I've already elaborated, with actual code.

https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html
https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html

> Does it mean that those subprojects are chosen manually and don't have
> "packages.jon" or etc exactly (or that too many subprojects in that
> same project would, undesirably, contain the same files)?

OK, one last time: packages.json and i.e. monorepos that have a
developing collection of similarly structured NPM packages that move
around is good case for marker files, undoubtedly.  I'm not putting that
into question.

But many times that's not the case and you have a big project in which a
mostly fixed heterogenous collection of sub-hierarchies exist and you
would like to designate as those as subprojects.  In the latter case,
marker files are useless, uselessly slow and perhaps even impossible.

In _both_ cases, it's very useful to have project operations let the
user choose the target: super-project or sub-project (or "parent
project", "outer project", "nested project", "inner project": I don't
care too much about the nomenclature).

> Would being able to set to absolute file names (directories) help? Or
> would that be too awkward?

That's more or less the idea, but they don't need to be absolute file
names which is indeed awkward See project-sub-project-prefixes in the
code I posted.  project-sub-project-prefixes can even be a regex pattern
applied on the super-project's root.  This describes the heterogenous
collection economically and robustly.  It is then typically set
dir-locally, with either a .dir-locals.el file or with
dir-locals-set-class-variables.

Of course, the member of project-find-functions that consults
project-sub-project-prefixes needs to be aware of containing
super-projects found by some other means (marker files included).  See
the code I posted to emacs-devel for a possible implementation.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]