by s3arch on 4/24/23, 2:49 AM with 13 comments
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?
by retrocryptid on 4/24/23, 4:34 AM
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.
by ParetoOptimal on 4/26/23, 3:30 PM
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?
by juxtapose on 4/25/23, 3:59 AM
A successor to Atom is Pulsar [2].
by throwawaysalome on 4/24/23, 6:28 AM
Well, which is it?
Your rambling suggests extreme ignorance of how emacs is built, and what it's good at.
by spindle on 4/24/23, 3:33 AM
by adastra22 on 4/24/23, 2:57 AM
by hackrusr on 4/25/23, 6:11 AM
emacs-ng
Nyxt