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
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