Ask HN: Design of Emacs type extensible editor based on electron?
Please hear me out: Do not consider this as some unrealistic ambitious project that I am going to pursue. This is purely a thought experiment and design discussion on the feasibility of the idea that bothers me.
I use Emacs most of the time. I do consider it a great piece of software purely due to its extensible nature. I can go on about how Emacs is fabulous, but that is not the point here.
I use VSCODE too. And it is also a great text editor based on Electron.
Electron is a great framework too.
Most of us while doing software development, use a browser. Either for browsing documentation, finding answers, checking the meaning of the error messages, etc. We copy code from the editor, shell to the browser, and back to the editor, and shell.
Also using electron we can create almost any kind of desktop application. Currently what is happening is we create/ship the entire Chrome/JS run time to create an entirely new application for each specific case.
Now let's try to put the pieces together.
Why can't there be a single editor that has a similar extensible nature as emacs but uses JavaScript as the scripting language, and develop extension using HTML and CSS unlike only a text-based extension using elisp in emacs, so that we can leverage the Chrome runtime efficiently?
Why can't we browse the web, edit text, and use the terminal all simultaneously?
Yes, anything is possible given that we solve the hurdles.
Based on your expertise and experience what challenges do you consider one may face during the design and implementation of these requirements? I was going to shout "heretic!" How dare you defame the C-c C-f gods with your BLASPHEMY! But yes, you're right, Electron is pretty cool and doing thought experiments is also cool. However... as a backend developer, I rarely use a browser. And when I do, I use Eww in emacs. If I want to read a pdf, I convert it to sixels and print it out to the terminal. Plus, if I stay in the terminal, my identity goes with me when I ssh to other systems, so I can avoid SSO weirdness. I'm not a BIG elisp fan, but I like scheme more than I like javascript (the reason I like javascript is I it has some scheme-like features.) The last time I thought about replacing emacs I thought about doing it with Janet. But I'm willing to bet you could compile Janet to JavaScript or JavaScript to Janet or really anything to anything else, so I think the rendering model might be the component to get absolutely right. Before you go off on HTML plus CSS, I encourage you to look at DSSSL, CSS and XLS(T)'s spiritual successor. The flow object model it used was IMHO much better than HTML's box model. It makes me think I should stop talking and write some code. I'd be real interested to hear more about what you come up with, even if it's just ideas or code snippets or very basic demos. This is why I love HN. There is always a learning. I never knew there were other models than HTML's box model. This is exactly what emacs-ng does? https://emacs-ng.github.io/emacs-ng/ > This project should be considered an additive native layer over emacs, bringing features like Deno's Javascript and Async I/O environment, Mozilla's Webrender, and other features in development. emacs-ng's approach is to utilize multiple new development approaches and tools to bring Emacs to the next level. It is maintained by a team that loves Emacs and everything it stands for - being totally introspectable, with a fully customizable and free development environment. We want Emacs to be a editor 40+ years from now that has the flexibility and design to keep up with progressive technology. I guess it uses webrender instead of electron? How do you dig out emacs-related threads that are so far down the Ask HN list? I'm surprised that nobody here mentioned Atom [1]. IIUC, Atom was designed to be hackable like Emacs. A successor to Atom is Pulsar [2]. Do not consider this an unrealistic ambitious project... this is purely a
thought experiment Well, which is it? Your rambling suggests extreme ignorance of how emacs is built, and what
it's good at. I think it's a good idea. It won't be as extensible as Emacs, though, because Emacs is lisp almost all the way down. Can you please help me understand more? What blocks it to be generally extensible? Emacs Lisp is deeply embedded everywhere in Emacs. For example, a character can carry some 'display' properties that contain Lisp code, and the display engine will actually run the code [1]. The same cannot be said for Web engines. Of course, the usefulness of this is quite debatable -- the display of Web elements can be managed by CSS just fine. [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Di... Sure you could do this. But why would anyone want to? Plenty of reasons: A. There are several types of experiments that could be easier outside of emacs than inside emacs. B. If you wanted to extend the browser with Javascript instead of e-lisp, rewriting it as a node package or electron app might be easier. C. To scratch an intellectual itch. How do you know what's possible if you don't try? To be sure, it would likely take a LOT of time before it reaches feature parity or attracts as large a community as emacs, but it sounds like a fun project. Yes. I understand this could be only my requirement. I always wanted to use web in Vscode, copy the error messages from terminal to inbuilt browser, and copy code from web back to terminal or editor. I also wanted to listen music, watch tutorials either from local or from web. I also wanted to develop extension that support these requirements. But I felt limited extending Vscode. Have a look at: emacs-ng Nyxt