-
brainchild
@krig, JavaScript may not be the most exciting language, but it has proved its purpose in becoming a standard for embedded applications. Considering its ubiquity, and the vast repertoire of packages available for Node (to say nothing of the extensions having been created for VS Code), I would be inclined to consider it seriously, for providing a runtime supported by a new code editor. While I admire the underlying elegance of Scheme, the practical fact is that it lacks the volume of developers and libraries, and lacks the predictable interoperability, available through Node. In a more perfect world, Node might have been a framework for Scheme applications not JavaScript. Ultimately, however, the choice seems to be one as whether the project seeks broader adoption, or niche appeal.
-
krig
I doubt the language matters that much in practice, if someone wants to write an extension they’ll probably copy an existing one and tweak it. But I also don’t want extensions to be central to the editor. The main use case would be to more easily be able to ship language support for a lot more languages built into the editor. Now the limitation is that all the tree-sitter grammars that are bundled need to be ABI-compatible, moving to a helix model would solve that while still letting us build language support into the editor
-
krig
but yeah the VS Code extension model sucks IMO, I don’t want to replicate that