C++ isn't a text editor. Why would one want to use a non-lisp language within emacs? Zed[4] is fairly new. Swift as wrapper/unix io cli pipe feed around sed

C++ isn't a text editor. Why would one want to use a non-lisp language within emacs? Zed[4] is fairly new. Swift as wrapper/unix io cli pipe feed around sed for interactive editing or pre/post process input/output to sed without the need to use/understand c++ just requires an understanding of unix cli, swift and just enough sed. Pretty easiy to add swift as an extension language to bashed[3]. Off the cuff guess: insufficient demand within main editor project for swift as language extension. Demand/use for supported extension languages within framework/ IDE / office suite (open office) does require significant/continuous time/effort to be supported within the main editor project. But why an extension language for text editor instead of using editor plugins / text transform dls? (where can insert call to swift program(s) to do transform work) aka non-swift lanuage examples: vim live server[0], likec4[1]. can use swift as pre/post process wrapper to neovim text editor[2] Insufficent time/space for additional editor comments on swift support. ----- [0] vim live server : https://github.com/wolandark/vim-live-server https://github.com/wolandark/vim-live-server Note: other programs for non-html bindings -- latex, postscript, rich text format, etc. Does this qualify as a gREPL or GREPL? (where g/G is short for GUI) [1] : likec4 : https://github.com/likec4/likec4?tab=readme-ov-file https://github.com/likec4/likec4?tab=readme-ov-file [2] : swift gui : https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui [3] : bashed : https://github.com/justinyaodu/bashed https://github.com/justinyaodu/bashed [4] : zed : https://zed.dev/ https://zed.dev/