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. > It seems obvious to me from this thread that a lot of people don't > actually want sub-projects as a separate entity (based on the > requested behavior, hi Stefan!), they just want Eglot to work with the > structure of their project. The current Eglot solution to start servers in sub-directories of repositories has already been described (and apparently accepted). 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