Dmitry Gutov<dgutov@yandex.ru> writes:
On 26/11/22 01:47, João Távora wrote:
You can use dir-locals-set-class-variables to variable like the
hypothetical project-subproject-prefixes to the super-project's root.
This contains a list of strings or regexps that identify the subprojects
inside the superproject. I don't see the problem. Elements in
project-find-functions would be aware of this value and proceed
accordingly to find the subprojects.
I don't see the problem in that.
I just fail to see an advantage either, given that the list of
prefixes would be different between the "super" projects, so the
suggestion to use a class is perplexing.
The point of dir-locals-set-class-variables is to set directly-locals
"from a distance" when creating an actual .dir-locals.el file isn't
feasible or desired.
(dir-locals-set-directory-class "~/Source/very-big-project"
'very-big-project)
(dir-locals-set-class-variables 'very-big-project ((nil . (project-find-prefixes "foo"
"bar/baz.*"))))
Even if it's a one-use class, there's nothing wrong with that IMO. And
chances are you have multiple clones or Git worktrees of the same
project, so you may as well make it a two- or three-use class
(dir-locals-set-directory-class "~/Source/worktree-2" 'very-big-project)
(dir-locals-set-directory-class "~/Source/another-clone" 'very-big-project)
Of course if the user is able to AND wants to use .dir-locals.el or
marker files, that is fine, too. I personally like the above scheme.