A sure sign you're no longer writing a text editor.
The thing is that there's no real separation between the core editor and plugins in Emacs. The core of the C code of Emacs is the implementation of Emacs Lisp, both the editor and any plug-ins are simply Emacs Lisp code running on that implementation. So whatever you can write in Emacs Lisp becomes part of Emacs itself (whether its part of base Emacs or an external package is only a difference in distribution, but not of the technical implementation).
That's a bit of exaggeration. The core also includes stuff like redisplay and I/O, it's not a pure Lisp implementation, but includes other editor-focused stuff.
That close coupling is one of the problems with changing the underlying implementation.
A successful rewrite of EMacs into a new language (or even to just rewrite the core C VM) is a significant and noteworthy achievement. Anyone able to do so would likely receive considerable notice both by peers and potential employers. One of the last people to do so (Jamie Zawinski) wound up basically creating the modern web browser (and arguably the web) with his post XEmacs Netscape/Mozilla work. THAT, AND NOT BOREDOM, IS WHY ONE MIGHT ENDEAVOR A REWRITE OF EMACS... hacks and glory.
Maybe I'm cynical. The first person to climb Everest achieved something. So to did the next few people. Now? Its still a challenge, but it is not exactly the same challenge it was.
Similarly, sure. I get it. Rewriting is a challenge, but its not as meaningful as it once was. Theres tons of problems you can solve and showcase talent.
show me one successful contemporary rewrite of Emacs (outside of XEmacs) that maintains 95%+ elisp source compatibility with GNU Emacs.
To my knowledge the closest anyone has come is the recent resuscitation of the Guile based backend for Emacs. Im not sure that effort qualifies as a "rewrite" tho.
But I mean, say you succeeded. Then what? The best case would seem to be that you have basically the same program still. Jokes aside modern machines are not struggling to run emacs .
OK, but are those problems unsolved for technical reasons or because the existing tooling hasn't yet been rewritten into another language. rewriting grep in Rust is different than solving an unsolved technical operating system or data management problem, and either of those examples are an entirely different thing than rewriting a terminal and GUI based (with multiple graphical backends) 40+ year old user land application that runs on many different operating systems and many different architectures and has done so for decades all while maintaining backwards compatibility for it's scripting language (elisp) across decades of releases. There just aren't very many examples of such endeavors. Not many at all...
I just don't understand if you attempted to implement Emacs before you have actually understood what is the job you have to do? :) Are you one of Remacs/Emacs-ng folks?
Emacs is not a trivial application. Of course you have to implement all the features they implement, and those have grown over 40 years.
While, your article is a nice read for someone who is not familiar with Emacs implementation and features, you should have really understood that before you have attempted to port or re-implement Emacs. There are also many more features one has to take care of, in their Lisp implementation, encodings and renderer, are just but some of "features" you have to re-implement. There are others as well.
By the way, already said, Lem is not try to re-implement Emacs. Even Emacs-ng and Remacs are more of forks than re-implementation, certainly Emacs-ng.
Nobody normal would, but the author somehow believes he has discovered hot water because they realized Emacs has lots of features that have to be re-implemented.
There are plenty of examples of rewrites of program foo in the same language as foo-ng too, where they want to fix some architectural issue.
Rewrites in another language should to some extent be seen as a case of that, where the language is also part of the engineering. Like replacing a wooden bridge with a steel or concrete one. The materials we use have their pros and cons, and not just programmer familiarity. And all the materials we have to work with were discovered in the last century, so switching language now might be a similar decision as when people in the 1960s decided they wanted to use some other plastic than bakelite; plastic didn't have to be all bakelite forever just because bakelite was the first household plastic.
And what fits the programmer is something to consider; our brains aren't all wired the same. A lot of the discussion around the differences in programming languages is framed in very universal terms, but ultimately no language fits everyone any more than one shoe design or ambient temperature or ingredient or tool design will fit everyone. The brain is an organ, too, we just have a hard time telling and talking about whether the tools for that fit the way we talk about tools fitting our hands.
And, finally, sometimes recreation is just a sort of creative expression, similar to playing established musical works on an instrument one is familiar with or trying to learn, or recreating some artwork in some given material or with some process, like whittling or 3d-printing a chess set. Or very trivial food production, like having one tomato plant. Sometimes the things we do are just about the personal connection, the process, and personal enjoyment.
I am becoming more and more convicted of the conspiracy that it is a push for less restrictive licenses for core parts so companies can use without having to worry about the GPL.
But, ofc, there are lot's of people also trying to use it for self-promotion as the market has sold the idea that everyone needs a rich GitHub profile to be hire-able. Many big projects complain about horrible PRs and obnoxious devs. Now with vibe coding this will become even worse.
Partially. I think it's really unfortunate that the uutils-coreutils aren't GPL-3.0-or-later.
But other tools, like sudo, were never GPL, so replacing that with sudo-rs is pretty uninteresting license-wise.
Though the way the MIT license works, I guess one possible future here is someone (GNU or other) forking the uutils-coreutils and relicensing it as GPL. It doesn't always have to be a MIT-to-proprietary pipeline :V
Good question. Unfortunately the obsession with rewriting Emacs in a new language has more to do with end running RMS' early daft elisp language design decisions (specifically not making elisp semantics symmetric with Common Lisp's) and less to do with simply rewriting programs simply for the sake of doing so.
Emacs is one of the oldest pieces of software in continuous use across multiple platforms and architectures. It has accumulated layers of kludges, hacks, spit, and duct tape to hold it all together over the decades. If one can successfully (and fully) migrate Emacs C based core to another language, that is a significant and notable accomplishment and a feather in any hacker's cap.... This is why you see efforts to rewrite EMACS in a new language.
Surely there are other newer projects with less technical and legacy debt than Emacs that experience rewrites in new languages... and that is also an accomplishment, but just not nearly the same level of accomplishment as a GNU Emacs rewrite.
Once you realize you can actually write stuff, you start seeing problems everywhere that need to be re-written using your new favourite language just because why not. It's a phase most of us go through.
There are good reasons and bad reasons to want to rewrite. Your example certainly does occur but those kinds of projects don't usually go very far. (How many software products have you personally switched to that tout "rewrite" as a main feature?)
I have a viscerally negative reaction to "X is bad because it's old". But there's some truth to the idea that when a project stretches its internal abstractions to their limits, they don't have anywhere to grow. That can happen because they were wrong to start with, or because the growth areas turned out to be different. For instance, emacs boots up an "image" and then stores that whole booted application's memory on disk so that booting it later can be fast. It predicted that startup time would be a, maybe the, primary concern in the future. In some sense the project is made to be about booting quickly, making some other concerns that it might have later more difficult to solve in exchange for the boot time benefit. And now it turns out that we do have those other concerns, and solving them is harder because of this architectural decision.
If a codebase shares 0 with the original a rewrite but implements an identical API (supports the existing elisp code to a perfect or even just a high degree) I'd still call it a rewrite, not a new product. But this is a semantic argument
I also think the ability to write compatible software written in entirely different languages is one of the most impressive things you can do in software engineering.
Like the ability to have complete compatibility is no different than actual spoken languages conveying similar concepts but with entirely different syntaxes and words.
This would be extremely impressive because computer science is not natural. You aren't going to find a naturally occurring CPU. The idea that we can create software with 100% interoperability is worth pursuing in and of itself.
It can only push our industry forward as a discipline.
Lisp is the greatest (class of) programming language ever created. Anyone who doesn't understand why Emacs (the greatest Editor ever created) needs to support Lisp needs to reconsider their value as a programmer.
Yes, absolutely. This is like asking "the kernel rewrite needs to support hardware?" Emacs is a lisp interpreter with a small editor layered on top of it. If you're not a lisp fan you're not going to be an emacs fan. That's fine, but this is a really baffling statement
This is one of the best articles on Emacs I've read in a long time, props to the author and thanks for posting this. It makes me appreciate just how special Emacs in, and the lengths it goes to to provide a good experience for users.
TwentyCharactersShor@reddit
A sure sign you're no longer writing a text editor.
As an aside, are people really that bored to re-write emacs? Surely theres better problems to solve.
roerd@reddit
The thing is that there's no real separation between the core editor and plugins in Emacs. The core of the C code of Emacs is the implementation of Emacs Lisp, both the editor and any plug-ins are simply Emacs Lisp code running on that implementation. So whatever you can write in Emacs Lisp becomes part of Emacs itself (whether its part of base Emacs or an external package is only a difference in distribution, but not of the technical implementation).
sickofthisshit@reddit
That's a bit of exaggeration. The core also includes stuff like redisplay and I/O, it's not a pure Lisp implementation, but includes other editor-focused stuff.
That close coupling is one of the problems with changing the underlying implementation.
somecucumber@reddit
You're right. Emacs is not a text editor and was never meant to be.
church-rosser@reddit
A successful rewrite of EMacs into a new language (or even to just rewrite the core C VM) is a significant and noteworthy achievement. Anyone able to do so would likely receive considerable notice both by peers and potential employers. One of the last people to do so (Jamie Zawinski) wound up basically creating the modern web browser (and arguably the web) with his post XEmacs Netscape/Mozilla work. THAT, AND NOT BOREDOM, IS WHY ONE MIGHT ENDEAVOR A REWRITE OF EMACS... hacks and glory.
TwentyCharactersShor@reddit
Maybe I'm cynical. The first person to climb Everest achieved something. So to did the next few people. Now? Its still a challenge, but it is not exactly the same challenge it was.
Similarly, sure. I get it. Rewriting is a challenge, but its not as meaningful as it once was. Theres tons of problems you can solve and showcase talent.
church-rosser@reddit
how many of those problems are 40+ years old and remain largely unsolved tho?
TwentyCharactersShor@reddit
A literal ton! Rewriting emacs - itself an icon of too many features - is not unsolved.
You could update *nix features, help manage large datasets etc. There's so many problems we havent solved and could benefit from open source.
church-rosser@reddit
Rewriting Emacs in another language is unsolved.
show me one successful contemporary rewrite of Emacs (outside of XEmacs) that maintains 95%+ elisp source compatibility with GNU Emacs.
To my knowledge the closest anyone has come is the recent resuscitation of the Guile based backend for Emacs. Im not sure that effort qualifies as a "rewrite" tho.
RICHUNCLEPENNYBAGS@reddit
But I mean, say you succeeded. Then what? The best case would seem to be that you have basically the same program still. Jokes aside modern machines are not struggling to run emacs .
church-rosser@reddit
Not entirely true. Emacs is single threaded, sometimes it blocks and redisplay lags...
church-rosser@reddit
OK, but are those problems unsolved for technical reasons or because the existing tooling hasn't yet been rewritten into another language. rewriting grep in Rust is different than solving an unsolved technical operating system or data management problem, and either of those examples are an entirely different thing than rewriting a terminal and GUI based (with multiple graphical backends) 40+ year old user land application that runs on many different operating systems and many different architectures and has done so for decades all while maintaining backwards compatibility for it's scripting language (elisp) across decades of releases. There just aren't very many examples of such endeavors. Not many at all...
L8_4_Dinner@reddit
Well they’re rewriting emacs as a warmup for rewriting Conway’s Game of Life. These things are widely used by every remaining 93 year old greybeard.
arthurno1@reddit
I just don't understand if you attempted to implement Emacs before you have actually understood what is the job you have to do? :) Are you one of Remacs/Emacs-ng folks?
Emacs is not a trivial application. Of course you have to implement all the features they implement, and those have grown over 40 years.
While, your article is a nice read for someone who is not familiar with Emacs implementation and features, you should have really understood that before you have attempted to port or re-implement Emacs. There are also many more features one has to take care of, in their Lisp implementation, encodings and renderer, are just but some of "features" you have to re-implement. There are others as well.
By the way, already said, Lem is not try to re-implement Emacs. Even Emacs-ng and Remacs are more of forks than re-implementation, certainly Emacs-ng.
RICHUNCLEPENNYBAGS@reddit
Why would you expect it to be easy to rewrite a project that many people have worked on for decades?
arthurno1@reddit
Nobody normal would, but the author somehow believes he has discovered hot water because they realized Emacs has lots of features that have to be re-implemented.
PM_ME_CALF_PICS@reddit
What’s with the obsession with rewriting programs in a new language? Just curious I’m a noob.
syklemil@reddit
There are plenty of examples of rewrites of program
fooin the same language asfoo-ngtoo, where they want to fix some architectural issue.Rewrites in another language should to some extent be seen as a case of that, where the language is also part of the engineering. Like replacing a wooden bridge with a steel or concrete one. The materials we use have their pros and cons, and not just programmer familiarity. And all the materials we have to work with were discovered in the last century, so switching language now might be a similar decision as when people in the 1960s decided they wanted to use some other plastic than bakelite; plastic didn't have to be all bakelite forever just because bakelite was the first household plastic.
And what fits the programmer is something to consider; our brains aren't all wired the same. A lot of the discussion around the differences in programming languages is framed in very universal terms, but ultimately no language fits everyone any more than one shoe design or ambient temperature or ingredient or tool design will fit everyone. The brain is an organ, too, we just have a hard time telling and talking about whether the tools for that fit the way we talk about tools fitting our hands.
And, finally, sometimes recreation is just a sort of creative expression, similar to playing established musical works on an instrument one is familiar with or trying to learn, or recreating some artwork in some given material or with some process, like whittling or 3d-printing a chess set. Or very trivial food production, like having one tomato plant. Sometimes the things we do are just about the personal connection, the process, and personal enjoyment.
arthurno1@reddit
This were definitely some of the better allegories I have read on programming.
RoomyRoots@reddit
I am becoming more and more convicted of the conspiracy that it is a push for less restrictive licenses for core parts so companies can use without having to worry about the GPL.
But, ofc, there are lot's of people also trying to use it for self-promotion as the market has sold the idea that everyone needs a rich GitHub profile to be hire-able. Many big projects complain about horrible PRs and obnoxious devs. Now with vibe coding this will become even worse.
notfancy@reddit
Suspicion is a prison alright. Break free.
/s(you meant *convinced)
PM_ME_CALF_PICS@reddit
I can see the licensing being a thing. Wasn’t that an issue recently with parts of Ubuntu being rewritten in rust under an MIT license?
syklemil@reddit
Partially. I think it's really unfortunate that the uutils-coreutils aren't
GPL-3.0-or-later.But other tools, like
sudo, were never GPL, so replacing that withsudo-rsis pretty uninteresting license-wise.Though the way the MIT license works, I guess one possible future here is someone (GNU or other) forking the uutils-coreutils and relicensing it as GPL. It doesn't always have to be a MIT-to-proprietary pipeline :V
RoomyRoots@reddit
Yeah, most of these new "better than GNU" are MIT or alike.
church-rosser@reddit
Good question. Unfortunately the obsession with rewriting Emacs in a new language has more to do with end running RMS' early daft elisp language design decisions (specifically not making elisp semantics symmetric with Common Lisp's) and less to do with simply rewriting programs simply for the sake of doing so.
Emacs is one of the oldest pieces of software in continuous use across multiple platforms and architectures. It has accumulated layers of kludges, hacks, spit, and duct tape to hold it all together over the decades. If one can successfully (and fully) migrate Emacs C based core to another language, that is a significant and notable accomplishment and a feather in any hacker's cap.... This is why you see efforts to rewrite EMACS in a new language.
Surely there are other newer projects with less technical and legacy debt than Emacs that experience rewrites in new languages... and that is also an accomplishment, but just not nearly the same level of accomplishment as a GNU Emacs rewrite.
FKaria@reddit
What's going on with the AI generated replies? Have nothing else to do?
old_man_snowflake@reddit
It’s the “good question!” Stuff at the beginning.
omgFWTbear@reddit
Imagine being so young that writing a paragraph must be the work of AI.
teslas_love_pigeon@reddit
Nothing about that comment came across as LLM writing.
ploptart@reddit
Good question.
church-rosser@reddit
haha, that wasn't AI, that's my squirrel brain run amok 😁
renatoathaydes@reddit
Once you realize you can actually write stuff, you start seeing problems everywhere that need to be re-written using your new favourite language just because why not. It's a phase most of us go through.
ketralnis@reddit (OP)
There are good reasons and bad reasons to want to rewrite. Your example certainly does occur but those kinds of projects don't usually go very far. (How many software products have you personally switched to that tout "rewrite" as a main feature?)
I have a viscerally negative reaction to "X is bad because it's old". But there's some truth to the idea that when a project stretches its internal abstractions to their limits, they don't have anywhere to grow. That can happen because they were wrong to start with, or because the growth areas turned out to be different. For instance, emacs boots up an "image" and then stores that whole booted application's memory on disk so that booting it later can be fast. It predicted that startup time would be a, maybe the, primary concern in the future. In some sense the project is made to be about booting quickly, making some other concerns that it might have later more difficult to solve in exchange for the boot time benefit. And now it turns out that we do have those other concerns, and solving them is harder because of this architectural decision.
justinhj@reddit
A rewrite is really just a new editor if the assumption is that emacs is built on the wrong concepts
ketralnis@reddit (OP)
If a codebase shares 0 with the original a rewrite but implements an identical API (supports the existing elisp code to a perfect or even just a high degree) I'd still call it a rewrite, not a new product. But this is a semantic argument
teslas_love_pigeon@reddit
I also think the ability to write compatible software written in entirely different languages is one of the most impressive things you can do in software engineering.
Like the ability to have complete compatibility is no different than actual spoken languages conveying similar concepts but with entirely different syntaxes and words.
This would be extremely impressive because computer science is not natural. You aren't going to find a naturally occurring CPU. The idea that we can create software with 100% interoperability is worth pursuing in and of itself.
It can only push our industry forward as a discipline.
YetiBarBar@reddit
Emacs is an OS that lacks a decent text editor. It's hard to write an OS!
sysop073@reddit
This joke is probably older than most of the people reading it
bobj33@reddit
Emacs is a recursive acronym like GNU
or
I heard these in the early 1990's when computers had between 4 to 16MB RAM
busres@reddit
Don't forget Escape Meta Alt Control Shift
GuyWithLag@reddit
That's why the Amiga500 with 512kb of RAM came with MicroEmacs...
jeffsterlive@reddit
Dammit eMacs.
OutOfDiskSpace44@reddit
The trees are everywhere part is great: https://kyo.iroiro.party/en/posts/why-rewriting-emacs-is-hard/#trees-are-everywhere
lovelettersforher@reddit
I enjoyed reading this part, this blog post is really well-written.
kanzenryu@reddit
I get the impression that even just building the current state from source is quite a challenge.
Tempus_Nemini@reddit
No, if you rewrite it in Rust using Neovim )))
bundt_chi@reddit
Should be a breeze for AI to do... /s
Sweaty-Link-1863@reddit
Rewriting Emacs is hard because Emacs rewrites you first
shevy-java@reddit
The rewrite needs to support lisp?
It may not be worth to rewrite.
stumblinbear@reddit
I've had u/church-rosser blocked for ages. You can ignore anything they say.
lelanthran@reddit
I think you're in the wrong thread. Or even wrong subreddit.
Come to think of it, you may just need to get your own internet.
RoomyRoots@reddit
Lot's of trolls everywhere.
stumblinbear@reddit
Trolling no longer has a discernible meaning
church-rosser@reddit
Lisp is the greatest (class of) programming language ever created. Anyone who doesn't understand why Emacs (the greatest Editor ever created) needs to support Lisp needs to reconsider their value as a programmer.
ketralnis@reddit (OP)
Yes, absolutely. This is like asking "the kernel rewrite needs to support hardware?" Emacs is a lisp interpreter with a small editor layered on top of it. If you're not a lisp fan you're not going to be an emacs fan. That's fine, but this is a really baffling statement
paholg@reddit
This is simply untrue. I happily used emacs for years, and interacting with lisp was by far the least pleasant part of it.
ketralnis@reddit (OP)
Sure, alright I can buy that. But you're sure as heck not going to be interested in a post about emacs internals and rewrites.
bravopapa99@reddit
I used to have emacs as my login shell. I used ratpoison for that too one upon a time. Ratpoison wasn;t half bad to be honest.
https://www.nongnu.org/ratpoison/
ahyatt@reddit
This is one of the best articles on Emacs I've read in a long time, props to the author and thanks for posting this. It makes me appreciate just how special Emacs in, and the lengths it goes to to provide a good experience for users.
victotronics@reddit
Lordy.