Dmitry Gutov <dgutov@yandex.ru> writes:
On 22/11/22 23:34, João Távora wrote:Given a tree a tree structure such as a file system that can have very many nodes, not having any means to take advantage of that structure tree-ness (as project.el clearly doesn't: see the protocol of project-files and the lack of sub-projects) is going to be a hard limitation. Monorepos are really popular in many businesses and many of these are large and/or getting larger.Like I said: if you want sub-projects, go and write a proper feature request, with expected behavior, which commands are affected, which are not.
I've just described in the other thread that I would like to have finding references and finding files to be able to operate on either sub-projects or super-projects on demand. This is the problem I'm facing, and it's not new. For example, there is only: find file in the very large project, and find file in the current directory. There is no "find file in this section of the repo, which is a sub-project in itself".
IMO, it's not "improper" to describe problems and use cases: in fact I prefer that people describe over jumping to vapourware solutions. But if you're really looking for a suggestion as to _how_ to design it, I suppose my problem would be well dealt with a negative prefix on C-x p g and C-x p f giving me a choice of which project to operate on. But that is only one possibility: new commands are also acceptable.
As to how one defines sub-projects, I think having project-find-functions be used to compose a list of projects (as opposed to to stopping after finding one) would be a nice way. It would be nice if the elements of project-find-functions could be informed of the projects found so far. But keeping the "stop after first" behaviour and having members return a more complex object is maybe also good. I really don't care much what you eventually choose, as long as I can solve my problem.
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