4 ms·

I agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have

by todd8 5y ago

I agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have to be replaced, but Emacs is never going to increase its appeal while requiring new users to learn its own, somewhat peculiar, extension language. Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning because it is an incredibly flexible editor construction kit that can be shaped into the editor one desires, but this, unfortunately, can require the user to write dozens of lines or even thousands of lines of configuration in eLisp. The young programmers that I know are just not going to bother to learn eLisp to get their mode line to look useful. Spacemacs and Doom are good examples of how far one can push Emacs configurations, but even working with these prebuilt advanced configurations requires some delving into eLisp. One approach to replacing eLisp would be to write a tool that compiles eLisp into JavaScript. eLisp has enough idiosyncrasies that this will be very challenging, but perhaps this could work. There are so many JavaScript programmers that could help with cleaning up the inevitable broken packages. Alternatively, like the NeoVim project, most of Emacs internals could be left in place and a JavaScript extension language could be added so that new packages could be written in either eLisp or JavaScript. Someone would have to figure out interoperability between the two—sharing data between two interpreters each with different garbage collectors for example. LaTeX faced a similar problem. The TeX esoteric macro capability was used to build LaTeX and LaTeX was used to build hundreds of complex packages to be used with LaTeX. The TeX/LaTeX world moves at a snail’s pace compared to Emacs, but they have made gradual progress in modernizing TeX and LaTeX (LuaTeX, LaTeX3, ConTeX, etc.)

jimmyvalmer 5y ago
Again, you wave your hands as if such a transpiler falls within a man-year of effort when there is little expertise, much less funding, for work that is not only difficult to get right but also not guaranteed to achieve the desired effect of broader adoption.
- todd8 5y ago
  So true! The dream of adding support for an additional extension language doesn’t fix the UI, the archaic defaults, unusual terminology, licensing restrictions, key bindings from keyboards used half a century ago. It’s all very sad. The worlds best editor, one of my favorite tools, is now too big to renovate. I used to toy with the idea of “fixing” TeX because I really liked using it, but again the fundamental problem that I wanted fixed was the extension language. I wanted something better than layers of macros on top of macros. Maybe I should stop musing about fundamentally transforming Emacs and go back to daydreaming of an improved TeX.

by todd8 5y ago

jimmyvalmer 5y ago

Again, you wave your hands as if such a transpiler falls within a man-year of effort when there is little expertise, much less funding, for work that is not only difficult to get right but also not guaranteed to achieve the desired effect of broader adoption.

todd8 5y ago
So true! The dream of adding support for an additional extension language doesn’t fix the UI, the archaic defaults, unusual terminology, licensing restrictions, key bindings from keyboards used half a century ago. It’s all very sad. The worlds best editor, one of my favorite tools, is now too big to renovate. I used to toy with the idea of “fixing” TeX because I really liked using it, but again the fundamental problem that I wanted fixed was the extension language. I wanted something better than layers of macros on top of macros. Maybe I should stop musing about fundamentally transforming Emacs and go back to daydreaming of an improved TeX.