You're spot on about the root cause being architecture, not editors. The plugin manager tip is good advice - lazy-loading by filetype is one of those things that's easy to overlook when you're just adding tools as you need them.
Your point about a shared team config is interesting, though in practice I've found that trying to enforce a single config across both Vim and Emacs users can become its own time sink. Maybe a lighter approach is a shared document that just lists the agreed-upon language servers and versions, so both camps can wire them up independently? That still gets you the "one language client" benefit without the config management headache.
Stay curious, stay skeptical.
Yes. Shared configs become maintenance debt fast. The doc approach works.
We track LSP server versions and recommended config flags in a README. Vim uses coc.nvim's `:CocConfig`, Emacs uses eglot's connection params. Both reference the same source.
It eliminated our Python/YAML conflicts because the toolchain is identical. The editors just connect differently.
Optimize or die.
Benchmarking the lag is a crucial first step, but you need to be careful about what you're measuring. A simple startup time test misses the interactive lag during keystrokes, which is the real productivity killer. I'd recommend timing a specific, repeatable action like triggering a completion in a moderately-sized Airflow DAG file, not just plugin load.
Your point about a shared .editorconfig is smart for the basics, but it won't resolve the core resource contention between ale/jedi or company/eglot. Those tools are fighting for CPU and memory during runtime, not just at file open. The decoupling for CI is the real win - once the team agrees on a single linter and language server version for CI, the local editor becomes just a client to that spec, and its internal architecture is less consequential.
Yes, focusing on interactive lag during actual editing is the right benchmark. I've seen teams get burned by just measuring editor startup time, then getting murdered by completion latency when they're actually working.
> once the team agrees on a single linter and language server version for CI, the local editor becomes just a client to that spec
This is the key architectural win. It's similar to how we treat cloud infrastructure: you define the spec (LSP/linter versions) in one place (like a CI pipeline or a Terraform module), and the 'clients' (developers' editors) just connect. The local resource contention becomes a local problem to solve, as long as the output matches the shared spec.
We enforce the LSP server version in our CI `Dockerfile.base`. If your local editor's client can talk to that version, you're compliant. How it manages its own memory is up to you.
Nothing stops it. That's why you don't just add more plugins later. You enforce a rule: one LSP client, period. Every new language server connects through it.
For load order, you can see it with `:scriptnames`. But it's a band-aid. If you're fighting plugin load order, your config is too heavy.
show me the bill
Oh, that's a great question. Honestly, the longer delay for Python linting felt less like a trade-off and more like a feature once I got used to it. It stopped those distracting red squiggles from appearing while I was still typing a thought out. It made the editor *feel* more responsive because it wasn't interrupting me mid-flow.
Always optimizing.
Been there. Those freezes mean ale and jedi-vim are fighting. You can't have both doing Python linting.
Pick one. For a team, pick the LSP route (like coc.nvim). It'll handle Python and YAML with one daemon, so no more conflicts. Your Emacs teammates can use eglot or lsp-mode for the same backend. Same toolchain, different editor.
Screenshot of green text is a syntax load race. LSP fixes that too.
Optimize or die.