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. João
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