Use python instead of lisp.
---
That's what using X instead of Lisp to make "a better Emacs" sounds like, okay? Emacs is a Lisp-machine, it's built on top of Lisp, it needs Lisp to be Emacs. Otherwise it wouldn't be Emacs. Like at all. Don't be stupid, stop saying stupid shit like "python instead of lisp"...
Interlisp-D/Medley: https://interlisp.org
MIT CADR: https://tumbleweed.nu/lm-3/
These run an actual Lisp operating system.
Can you imagine people enjoying the user experience of Emacs while simultaneously preferring languages that are not Lisp?
It's not "for me", it is what it is. Emacs first and foremost is a Lisp machine, with a text-editor built into it, not the other way around, it's not a text-editor that uses Lisp as its configuration language.
"user experience of Emacs" is to be able to send any expression and sub-expression without any preceding ceremony directly to the REPL. Everything what Emacs does stems from that. No, Python doesn't have the same REPL. Every single stage of it in Python is different. Lisp's Read, Eval, Print, Loop - they all have slightest differences. Those differences are possible because of Lisp's homoiconic nature. Because of that you get Lisp macros, because of that you get advising functions, because of that you can do source blocks in Org-mode that can interact with and modify their own execution environment. Lisp's homoiconicity allows code to be treated as data and vice versa, enabling powerful metaprogramming capabilities. This means you can:
1. Manipulate code at runtime
2. Create domain-specific languages easily
3. Extend the language itself
In Org-mode, this translates to source blocks that can:
1. Dynamically generate and execute code
2. Modify their own content or other blocks' content
3. Interact with the Emacs environment seamlessly
This level of flexibility and power isn't achievable in Python's REPL due to its more rigid separation between code and data. While Python is highly versatile, it lacks the deep introspection and self-modifying capabilities that Lisp's homoiconic nature provides, making Lisp uniquely suited for certain advanced metaprogramming tasks and interactive development paradigms.
So the bottom line is: you can imagine really hard, but it would remain just an imagination, if you want to build something like Emacs - a REPL that has a built-in text editor, you need a Lisp, because non-homoiconic languages DO NOT HAVE exactly same REPLs. Now, do you want me to get seriously pedantic and explain how every step in ReadEvalPrintLoop differs in Lisp and Python?
I don't think it makes sense. One can build programmable editors in many interactive languages. The language for an editor doesn't need to be Lisp. It could be Python, JavaScript, Ruby, PERL, Forth, ... Typically a form of EVAL or compile/load is enough to do so.
Of course, one can - VSCode is a "programmable editor", no? Emacs is a bit different though, wouldn't you agree? It's rather a Lisp REPL that has a text-editor built on top of it.
The first Emacs wasn't using Lisp at all. Wasn't it literally the Emacs?
> It's rather a Lisp REPL that has a text-editor built on top of it.
Just write an Emacs without a Lisp REPL. It can have the same Dired, just written in Python. There is nothing in Dired, which requires Lisp.
Maybe it's just personal preference, since I think it's easier for me to think in python over lisp (which I've known for longer, but I still fumble through)
I do think python would make emacs more accessible to a wider audience.
It would not be Emacs anymore. Emacs is specifically tied to Lisp. Emacs is not a text editor that uses Lisp as the configuration language. Emacs is a Lisp machine that has a text editor built into it.
An "Emacs-like" editor built on Python might be interesting, but it wouldn't be a "better Emacs" or even "like Emacs", it would be a completely different thing.
You may dislike Lisp, you may even hate Lisp, but the fact remains unchanged - there is an emerging class of applications that is significantly more difficult to build around non-homoiconic languages. Emacs is one of them. Stop fetishizing your favorite programming language as the quintessence of Emacs. The best one can do is to build a compiler/transpiler to spit out Lisp code, and people have tried that. Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs.
GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages.
> Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs
That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, using Lisp.
Sure, there's Guile Emacs, there's MicroEmacs - both not Elisp-based, still built on top of Lisp dialects; there's XEmacs, Remacs - both still use Elisp, there's also mg which afaik completely not lisp-based, but I don't know how much of it still 'emacs-like'. In general though, GNU Emacs is what people usually mean when they speak about Emacs, unless they're explicitly talking about others.
Here is an old Emacs timeline:
https://www.jwz.org/doc/emacs-timeline.html
The actual historic Emacs wasn't written in Lisp and was not extensible in Lisp. It was written on top of TECO and assembly. It was extensible.
The second and third Emacs were both written in Lisp (Zetalisp and Maclisp) and they were completely written in Lisp.
At some point Gosling wrote an Emacs in C and Mocklisp. Stallman took that one and rewrote it into GNU Emacs.
We have lots of Emacs variants written in languages like TECO, C, Fortran, ...
Craig A. Finseth wrote "The Craft of Text Editing: Emacs For The Modern World"
Chapter Ten of above book describes what Emacs-type means: http://www.finseth.com/craft/#c10
Extensibility is a general feature and not tied to Lisp or GNU Emacs.
The book contained a list of Emacs implementations. An newer list is here: http://www.finseth.com/emacs.html
You can see that there is a multitude of editors in the Emacs category. The list also mentions the implementation and the extension language.
> GNU Emacs is what people usually mean when they speak about Emacs
That's a bit sad. It's like saying "Linux" and think that its the same as "Debian Linux". Similar there are a lot of different Emacs-like editors. Claiming that there is only a single way to implement Emacs goes against the evidence that there are a lot of Emacs-like editors, which are not implemented in C + Emacs Lisp, including the original first Emacs.
I would think that by far the most important Emacs is GNU Emacs, but I don't think its implementation language choice (C + Lisp) is necessary to implement an extensible Emacs-like editor. Also be aware even though GNU Emacs is a popular Emacs editor, there are some people who are using different Emacs-like editors instead. I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. Both core designs date back many decades, actually even before GNU Emacs existed.
So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
> Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written in Emacs Lisp for GNU Emacs. Remember, the core of GNU Emacs - both the core Lisp implementation and some core editor and UI functionality - is written in C.
Btw., on a real Lisp Machine the editor (Zmacs) was not the main user interface. For example on a Symbolics (but also in Interlisp-D), the listener and a file browsers were their own applications. Zmacs in Genera has a Dired mode, but no listener. Also Genera can run multiple Zmacs windows in the same Lisp, running concurrently -> the Lisp supports multiple threads and the applications use that feature.. Something which GNU Emacs can't easily do. It's mostly blocking and single threaded. Something which can't be easily fixed in Emacs Lisp.
Run Lisp code in GNU Emacs in the REPL (m-x ielm) and it blocks the UI. That can't trivially fixed and is a major implementation fail of GNU Emacs.
Other Emacs-like editors can run multiple things, without blocking the user interface.
Like interactively, without restarts and all? Wow.
> That can't trivially fixed and is a major implementation fail of GNU Emacs.
Yes, that is a real big, sad flop.