On Tue, Nov 22, 2022, 15:48 Dmitry Gutov wrote: I cannot reasonably add a feature with only one known (and expected) > consumer. Whether we call it subprojects, or an eglot-only backend, or etc. > I've given you two other cases of non-Eglot consumption. In fact, my problem isn't really Eglot/LSP-motivated at all: AFAICT clangd.exe works fine with that monster repo. Rather it's the fact that the monorepo is clearly organized into loosely coupled sub-projects and very often (but not always) it makes sense to do sub-project wide file-finding and reference-finding. No LSP/Eglotness involved at all. As I explained earlier, it would also help if project-files weren't so "flat list" oriented and allowed generalized collections, such as my completion table based on a very fast external indexer. > As the Eglot "fix" for the current status quo, it's just a > > documentation change to the manual. > > I think it's a problem when a significant part of userbase need to make > a change to their config (a specific, non-trivial one) to make Eglot > functional in their projects. > Depends what you call significant, and non-trivial. Eglot aims to make the common stuff trivial, and the complex stuff possible. 80-20 rule. Of course, as soon as you discover that a certain usage pattern is falling to the "80" side of things, you make it easier for that case. If that case is Python "venvs", and those are indeed very common, then make Python mode use Eglot's and project.el's API: it's what they are there for, I would presume. I sympathize with not wanting to collect that info for every file type > and their dog in Eglot, but it's not 100% obvious to me that the place > for that info is in major modes. > "File types" are handled by the major mode abstraction in Emacs. Eglot strives not to change that and I think this is a winning idea. João >