Earlier quoted context omitted.
All of this plus that with their approach of shipping an editor that is useable out of the box I feel a lot safer from supply chain attacks. No matter if VSCode or (neo)vim, needing tens of plugins from almost that many different parties always made me feel quite uneasy.
Their cargo.lock file is 3500 lines or so: https://github.com/helix-editor/helix/blob/master/Cargo.lock So, I kind of agree with you, but that’s still a lot of dependencies baked into the editor. It’s probably not as bad as Neovim+plugins, but it’s still a supply chain issue.
305 with helix- removed
258 with gix removed (git stuff in multiple packages from a single upstream group)
240 with windows api wrappers removed.
170 if you remove all subprojects (split on -/_ taking first field, then uniq).
fast math and various hashes
backtrace utils
various build utils
some allocators, zero copy facilities, mmap and structures like lrus
time and date handling
character maps / internationalization
concurrency libraries (futures, runtime, etc)
cross platform path & directory helpers
support for general unix platforms, for redox, for linux, for windows
logging infrastructure
some compression libraries
markdown
various testing helpers
rope string representation
shell lexer and utils
terminal interaction models
toml
wasm & wasi
so where's the rest? well the rest is in the project: tokei says helix contains 132kloc. tokei says neovim contains 984kloc.
so round a little and you get: helix has an order of magnitude more dependencies, but also an order of magnitude less code than neovim.
while I'm sympathetic to concerns around dependency bloat, particularly with an eye to the js ecosystem and supply chain security, it's important to look through the right lens - when the functionality is fairly closely equivalent (there are differences, helix has a lot more modern features, vim has a lot more traditional text manipulation and unixy integration features), and there's an order of magnitude tradeoff in both directions - this is likely demonstration of fairly effective code sharing in helix.
there are important supply chain safety techniques required when using a wide number of disparately owned dependencies. there are also important supply chain safety techniques required when managing a wide number of disparately owned sub-directories of a larger project. there could just as well be a needle in neovims vimscript haystack as there is in helix dependency stack, i can tell you now though, as i'm familiar with almost all of helix dependencies i've put eyes over their code at least once, there's almost certainly been more eyes on helix deps recently than on neovims vimscript - though eye's passing over don't always catch things either of course.