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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4