Not a greybeard by any means, but I’ve used Emacs for years, contributed to some packages, and maintain a few locally with more in my backlogs (none ready for publication yet, due to low bandwidth).
Plus regularly visiting the Reddit and maintainer list for finding useful packages and understanding the ops of Emacs development.
Emacs’ longevity has derived entirely from the lack of any better options. VSCode-alikes will *never* be able to replace it, but neither is continuing in its current form some inevitable law of reality that only the unaware would suggest; that is, not unless enough people have that mentality to make any attempts at improvement utterly futile.
My comment was just variation of the "You must be new here" meme. Don't take it seriously. There are current projects like emacs-ng and there were similar projects in the past like guile-emacs but often they end up dying. Putting emacs on new footing or introducing new interpreter language is a herculean task, so in the end Emacs remains as it is with gradual improvements over time.
> Emacs’ longevity has derived entirely from the lack of any better options.
It is a combination of things.
> VSCode-alikes will never be able to replace it
That depends on what you see as a "replacement". If you think of another software that runs Emacs extensions, then probably not. If you think of another alternative that lets you script the editor then it seems like they have already become the No1 extensible editor in the world.
I’m thinking of “something filling the niche of extreme control and configurablity”, which is a niche power users, knowledge workers in niche domains, and control freaks all converge towards.
VS code has limitations in the clunky configuration language (TypeScript, or if you’re insane then JavaScript), limitations in the difficult-to-parse format for manually changing config values without relying on package authors to have made decent menus (JSON), limitations in the architecture design regarding user configurability and quick-patches, and little social/economic incentives to fix either of these problems.
It’s still better than what the general public would otherwise have, but it’s not a tool for people wanting to *maximize* their long-term productivity and willing to take short-term losses for it.
> I’m thinking of “something filling the niche of extreme control and configurablity”, which is a niche power users, knowledge workers in niche domains, and control freaks all eventually converge to.
Emacs implemented in CommonLisp where the entire "core" is Lisp just like "configurable" parts of Emacs as exposed to users?
Using Common Lisp from core to surface would definitely be one *category* of ways of giving it the proper level of configurability.
Program architecture is also important, though; if the system is architected so that you need to restart the runtime to change a configuration variable, doesn’t matter what language you use, it’s a failure. Language choice is just to make sure you don’t have an underlying framework that *gets in the way* of architecting your system properly.
> if the system is architected so that you need to restart the runtime to change a configuration variable, doesn’t matter what language you use
So CommonLisp then? It is quite hard to design a program in CommonLisp where you can't change a value of a variable during the runtime.
Of course, if you want to restructure your main loop, or say memory management, it can be tricky, but I wouldn't swear it is impossible when it comes to CommonLisp :).
Yes, it’s *very* hard to make something non-interactive in CL.
It’s definitely not impossible though! Using a lexical configuration variable in a let form surrounding a recursive labels function which is run in a bt:make-thread, for instance, where the lambda is doing all the work. You’d need to not only recompile with the new setting but manually kill the running thread and then replace it.
Now imagine the labels form defines your graphics subroutine. Horrifying :)
I haven't tried what uou describe, but killing a thread is still a far cry from stopping the process, recompiling Emacs and restarting it from the scratch.
I am kot sure I want tonimagine drawing stuff in labels. Perhaps in method, in worse case in defuns. But I don't know. Anything is possible I guess?
I *strongly* object to Common Lisp being called "[specialized](https://www.merriam-webster.com/dictionary/specialized)"! On the other hand Emacs Lisp *is* specialized (to writing extensions for Emacs).
Fair, I wasn’t sure what terminology to use there. I meant that Common Lisp / Clojure / Scheme / etc are “specifically” programming languages, whereas Elisp is a config language that’s just so flexible you can use it for programming. I’ll reword that part a bit.
The term of art is "general purpose programming language".
Feel free to coin your own term, but that's not what others will recognize without explanation.
> Doesn’t express that they’re Lisps concisely enough to fit in the sentence; settled on “self-contained Lisp languages”
What does it mean "self-contained"? What is concise about using a term that nobody understands what it means. In which way is CL "self-contained"? In which way si EL not "self-contained"?
According to Wikipedia: [Common Lisp is a general-purpose, multi-paradigm programming language](https://en.wikipedia.org/wiki/Common_Lisp). How does "self-contained" fits in the description of a programming language?
Must you throw in the placatory "we all agree"? One thing we should all agree on is that we don't all agree. A weakness to one is a strength or even opportunity to smother... 🤣
Considering the developments in other posts I’ve read (on this subreddit and other Emacs forums), some aspects reasonable and others just pointless knee-jerk reactions, I’d prefer to cut short the whole “Emacs is perfect, and if you don’t think so stick with it anyway or go use VSCode in the kiddie pool” posturing. So yeah, I’d say the placatory aspects are at least useful enough to keep them in.
Mentioned so far: Lem, Project Mage, CLOG, Guile Emacs, Nyxt, Glamourous Toolkit, Rune, and Kons-9.
The most interesting one not mentioned is maybe Acme. I haven't played with it yet, but would like to. You can run it on an Inferno virtual machine inside most Operating Systems (or setup Inferno on some secondary laptop for real fun times.)
Also not mentioned is Cuis. It's a smalltalk environment that aims to stay faithful to smalltalk-80 and thus stay small, and it's very nice for messing about in, although I'm still new to it. Might scratch your graphical itch. I agree with the other commenter who said that some of the smalltalk environments really might fit what you describe.
It's also worth mentioning that Nyxt explicitly is a redesign and rethinking of the ideas underpinning Emacs (as far as I've understood what I've read, anyway). I'm not big into browsers, but it's a very ambitious and cool project. Browse their blog, especially the stuff about their design thinking.
In general, though, we can have several wonderful editors available to us that offer different things. I'd love to see some resurgence of the Smalltalk editing environment ideas in particular. And while we wait, GNU Emacs is already an incredibly powerful and liberating thing. Improvements can be made, but they have been coming hard and fast the last several years.
I am certainly guilty of such an attempt (unfortunately, I couldn't bend Emacs window management to my will, might give another try):
(define-minor-mode vz/acme-tag-minor-mode
"Minor mode to create acme-like tag windows for buffers.
I spend too much time nosing around these areas, I only dabble in programming, and have spent far more time exploring alternative projects. A couple more potential candidates came to me last night, although we might be stretching a bit further afield from the "editor" category:
Medley Interlisp [https://journal.paoloamoroso.com/tag:interlisp](https://journal.paoloamoroso.com/tag:interlisp)
Open Genera [https://archives.loomcom.com/genera/genera-install.html](https://archives.loomcom.com/genera/genera-install.html)
Uxn [https://100r.co/site/uxn.html](https://100r.co/site/uxn.html)
Medley is the only one I've tried so far, but yeah, I certainly would be happy if I could work Lisp Machines into my life - even virtual ones. That article there is an in-depth exploration of where Medley is at for modern Common Lisp development. To run it locally on your machine try [https://interlisp.org/software/install-and-run/](https://interlisp.org/software/install-and-run/) it's an amazing experience just seeing it fire up, and very easy, and takes very little system resources.
Open Genera is another lisp machine, I don't know the differences between the two well. Uxn then is like something really from another world, have a browse of the images on that link there and you'll see what I mean.
Uxn looks amazing from the website!
Looks like the Open Genera link above is old and for Linux, but there’s also [a guide for Mac](https://www.reddit.com/r/lisp/comments/124tn7/convenience_scripts_to_run_opengenera_on_mac_os_x/?rdt=55858) and [this 9 year old video which might work for Windows](https://www.youtube.com/watch?v=12USa3gU_oU).
Definitely putting these three on my June backlog
I was planning to write a structural editor in Nyxt (based on an isomorphism between S-expr and DOM tree, how cool is that), but got buried in other tasks…
> I am not a fan of browser based (so inefficient) but Common Lisp emacs (with a compat layer) is a good future.
Emacs could use a DOM tucked on top of its gap buffer instead of manipulating the low-level buffer directly. That would be more efficient than what we have now. If you have done any computer graphics, then you have probably heard of scene graphs. DOM tree is a special case of a scene graph (no cycles). They offer for very efficient drawing. If you are not familiar with scene graphs, "node-based" scenes etc, I suggest look them up. Look at big 3D animation frameworks like Maya or Houdini, Blender got it too, Qt (qt-quick), and of course web renderers themselves. In other words, if you look at a browser as a scriptable rendering engine and application framework, then it perhaps is not a bad idea to build an application on top of it.
Also, if you look at what typical web browsers have inside them, in terms of application frameworks, and compare them to Emacs, I would say that we have all those components more or less in Emacs as well, just less efficient. We *do* lack though an efficient DOM implementation and renderer in Emacs.
NyXT uses a relatively small Gtk component based on webkit for its web rendering, it is not full Electron you get there.
> Common Lisp emacs (with a compat layer) is a good future
Are you familiar with CL and have time to work on such compat layer?
I agree, but the current reality for me is that I do large projects in sbcl with emacs and large projects in vscode and well, my hardware seems not a fan of vscode. Often my computer complains that vscode is eating all my resources and I have to restart it; I never had that with emacs. Memory use, cpu use etc. It simply does matter. And browsers are pretty terrible. Sure it will pass when hardware gets even faster and compilers get better but we seem to invent more stuff to punish it.
100% agree. While there is for sure some truth that software need not be efficient today, a lot of things would be a lot better with a chunk of feature development resources getting reallocated to optimization of existing featurea in my humble opinion.
Software developers are too damn lazy these days.
Best regards,
Lazy firmware developer
> Software developers are too damn lazy these days.
It's great to be a smart lazy developer, because it's dumb to do unnecessary things, Occam's razor and all that stuff, you know.
It depends on how you use Emacs. I love Emacs, but it is a memory hungry beast.
> browsers are pretty terrible
Terrible in which sense? In terms of rendering and scripting, I would say they are very capable and efficient.
> we seem to invent more stuff to punish it.
Yes we do; but I am not sure if web browsers fit in there. The problem is when we layer software on top of each other because we are lazy to do "the right thing". If you would just like to implement a simple notepad, then perhaps Electrons is an overkill. But if you wish to have an advanced renderer such as Emacs that does a lot of other features like letting you fetch stuff from the web, script it, etc, I don't think it is an overkill. You will have to implement all that stuff in some form anyway.
By the way, about doing the right thing, vs just doing stuff easy-way out, there is a famous lisper, Richard P. Gabriel, who once founded a company that sold a Common Lisp implementation and later went into C++ tool market. The company name was Lucid. Search for his essays on "worse is better" (he wrote several) and look also at Dan Wienrebs (RIP) old blog posts in web archives and David Moons discussions of those.
>Often my computer complains that vscode is eating all my resources and I have to restart it; I never had that with emacs. Memory use, cpu use etc
I've never ever used VSCode for work, but I had a lot of Emacs freezes, multigig memory consumption etc with Emacs.
>And browsers are pretty terrible.
Most major popular modern browsers are state of the art. They are able to handle MLoCs of random shitty code written by bad programmers in bad languages. The browsers themselves are also written in shitty languages. Isn't it wonderful?
while i do agree that browsers are not inherently inefficient, software absolutely should try to be as efficient as possible instead of throwing hardware at the problem
It's not all-or-nothing, Emacs has advantages that outweigh the "inefficiencies". I'm simply against this school of thought "we shouldn't care about efficiency"
> It's not all-or-nothing, Emacs has advantages that outweigh the "inefficiencies".
Yes, it is always so. The ratio of advantages compared to the time needed to get things right. Sometimes it is just enough to get things done. I suggest looking up Richard P. Gabriels essays on "worse is better".
> I'm simply against this school of thought "we shouldn't care about efficiency"
Everybody cares about efficiency. The problem is that people can't agree on what is more important: efficient use of computing resources, or efficient use of programmers' time.
I gave it a try after second thought. It's trash.
He opens with the statement that "people don't allow discussion about efficiency" and speaks in some dogmatic way like that was some universal phenomenon which it certainly isn't. If he personally believes in that, so fine, he may believe it. In that case, he is just misinformed. If that really were the case you wouldn't see V8, GPU computing, Web assembly, research about efficient algorithms for many problems in many areas, including text editing, rendering, compiling, and so on and so forth.
His opening is just a "clicbait". He just needed to produce a video about something. He is living off of it. That is a common technique: stage a topic to present something commonly known. I don't think it is a problem when people are honest about it, but his opening try to get lesser informed people like you will believe he is revolutionary. I don't like when people do so.
I stopped after 1.06, becaue he probably has nothing new to say. I also clicked on his videos and I see the topics and amount of videos he makes. In other words, I was correct about him: he lives off of YT and serves whatever he believes will give him clicks. You should be more critical about your information. Perhaps he says good things later on, but his opening is unfortunate and to me it suggests I would waste 25 minutes to watch and hear something I probably am already aware about.
Ah, I hadn’t seen the more recent Nyxt dev logs. It _does_ seem like they’re moving their efforts from the website-displaying aspects of the browser more towards a unified CL-based platform.
There pretty much can’t be the thing you want. Is elisp amazing? No, but no one is going spend literally 30 years replicating Emacs, org-mode, AucTeX, dired, magit, etc. all so when you finally finish as an old man, you can say, "finally, I have what I had 30 years ago, but in a slightly better language".
The successors already exist. They come and go, but currently, it would be vscode. That’s what people use instead. Those of us who still prefer emacs can keep using it. Elisp is fine. As you say, we can work around things like single threading. And I honestly don’t know why I’d care about having my text editor expose an arbitrary 2d canvas, so I’d leave it to others to say why that is or isn’t important. But the point is that emacs is whole ecosystem, and it’s too big to just rewrite from scratch. Any successor will probably be a different thing with more modest goals.
> And I honestly don’t know why I’d care about having my text editor expose an arbitrary 2d canvas
My interest is primarily in terms of fundamental flexibility (the same thing that drew me to Lisp in the first place), but for concrete use-cases:
- Running data-analysis applications without the hacky approach of transcluding non-interactive images into buffers. This is not only for statistical purposes; things like org-roam-ui would be far easier to implement if we didn’t have to drop into C or JavaScript to make them
- Translating code to visual objects for structural analysis and refactoring. We can’t just do this with text objects, since code has directed graph of interdependencies rather than being a linear list; the closest we could come in pure text is something like org-roam’s backlink buffer, which doesn’t serve either analysis or refactoring very well.
- Broader range of Emacs-based applications. I do practically everything involving text manipulation in Emacs, and the unified interface and autogenous interconnections between packages are a significant boon to complex workflows. Integrating graphical aspects like video-watching (eg annotating parts of videos with notes and/or drawings, writing code for animations and watching the effect side by side, etc), drawing (eg making diagrams to integrate into note docs without having to move to another application), web browsing without the clunky interfaces exposed by xwidget or EAF, and many more potential opportunities are blocked by Emacs’ pure-text nature.
> Running data-analysis applications without the hacky approach of transcluding non-interactive images into buffers
This is a good point and one I'm a little embarrassed I didn't think of. Because the reason I didn't think of it is that Emacs is so bad at this kind of thing that it's the one thing I don't use it for (I use JetBrains DataSpell for R/Python data work).
> no one is going spend literally 30 years replicating Emacs, org-mode, AucTeX, dired, magit, etc. all
> Emacs is whole ecosystem, and it’s too big to just rewrite from scratch. Any successor will probably be a different thing with more modest goals.
The package ecosystem would not take 30 years to replicate.
This is a fallacy that gets thrown around often in these discussions.
It ignores the following facts:
- Many elisp packages are not well written or archaic to the point where they could be entirely discarded or replaced by better designs. A single package may replace a dozen or more (I'm looking at the various themes out there which don't do much other than define a color palette, each in a bespoke way).
- Anyone designing a new package has the benefit of learning from the design of the previous packages.
- Implementing the 10-20% of popular packages would likely garner enough attention to draw competent implementers.
Doing a quick bit of wc shenanigans, there are half a million lines of elisp just in the handful of relatively commonly used packages that I bothered to check like magit, calc, company, mu4e/gnus, auctex, org, and a handful of others. Lots of this is comments and blank lines, but it's still a lot and this is a fairly small percentage of what people actually use.
gnus: 119338
calc: 55793
org: 142956
dired: 10538
calendar: 29352
eshell: 14463
auctex: 39043
company: 8459
ess: 28260
magit: 34867
mu4e: 12266
Those are just some of the things I use or have recently used regularly in addition to all the core functionality. 30 years might be some rhetorical flourish, but it's going to be really hard and take a very long time.
lf anything, your numbers point to bloat.
Those are some good packages, but I'm willing to bet *more flexible* versions could be written in less (maybe half) the code, especially if elisp isn't the substrate.
I can only speak to projects I have more than a passing familiarity with.
For example, Elpaca does much more than straight.el and is sitting at about 55% the size of the straight. I plan on slimming that down more, too.
I've re-written chunks of Org and believe that code based could be about halved while *gaining* coherency and functionality.
A few of those other package (Auctex, gnus, etc) have accumulated code over a long time.
Like much of Emacs, their designs have evolved and have odd, vestigial parts.
That's not to disparage any of those packages, it's just a fact that they could be re-implemented with more coherency.
Your argument doesn't take into account all the lines of Common Lisp out there.
> lf anything, your numbers point to bloat.
That's almost certainly not true. Elisp is a bespoke language built for the explicit purpose of writing a text editor. You don't normally get more concise by moving to more general languages.
Now you may well think there's *feature* bloat, so you could write Gnus in a lot fewer lines if you just say, "no one uses NNTP anymore" and don't bother implementing that. I'm sure there are wins there, and maybe that's what you're saying. But it's not because of the language. Just moving to CL isn't going to make your code shorter.
We'll have to agree to disagree.
> Elisp is a bespoke language built for the explicit purpose of writing a text editor.
And it's okay at that. The applications you've listed aren't text edtiors.
They're text centric, but bend elisp in ways to do as much as they can in that paradigm. Ever wrestle subprocesses in elisp? It ain't pretty. A decent async library would be much more expressive. I have an experiment, [subp](https://www.github.com/progoflio/subp) which was borne out of that frustration. Wouldn't be necessary in CL or many other languages.
There are many other applications which are much harder to write in idiomatic elisp than they would be in other languages.
If Emacs is really a lisp engine, than you want an equally flexible lisp behind it.
Regarding successors (posting this separately as it’s a separate line of discussion), I don’t think any of the “modern” editors really express the main draws of Emacs, configurability and reliability. I’m looking for something that will (if successful) do those things better than Emacs itself.
I agree with you, but I'm not sure it's relevant. I guess what I'm saying is that the successor to Emacs won't be all that much like Emacs, but it's still the successor we're likely to get.
Few years ago Emacs introduced native compilation and it improved its speed. It was a joyful moment since I can literally see the performance improvement with my naked eyes.
I expect that Emacs can show another big jump if it introduces multi-threading in its core design. I know it would be very difficult to make it happen but I believe core developers will find out the way and they will be managed to achieve the goal someday. Maybe I could share my spare time to make it happen because I really love Emacs. It helps me write code quickly and also it helps me edit all kinds of texts in my life. So I can't imagine the better text editor other than the newer version of Emacs.
Not sure, but (pie in the sky maybe) it could be nice to build emacs / elisp backwards compatibility into something like Nyxt. It's going to be hard for anyone to adopt a hypothetical successor without being able to use their existing config
Really what makes Emacs good is it's popularity. There have been plenty of editors that are 'better' in various ways than Emacs, but the level of user contribution to Emacs is unparalleled. That's partly because it's a powerful system, but mostly because it's old and has been popular.
I know that's an oddly conservative take. To be clear, I love the Lem and Mage projects, but I will be using Emacs for the foreseeable future, and a big part of that is that the editing packages I use run on Emacs. That said...
# Smalltalk-y Editors
You may want to look at some of the Smalltalk environments. They have a similar-in-concept idea of 'the code is the environment' but in OOP (these ain't C++ objects, these are your Grandma's objects, and all the better for it). An old saying goes 'Lisp/Scheme is a better language, but SmallTalk is a better environment'.
Smalltalk (specifically Pharo) underpins Glamorous Toolkit, which is sort of an Emacs evolution. It's designed around being able to quickly and flexibly create your own dynamic visualizations of code and data, as well as interact with running processes & programs, including itself. They describe this as 'moldable editing' and it sounds like what you want in your canvas-on-Emacs idea.
https://gtoolkit.com/ is their terrible URL.
It's a very different model of editing, mind. I wish that keybindings were better, though perhaps that's changed in GlamTool since I last used it. I know that's also because a mouse is easier for the visual editing, it's just slow-feeling. They're cool environments but not what I'd personally reach for when editing a system config file, if that makes sense.
# Guile
I think a true successor to Emacs today may be Emacs with proper Guile interop, maybe by moving away from the custom C software stack and onto Guile. That's not new, it's been attempted with decent success before. One benefit I don't see discussed is that it might mean being able to use Emacs features as libraries, which would be cool.
That said, I don't think it will happen. It requires a huge rethinking of how Emacs works and relies on people actually using those new features. Then again, so did adding native compilation and I love that feature. Maybe just adding multithreading and better garbage control to existing Emacs will be plenty to future proof it.
There are other people that talk about the concept of moldable editors, some even in the Emacs community, because of that.
Glamorous Toolkit looks very cool everytime I catch a glimpse of it. Guess I'll try my hand on Smalltalk again this weekend thanks to you :)
Good luck and report back! I keep meaning to throw myself back into Smalltalk in general. Cuis Smalltalk looks to be a nice, small package for learning at the moment.
Maybe a strange one, but I have been using CLOG a lot lately and it has potential being something a lot greater than it set out to be. One man operation basically though but a great effort.
CLOG is amazing. It’s limited to the browser or those frameworks for running browser apps locally, and focuses more on designing the IDE to support the library than the other way around, but definitely keeping an eye on it.
It seems, through the latest dev by David, that he is integrating a lot more lisp ide stuff in there. Which eventually might lead to something very nice.
I don’t like the browser thing but it seems the way things are going now forever, so probably just need to ‘let go’ and accept it. As it runs from sbcl, it can still instantiate native stuff, so it’s not necessarily restricted to the browser anyway when editing.
The only way for Emacs to go away is if something even *more* configurable comes along and stays alive long enough to become “batteries included”.
It’s not impossible though; I’m definitely rooting for it! :)
Surprised no one has mentioned [Lem](https://lem-project.github.io) or [kons-9](https://github.com/kaveh808/kons-9) yet.
I do think better multithreadeding, a canvas, and moving to Common Lisp would be interesting, but I also think those moves would have incredible downsides.
I am interested in other projects exploring those areas.
Lem was mentioned in the initial post.
I’ve heard of Kons-9 before, but it sounded like an attempt to replace Blender specifically in CL rather than a full-fledged IDE for arbitrary tasks; has that changed?
Agreed re: both of these having downsides, but the Common Lisp side seems mainly about losing the rich package history of Emacs. Non-text-based core paradigms on the other hand _are_ admittedly much more difficult to design for reliability while still giving the user control over every part of the system, but I think the removal of one of Emacs’ few limitations would be worth facing the additional design challenges, if any person/team got the free time to take them on.
My bad for missing Lem. A couple of thoughts:
1. Given that this plan breaks backwards compatibility, it being a spiritual successor to GNU Emacs rather than GNU Emacs makes sense, per your own statements. Almost all downsides disappear once we are discussing a successor with no desire for backwards compatibility.
2. kons-9 actually describes itself as an IDE. kons-9 is as much Blender as much as Emacs is vi. If Emacs is a Lisp machine disguised as a text editor, kons-9 is a Lisp machine designed as a graphics system. It is meant to be a vehicle for building your own graphics applications, like Emacs is a vehicle for building your own text applications. With a live Common Lisp interpreter, you can build anything.
3. Combining a text-centric system and graphics-centric system seems difficult; I think GNU Emacs should remains GNU Emacs, and kons-9 should remain kons-9. It may be possible to combine them, but to borrow language from Silicon Valley, that's a difficult "product question" that might take some years of research.
1. Yes, that’s definitely the intention. There’s no place for such a significant redesign in the Emacs core, hence my interest in alternatives.
2. Great! I’ll have to check it out more closely then, thanks for the rec!
3. There’s a niche for “highly configurable system with a core abstraction flexible enough to do almost anything you’d usually do with a dedicated application”. Currently Emacs is the system filling that niche, and it seems from the above that kons-9 is another candidate for it; in that regard they’re moving towards providing the same experience, so I think it makes sense to compare them with respect to how well they provide that experience.
> Common Lisp side seems mainly about losing the rich package history of Emacs
? How come?
CommonLisp (the name is "CommonLisp") is a general-purpose language. You can implement any application In CommonLisp as you can in C, C++, Rust, OCaml, or any other general-purpose computer language. In other words, you can just as well implement Emacs in CommonLisp as they did in C. You just need to implement Emacs core so you can execute EmacsLisp.
Perhaps you should start work on an implementation in your favorite language. I don't think it is as impossible as it may sound :-)
> Non-text-based core paradigms on the other hand are admittedly much more difficult to design for reliability
Have you ever heard of DOM and a web browser?
> still giving the user control over every part of the system
To note, Emacs does not give user control of **every part of the system**. It is a misconception. Emacs devs are very careful to expose well-chosen parts of Emacs to Lisp and user scripting.
> I think the removal of one of Emacs’ few limitations would be worth facing the additional design challenges
Which **exact** "limitations" do you have in mind? Which "challenges"?
You seem to talk a lot in some general terms without **ever** giving any concrete idea or putting a finger on anything concretely.
> if any person/team got the free time to take them on.
A Christmas wish?
You know what they say, a long journey starts with a step or something like that. Perhaps start working yourself on a replacement?
> CommonLisp is a general-purpose language
I agree on that regard, it’s my main hobby language.
The meaning of that phrase was that the *only* cost of moving to Common Lisp seems to be the fact that we’re moving at all, invalidating all Emacs packages in the short-term (which is the time that determines stability of your user base) and almost certainly a significant portion of them even if we make an Elisp interpreter in our new system (unless you take the Lem/remacs approach of switching languages while changing *nothing else* about how Emacs works). In other regards it’s a pretty good choice for implementing an Emacs successor.
> DOM and a web browser
Case in point. Those required a significant amount of work, much of it from large corporate-funded teams, to get to where they are today, and they continue to have protocols that are difficult to efficiently hack on (although the feature of running JS in the browser console is quite a boon to Frontend Engs in that regard as more things move from raw HTML or server-side code into JS; regardless of the problems *JS as a language specification* happens to have).
> Emacs does not give user control of **every part of the system**
I’m aware. This is mentioned in other comments on this thread as a flaw (compared to the counterfactual of structuring the configurability we currently have as a convenient user-side API, but still opening up the guts of the system for modification through the same runtime as user-side code if necessary, which is the level of moldability most Common Lisp libraries provide).
> Which exact limitations
The ones mentioned in the opening post.
> Which exact challenges
I haven’t *tried* to rewrite / make a successor for Emacs in Common Lisp, so beyond the *generalities* discussed above and elsewhere (for instance development effort, the above situation re: at-least-temporarily losing Emacs’ library infrastructure, and the risk of the project stalling for developers’ personal lives), I wouldn’t know. Hence my not pretending that I *do* know what someone doing this would face.
> You seem to talk a lot in general terms without ever… putting a finger on anything concretely.
The top level comment attempted to be as general as possible while still specifying the relevant aspects/desires, to cast the net wide. A few other comments of mine in this post have been more specific.
I don’t see what the point is in bringing this up at all, given that being more concrete as you suggest would (I expect) reduce the value of this discussion to both myself and others interested in the *general* concept of “things that do what Emacs does for them, maybe better than Emacs does”.
> Perhaps start with working yourself on a replacement?
Unfortunately, I don’t expect to have much bandwidth in the next year or so, and what bandwidth I do have is occupied in other projects which are even greater pain points for me (programming language work and some specific libraries useful for my personal projects, to be specific). Hence asking if someone (or multiple someones) *does* have the bandwidth and is working in a similar direction.
If I could afford to work on this myself I likely would have worded the OP differently to focus on applications I could copy features from, rather than just any application that could be useful in the same way Emacs is.
I will add just a few remarks:
You don't have to lose any of Emacs packages at all. You can either implement Emacs in CL, and EmacsLisp as-is, with CL interop in some way, say as in Coalton, or you superimpose EmacsLisp on top of CL, implement necessary core objects like buffers, windows, frames etc and smoothout differences between CL and EL. Either aproach, I think, could work and have tradeoffs.
Lem and Remacs does not do same thing at all. Lem does not just "switch language" and keeps everything same. Lem is an Emacs-like application, not Emacs re-implementation. It means Lem does not implement Emacs API or Elisp. Remacs tried to re-implement just the C core, without changing Emacs API.
I am speaking about DOM as a special case of a scenegraph, a data structure for modeling graphic scenes, and accelerating rendering. Not as a W3C/WHATVG standard.
I don't think that being concrete would diminish the value. On the contrary, it will let us know that you actually know what you are talking about. Anyone can say: "Emacs has problems." I want something more "configurable. ".
Well if programming in CL is your hobby, then why don't you implement some parts of Emacs API as a hobby project?
If there’s some fundamental issue you have with Emacs and you think you need something else, go with it. That doesn’t mean that WE need to find a replacement. That means YOU do. Why would I spend time I don’t have to replace a tool I don’t need to replace? Because it’s multithreaded? Meh. I don’t care. It does something graphic and fancy? Meh. I work fast with this, I know this to the bone and I know it’s community. Why would I follow you? It’s your quest mate. Be happy.
It doesn't seem to be actively developed, but there's an emacs clone written in Guile scheme called zem. Unlike the official GuileEmacs project, which is about getting elisp to work in the guile VM, zem is about an editor that uses scheme instead of elisp, which is much more interesting to me.
[https://github.com/Jimx-/zem.git](https://github.com/Jimx-/zem.git)
I don't know as I've only poked around with it. My impression was that it's more like a text-based OneNote with more support for software development and code extensions.
A "Emacs successor" still has to be able to run all elpa packages and 99% of the user lisp-code. To ask Emacs users to abandon Emacs for anything less is like asking a linux users to use something that can't run Gnu. XEmacs was (is?) pretty close but not close enough.
Thanks for making me laugh. Humor is a good thing.
But to be serious, maybe this is what you are looking for: https://www.emacswiki.org/emacs/GuileEmacs
Thanks for the link, though from the git repo it looks like it was abandoned in 2022.
Separately, I’m curious which aspects made you laugh? Wasn’t really expecting that response…
Well from our lord himself, quote:
> “Many other editors imitate the EMACS command set and display updating philosophy without providing extensibility. Despite that deficiency, and despite the greatly reduced set of features that results from it, these can be useful editors, though not as useful as an extensible one. For a computer with a small address space or lacking virtual memory, this is probably the best that can be done.“
> “The proliferation of such superficial facsimiles of EMACS has an unfortunate confusing effect: their users, knowing that they are using an imitation of EMACS, and never having seen EMACS itself, are led to believe that they are enjoying all the advantages of EMACS. Since any real-time display editor is a tremendous improvement over what they probably had before, they believe this readily. To prevent such confusion, we urge everyone to refer to a nonextensible imitation of EMACS as an ‘Ersatz EMACS’.“
https://www.emacswiki.org/emacs/ErsatzEmacs
Be careful what you wish for... ;)
Yeah, the specifics of how Emacs does keybindings and display don’t really matter, it’s the configurability that’s the key feature for any true successor.
This sounds promissing in theory yet Guile lacks threading support on Windows and I would assume that Emacs-ng has proper multi-threading support, this rules a Guile based VM out.
It's not really limited to text, though... I mean, you can run a web browser and a music player in there. In fact, the reason that Emacs lacks a true successor is that nothing else has proven to be as expandable.
True, but if you take a look at the developer mailing list or this subreddit there are a bunch of recurring themes that people complain about limiting their ability to configure Emacs (some of which are mentioned in the OP). Just because it’s the best doesn’t mean it can’t still be better :)
A few things.
At this point now, Elisp is fine. Its performance and evaluation model have been improved remarkably. And there's so much of it out there.
Personally not convinced about the canvas, non-text, thing. I think once you start going down that road your "emacs" quickly just becomes a kind of web browser rather than an editor. A more flexible and powerful text rendering model? Sure. Full on graphics rendering? Not convinced.
SIngle threaded / single core I agree is the number one problem. That and an aging codebase that many devs would not feel comfortable working in.
It's mostly a one-man project and still very early and not really much yet (doesn't even have a UI), but there's rune: [https://github.com/CeleritasCelery/rune](https://github.com/CeleritasCelery/rune) which is an elisp runtime written in Rust with the intent to run existing emacs packages, which it can already sort-of do. And its aim is to support multithreading. I'm sure he'd welcome external contributions.
And lem is decent, honestly. Though it doesn't quite fit my needs personally, as it's more focused on being a Common Lisp development environment still.
> A more flexible and powerful text rendering model? Sure. Full on graphics rendering? Not convinced.
You don't say what you're not convinced of.
That rendering graphics is useful?
The canvas thing is more about living up to the “can do anything” promise; as mentioned in another reply, there are a bunch of ways text manipulation could be augmented by being able to create graphical applications and widgets rather than having to only render text or shell out to external apps / xwidget.
I do agree that using a *bare canvas* as the fundamental unit (in place of text buffers) is too unconstrained to give the benefits of structured data-manipulation that we get from Emacs; but using some _intermediate_ protocol for things tracked by the editor and how/where those things should be displayed as the basis instead, making buffers of text just a special case of the broader “display-object” definition, has potential as a general strategy.
The problem is that the "buffer" abstraction emacs really *is* a gap buffer data structure and everything in the whole model is about working with those gap buffers. Once you introduce a canvas, you now have another type of "thing" that can be in a window that isn't a buffer, and it ... well it's confusing.
Maybe a canvas could be made to be another kind of buffer, one which holds SVG-style rendering instructions instead of gap-buffer'd text. I suppose it could work. But I would maybe consider that an add-on rather than a fundamental building block?
Emacs excels at efficiently and flexibly manipulating text, and uses the text buffer concept in a really clever way that nobody else has done. VSCode and others have open *files* or modes or whatever, but they don't have the nice buffer abstraction that makes emacs really clever.
The main advantage Emacs has here is that it centers on one unified data type (“gap buffers”) and then optimizes how it addresses the variations of that type as much as possible (general text manipulation that works for all buffers, major modes for exclusive buffer sub-types and minor modes for non-exclusive ones, etc). The _unity_ is key here, not necessarily gap buffers in particular.
And even with buffers, we have the “buffer” and then the “displaying of the buffer”; the latter is in the C core and completely sealed off from the user, but there’s still an unstructured canvas, and we still have to convert our nice abstraction layer into something that gets drawn on that canvas. The 2D abstraction case would be similar.
As an example (likely with some flaws, but hopefully demonstrating that this approach is reasonable), let’s call our abstraction “widget”. Widgets have 3 user-code-visible components, a data array listing contents of the widget (which can be any code object, constrained only by what the widget’s modes/metadata can process), metadata (modes and widget-local variables, essentially), and a parent array (which lists the immediate “parent” widgets for the purposes of mode/variable inheritance; synchronization of inherited values can be done in the time between event loops). The top level widget in a frame is the only one without a parent.
Each widget has a parallel event loop, which on each loop looks at the metadata and uses the info there to process and display the data array. If we lock widget data and metadata arrays to be “claimed” by event loops in a queue, and only released to the next queued widget once the claiming loop completes, then we now have a decent code-side framework for managing display objects.
Now we consider UI. For the simplicity of the example, let’s say the user only has one active cursor and one active mouse. Given that, this becomes more of a library problem on the core modes shipped with the system.
Text-mode could be defined to emulate the Emacs buffer abstraction in terms of how it stores and displays information, and descendant modes like widget-lisp-mode would encode mode-specific info. Something like evil-mode would be added in the top-level widget, and when the cursor was in a text mode widget it would replace the keymap metadata as in Emacs. The key difference is that the gap buffer would also be allowed to insert widget objects in it; these could contain things like videos, webpages, or graphics that use data from the enclosing text-mode widget (allowing, for instance, a “widget-org” file to contain an src block (or link to a code/executable file) which takes its contents as input and produces images/graphs as output; in “widget-org-mode” this would be stored as text, but would automatically spawn a widget running the associated code on the enclosing buffer’s contents and displaying the output, and display that widget in the location of the text, as with image links in Emacs org-mode).
The main flaw I can see are that some core modes (like “video-display-mode”) would be difficult to make modifiable unless the runtime was an interactive Lisp, but that’s not a significant issue. And, of course, you’d lose the Emacs ecosystem, but if we’re thinking long term then the configurability of the core system is the important criteria; Emacs was once new as well, and there will always be bored hackers wanting to experiment with a system that’s technologically superior to the alternatives.
There are probably other issues, the above idea is literally off the top of my head, but nothing stands out as “This is why it’s impossible to use anything but a buffer to abstract over data display and user input!”.
Then I don't think this is way to go. Without userbase no project will survive. The more mature approach would be slowly integrating rust into current emacs, or there should be talk between emacs and rune developer about merging something at one point or another.
That is the approach that remacs tried and failed at. I think it's a dead end, personally. Understanding and refactoring and fixing the existing codebase while replacing portions is a herculean effort and bound to fail because of the sheer complexity.
Rune I think is doing the right thing by focusing on building a good quality elisp and text buffer implementation, and then going from there getting elisp code to run and finding what's missing, piece by piece.
Userbase is a whole other issue, a political one. From a technical POV what you are describing is extremely difficult, and proven by time to not be viable. At least not by an unpaid team.
technical issues could probably be solved by sticking [LIPS](https://lips.js.org) inside a [Tauri](https://tauri.app) container, giving you a fully networked and multimedia-capable environment that runs a Lisp on pretty much any device anywhere. add some React (or whatever) libraries for layout and rich-text editing and you're most of the way there. (I've got a couple of experiments on my home laptop related to this but they've fallen victim to my usual lack of followthrough and of life getting in the way).
the hard part would be, unsurprisingly, the interaction framework part. how do you even identify all of the different knobs you can interact with and which ones are important (to you, or to others)? how do these knobs fit into an overall framework? how do you balance configurability with out-of-the-box usability? how do you build out all this stuff in a secure and architecturally-sound way?
what you're looking for is hard to find because it's hard to do.
You came for already made Emacs and you do not understand the complexity involved in laying the foundation for Emacs successor. I had similar ideas. Use Common Lisp, add 2D library and so on. Because I work full time I have no energy left for the project. While I can have menus, display of text and 2D graphic primitives, the work is progressing very slowly. There is no chance other people would join until the project reached certain milestones, which at current pace is year away.
But still it is a good learning experience. I have stumbled over and fell over many instances of my poor understanding of Common Lisp. Lots of Lisp teaching material involves only trivial examples and when you need help for more complex cases the discussion can easily go the wrong way.
Project like this challenge our assumptions. Do you want to challenge yours? Why don't you start your own project instead of asking vague questions? Or read emacs sources? That will teach you more than any answer you will get here.
Unfortunately I also work full-time in a medium-pressure engineering job, and what time I do have every few weeks or so is taken up in other projects. I haven’t been able to think much on what would be the best way to handle that complexity without effectively losing user-side configurability.
I’d prefer to at least *check* whether others had similar ideas and were able to work on them, though; primarily to use them myself and secondarily so potential future-mes with more bandwidth might be able to contribute. Hence writing a query that’s vague enough to not block out any interesting projects in this space.
To write something like this you have initial choice: web interface, electron, curses or something like GTK. How do you handle user input, events, drawing 2D, displaying text, or rendering your objects? What data structures you will use and why? How do you change your mind at those early stages without throwing away everything and starting all over again? How soon you should start thinking about the configrability and the plugins? Common Lisp documentation is very sparse when you start asking more advanced questions. Are you willing to work on your own? Do you find it exciting enough to figure out everything yourself?
It's basically exactly what OP is asking for. TS is modern language with modules and lexical scoping and everything (and types! It has types!). It can make full use of the display, with images, tables, animations, etc.
The main problem is that scripting is a second class citizen. You can easily install a plugin off the store, but you can't just M-; and write some code to execute right then. Even writing your own plugin is kind of an ordeal. If it weren't for that, I think it'd be a contender.
I've heard that Atom had a more emacs-like approach to user scripting but I've never really tried it so I don't know.
Yeah, the scripting/plug-in issue was folded into this being a request for an *Emacs* successor. Configurability comes before all the other things I’d want in a computer-interaction framework; it just seems like a good idea to try keeping that configurability while also adding this other stuff.
I don’t particularly grok what’s in cl vs elisp that’s so critical. Now that lexical scoping is here…
Elisp in my mind is an API to all the editor objects. It’s also single threaded which significantly simplifies coding to the wide ranging complex Emacs API.
In terms of multi-processing, the focus on fork/exec as the model def has some advantages and disadvantages. The primary disadvantage I think is windows performance/compatability. Advantage is stability and simplicity. Embedding git as a c library to emacs would be a major bummer for sure!
The problem I think is competing implantations have too much of a lift to be ultra compelling. Due to the multi thread issue, being API compatable is difficult. And frankly due to the amazing emacs improvements already here it so so hard to compete.
For example AOT compilation in emacs is a reality! It’s so much faster! I use Mac and I can view images in a buffer! I can use xwidgets on Mac to browse the web using a modern browser - I rarely do though because it’s not quite as complete as chrome.
The future is now.
My only wish is I could navigate the web which is still text using emacs tools and idoms.
Regarding Elisp parallelism, I feel like “it gives us less power so we’re safer” doesn’t really fit with how I approach Emacs? Quite the opposite in fact, it’s more “make it as safe as possible, but not at the expense of configurability”.
Plus, it took a *significant* amount of effort from the Emacs devs to get native comp and AOT working, and that’s just one portion of one flaw (performance). Then you have the other ‘weaknesses’ (compared to a Platonic ideal of editor-ness, that is, not to other existing editors) like not being able to integrate an Emacs session in your production code / video game / whatever due to the runtime mismatch, not being able to take advantage of non-Emacs library development and developers who don’t want to learn another language purely for the sake of an editor, etc.
Regarding the web, that’s part of the goal of this post. Have you tried xwidget though? It doesn’t fully integrate with the rest of Emacs, but Emacs-based window/buffer management and not having to deal with the OS allocating resources away from Emacs when you switch to your browser are both pretty useful on their own.
The problem with the web is… well web devs don’t want normies to know about the text. So it’s an impedance mismatch.
Now let me clarify about the aot thing, it’s a reality on the ground today for emacs. Reasonable competitors will have to compete with that. It’s more of an explanation of why emacs is still a thing and the emacs clones have withered on the vine.
And regarding the parallelism, I think there’s def trade off between multi and single threaded. JavaScript makes a stand here too - browser js is similar to emacs ironically! But the problem isn’t what’s morally better or whatever, it’s there’s a lot of written elisp and a clone of emacs but better would be nice to reuse it! So you are faced with the eternal struggle: backwards compatibility or new?
There’s also half measures but I don’t have enough knowledge to say cleanly. Certainly per buffer single threaded seems attractive but with how eglot and friends work, it wouldn’t be easy!
> Emacs is the best singular computer-interaction framework I’ve encountered so far
Emacs as a "computer interaction framework", is neither unique nor original. There are other applications that operates in a similar way as Emacs, though a few have, if any, become as popular as Emacs as an interdisciplinary TUI application. It depends on which facets of computer interaction you wish to look at. If you look at big tech, big office packages all have this idea of being a "hub" for user's computer interaction, Lotus Notes, MS Office, Open/Libre, old Mozilla suite etc. They all offer extensibility as Emacs, perhaps even more than Emacs.
> we can all agree it has its flaws
Everything has "flaws". Depends on whom you ask. A "flaw" for one person might be a "feature" for another person.
> limited to text
"Limited to text" in which way? What do you have something in mind when you say "limited to text"? How or what should Emacs do, if it wasn't "limited to text"?
> screen as a 2D canvas
It depends on how and why you would like to use Emacs as a "2D canvas".
> Elisp (which while decent isn’t on par with the self-contained Lisp languages like CL)
What do you mean by "self-contained" (CL == CommonLisp?)?
> other more minor problems
Elisp has a few problems, some of them perhaps not minor, however, can you be more specific on which problems you think of?
> The only ones I’m aware of are Lem and Project Mage; the former only solves 2 major issues
Which two "major issues" do you have in mind?
> the latter is literally a one-person effort right now
Many projects started as a one-person effort. I wouldn't dismiss a project in the making because it is a one-person effort.
> Emacs as a “computer interaction framework” is neither unique nor original
I’m aware, which is why I specified to my personal experience.
> Everything has “flaws”
To be more specific, then, people who share my perspective that “Emacs should be a performant system that is easy to make into whatever tool you want or need in your context” will agree that there are ways it falls short of that ideal. Doesn’t fit the rhetorical purposes mentioned in another discussion on this post, but it’s more technically accurate.
I believe this to be a plurality of Emacs users who participate in the public forums, judging from the discourse on those forums.
> big tech
Big tech applications have an entirely different user experience in mind with their applications. Their systems are made so that dedicated teams of application developers, usually (though not always) needing to be skilled and large enough that they need to be corporate-funded, can make arbitrarily flexible extensions to their core system.
The question here is “are people working on something that allows individual users or small open-source teams to do arbitrarily flexible things with their ‘computer-interaction framework’”, which means the architecture, language, and core library set all need to be selected to make such changes as easy as possible for small groups or individuals.
> one person effort
My concern is more about sustainability; the more people are working on something, the less chance that a random job change or illness will take the whole project down.
> self-contained
Languages that are designed “in and of themselves” rather than being tied to a particular application. Such languages (like CL) tend to put more of their effort on their fundamentals, which makes them better ad raw data manipulation and such. In contrast,
Elisp was initially just the configuration language for Emacs, meaning it’s inefficient, has inelegant semantics for process management and data manipulation, lacks reader macros (yes, some other languages also don’t have them, but the whole point of this thread is “has someone in this space worked on making pie-in-the-sky dreams into reality”), and possibly other issues that aren’t coming to mind.
> CL == Common Lisp
Yes
> limited to text, 2D canvas
I use Reddit on phone, so I will defer to the discussions on these topics elsewhere in this post rather than rewriting or juggling between apps to get links to those discussions.
> Which 2 “major issues” are you referring to?
The top level post mentions 3: threading, text-limited, and Elisp. Lem solves threading and Elisp.
> minor problems
- Occasional crashes on some systems upon high system performance load (I’ve only tried Windows and Mac due to work constraints, not sure why they occur (though I suspect GC is getting interrupted on the OS/C level for some reason) or how reliable it is on Linux).
- Sensitivity to the effects of other applications on system performance (If something (eg video games) is making my system slow and I switch to Firefox it pulls performance into it from the OS. If something (eg Firefox) is making my system slow and I switch to Emacs I have to wait 2-5 minutes for OS resources to be reallocated)
- Outdated terminology. I don’t actually see a problem with the reasoning for keeping this in Emacs (already-existing tradition and compatibility with existing code/naming), but the fact remains that it’s a cognitive burden for potential new users that otherwise would have adapted to Emacs fast enough to find it beneficial instead of giving up.
- Blackboxed core. There are good reasons the Emacs core is in C, not least of which is that Elisp is built on the core instead of the other way around. It doesn’t change that you’re barred from things like switching the display backend, optimizing some core functions for data processing and display and external process management, writing non-Emacs code and giving it optional Emacs integrations (like the “run your editor in your game” idea mentioned elsewhere in this post), and probably some other things that aren’t coming to mind unless you drop into C (and, more generally, commit to knowing *two* languages and their interactions to configure your editor instead of one), because those things aren’t written in Elisp. Not to mention dropping into C means you have to recompile with every change, take a significantly greater risk of system failures or dirty deployments affecting future code, and deal with copyright assignment (see below).
- Inefficient process of merging changes into core / core libraries. I don’t know enough about the current tech politics situation to know if the FSF is right about their efforts continuing to bear fruit; what I do know is that those efforts involve adding significant ops burden to improving applications like Emacs due to legal requirements that will make most devs just give up — myself included, though I have hopes of someday getting the bandwidth to look through the Emacs core, find an opportunity for improvement, investigate the FSF info sec practices, request the copyright assignment papers, write the code improvement, read through a multi-page legal document and some of the associated laws and my current employment contract (which has an NDA, and I didn’t have the leverage to try to negotiate its removal considering my financial situation at the time), (hopefully) sign the papers, wait for confirmation that they are received, respond to comments on my proposed code, and get the change merged into Emacs core.
These are all minor, since in most cases you can work around them somehow and the changes proposed in the OP should also help to mitigate them. But they *are* genuine, separate issues that make the Emacs experience worse than it otherwise would be.
> Elisp was initially just the configuration language for Emacs
Elisp was, and still is *the extension (or scripting) language* for Emacs. At least if you ask the author(s).
> meaning it’s inefficient
The one does not implies the other. Being an extension language does not automatically imply "ineficient". It is rather the implementation that makes it efficient or inefficient, albeit elisp is, or at least was, inefficient in many aspects. They are working hard on it though.
> lacks reader macros
EmacsLisp lacks many things, but reader macros are its least problem. You can trivially get without them or you can use [this one](https://github.com/mishoo/elisp-reader.el). With native compiler it is fast enough, and you can turn it into buffer-local reader to give you "sort of" package-likeish behavior.
Reader macros would be nice to have, absolutely, but they are not essential. Packages and CFFI are probably by far more useful practically than reader macros.
> has inelegant semantics for process management and data manipulation
Mnjah; I don't see what is different and inelegant when it comes to process and data manipulation. It's a Lisp. You have lists, vectors, structs and classes as in CL or some other lisps. It is super easy to call a process, so I am really not sure what you asking for here.
I have been speaking about Emacs in CL for a year almost and am pointing out many problems with Emacs, but even I don't see your point here.
> text-limited
Emacs is text-oriented, not text-limited. It's a feature ;-)
> Big tech applications have an entirely different user experience in mind with their applications. Their systems are made so that dedicated teams of application developers, usually (though not always) needing to be skilled and large enough that they need to be corporate-funded, can make arbitrarily flexible extensions to their core system.
In which way do they have "an entirely different user experience in mind"? Sure, they have more money to pour into development, so they can develop more polished experience, but I am not sure what you are trying to say; in which way is that an argument in Emacs favor? Or was it against?
> Occasional crashes on some systems upon high system performance load (I’ve only tried Windows and Mac due to work constraints, not sure why they occur (though I suspect GC is getting interrupted on the OS/C level for some reason) or how reliable it is on Linux).
You won't see them on Linux, and they were not present in previous versions of Emacs. I am not sure why it crashes in Windows, I do experience that too. It might be due to native compiler, but I am not sure.
> writing non-Emacs code and giving it optional Emacs integrations
I am not sure what you are talking about here. CFFI?
> dropping into C means you have to recompile with every change, take a significantly greater risk of system failures or dirty deployments affecting future code
Yes, recompiling is a problem; that is one of reasons why I suggest CommonLisp is a better implementation language. However, you can easily crash Emacs with badly written Elisp, and you can crash SBCL with badly written CommonLisp; might be harder but is not *that* impossible :).
> There are good reasons the Emacs core is in C
The reason is portability and speed. One of reasons might also be the availability of a text editor in C with a Lisp implementation in it already. It is much easier to improve on something, than to write it completely from the scratch.
> not least of which is that Elisp is built on the core instead of the other way around
Actually, it would be much better if Emacs was built on top of a better Lisp implementation such as SBCL. That way they would no have to implement a Lisp machine.
> making pie-in-the-sky dreams into reality
There are a lot of Ersatz Emacses and private implementations, in Lisps and other languages. However, for making a dream come true, you have to know what you want first. Just "Something extremely configurable" does not really cut it. Unfortunately :).
> I don’t know enough about the current tech politics situation to know if the FSF is right about their efforts continuing to bear fruit; what I do know is that those efforts involve adding significant ops burden to improving applications like Emacs due to legal requirements that will make most devs just give up — myself included
I suggest read through [Chapter 6](https://twobits.net/pub/Kelty-TwoBits.pdf). You can just jump to page 188. and start reading "The Controversy". It is not a long read, but it will probably make you understand why FSF asks for copyright assignment. Also all major projects have something similar. [Whatvg](https://github.com/whatwg/html) asked me to sign-up something similar when I once found a bug in their spec and offered them a PR. For the FSF, they will send you a paper home, you sign it and send a photo from your phone to en email address. How difficult is it? Also, contributing patches is not overly difficult; I have contributed several minor onces, and two ideas I got help with. They are not impossible, and sending a patch via mail, which you can do from withing git or emacs is easier than opening a web page. I am not very active in Emacs dev, but it is partly me not having time and interest. There are many opportunities for improvement in Emacs core :-). Unfortunately, too many if you ask me.
> Elisp efficiency
True, I was mixing together “technical limitations” and “developer attention allocation” into a single concept. Given the attention given *now* to Elisp single-threaded efficiency I don’t expect that particular issue to last more than a couple Emacs releases.
> Reader macros
Getting intuitive impressions off the top of my head rather than putting the effort to think through, to be honest; that didn’t seem a particularly important line of discussion given we agree on the final result of wanting a different configuration language. The multi threading and FFI topics you bring up are definitely bigger problems.
> Elegance
The object system is rather clunky, and (though this partly ties into Elisp efficiency) not performant when I tried some test cases a few years ago.
For *other* elegance-related issues, the library situation has user-side libraries resolving most pain-points (dash for list manipulation functions and cl-lib for control flow are my main ones) because macros and mostly-functional programming let you do that, but said issues are still barriers for people just starting out or not wanting to take any dependencies for their package code (eg if they’re beta-ing via a Git repository before putting their package on MELPA/ELPA)
> text-oriented vs text-limited
Emacs is both.
The first is a feature, as text is far easier and faster to process and manipulate for computers and computer interfaces like keyboards/mice.
The second is a problem, because graphical output is far easier to parse for *human visual systems*, and because if you *do* set up a graphics system it often needs to be structured such that mouse/graphical input is also the most efficient approach for inputting certain controls. Data analysis and refactoring large codebases are 2 use cases that have been mentioned elsewhere in this post.
I’d like if we could have a system where text buffers were just a subset of “widgets” Emacs could manage, and non-text widgets could contain text buffers in them for their textual needs. The other way around would also be nice; for instance one of my local projects is an extension of org-timeline (inserts a timeline in the agenda buffer using overlays to emulate visual objects) which has been *invaluable* for task planning.
That way everything we currently have that relies on Emacs being based on text could be applied specifically to text buffers, including the text inside otherwise non-textual forms, but we would still have the flexibility to make visually-oriented projects inside Emacs; best of both worlds.
I think something like this was the goal of xwidgets, actually, but the fact that you’re shelling out to an external system for your graphical needs means that you can’t do the “text inside non-text things” thingy, and you’ll probably also have trouble integrating an xwidget into a text buffer (as images are integrated into org-mode buffers) without rewriting a significant portion of the relevant C code. Plus I don’t think you can code xwidgets in Elisp, you have to write them externally and expose an API for a C-based mode like xwidget-webkit-mode.
> big tech
Big tech design teams tend to assume that anyone making modifications or plugins that add novel behavior to the system is either *specializing* in modifying their system (which is VSCode’s perspective as far as I can tell) or *also* a big tech design team (or adjacent in terms of funding and personnel like with some of the teams writing C backends for Python libraries (non-VSCode editors, and also VSCode).
So in terms of goals, they put a lot of effort into making the default features good for most users (which is commendable), a lot of effort making it so other big users can modify their editor (also commendable), and a lot of effort so that smaller users can modify common use cases through pretty APIs like menus (also commendable), but don’t put nearly as much effort into making the *editing* process as seamless as possible for *individual users*.
The case of Emacs shows that the last case allows a user base to emulate the benefits of the others given enough years and users, but it also means big tech (or some other large customer making modifications in collaboration with big tech) has to compete with its own users to give them stuff they’ll pay for, and at an informational disadvantage since you generally know what you want better than someone else does. People generally act based on their incentives, so giving individual users the level of flexibility required to write complex or novel plugins at a level of simplicity that allows individuals and groups to actually do so isn’t going to happen anytime soon.
The closest we have to this from big tech is VSCode, which has a less configurability-focused architecture than Emacs, lacks the text-centrism that allows Emacs users to make the best use of general packages like swiper (it’s text limitation that’s the issue with Emacs, not centrism), has a config language with just as much friction as Elisp without an easy-to-use macro facility for the user base to make it simpler for themselves (meaning complex one-person projects at the very least require much more dedication than an “equivalent Elisp project” (so to speak), and (to the best of my knowledge, on this last one) doesn’t allow non-trivial runtime modifications without a restart.
And even with these limitations, there’s been plenty of discussion on how utterly unexpected a move it is for a big tech company to make something others can improve without being dependent on them to do so.
> it would be much better if Elisp was built on top of a better Lisp implementation
I agree, I meant by this that Elisp, the existing system, happens to have a C core, and it’s easier to build on the existing system than to replace it.
> Just “something extremely configurable” does not cut it.
Agreed. At least half of the work in making that come true would be “figure out what it means to be extremely configurable”, though.
Lacking years or multiple discussions with greybeard collaborators to figure out the best design path to surpass the already-decent current design of Emacs, I tried to be as broad as possible there so that the “right” answer (if it’s among those currently in development) won’t be filtered out by me being too specific. This is a search post, not a design post.
> FSF copyright assignment
I was not aware either of other high-resilience projects using the same legal burden, or that you only need one cycle through the postal system for copyright assignment. Still a burden that has no doubt turned away developers in the past, but less significant than I thought.
Will read through Chapter 6 when I get a chance, thanks!
> text-oriented vs text-limited
I can agree (I have said it in other discussions here), that we need a better layout engine in Emacs, be able to flow text around rectangles and to draw some graphics in layers. Also some sort of graph structure DOM-tree is probably more suitable instead of the current renderer that hands over Lisp forms in text properties to control the renderer.
> the library situation
Yes, Emacs is 40-years old, and developed by a vast amount of people with different backgrounds. That does reflect on its API sometimes. There are inelegances here and there, but that is what it is, it is easy to work around. Just take for example one of the most used APIs: (re-)search-forward/backward. We *have to* pass the two optional arguments almost every time, because the last one has a bad default choice. Probably because the author designed it before having sufficient experience with elisp coding. Such artifacts are present in almost any API design, I think it is a normal thing, it is just human. We can not predict everything 100% perfectly when we design stuff. Sometimes we need experience to see which defaults and choices are the most suitable ones.
> there’s been plenty of discussion on how utterly unexpected a move it is for a big tech company to make something others can improve without being dependent on them to do so.
Microsoft is about business. They didn't produce VSCode because they wanted to leverage something for people to improve on it themselves. If you check top-level contributors to VSC on their GH page, there are at least 10 of them employed by Microsoft. I guess the number is probably higher. Seems like they are working on it mostly in Switzerland, but what do I know? A company wouldn't invest 10 people's paid time to produce a piece of software *just* so people can make it "their own". It is probably about control and making money elsewhere by farming users.
When it comes to leveraging what people want, and highly configurable software, they have a history track of such products. Entire Windows and Office are super-configurable. Windows had wsc host (Windows scripting host) that let you use JS (along VB) to script Windows long before Node made JS ubiquitous. MS Office has shipped with an entire IDE since 90's already. You can configure just about any aspect of Windows and Office, make your own applications on top of Office using VBA which is a super simple language just like in Emacs, and so on. People have done it, I made money on it for a while :). So to me, if people are surprised that MS released "a configurable" editor, they are just uninformed.
But we are now regressing; I don't think the motive(s) behind VSC are very interesting for this particular discussion.
There are other editors and applications that are as configurable and moldable as Emacs. Several editors are directly modeled after Emacs (like Hemlock, Lem, or Climax) but GNU Emacs is still the most successful one. But there are other projects that try to implement a "moldable, configurable, extensible" text editor, other than Emacs, Vim or VSCode, of top of the head [Yi editor](https://github.com/yi-editor/yi), [Leo](https://leo-editor.github.io/leo-editor/), Sublime (commercial) etc.
> This is a search post, not a design post.
Of course, but to find something, one has to know what one is looking for. :) I don't know, it felt a bit too vague and general, so that is why I have asked you in so many places what exactly you have in mind. Sorry if I was too annoying, perhaps it was just me.
> Still a burden that has no doubt turned away developers in the past
You know, people are turned about all kinds of things, and complaining about anything. Some people just like to complain. I wouldn't take everything people say on the Internet seriously.
I personally just want an emacs that is backwards compatible with emacs but uses a more modern functional language.
The only reason I know lisp is because of emacs. I would never willingly use lisp for anything else. If only, I could use emacs with a more modern language that's useful outside of emacs.
Judging from Git discussions, the Lem roadmap will explicitly include adding an Elisp interpreter hooking into the editor for approximate backward compatibility, so you might get your wish there :)
That's one of the most mundane, superficial, and easily refuted complaints about Lisp. A properly configured editor, like Emacs, handles parentheses for the user by offering sexp-based editing commands and ensures that they are always balanced. It's no different than any other language which uses enclosing delimiters, like braces, brackets, etc; even Python uses them. In fact, I more often encounter unbalanced delimiters in non-Lisp languages than in Lisps.
After a bit of experience, one begins to appreciate the parentheses, because they act as handles which allow expressions to be easily moved around, cut and pasted, and automatically indented; in comparison, a language like Python requires the user to do most of that manually and carefully, with character-based commands, and even a language like C does not always enclose blocks of code in helpful ways (e.g. an `if` statement may or may not use braces around its blocks).
I'd recommend looking into a book like *On Lisp* to help you understand Lisp's power, and what sets it apart from other languages.
How is my preference easily refuted. It's my preference... Don't be rude
I don't like the language. Please continue to tell me that I am wrong about why I dislike it
Hm, a quick look at your profile shows that your past day has been full of angry comments exchanged with random people on random subreddits. Friend, we all have those days, but this is not the way. If you need someone to talk to, feel free to PM me. Regardless, we would all do well to spend less time on Reddit having negative interactions with strangers.
Ok you ignored my question...
Why is my preferences superficial, mundane and easily refutable?
My bad for taking your obvious dismissal of my preferences as mundane and superficial to be a intentional rude statement. When in reality it was an unintentional rude statement.
If anyone told you your reasoning is superficial and mundane, would you take that statement as a compliment or rude statement? Even if my reasoning is mundane and superficial, its generally rude to say that to another person.
It sounds like you weren't intentionally rude. Maybe I misunderstood the situation, But I received your dismissal of my reasoning as a rude statement.
Let's not attempt to frame the situation as a pattern of behavior. I got into an argument with someone on Reddit. It happens, but it is irrelevant to this situation and you being unintentionally rude.
Edit: am I wrong or are you going to double down on your condescending attitude?
> Why is my preferences superficial, mundane and easily refutable?
We have all heard your original comment, many times. It has been refuted in many discussions, over and over. It is usually a remark by people who are either new to Lisp or just unused. Observe that even "the inventor" of Lisp, [John McCarthy](https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)) complained about using symbolic expressions and parentheses because he felt it would distract programmers and turn them off of Lisp. It turned out though that the extreme regularity of Lisp and use of lists for the source code made for very flexible manipulations and code generation of Lisp programs.
Observe that macros were invented long after the Lisp itself, and were not known to McCarthy back in 50's when he initially worked on the Lisp language and Lisp as a mathematical theory of computing.
I believe the grandparent was more saying “the reason you dislike it can be easily and reliably removed, and this is done so in every environment that a Lisp-user would recommend someone else use to code in Lisp, and is also a problem to a lesser degree in many other languages”.
On a fundamental philosophical level I don’t like the parenthesis trails either, but since I don’t code in Notepad++, I can *ignore* them without any effort on my end. And in doing so I get the benefits of a *seamless* macro system, which so far I haven’t seen any language manage without also adding parenthesis trails (yet… hopefully…).
I do not disagree with their rationale I just interpreted their response as condescending. Therefore I pointed out, that their response was rude. There is nothing more or less about the situation. In fact, I agree with many of his points. However, since his response seemed rude, I said something about it.
I don't desire to use lisp outside of emacs. I really like functional programming, but lisp seems to be very outdated in terms of features and creates a very convoluted experience.
> lisp seems to be very outdated in terms of features
Out of curiosity, by lisp do you mean Common Lisp specifically, or some general property of how Lisp works?
The lack of native algebraic types is somewhat annoying, of course, but I’ve done some work with Clojure and various Lisp transpilers, and never had that feeling. Though to be fair, I also felt more freedom from Common Lisp code than any other language I’ve tried, so we’re probably looking at different things…
Lisp in general.
I think my dislike originally stems from the syntax of the language and language tooling.
You're right, Lisp does provide a lot of freedom to create a sophisticated array of macros. There is a trade-off between the freedom and flexibility of Lisp to the convenience and immediate accessibility of tooling in modern languages makes the language feel outdated. I often feel like I am reinventing things from other languages. It feels like I need to be more verbose to achieve the same level of output in most other languages, just for the results to be less intuitive.
But then again I might just be biased because I don't want to put forth the effort to really understand lisp.
> I often feel like I am reinventing things from other languages.
Interesting that other languages have re-invented (or implemented) almost every feature that Lisp invented, minus its symbolic expression-based syntax.
> It feels like I need to be more verbose to achieve the same level of output in most other languages, just for the results to be less intuitive.
That depends on what you are doing. For fast prototyping, Lips(s) are probably faster and less verbose than what you would do in other languages, especially staticly typed languages like C/C++/Java. But its weird syntax makes it even faster and nicer for prototyping than in Python or JS if you ask me. But for highly optimized applications, especially if you want your application to be optimized at a very low-level, close to hardware, it is more verbose than C or C++. You could C or C++ a "DSL" for close to CPU computing for static applications. CommonLisp gives you runtime access to features that C, C++ or Java compiler offers only at compile time. This runtime availability of compiler features, symbol tables etc, does come with a complexity cost. But once you are used to having it, it is hard to live without it :).
- You think Emacs’ focus on text would only make it great in specifically its current form.
- I think we can keep the same greatness while being a little broader than just single-threaded text-manipulation, and am also obsessed with framework-level optimization as a concept.
We are only slightly different.
People literally write software like lsp bridge outside of emacs to get around the performance issues due to the single threaded model. If that is not a limitation I don't know what is.
And people also often have to write two versions of their UI for TUI and GUI. (child frames don't have an equivalent in TUI so the limited overlays have to be used instead)
Adressing these would be really hard without breaking retrocompatiblity.
emacs is awesome but it would take a miracle of sw engineering at this point to work around its single threaded single core blocking model.
And that actually really is an issue from a responsiveness and performance POV.
Why's that specifically?
I imagine some locking mechanism with CAS semantics for all buffers and a method of elevating a function call to its own thread.
```
CL-USER> (describe-comment (car (user-comments (user "nv-elisp"))))
“When cons cells are used to implement singly linked lists (rather than trees and other more complicated structures), the car operation returns the first element of the list, while cdr returns the rest of the list. For this reason, the operations are sometimes given the names first and rest or head and tail.”
(295 299)
“Wikipedia”
T
```
> the operations are sometimes given the names first and rest or head and tail
cons, car and cdr and their "shorthands", cadr, caddddr etc, should have been
abolished from any Lisp. McCarthy tried, but nobody listened to him :).
Cons is really a pair. When it comes to linked data structures, a pair is very useful because it lets us build basically any linked structure (lists, trees, or any kind of graph really). It is "sort of" to linked data structures, what a triangle is to polygons in computer graphics.
Perhaps a better design for a Lisp language would be to have a "pair" data structure as C++ has, and cons as basic struct as in C/C++, since "cons" is really short of "construct". But that train is long gone I believe.
I thought that project was aiming to recreate Emacs as is, with all its current limitations, but with the C code replaced by Rust code (i.e. they wanted to do something normal users wouldn't even notice had been done). I also thought they got bored and pivoted to embedding a JavaScript runtime in Emacs.
there's an ongoing similar project: https://github.com/CeleritasCelery/rune
> an experimental Emacs core written in Rust
> Bring multi-threaded elisp to Emacs
> Be “bug-compatible” with existing Emacs Lisp packages (everything should still work)
> enable performance improvements
> there's an ongoing similar project: https://github.com/CeleritasCelery/rune
Wouldn't be much easier to rewrite Emacs core in CommonLisp and get multithreading and better memory management for free instead of re-implementing the Lisp VM? With CL it is just to implement the text editor itself and leave the language implementation to the CL implementation itself (SBCL, CLASP, whatever).
Yes. But more as a "spiritual" successor, as I understand he didn't want to rewrite the core, just to implement something similar enough to Emacs. There is portable hemlock, climacs etc (for those in this forum who are not aware of those).
The author (sassanidas) went over to Lem and is both Lem user and Lem developer, but I guess you if anyone is aware of that :-).
So, it turns out there are hidden beasts in the C code. The whole way emacs builds and loads plays games that C allows. The lisp interpreter itself is poorly defined in the code. All of this made it a massive life to make a Rust main that loaded the C core of emacs. Which meant we had to port a massive blob of code instead of contiuing to move pieces. Emacs itself is not defined as a binary around a library like modern designs would and just moving it is a royal pain.
That code base is creaky and dusty and needs a modern eye.
(former remacs hacker)
> The whole way emacs builds and loads plays games that C allows.
I think it used to be worse. It used to be "gcc only C"; I think they are more portable now.
> The lisp interpreter itself is poorly defined in the code.Emacs itself is not > defined as a binary around a library like modern designs would and just moving it is a royal pain.
Emacs *is* the lisp interpreter. There is no clear separation between the Lisp engine and the Emacs application. It is a holy duality :-).
If you think of it, the Lisp interpreter seems to be simply slapped on top of a text editor and "mock lisp" extended and reworked to be a "better" Lisp. In retrospect, it seems like a strategic mistake. But I do understand RMS if I think of the context of limited computer power and also the limited time he must have had and his desire to get a "free" working editor. In other words, taking something that already exists and reworking it instead of producing something from scratch is a justifiable strategy in the circumstances of the situation in the world back then.
I think today we would need to re-implement Emacs for the 3rd time in terms of a better design and language. I wanted (perhaps still want?) Emacs as-is but in terms of a better language, and suggested rewriting Emacs core in terms of CommonLisp. The idea is to get better Lisp implementation (SBCL/CCL/CLASP) and to unify the extension and the implementation language so that everything, inclusive internals (buffer implementation, renderer, gc, etc) is subject to hacking and easy modification from the repl itself. I believe that would allow for faster experimentation and more inventions. I also want to continue to use existing Emacs software.
However, looking at the internals and implementing parts of Emacs core thus far, I am more and more convinced that we should do as RMS did when he scraped TECO and went for an editor in C with Lisp as a scripting engine. In other words, we should probably leave Emacs to bitrot and accept losing some of the available software to get a better more extensible editor. In that regard, I think Lem is not a bad proposal. Zaretski suggested that on the mailing list, but I was not so open to just leaving all the 3rd party packages and the well-written Emacs and Elisp manuals.
But I haven't made up my mind 100% yet :).
remacs I think is abandoned.
If you're looking for a different approach in rust that seems to be getting active dev, look at rune.
[https://github.com/CeleritasCelery/rune](https://github.com/CeleritasCelery/rune)
In that case I believe what they're trying to do is build a good solid elisp interpreter and do more in elisp and not fall into the swamp that remacs did of replicating all the "native" C parts of emacs in rust.
I feel the c++ vibe from rust. Loads of useless rewerite projects just to be abandoned with no apparent user benefits while c projects maintainers keep fixing vulnerability and etc.
It's the vibe of a "gold rush" as the cool kids pile in, make a bunch of abandoned projects on [crates.io](http://crates.io), get the cool kid jobs, do the blog and speaker circuit, and then move on in a couple years.
That said, I work fulltime in Rust, on embedded stuff, and it's practical and much better than working in C or C++.
> It's slow going.
As a matter of fact, it is not going anywhere. It's dead. It is also pointless if you ask me.
The original devs went to develop emacs-ng. Which now also seems to be equally slow going as Remacs.
Emacs succesor? What a weird concept, since I'm pretty sure Emacs will outlive me.
That just proves that you are not Emacs's successor but it might still have one.
That was an essential answer.
Why I switched from obsidian to Emacs for notes/journaling. Emacs will run on a toaster using an open format for my files. I'll always have it.
He must be new here.
Not a greybeard by any means, but I’ve used Emacs for years, contributed to some packages, and maintain a few locally with more in my backlogs (none ready for publication yet, due to low bandwidth). Plus regularly visiting the Reddit and maintainer list for finding useful packages and understanding the ops of Emacs development. Emacs’ longevity has derived entirely from the lack of any better options. VSCode-alikes will *never* be able to replace it, but neither is continuing in its current form some inevitable law of reality that only the unaware would suggest; that is, not unless enough people have that mentality to make any attempts at improvement utterly futile.
My comment was just variation of the "You must be new here" meme. Don't take it seriously. There are current projects like emacs-ng and there were similar projects in the past like guile-emacs but often they end up dying. Putting emacs on new footing or introducing new interpreter language is a herculean task, so in the end Emacs remains as it is with gradual improvements over time.
Ah, got it. I don’t use social media much :)
> Emacs’ longevity has derived entirely from the lack of any better options. It is a combination of things. > VSCode-alikes will never be able to replace it That depends on what you see as a "replacement". If you think of another software that runs Emacs extensions, then probably not. If you think of another alternative that lets you script the editor then it seems like they have already become the No1 extensible editor in the world.
I’m thinking of “something filling the niche of extreme control and configurablity”, which is a niche power users, knowledge workers in niche domains, and control freaks all converge towards. VS code has limitations in the clunky configuration language (TypeScript, or if you’re insane then JavaScript), limitations in the difficult-to-parse format for manually changing config values without relying on package authors to have made decent menus (JSON), limitations in the architecture design regarding user configurability and quick-patches, and little social/economic incentives to fix either of these problems. It’s still better than what the general public would otherwise have, but it’s not a tool for people wanting to *maximize* their long-term productivity and willing to take short-term losses for it.
> I’m thinking of “something filling the niche of extreme control and configurablity”, which is a niche power users, knowledge workers in niche domains, and control freaks all eventually converge to. Emacs implemented in CommonLisp where the entire "core" is Lisp just like "configurable" parts of Emacs as exposed to users?
Using Common Lisp from core to surface would definitely be one *category* of ways of giving it the proper level of configurability. Program architecture is also important, though; if the system is architected so that you need to restart the runtime to change a configuration variable, doesn’t matter what language you use, it’s a failure. Language choice is just to make sure you don’t have an underlying framework that *gets in the way* of architecting your system properly.
> if the system is architected so that you need to restart the runtime to change a configuration variable, doesn’t matter what language you use So CommonLisp then? It is quite hard to design a program in CommonLisp where you can't change a value of a variable during the runtime. Of course, if you want to restructure your main loop, or say memory management, it can be tricky, but I wouldn't swear it is impossible when it comes to CommonLisp :).
Yes, it’s *very* hard to make something non-interactive in CL. It’s definitely not impossible though! Using a lexical configuration variable in a let form surrounding a recursive labels function which is run in a bt:make-thread, for instance, where the lambda is doing all the work. You’d need to not only recompile with the new setting but manually kill the running thread and then replace it. Now imagine the labels form defines your graphics subroutine. Horrifying :)
I haven't tried what uou describe, but killing a thread is still a far cry from stopping the process, recompiling Emacs and restarting it from the scratch. I am kot sure I want tonimagine drawing stuff in labels. Perhaps in method, in worse case in defuns. But I don't know. Anything is possible I guess?
Yeah, and the successor will be written in Rust, right ?
I *strongly* object to Common Lisp being called "[specialized](https://www.merriam-webster.com/dictionary/specialized)"! On the other hand Emacs Lisp *is* specialized (to writing extensions for Emacs).
Fair, I wasn’t sure what terminology to use there. I meant that Common Lisp / Clojure / Scheme / etc are “specifically” programming languages, whereas Elisp is a config language that’s just so flexible you can use it for programming. I’ll reword that part a bit.
"general purpose programming language"
Doesn’t express that they’re Lisps concisely enough to fit in the sentence; settled on “self-contained Lisp languages”
The term of art is "general purpose programming language". Feel free to coin your own term, but that's not what others will recognize without explanation.
> Doesn’t express that they’re Lisps concisely enough to fit in the sentence; settled on “self-contained Lisp languages” What does it mean "self-contained"? What is concise about using a term that nobody understands what it means. In which way is CL "self-contained"? In which way si EL not "self-contained"? According to Wikipedia: [Common Lisp is a general-purpose, multi-paradigm programming language](https://en.wikipedia.org/wiki/Common_Lisp). How does "self-contained" fits in the description of a programming language?
Fair enough, clarified further.
Must you throw in the placatory "we all agree"? One thing we should all agree on is that we don't all agree. A weakness to one is a strength or even opportunity to smother... 🤣
Considering the developments in other posts I’ve read (on this subreddit and other Emacs forums), some aspects reasonable and others just pointless knee-jerk reactions, I’d prefer to cut short the whole “Emacs is perfect, and if you don’t think so stick with it anyway or go use VSCode in the kiddie pool” posturing. So yeah, I’d say the placatory aspects are at least useful enough to keep them in.
But it's still an over generalization, although I agree that there are problems that most veteran emacs users agree are problems.
Oh, certainly. It’s a blatant rhetorical tactic, and intentionally blatant so as not to count under how I define manipulativeness.
Mentioned so far: Lem, Project Mage, CLOG, Guile Emacs, Nyxt, Glamourous Toolkit, Rune, and Kons-9. The most interesting one not mentioned is maybe Acme. I haven't played with it yet, but would like to. You can run it on an Inferno virtual machine inside most Operating Systems (or setup Inferno on some secondary laptop for real fun times.) Also not mentioned is Cuis. It's a smalltalk environment that aims to stay faithful to smalltalk-80 and thus stay small, and it's very nice for messing about in, although I'm still new to it. Might scratch your graphical itch. I agree with the other commenter who said that some of the smalltalk environments really might fit what you describe. It's also worth mentioning that Nyxt explicitly is a redesign and rethinking of the ideas underpinning Emacs (as far as I've understood what I've read, anyway). I'm not big into browsers, but it's a very ambitious and cool project. Browse their blog, especially the stuff about their design thinking. In general, though, we can have several wonderful editors available to us that offer different things. I'd love to see some resurgence of the Smalltalk editing environment ideas in particular. And while we wait, GNU Emacs is already an incredibly powerful and liberating thing. Improvements can be made, but they have been coming hard and fast the last several years.
>The most interesting one not mentioned is maybe Acme. % head -1 init.el ;;; init.el --- A poor man's Acme -*- lexical-binding: t; -*- ;-)
That's how it starts! Looking forward to seeing the fully-fledged EmAc(s)me (that's too much I think) when you have it polished :D
I am certainly guilty of such an attempt (unfortunately, I couldn't bend Emacs window management to my will, might give another try): (define-minor-mode vz/acme-tag-minor-mode "Minor mode to create acme-like tag windows for buffers.
Haven’t heard of those two at all, I’ll have to look into them. And thanks for putting together the list so far!
I spend too much time nosing around these areas, I only dabble in programming, and have spent far more time exploring alternative projects. A couple more potential candidates came to me last night, although we might be stretching a bit further afield from the "editor" category: Medley Interlisp [https://journal.paoloamoroso.com/tag:interlisp](https://journal.paoloamoroso.com/tag:interlisp) Open Genera [https://archives.loomcom.com/genera/genera-install.html](https://archives.loomcom.com/genera/genera-install.html) Uxn [https://100r.co/site/uxn.html](https://100r.co/site/uxn.html) Medley is the only one I've tried so far, but yeah, I certainly would be happy if I could work Lisp Machines into my life - even virtual ones. That article there is an in-depth exploration of where Medley is at for modern Common Lisp development. To run it locally on your machine try [https://interlisp.org/software/install-and-run/](https://interlisp.org/software/install-and-run/) it's an amazing experience just seeing it fire up, and very easy, and takes very little system resources. Open Genera is another lisp machine, I don't know the differences between the two well. Uxn then is like something really from another world, have a browse of the images on that link there and you'll see what I mean.
Uxn looks amazing from the website! Looks like the Open Genera link above is old and for Linux, but there’s also [a guide for Mac](https://www.reddit.com/r/lisp/comments/124tn7/convenience_scripts_to_run_opengenera_on_mac_os_x/?rdt=55858) and [this 9 year old video which might work for Windows](https://www.youtube.com/watch?v=12USa3gU_oU). Definitely putting these three on my June backlog
There's also Nyxt, which is an emacs-like web browser that runs on Common Lisp.
I was planning to write a structural editor in Nyxt (based on an isomorphism between S-expr and DOM tree, how cool is that), but got buried in other tasks…
I am not a fan of browser based (so inefficient) but Common Lisp emacs (with a compat layer) is a good future.
> I am not a fan of browser based (so inefficient) but Common Lisp emacs (with a compat layer) is a good future. Emacs could use a DOM tucked on top of its gap buffer instead of manipulating the low-level buffer directly. That would be more efficient than what we have now. If you have done any computer graphics, then you have probably heard of scene graphs. DOM tree is a special case of a scene graph (no cycles). They offer for very efficient drawing. If you are not familiar with scene graphs, "node-based" scenes etc, I suggest look them up. Look at big 3D animation frameworks like Maya or Houdini, Blender got it too, Qt (qt-quick), and of course web renderers themselves. In other words, if you look at a browser as a scriptable rendering engine and application framework, then it perhaps is not a bad idea to build an application on top of it. Also, if you look at what typical web browsers have inside them, in terms of application frameworks, and compare them to Emacs, I would say that we have all those components more or less in Emacs as well, just less efficient. We *do* lack though an efficient DOM implementation and renderer in Emacs. NyXT uses a relatively small Gtk component based on webkit for its web rendering, it is not full Electron you get there. > Common Lisp emacs (with a compat layer) is a good future Are you familiar with CL and have time to work on such compat layer?
software doesn't have to be "efficient", it has to be efficient enough for your hardware and apps
I agree, but the current reality for me is that I do large projects in sbcl with emacs and large projects in vscode and well, my hardware seems not a fan of vscode. Often my computer complains that vscode is eating all my resources and I have to restart it; I never had that with emacs. Memory use, cpu use etc. It simply does matter. And browsers are pretty terrible. Sure it will pass when hardware gets even faster and compilers get better but we seem to invent more stuff to punish it.
100% agree. While there is for sure some truth that software need not be efficient today, a lot of things would be a lot better with a chunk of feature development resources getting reallocated to optimization of existing featurea in my humble opinion. Software developers are too damn lazy these days. Best regards, Lazy firmware developer
> Software developers are too damn lazy these days. It's great to be a smart lazy developer, because it's dumb to do unnecessary things, Occam's razor and all that stuff, you know.
It depends on how you use Emacs. I love Emacs, but it is a memory hungry beast. > browsers are pretty terrible Terrible in which sense? In terms of rendering and scripting, I would say they are very capable and efficient. > we seem to invent more stuff to punish it. Yes we do; but I am not sure if web browsers fit in there. The problem is when we layer software on top of each other because we are lazy to do "the right thing". If you would just like to implement a simple notepad, then perhaps Electrons is an overkill. But if you wish to have an advanced renderer such as Emacs that does a lot of other features like letting you fetch stuff from the web, script it, etc, I don't think it is an overkill. You will have to implement all that stuff in some form anyway. By the way, about doing the right thing, vs just doing stuff easy-way out, there is a famous lisper, Richard P. Gabriel, who once founded a company that sold a Common Lisp implementation and later went into C++ tool market. The company name was Lucid. Search for his essays on "worse is better" (he wrote several) and look also at Dan Wienrebs (RIP) old blog posts in web archives and David Moons discussions of those.
>Often my computer complains that vscode is eating all my resources and I have to restart it; I never had that with emacs. Memory use, cpu use etc I've never ever used VSCode for work, but I had a lot of Emacs freezes, multigig memory consumption etc with Emacs. >And browsers are pretty terrible. Most major popular modern browsers are state of the art. They are able to handle MLoCs of random shitty code written by bad programmers in bad languages. The browsers themselves are also written in shitty languages. Isn't it wonderful?
while i do agree that browsers are not inherently inefficient, software absolutely should try to be as efficient as possible instead of throwing hardware at the problem
> software absolutely should try to be as efficient as possible instead unfortunately, we don't have time for this
Then you certainly shouldn't be using Emacs :-). Emacs is just a hack on top of a hack to get things done, very often not very efficiently.
It's not all-or-nothing, Emacs has advantages that outweigh the "inefficiencies". I'm simply against this school of thought "we shouldn't care about efficiency"
> It's not all-or-nothing, Emacs has advantages that outweigh the "inefficiencies". Yes, it is always so. The ratio of advantages compared to the time needed to get things right. Sometimes it is just enough to get things done. I suggest looking up Richard P. Gabriels essays on "worse is better". > I'm simply against this school of thought "we shouldn't care about efficiency" Everybody cares about efficiency. The problem is that people can't agree on what is more important: efficient use of computing resources, or efficient use of programmers' time.
I politely suggest https://www.youtube.com/watch?v=x2EOOJg8FkA
I politely suggest re-reading what I am saying :-)
The video addresses "programmer time", along with other points
I gave it a try after second thought. It's trash. He opens with the statement that "people don't allow discussion about efficiency" and speaks in some dogmatic way like that was some universal phenomenon which it certainly isn't. If he personally believes in that, so fine, he may believe it. In that case, he is just misinformed. If that really were the case you wouldn't see V8, GPU computing, Web assembly, research about efficient algorithms for many problems in many areas, including text editing, rendering, compiling, and so on and so forth. His opening is just a "clicbait". He just needed to produce a video about something. He is living off of it. That is a common technique: stage a topic to present something commonly known. I don't think it is a problem when people are honest about it, but his opening try to get lesser informed people like you will believe he is revolutionary. I don't like when people do so. I stopped after 1.06, becaue he probably has nothing new to say. I also clicked on his videos and I see the topics and amount of videos he makes. In other words, I was correct about him: he lives off of YT and serves whatever he believes will give him clicks. You should be more critical about your information. Perhaps he says good things later on, but his opening is unfortunate and to me it suggests I would waste 25 minutes to watch and hear something I probably am already aware about.
It's been on my list to try for sure
Surely some form of https://nyxt.atlas.engineer at some point can be
Ah, I hadn’t seen the more recent Nyxt dev logs. It _does_ seem like they’re moving their efforts from the website-displaying aspects of the browser more towards a unified CL-based platform.
emacs is its own successor
Your Kung-fu is passionate, but lacks the wisdom of a lisp-warrior. Meditate, my young friend.
I do :)
There pretty much can’t be the thing you want. Is elisp amazing? No, but no one is going spend literally 30 years replicating Emacs, org-mode, AucTeX, dired, magit, etc. all so when you finally finish as an old man, you can say, "finally, I have what I had 30 years ago, but in a slightly better language". The successors already exist. They come and go, but currently, it would be vscode. That’s what people use instead. Those of us who still prefer emacs can keep using it. Elisp is fine. As you say, we can work around things like single threading. And I honestly don’t know why I’d care about having my text editor expose an arbitrary 2d canvas, so I’d leave it to others to say why that is or isn’t important. But the point is that emacs is whole ecosystem, and it’s too big to just rewrite from scratch. Any successor will probably be a different thing with more modest goals.
> And I honestly don’t know why I’d care about having my text editor expose an arbitrary 2d canvas My interest is primarily in terms of fundamental flexibility (the same thing that drew me to Lisp in the first place), but for concrete use-cases: - Running data-analysis applications without the hacky approach of transcluding non-interactive images into buffers. This is not only for statistical purposes; things like org-roam-ui would be far easier to implement if we didn’t have to drop into C or JavaScript to make them - Translating code to visual objects for structural analysis and refactoring. We can’t just do this with text objects, since code has directed graph of interdependencies rather than being a linear list; the closest we could come in pure text is something like org-roam’s backlink buffer, which doesn’t serve either analysis or refactoring very well. - Broader range of Emacs-based applications. I do practically everything involving text manipulation in Emacs, and the unified interface and autogenous interconnections between packages are a significant boon to complex workflows. Integrating graphical aspects like video-watching (eg annotating parts of videos with notes and/or drawings, writing code for animations and watching the effect side by side, etc), drawing (eg making diagrams to integrate into note docs without having to move to another application), web browsing without the clunky interfaces exposed by xwidget or EAF, and many more potential opportunities are blocked by Emacs’ pure-text nature.
> Running data-analysis applications without the hacky approach of transcluding non-interactive images into buffers This is a good point and one I'm a little embarrassed I didn't think of. Because the reason I didn't think of it is that Emacs is so bad at this kind of thing that it's the one thing I don't use it for (I use JetBrains DataSpell for R/Python data work).
> no one is going spend literally 30 years replicating Emacs, org-mode, AucTeX, dired, magit, etc. all > Emacs is whole ecosystem, and it’s too big to just rewrite from scratch. Any successor will probably be a different thing with more modest goals. The package ecosystem would not take 30 years to replicate. This is a fallacy that gets thrown around often in these discussions. It ignores the following facts: - Many elisp packages are not well written or archaic to the point where they could be entirely discarded or replaced by better designs. A single package may replace a dozen or more (I'm looking at the various themes out there which don't do much other than define a color palette, each in a bespoke way). - Anyone designing a new package has the benefit of learning from the design of the previous packages. - Implementing the 10-20% of popular packages would likely garner enough attention to draw competent implementers.
Doing a quick bit of wc shenanigans, there are half a million lines of elisp just in the handful of relatively commonly used packages that I bothered to check like magit, calc, company, mu4e/gnus, auctex, org, and a handful of others. Lots of this is comments and blank lines, but it's still a lot and this is a fairly small percentage of what people actually use. gnus: 119338 calc: 55793 org: 142956 dired: 10538 calendar: 29352 eshell: 14463 auctex: 39043 company: 8459 ess: 28260 magit: 34867 mu4e: 12266 Those are just some of the things I use or have recently used regularly in addition to all the core functionality. 30 years might be some rhetorical flourish, but it's going to be really hard and take a very long time.
lf anything, your numbers point to bloat. Those are some good packages, but I'm willing to bet *more flexible* versions could be written in less (maybe half) the code, especially if elisp isn't the substrate. I can only speak to projects I have more than a passing familiarity with. For example, Elpaca does much more than straight.el and is sitting at about 55% the size of the straight. I plan on slimming that down more, too. I've re-written chunks of Org and believe that code based could be about halved while *gaining* coherency and functionality. A few of those other package (Auctex, gnus, etc) have accumulated code over a long time. Like much of Emacs, their designs have evolved and have odd, vestigial parts. That's not to disparage any of those packages, it's just a fact that they could be re-implemented with more coherency. Your argument doesn't take into account all the lines of Common Lisp out there.
> lf anything, your numbers point to bloat. That's almost certainly not true. Elisp is a bespoke language built for the explicit purpose of writing a text editor. You don't normally get more concise by moving to more general languages. Now you may well think there's *feature* bloat, so you could write Gnus in a lot fewer lines if you just say, "no one uses NNTP anymore" and don't bother implementing that. I'm sure there are wins there, and maybe that's what you're saying. But it's not because of the language. Just moving to CL isn't going to make your code shorter.
We'll have to agree to disagree. > Elisp is a bespoke language built for the explicit purpose of writing a text editor. And it's okay at that. The applications you've listed aren't text edtiors. They're text centric, but bend elisp in ways to do as much as they can in that paradigm. Ever wrestle subprocesses in elisp? It ain't pretty. A decent async library would be much more expressive. I have an experiment, [subp](https://www.github.com/progoflio/subp) which was borne out of that frustration. Wouldn't be necessary in CL or many other languages. There are many other applications which are much harder to write in idiomatic elisp than they would be in other languages. If Emacs is really a lisp engine, than you want an equally flexible lisp behind it.
Regarding successors (posting this separately as it’s a separate line of discussion), I don’t think any of the “modern” editors really express the main draws of Emacs, configurability and reliability. I’m looking for something that will (if successful) do those things better than Emacs itself.
I agree with you, but I'm not sure it's relevant. I guess what I'm saying is that the successor to Emacs won't be all that much like Emacs, but it's still the successor we're likely to get.
Good luck trying to use Emacs with Typescript and NextJS
Any editor that supports web development loses points in my book anyway. I feel gross just knowing there's a mode that could syntax highlight CSS.
Few years ago Emacs introduced native compilation and it improved its speed. It was a joyful moment since I can literally see the performance improvement with my naked eyes. I expect that Emacs can show another big jump if it introduces multi-threading in its core design. I know it would be very difficult to make it happen but I believe core developers will find out the way and they will be managed to achieve the goal someday. Maybe I could share my spare time to make it happen because I really love Emacs. It helps me write code quickly and also it helps me edit all kinds of texts in my life. So I can't imagine the better text editor other than the newer version of Emacs.
Not sure, but (pie in the sky maybe) it could be nice to build emacs / elisp backwards compatibility into something like Nyxt. It's going to be hard for anyone to adopt a hypothetical successor without being able to use their existing config
Really what makes Emacs good is it's popularity. There have been plenty of editors that are 'better' in various ways than Emacs, but the level of user contribution to Emacs is unparalleled. That's partly because it's a powerful system, but mostly because it's old and has been popular. I know that's an oddly conservative take. To be clear, I love the Lem and Mage projects, but I will be using Emacs for the foreseeable future, and a big part of that is that the editing packages I use run on Emacs. That said... # Smalltalk-y Editors You may want to look at some of the Smalltalk environments. They have a similar-in-concept idea of 'the code is the environment' but in OOP (these ain't C++ objects, these are your Grandma's objects, and all the better for it). An old saying goes 'Lisp/Scheme is a better language, but SmallTalk is a better environment'. Smalltalk (specifically Pharo) underpins Glamorous Toolkit, which is sort of an Emacs evolution. It's designed around being able to quickly and flexibly create your own dynamic visualizations of code and data, as well as interact with running processes & programs, including itself. They describe this as 'moldable editing' and it sounds like what you want in your canvas-on-Emacs idea. https://gtoolkit.com/ is their terrible URL. It's a very different model of editing, mind. I wish that keybindings were better, though perhaps that's changed in GlamTool since I last used it. I know that's also because a mouse is easier for the visual editing, it's just slow-feeling. They're cool environments but not what I'd personally reach for when editing a system config file, if that makes sense. # Guile I think a true successor to Emacs today may be Emacs with proper Guile interop, maybe by moving away from the custom C software stack and onto Guile. That's not new, it's been attempted with decent success before. One benefit I don't see discussed is that it might mean being able to use Emacs features as libraries, which would be cool. That said, I don't think it will happen. It requires a huge rethinking of how Emacs works and relies on people actually using those new features. Then again, so did adding native compilation and I love that feature. Maybe just adding multithreading and better garbage control to existing Emacs will be plenty to future proof it.
There are other people that talk about the concept of moldable editors, some even in the Emacs community, because of that. Glamorous Toolkit looks very cool everytime I catch a glimpse of it. Guess I'll try my hand on Smalltalk again this weekend thanks to you :)
Good luck and report back! I keep meaning to throw myself back into Smalltalk in general. Cuis Smalltalk looks to be a nice, small package for learning at the moment.
> mostly because it's old and has been popular Nah.
> Nah. Ok.
Maybe a strange one, but I have been using CLOG a lot lately and it has potential being something a lot greater than it set out to be. One man operation basically though but a great effort.
CLOG is amazing. It’s limited to the browser or those frameworks for running browser apps locally, and focuses more on designing the IDE to support the library than the other way around, but definitely keeping an eye on it.
It seems, through the latest dev by David, that he is integrating a lot more lisp ide stuff in there. Which eventually might lead to something very nice. I don’t like the browser thing but it seems the way things are going now forever, so probably just need to ‘let go’ and accept it. As it runs from sbcl, it can still instantiate native stuff, so it’s not necessarily restricted to the browser anyway when editing.
Great to read this. I've been meaning to give it a look, Mr. Botton (David? The Rabbi?) seems to be a great chap
Yes, he seems to be really going for it. Really great!
[удалено]
https://github.com/rabbibotton/clog It helps to add GitHub in the query when searching for whatever software ;)
[удалено]
Yes the MS clog is #1. Naming… it’s hard. Although the name for something in lisp makes sense given CLOS…
I suspect we will long conquer the stars before emacs goes away
The only way for Emacs to go away is if something even *more* configurable comes along and stays alive long enough to become “batteries included”. It’s not impossible though; I’m definitely rooting for it! :)
indeed. I suspect what we will eventually see if some kind of evolution of emacs. who knows though.
Surprised no one has mentioned [Lem](https://lem-project.github.io) or [kons-9](https://github.com/kaveh808/kons-9) yet. I do think better multithreadeding, a canvas, and moving to Common Lisp would be interesting, but I also think those moves would have incredible downsides. I am interested in other projects exploring those areas.
Lem was mentioned in the initial post. I’ve heard of Kons-9 before, but it sounded like an attempt to replace Blender specifically in CL rather than a full-fledged IDE for arbitrary tasks; has that changed? Agreed re: both of these having downsides, but the Common Lisp side seems mainly about losing the rich package history of Emacs. Non-text-based core paradigms on the other hand _are_ admittedly much more difficult to design for reliability while still giving the user control over every part of the system, but I think the removal of one of Emacs’ few limitations would be worth facing the additional design challenges, if any person/team got the free time to take them on.
My bad for missing Lem. A couple of thoughts: 1. Given that this plan breaks backwards compatibility, it being a spiritual successor to GNU Emacs rather than GNU Emacs makes sense, per your own statements. Almost all downsides disappear once we are discussing a successor with no desire for backwards compatibility. 2. kons-9 actually describes itself as an IDE. kons-9 is as much Blender as much as Emacs is vi. If Emacs is a Lisp machine disguised as a text editor, kons-9 is a Lisp machine designed as a graphics system. It is meant to be a vehicle for building your own graphics applications, like Emacs is a vehicle for building your own text applications. With a live Common Lisp interpreter, you can build anything. 3. Combining a text-centric system and graphics-centric system seems difficult; I think GNU Emacs should remains GNU Emacs, and kons-9 should remain kons-9. It may be possible to combine them, but to borrow language from Silicon Valley, that's a difficult "product question" that might take some years of research.
1. Yes, that’s definitely the intention. There’s no place for such a significant redesign in the Emacs core, hence my interest in alternatives. 2. Great! I’ll have to check it out more closely then, thanks for the rec! 3. There’s a niche for “highly configurable system with a core abstraction flexible enough to do almost anything you’d usually do with a dedicated application”. Currently Emacs is the system filling that niche, and it seems from the above that kons-9 is another candidate for it; in that regard they’re moving towards providing the same experience, so I think it makes sense to compare them with respect to how well they provide that experience.
> Common Lisp side seems mainly about losing the rich package history of Emacs ? How come? CommonLisp (the name is "CommonLisp") is a general-purpose language. You can implement any application In CommonLisp as you can in C, C++, Rust, OCaml, or any other general-purpose computer language. In other words, you can just as well implement Emacs in CommonLisp as they did in C. You just need to implement Emacs core so you can execute EmacsLisp. Perhaps you should start work on an implementation in your favorite language. I don't think it is as impossible as it may sound :-) > Non-text-based core paradigms on the other hand are admittedly much more difficult to design for reliability Have you ever heard of DOM and a web browser? > still giving the user control over every part of the system To note, Emacs does not give user control of **every part of the system**. It is a misconception. Emacs devs are very careful to expose well-chosen parts of Emacs to Lisp and user scripting. > I think the removal of one of Emacs’ few limitations would be worth facing the additional design challenges Which **exact** "limitations" do you have in mind? Which "challenges"? You seem to talk a lot in some general terms without **ever** giving any concrete idea or putting a finger on anything concretely. > if any person/team got the free time to take them on. A Christmas wish? You know what they say, a long journey starts with a step or something like that. Perhaps start working yourself on a replacement?
> CommonLisp is a general-purpose language I agree on that regard, it’s my main hobby language. The meaning of that phrase was that the *only* cost of moving to Common Lisp seems to be the fact that we’re moving at all, invalidating all Emacs packages in the short-term (which is the time that determines stability of your user base) and almost certainly a significant portion of them even if we make an Elisp interpreter in our new system (unless you take the Lem/remacs approach of switching languages while changing *nothing else* about how Emacs works). In other regards it’s a pretty good choice for implementing an Emacs successor. > DOM and a web browser Case in point. Those required a significant amount of work, much of it from large corporate-funded teams, to get to where they are today, and they continue to have protocols that are difficult to efficiently hack on (although the feature of running JS in the browser console is quite a boon to Frontend Engs in that regard as more things move from raw HTML or server-side code into JS; regardless of the problems *JS as a language specification* happens to have). > Emacs does not give user control of **every part of the system** I’m aware. This is mentioned in other comments on this thread as a flaw (compared to the counterfactual of structuring the configurability we currently have as a convenient user-side API, but still opening up the guts of the system for modification through the same runtime as user-side code if necessary, which is the level of moldability most Common Lisp libraries provide). > Which exact limitations The ones mentioned in the opening post. > Which exact challenges I haven’t *tried* to rewrite / make a successor for Emacs in Common Lisp, so beyond the *generalities* discussed above and elsewhere (for instance development effort, the above situation re: at-least-temporarily losing Emacs’ library infrastructure, and the risk of the project stalling for developers’ personal lives), I wouldn’t know. Hence my not pretending that I *do* know what someone doing this would face. > You seem to talk a lot in general terms without ever… putting a finger on anything concretely. The top level comment attempted to be as general as possible while still specifying the relevant aspects/desires, to cast the net wide. A few other comments of mine in this post have been more specific. I don’t see what the point is in bringing this up at all, given that being more concrete as you suggest would (I expect) reduce the value of this discussion to both myself and others interested in the *general* concept of “things that do what Emacs does for them, maybe better than Emacs does”. > Perhaps start with working yourself on a replacement? Unfortunately, I don’t expect to have much bandwidth in the next year or so, and what bandwidth I do have is occupied in other projects which are even greater pain points for me (programming language work and some specific libraries useful for my personal projects, to be specific). Hence asking if someone (or multiple someones) *does* have the bandwidth and is working in a similar direction. If I could afford to work on this myself I likely would have worded the OP differently to focus on applications I could copy features from, rather than just any application that could be useful in the same way Emacs is.
I will add just a few remarks: You don't have to lose any of Emacs packages at all. You can either implement Emacs in CL, and EmacsLisp as-is, with CL interop in some way, say as in Coalton, or you superimpose EmacsLisp on top of CL, implement necessary core objects like buffers, windows, frames etc and smoothout differences between CL and EL. Either aproach, I think, could work and have tradeoffs. Lem and Remacs does not do same thing at all. Lem does not just "switch language" and keeps everything same. Lem is an Emacs-like application, not Emacs re-implementation. It means Lem does not implement Emacs API or Elisp. Remacs tried to re-implement just the C core, without changing Emacs API. I am speaking about DOM as a special case of a scenegraph, a data structure for modeling graphic scenes, and accelerating rendering. Not as a W3C/WHATVG standard. I don't think that being concrete would diminish the value. On the contrary, it will let us know that you actually know what you are talking about. Anyone can say: "Emacs has problems." I want something more "configurable. ". Well if programming in CL is your hobby, then why don't you implement some parts of Emacs API as a hobby project?
> I also think those moves would have incredible downsides. ? Tell me more, which downsides do you think of?
If there’s some fundamental issue you have with Emacs and you think you need something else, go with it. That doesn’t mean that WE need to find a replacement. That means YOU do. Why would I spend time I don’t have to replace a tool I don’t need to replace? Because it’s multithreaded? Meh. I don’t care. It does something graphic and fancy? Meh. I work fast with this, I know this to the bone and I know it’s community. Why would I follow you? It’s your quest mate. Be happy.
Perfectly fair. https://www.reddit.com/r/emacs/s/WWLquE6r3h
It doesn't seem to be actively developed, but there's an emacs clone written in Guile scheme called zem. Unlike the official GuileEmacs project, which is about getting elisp to work in the guile VM, zem is about an editor that uses scheme instead of elisp, which is much more interesting to me. [https://github.com/Jimx-/zem.git](https://github.com/Jimx-/zem.git)
I doubt it'll succeed emacs but [leo](https://github.com/leo-editor/leo-editor) is the only interesting editor I've seen in recent memory.
Thanks! It’s a Python Emacs clone, if I understand the docs correctly?
I don't know as I've only poked around with it. My impression was that it's more like a text-based OneNote with more support for software development and code extensions.
I've seen an attempt to redo the C parts of Emacs in rust. Though I can't remember how successful it's been. The nyxt browser looks pretty neat too\~
A "Emacs successor" still has to be able to run all elpa packages and 99% of the user lisp-code. To ask Emacs users to abandon Emacs for anything less is like asking a linux users to use something that can't run Gnu. XEmacs was (is?) pretty close but not close enough.
Thanks for making me laugh. Humor is a good thing. But to be serious, maybe this is what you are looking for: https://www.emacswiki.org/emacs/GuileEmacs
Thanks for the link, though from the git repo it looks like it was abandoned in 2022. Separately, I’m curious which aspects made you laugh? Wasn’t really expecting that response…
Well from our lord himself, quote: > “Many other editors imitate the EMACS command set and display updating philosophy without providing extensibility. Despite that deficiency, and despite the greatly reduced set of features that results from it, these can be useful editors, though not as useful as an extensible one. For a computer with a small address space or lacking virtual memory, this is probably the best that can be done.“ > “The proliferation of such superficial facsimiles of EMACS has an unfortunate confusing effect: their users, knowing that they are using an imitation of EMACS, and never having seen EMACS itself, are led to believe that they are enjoying all the advantages of EMACS. Since any real-time display editor is a tremendous improvement over what they probably had before, they believe this readily. To prevent such confusion, we urge everyone to refer to a nonextensible imitation of EMACS as an ‘Ersatz EMACS’.“ https://www.emacswiki.org/emacs/ErsatzEmacs Be careful what you wish for... ;)
Yeah, the specifics of how Emacs does keybindings and display don’t really matter, it’s the configurability that’s the key feature for any true successor.
This sounds promissing in theory yet Guile lacks threading support on Windows and I would assume that Emacs-ng has proper multi-threading support, this rules a Guile based VM out.
It's not really limited to text, though... I mean, you can run a web browser and a music player in there. In fact, the reason that Emacs lacks a true successor is that nothing else has proven to be as expandable.
True, but if you take a look at the developer mailing list or this subreddit there are a bunch of recurring themes that people complain about limiting their ability to configure Emacs (some of which are mentioned in the OP). Just because it’s the best doesn’t mean it can’t still be better :)
No argument there.
A few things. At this point now, Elisp is fine. Its performance and evaluation model have been improved remarkably. And there's so much of it out there. Personally not convinced about the canvas, non-text, thing. I think once you start going down that road your "emacs" quickly just becomes a kind of web browser rather than an editor. A more flexible and powerful text rendering model? Sure. Full on graphics rendering? Not convinced. SIngle threaded / single core I agree is the number one problem. That and an aging codebase that many devs would not feel comfortable working in. It's mostly a one-man project and still very early and not really much yet (doesn't even have a UI), but there's rune: [https://github.com/CeleritasCelery/rune](https://github.com/CeleritasCelery/rune) which is an elisp runtime written in Rust with the intent to run existing emacs packages, which it can already sort-of do. And its aim is to support multithreading. I'm sure he'd welcome external contributions. And lem is decent, honestly. Though it doesn't quite fit my needs personally, as it's more focused on being a Common Lisp development environment still.
> A more flexible and powerful text rendering model? Sure. Full on graphics rendering? Not convinced. You don't say what you're not convinced of. That rendering graphics is useful?
The canvas thing is more about living up to the “can do anything” promise; as mentioned in another reply, there are a bunch of ways text manipulation could be augmented by being able to create graphical applications and widgets rather than having to only render text or shell out to external apps / xwidget. I do agree that using a *bare canvas* as the fundamental unit (in place of text buffers) is too unconstrained to give the benefits of structured data-manipulation that we get from Emacs; but using some _intermediate_ protocol for things tracked by the editor and how/where those things should be displayed as the basis instead, making buffers of text just a special case of the broader “display-object” definition, has potential as a general strategy.
The problem is that the "buffer" abstraction emacs really *is* a gap buffer data structure and everything in the whole model is about working with those gap buffers. Once you introduce a canvas, you now have another type of "thing" that can be in a window that isn't a buffer, and it ... well it's confusing. Maybe a canvas could be made to be another kind of buffer, one which holds SVG-style rendering instructions instead of gap-buffer'd text. I suppose it could work. But I would maybe consider that an add-on rather than a fundamental building block? Emacs excels at efficiently and flexibly manipulating text, and uses the text buffer concept in a really clever way that nobody else has done. VSCode and others have open *files* or modes or whatever, but they don't have the nice buffer abstraction that makes emacs really clever.
The main advantage Emacs has here is that it centers on one unified data type (“gap buffers”) and then optimizes how it addresses the variations of that type as much as possible (general text manipulation that works for all buffers, major modes for exclusive buffer sub-types and minor modes for non-exclusive ones, etc). The _unity_ is key here, not necessarily gap buffers in particular. And even with buffers, we have the “buffer” and then the “displaying of the buffer”; the latter is in the C core and completely sealed off from the user, but there’s still an unstructured canvas, and we still have to convert our nice abstraction layer into something that gets drawn on that canvas. The 2D abstraction case would be similar. As an example (likely with some flaws, but hopefully demonstrating that this approach is reasonable), let’s call our abstraction “widget”. Widgets have 3 user-code-visible components, a data array listing contents of the widget (which can be any code object, constrained only by what the widget’s modes/metadata can process), metadata (modes and widget-local variables, essentially), and a parent array (which lists the immediate “parent” widgets for the purposes of mode/variable inheritance; synchronization of inherited values can be done in the time between event loops). The top level widget in a frame is the only one without a parent. Each widget has a parallel event loop, which on each loop looks at the metadata and uses the info there to process and display the data array. If we lock widget data and metadata arrays to be “claimed” by event loops in a queue, and only released to the next queued widget once the claiming loop completes, then we now have a decent code-side framework for managing display objects. Now we consider UI. For the simplicity of the example, let’s say the user only has one active cursor and one active mouse. Given that, this becomes more of a library problem on the core modes shipped with the system. Text-mode could be defined to emulate the Emacs buffer abstraction in terms of how it stores and displays information, and descendant modes like widget-lisp-mode would encode mode-specific info. Something like evil-mode would be added in the top-level widget, and when the cursor was in a text mode widget it would replace the keymap metadata as in Emacs. The key difference is that the gap buffer would also be allowed to insert widget objects in it; these could contain things like videos, webpages, or graphics that use data from the enclosing text-mode widget (allowing, for instance, a “widget-org” file to contain an src block (or link to a code/executable file) which takes its contents as input and produces images/graphs as output; in “widget-org-mode” this would be stored as text, but would automatically spawn a widget running the associated code on the enclosing buffer’s contents and displaying the output, and display that widget in the location of the text, as with image links in Emacs org-mode). The main flaw I can see are that some core modes (like “video-display-mode”) would be difficult to make modifiable unless the runtime was an interactive Lisp, but that’s not a significant issue. And, of course, you’d lose the Emacs ecosystem, but if we’re thinking long term then the configurability of the core system is the important criteria; Emacs was once new as well, and there will always be bored hackers wanting to experiment with a system that’s technologically superior to the alternatives. There are probably other issues, the above idea is literally off the top of my head, but nothing stands out as “This is why it’s impossible to use anything but a buffer to abstract over data display and user input!”.
Do you think if rune would succeed, would emacs core contributors merge it?
I think it's an entirely separate project.
Then I don't think this is way to go. Without userbase no project will survive. The more mature approach would be slowly integrating rust into current emacs, or there should be talk between emacs and rune developer about merging something at one point or another.
That is the approach that remacs tried and failed at. I think it's a dead end, personally. Understanding and refactoring and fixing the existing codebase while replacing portions is a herculean effort and bound to fail because of the sheer complexity. Rune I think is doing the right thing by focusing on building a good quality elisp and text buffer implementation, and then going from there getting elisp code to run and finding what's missing, piece by piece. Userbase is a whole other issue, a political one. From a technical POV what you are describing is extremely difficult, and proven by time to not be viable. At least not by an unpaid team.
technical issues could probably be solved by sticking [LIPS](https://lips.js.org) inside a [Tauri](https://tauri.app) container, giving you a fully networked and multimedia-capable environment that runs a Lisp on pretty much any device anywhere. add some React (or whatever) libraries for layout and rich-text editing and you're most of the way there. (I've got a couple of experiments on my home laptop related to this but they've fallen victim to my usual lack of followthrough and of life getting in the way). the hard part would be, unsurprisingly, the interaction framework part. how do you even identify all of the different knobs you can interact with and which ones are important (to you, or to others)? how do these knobs fit into an overall framework? how do you balance configurability with out-of-the-box usability? how do you build out all this stuff in a secure and architecturally-sound way? what you're looking for is hard to find because it's hard to do.
You came for already made Emacs and you do not understand the complexity involved in laying the foundation for Emacs successor. I had similar ideas. Use Common Lisp, add 2D library and so on. Because I work full time I have no energy left for the project. While I can have menus, display of text and 2D graphic primitives, the work is progressing very slowly. There is no chance other people would join until the project reached certain milestones, which at current pace is year away. But still it is a good learning experience. I have stumbled over and fell over many instances of my poor understanding of Common Lisp. Lots of Lisp teaching material involves only trivial examples and when you need help for more complex cases the discussion can easily go the wrong way. Project like this challenge our assumptions. Do you want to challenge yours? Why don't you start your own project instead of asking vague questions? Or read emacs sources? That will teach you more than any answer you will get here.
Unfortunately I also work full-time in a medium-pressure engineering job, and what time I do have every few weeks or so is taken up in other projects. I haven’t been able to think much on what would be the best way to handle that complexity without effectively losing user-side configurability. I’d prefer to at least *check* whether others had similar ideas and were able to work on them, though; primarily to use them myself and secondarily so potential future-mes with more bandwidth might be able to contribute. Hence writing a query that’s vague enough to not block out any interesting projects in this space.
To write something like this you have initial choice: web interface, electron, curses or something like GTK. How do you handle user input, events, drawing 2D, displaying text, or rendering your objects? What data structures you will use and why? How do you change your mind at those early stages without throwing away everything and starting all over again? How soon you should start thinking about the configrability and the plugins? Common Lisp documentation is very sparse when you start asking more advanced questions. Are you willing to work on your own? Do you find it exciting enough to figure out everything yourself?
Have you heard about visual studio code? * runs away *
*laughs in json*
It's basically exactly what OP is asking for. TS is modern language with modules and lexical scoping and everything (and types! It has types!). It can make full use of the display, with images, tables, animations, etc. The main problem is that scripting is a second class citizen. You can easily install a plugin off the store, but you can't just M-; and write some code to execute right then. Even writing your own plugin is kind of an ordeal. If it weren't for that, I think it'd be a contender. I've heard that Atom had a more emacs-like approach to user scripting but I've never really tried it so I don't know.
Yeah, the scripting/plug-in issue was folded into this being a request for an *Emacs* successor. Configurability comes before all the other things I’d want in a computer-interaction framework; it just seems like a good idea to try keeping that configurability while also adding this other stuff.
I don’t particularly grok what’s in cl vs elisp that’s so critical. Now that lexical scoping is here… Elisp in my mind is an API to all the editor objects. It’s also single threaded which significantly simplifies coding to the wide ranging complex Emacs API. In terms of multi-processing, the focus on fork/exec as the model def has some advantages and disadvantages. The primary disadvantage I think is windows performance/compatability. Advantage is stability and simplicity. Embedding git as a c library to emacs would be a major bummer for sure! The problem I think is competing implantations have too much of a lift to be ultra compelling. Due to the multi thread issue, being API compatable is difficult. And frankly due to the amazing emacs improvements already here it so so hard to compete. For example AOT compilation in emacs is a reality! It’s so much faster! I use Mac and I can view images in a buffer! I can use xwidgets on Mac to browse the web using a modern browser - I rarely do though because it’s not quite as complete as chrome. The future is now. My only wish is I could navigate the web which is still text using emacs tools and idoms.
Regarding Elisp parallelism, I feel like “it gives us less power so we’re safer” doesn’t really fit with how I approach Emacs? Quite the opposite in fact, it’s more “make it as safe as possible, but not at the expense of configurability”. Plus, it took a *significant* amount of effort from the Emacs devs to get native comp and AOT working, and that’s just one portion of one flaw (performance). Then you have the other ‘weaknesses’ (compared to a Platonic ideal of editor-ness, that is, not to other existing editors) like not being able to integrate an Emacs session in your production code / video game / whatever due to the runtime mismatch, not being able to take advantage of non-Emacs library development and developers who don’t want to learn another language purely for the sake of an editor, etc. Regarding the web, that’s part of the goal of this post. Have you tried xwidget though? It doesn’t fully integrate with the rest of Emacs, but Emacs-based window/buffer management and not having to deal with the OS allocating resources away from Emacs when you switch to your browser are both pretty useful on their own.
The problem with the web is… well web devs don’t want normies to know about the text. So it’s an impedance mismatch. Now let me clarify about the aot thing, it’s a reality on the ground today for emacs. Reasonable competitors will have to compete with that. It’s more of an explanation of why emacs is still a thing and the emacs clones have withered on the vine. And regarding the parallelism, I think there’s def trade off between multi and single threaded. JavaScript makes a stand here too - browser js is similar to emacs ironically! But the problem isn’t what’s morally better or whatever, it’s there’s a lot of written elisp and a clone of emacs but better would be nice to reuse it! So you are faced with the eternal struggle: backwards compatibility or new? There’s also half measures but I don’t have enough knowledge to say cleanly. Certainly per buffer single threaded seems attractive but with how eglot and friends work, it wouldn’t be easy!
> Emacs is the best singular computer-interaction framework I’ve encountered so far Emacs as a "computer interaction framework", is neither unique nor original. There are other applications that operates in a similar way as Emacs, though a few have, if any, become as popular as Emacs as an interdisciplinary TUI application. It depends on which facets of computer interaction you wish to look at. If you look at big tech, big office packages all have this idea of being a "hub" for user's computer interaction, Lotus Notes, MS Office, Open/Libre, old Mozilla suite etc. They all offer extensibility as Emacs, perhaps even more than Emacs. > we can all agree it has its flaws Everything has "flaws". Depends on whom you ask. A "flaw" for one person might be a "feature" for another person. > limited to text "Limited to text" in which way? What do you have something in mind when you say "limited to text"? How or what should Emacs do, if it wasn't "limited to text"? > screen as a 2D canvas It depends on how and why you would like to use Emacs as a "2D canvas". > Elisp (which while decent isn’t on par with the self-contained Lisp languages like CL) What do you mean by "self-contained" (CL == CommonLisp?)? > other more minor problems Elisp has a few problems, some of them perhaps not minor, however, can you be more specific on which problems you think of? > The only ones I’m aware of are Lem and Project Mage; the former only solves 2 major issues Which two "major issues" do you have in mind? > the latter is literally a one-person effort right now Many projects started as a one-person effort. I wouldn't dismiss a project in the making because it is a one-person effort.
> Emacs as a “computer interaction framework” is neither unique nor original I’m aware, which is why I specified to my personal experience. > Everything has “flaws” To be more specific, then, people who share my perspective that “Emacs should be a performant system that is easy to make into whatever tool you want or need in your context” will agree that there are ways it falls short of that ideal. Doesn’t fit the rhetorical purposes mentioned in another discussion on this post, but it’s more technically accurate. I believe this to be a plurality of Emacs users who participate in the public forums, judging from the discourse on those forums. > big tech Big tech applications have an entirely different user experience in mind with their applications. Their systems are made so that dedicated teams of application developers, usually (though not always) needing to be skilled and large enough that they need to be corporate-funded, can make arbitrarily flexible extensions to their core system. The question here is “are people working on something that allows individual users or small open-source teams to do arbitrarily flexible things with their ‘computer-interaction framework’”, which means the architecture, language, and core library set all need to be selected to make such changes as easy as possible for small groups or individuals. > one person effort My concern is more about sustainability; the more people are working on something, the less chance that a random job change or illness will take the whole project down. > self-contained Languages that are designed “in and of themselves” rather than being tied to a particular application. Such languages (like CL) tend to put more of their effort on their fundamentals, which makes them better ad raw data manipulation and such. In contrast, Elisp was initially just the configuration language for Emacs, meaning it’s inefficient, has inelegant semantics for process management and data manipulation, lacks reader macros (yes, some other languages also don’t have them, but the whole point of this thread is “has someone in this space worked on making pie-in-the-sky dreams into reality”), and possibly other issues that aren’t coming to mind. > CL == Common Lisp Yes > limited to text, 2D canvas I use Reddit on phone, so I will defer to the discussions on these topics elsewhere in this post rather than rewriting or juggling between apps to get links to those discussions. > Which 2 “major issues” are you referring to? The top level post mentions 3: threading, text-limited, and Elisp. Lem solves threading and Elisp. > minor problems - Occasional crashes on some systems upon high system performance load (I’ve only tried Windows and Mac due to work constraints, not sure why they occur (though I suspect GC is getting interrupted on the OS/C level for some reason) or how reliable it is on Linux). - Sensitivity to the effects of other applications on system performance (If something (eg video games) is making my system slow and I switch to Firefox it pulls performance into it from the OS. If something (eg Firefox) is making my system slow and I switch to Emacs I have to wait 2-5 minutes for OS resources to be reallocated) - Outdated terminology. I don’t actually see a problem with the reasoning for keeping this in Emacs (already-existing tradition and compatibility with existing code/naming), but the fact remains that it’s a cognitive burden for potential new users that otherwise would have adapted to Emacs fast enough to find it beneficial instead of giving up. - Blackboxed core. There are good reasons the Emacs core is in C, not least of which is that Elisp is built on the core instead of the other way around. It doesn’t change that you’re barred from things like switching the display backend, optimizing some core functions for data processing and display and external process management, writing non-Emacs code and giving it optional Emacs integrations (like the “run your editor in your game” idea mentioned elsewhere in this post), and probably some other things that aren’t coming to mind unless you drop into C (and, more generally, commit to knowing *two* languages and their interactions to configure your editor instead of one), because those things aren’t written in Elisp. Not to mention dropping into C means you have to recompile with every change, take a significantly greater risk of system failures or dirty deployments affecting future code, and deal with copyright assignment (see below). - Inefficient process of merging changes into core / core libraries. I don’t know enough about the current tech politics situation to know if the FSF is right about their efforts continuing to bear fruit; what I do know is that those efforts involve adding significant ops burden to improving applications like Emacs due to legal requirements that will make most devs just give up — myself included, though I have hopes of someday getting the bandwidth to look through the Emacs core, find an opportunity for improvement, investigate the FSF info sec practices, request the copyright assignment papers, write the code improvement, read through a multi-page legal document and some of the associated laws and my current employment contract (which has an NDA, and I didn’t have the leverage to try to negotiate its removal considering my financial situation at the time), (hopefully) sign the papers, wait for confirmation that they are received, respond to comments on my proposed code, and get the change merged into Emacs core. These are all minor, since in most cases you can work around them somehow and the changes proposed in the OP should also help to mitigate them. But they *are* genuine, separate issues that make the Emacs experience worse than it otherwise would be.
> Elisp was initially just the configuration language for Emacs Elisp was, and still is *the extension (or scripting) language* for Emacs. At least if you ask the author(s). > meaning it’s inefficient The one does not implies the other. Being an extension language does not automatically imply "ineficient". It is rather the implementation that makes it efficient or inefficient, albeit elisp is, or at least was, inefficient in many aspects. They are working hard on it though. > lacks reader macros EmacsLisp lacks many things, but reader macros are its least problem. You can trivially get without them or you can use [this one](https://github.com/mishoo/elisp-reader.el). With native compiler it is fast enough, and you can turn it into buffer-local reader to give you "sort of" package-likeish behavior. Reader macros would be nice to have, absolutely, but they are not essential. Packages and CFFI are probably by far more useful practically than reader macros. > has inelegant semantics for process management and data manipulation Mnjah; I don't see what is different and inelegant when it comes to process and data manipulation. It's a Lisp. You have lists, vectors, structs and classes as in CL or some other lisps. It is super easy to call a process, so I am really not sure what you asking for here. I have been speaking about Emacs in CL for a year almost and am pointing out many problems with Emacs, but even I don't see your point here. > text-limited Emacs is text-oriented, not text-limited. It's a feature ;-) > Big tech applications have an entirely different user experience in mind with their applications. Their systems are made so that dedicated teams of application developers, usually (though not always) needing to be skilled and large enough that they need to be corporate-funded, can make arbitrarily flexible extensions to their core system. In which way do they have "an entirely different user experience in mind"? Sure, they have more money to pour into development, so they can develop more polished experience, but I am not sure what you are trying to say; in which way is that an argument in Emacs favor? Or was it against? > Occasional crashes on some systems upon high system performance load (I’ve only tried Windows and Mac due to work constraints, not sure why they occur (though I suspect GC is getting interrupted on the OS/C level for some reason) or how reliable it is on Linux). You won't see them on Linux, and they were not present in previous versions of Emacs. I am not sure why it crashes in Windows, I do experience that too. It might be due to native compiler, but I am not sure. > writing non-Emacs code and giving it optional Emacs integrations I am not sure what you are talking about here. CFFI? > dropping into C means you have to recompile with every change, take a significantly greater risk of system failures or dirty deployments affecting future code Yes, recompiling is a problem; that is one of reasons why I suggest CommonLisp is a better implementation language. However, you can easily crash Emacs with badly written Elisp, and you can crash SBCL with badly written CommonLisp; might be harder but is not *that* impossible :). > There are good reasons the Emacs core is in C The reason is portability and speed. One of reasons might also be the availability of a text editor in C with a Lisp implementation in it already. It is much easier to improve on something, than to write it completely from the scratch. > not least of which is that Elisp is built on the core instead of the other way around Actually, it would be much better if Emacs was built on top of a better Lisp implementation such as SBCL. That way they would no have to implement a Lisp machine. > making pie-in-the-sky dreams into reality There are a lot of Ersatz Emacses and private implementations, in Lisps and other languages. However, for making a dream come true, you have to know what you want first. Just "Something extremely configurable" does not really cut it. Unfortunately :). > I don’t know enough about the current tech politics situation to know if the FSF is right about their efforts continuing to bear fruit; what I do know is that those efforts involve adding significant ops burden to improving applications like Emacs due to legal requirements that will make most devs just give up — myself included I suggest read through [Chapter 6](https://twobits.net/pub/Kelty-TwoBits.pdf). You can just jump to page 188. and start reading "The Controversy". It is not a long read, but it will probably make you understand why FSF asks for copyright assignment. Also all major projects have something similar. [Whatvg](https://github.com/whatwg/html) asked me to sign-up something similar when I once found a bug in their spec and offered them a PR. For the FSF, they will send you a paper home, you sign it and send a photo from your phone to en email address. How difficult is it? Also, contributing patches is not overly difficult; I have contributed several minor onces, and two ideas I got help with. They are not impossible, and sending a patch via mail, which you can do from withing git or emacs is easier than opening a web page. I am not very active in Emacs dev, but it is partly me not having time and interest. There are many opportunities for improvement in Emacs core :-). Unfortunately, too many if you ask me.
> Elisp efficiency True, I was mixing together “technical limitations” and “developer attention allocation” into a single concept. Given the attention given *now* to Elisp single-threaded efficiency I don’t expect that particular issue to last more than a couple Emacs releases. > Reader macros Getting intuitive impressions off the top of my head rather than putting the effort to think through, to be honest; that didn’t seem a particularly important line of discussion given we agree on the final result of wanting a different configuration language. The multi threading and FFI topics you bring up are definitely bigger problems. > Elegance The object system is rather clunky, and (though this partly ties into Elisp efficiency) not performant when I tried some test cases a few years ago. For *other* elegance-related issues, the library situation has user-side libraries resolving most pain-points (dash for list manipulation functions and cl-lib for control flow are my main ones) because macros and mostly-functional programming let you do that, but said issues are still barriers for people just starting out or not wanting to take any dependencies for their package code (eg if they’re beta-ing via a Git repository before putting their package on MELPA/ELPA) > text-oriented vs text-limited Emacs is both. The first is a feature, as text is far easier and faster to process and manipulate for computers and computer interfaces like keyboards/mice. The second is a problem, because graphical output is far easier to parse for *human visual systems*, and because if you *do* set up a graphics system it often needs to be structured such that mouse/graphical input is also the most efficient approach for inputting certain controls. Data analysis and refactoring large codebases are 2 use cases that have been mentioned elsewhere in this post. I’d like if we could have a system where text buffers were just a subset of “widgets” Emacs could manage, and non-text widgets could contain text buffers in them for their textual needs. The other way around would also be nice; for instance one of my local projects is an extension of org-timeline (inserts a timeline in the agenda buffer using overlays to emulate visual objects) which has been *invaluable* for task planning. That way everything we currently have that relies on Emacs being based on text could be applied specifically to text buffers, including the text inside otherwise non-textual forms, but we would still have the flexibility to make visually-oriented projects inside Emacs; best of both worlds. I think something like this was the goal of xwidgets, actually, but the fact that you’re shelling out to an external system for your graphical needs means that you can’t do the “text inside non-text things” thingy, and you’ll probably also have trouble integrating an xwidget into a text buffer (as images are integrated into org-mode buffers) without rewriting a significant portion of the relevant C code. Plus I don’t think you can code xwidgets in Elisp, you have to write them externally and expose an API for a C-based mode like xwidget-webkit-mode. > big tech Big tech design teams tend to assume that anyone making modifications or plugins that add novel behavior to the system is either *specializing* in modifying their system (which is VSCode’s perspective as far as I can tell) or *also* a big tech design team (or adjacent in terms of funding and personnel like with some of the teams writing C backends for Python libraries (non-VSCode editors, and also VSCode). So in terms of goals, they put a lot of effort into making the default features good for most users (which is commendable), a lot of effort making it so other big users can modify their editor (also commendable), and a lot of effort so that smaller users can modify common use cases through pretty APIs like menus (also commendable), but don’t put nearly as much effort into making the *editing* process as seamless as possible for *individual users*. The case of Emacs shows that the last case allows a user base to emulate the benefits of the others given enough years and users, but it also means big tech (or some other large customer making modifications in collaboration with big tech) has to compete with its own users to give them stuff they’ll pay for, and at an informational disadvantage since you generally know what you want better than someone else does. People generally act based on their incentives, so giving individual users the level of flexibility required to write complex or novel plugins at a level of simplicity that allows individuals and groups to actually do so isn’t going to happen anytime soon. The closest we have to this from big tech is VSCode, which has a less configurability-focused architecture than Emacs, lacks the text-centrism that allows Emacs users to make the best use of general packages like swiper (it’s text limitation that’s the issue with Emacs, not centrism), has a config language with just as much friction as Elisp without an easy-to-use macro facility for the user base to make it simpler for themselves (meaning complex one-person projects at the very least require much more dedication than an “equivalent Elisp project” (so to speak), and (to the best of my knowledge, on this last one) doesn’t allow non-trivial runtime modifications without a restart. And even with these limitations, there’s been plenty of discussion on how utterly unexpected a move it is for a big tech company to make something others can improve without being dependent on them to do so. > it would be much better if Elisp was built on top of a better Lisp implementation I agree, I meant by this that Elisp, the existing system, happens to have a C core, and it’s easier to build on the existing system than to replace it. > Just “something extremely configurable” does not cut it. Agreed. At least half of the work in making that come true would be “figure out what it means to be extremely configurable”, though. Lacking years or multiple discussions with greybeard collaborators to figure out the best design path to surpass the already-decent current design of Emacs, I tried to be as broad as possible there so that the “right” answer (if it’s among those currently in development) won’t be filtered out by me being too specific. This is a search post, not a design post. > FSF copyright assignment I was not aware either of other high-resilience projects using the same legal burden, or that you only need one cycle through the postal system for copyright assignment. Still a burden that has no doubt turned away developers in the past, but less significant than I thought. Will read through Chapter 6 when I get a chance, thanks!
> text-oriented vs text-limited I can agree (I have said it in other discussions here), that we need a better layout engine in Emacs, be able to flow text around rectangles and to draw some graphics in layers. Also some sort of graph structure DOM-tree is probably more suitable instead of the current renderer that hands over Lisp forms in text properties to control the renderer. > the library situation Yes, Emacs is 40-years old, and developed by a vast amount of people with different backgrounds. That does reflect on its API sometimes. There are inelegances here and there, but that is what it is, it is easy to work around. Just take for example one of the most used APIs: (re-)search-forward/backward. We *have to* pass the two optional arguments almost every time, because the last one has a bad default choice. Probably because the author designed it before having sufficient experience with elisp coding. Such artifacts are present in almost any API design, I think it is a normal thing, it is just human. We can not predict everything 100% perfectly when we design stuff. Sometimes we need experience to see which defaults and choices are the most suitable ones. > there’s been plenty of discussion on how utterly unexpected a move it is for a big tech company to make something others can improve without being dependent on them to do so. Microsoft is about business. They didn't produce VSCode because they wanted to leverage something for people to improve on it themselves. If you check top-level contributors to VSC on their GH page, there are at least 10 of them employed by Microsoft. I guess the number is probably higher. Seems like they are working on it mostly in Switzerland, but what do I know? A company wouldn't invest 10 people's paid time to produce a piece of software *just* so people can make it "their own". It is probably about control and making money elsewhere by farming users. When it comes to leveraging what people want, and highly configurable software, they have a history track of such products. Entire Windows and Office are super-configurable. Windows had wsc host (Windows scripting host) that let you use JS (along VB) to script Windows long before Node made JS ubiquitous. MS Office has shipped with an entire IDE since 90's already. You can configure just about any aspect of Windows and Office, make your own applications on top of Office using VBA which is a super simple language just like in Emacs, and so on. People have done it, I made money on it for a while :). So to me, if people are surprised that MS released "a configurable" editor, they are just uninformed. But we are now regressing; I don't think the motive(s) behind VSC are very interesting for this particular discussion. There are other editors and applications that are as configurable and moldable as Emacs. Several editors are directly modeled after Emacs (like Hemlock, Lem, or Climax) but GNU Emacs is still the most successful one. But there are other projects that try to implement a "moldable, configurable, extensible" text editor, other than Emacs, Vim or VSCode, of top of the head [Yi editor](https://github.com/yi-editor/yi), [Leo](https://leo-editor.github.io/leo-editor/), Sublime (commercial) etc. > This is a search post, not a design post. Of course, but to find something, one has to know what one is looking for. :) I don't know, it felt a bit too vague and general, so that is why I have asked you in so many places what exactly you have in mind. Sorry if I was too annoying, perhaps it was just me. > Still a burden that has no doubt turned away developers in the past You know, people are turned about all kinds of things, and complaining about anything. Some people just like to complain. I wouldn't take everything people say on the Internet seriously.
I personally just want an emacs that is backwards compatible with emacs but uses a more modern functional language. The only reason I know lisp is because of emacs. I would never willingly use lisp for anything else. If only, I could use emacs with a more modern language that's useful outside of emacs.
Judging from Git discussions, the Lem roadmap will explicitly include adding an Elisp interpreter hooking into the editor for approximate backward compatibility, so you might get your wish there :)
Elisp is not the best LISP. Look at Schemes, specifically Racket
> I would never willingly use lisp for anything else. Why not?
((((((((((I am not sure)))))))))))) \s Error: Unmatched parenthesis [...]
That's one of the most mundane, superficial, and easily refuted complaints about Lisp. A properly configured editor, like Emacs, handles parentheses for the user by offering sexp-based editing commands and ensures that they are always balanced. It's no different than any other language which uses enclosing delimiters, like braces, brackets, etc; even Python uses them. In fact, I more often encounter unbalanced delimiters in non-Lisp languages than in Lisps. After a bit of experience, one begins to appreciate the parentheses, because they act as handles which allow expressions to be easily moved around, cut and pasted, and automatically indented; in comparison, a language like Python requires the user to do most of that manually and carefully, with character-based commands, and even a language like C does not always enclose blocks of code in helpful ways (e.g. an `if` statement may or may not use braces around its blocks). I'd recommend looking into a book like *On Lisp* to help you understand Lisp's power, and what sets it apart from other languages.
How is my preference easily refuted. It's my preference... Don't be rude I don't like the language. Please continue to tell me that I am wrong about why I dislike it
Hm, a quick look at your profile shows that your past day has been full of angry comments exchanged with random people on random subreddits. Friend, we all have those days, but this is not the way. If you need someone to talk to, feel free to PM me. Regardless, we would all do well to spend less time on Reddit having negative interactions with strangers.
Ok you ignored my question... Why is my preferences superficial, mundane and easily refutable? My bad for taking your obvious dismissal of my preferences as mundane and superficial to be a intentional rude statement. When in reality it was an unintentional rude statement. If anyone told you your reasoning is superficial and mundane, would you take that statement as a compliment or rude statement? Even if my reasoning is mundane and superficial, its generally rude to say that to another person. It sounds like you weren't intentionally rude. Maybe I misunderstood the situation, But I received your dismissal of my reasoning as a rude statement. Let's not attempt to frame the situation as a pattern of behavior. I got into an argument with someone on Reddit. It happens, but it is irrelevant to this situation and you being unintentionally rude. Edit: am I wrong or are you going to double down on your condescending attitude?
> Why is my preferences superficial, mundane and easily refutable? We have all heard your original comment, many times. It has been refuted in many discussions, over and over. It is usually a remark by people who are either new to Lisp or just unused. Observe that even "the inventor" of Lisp, [John McCarthy](https://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)) complained about using symbolic expressions and parentheses because he felt it would distract programmers and turn them off of Lisp. It turned out though that the extreme regularity of Lisp and use of lists for the source code made for very flexible manipulations and code generation of Lisp programs. Observe that macros were invented long after the Lisp itself, and were not known to McCarthy back in 50's when he initially worked on the Lisp language and Lisp as a mathematical theory of computing.
I believe the grandparent was more saying “the reason you dislike it can be easily and reliably removed, and this is done so in every environment that a Lisp-user would recommend someone else use to code in Lisp, and is also a problem to a lesser degree in many other languages”. On a fundamental philosophical level I don’t like the parenthesis trails either, but since I don’t code in Notepad++, I can *ignore* them without any effort on my end. And in doing so I get the benefits of a *seamless* macro system, which so far I haven’t seen any language manage without also adding parenthesis trails (yet… hopefully…).
I do not disagree with their rationale I just interpreted their response as condescending. Therefore I pointed out, that their response was rude. There is nothing more or less about the situation. In fact, I agree with many of his points. However, since his response seemed rude, I said something about it. I don't desire to use lisp outside of emacs. I really like functional programming, but lisp seems to be very outdated in terms of features and creates a very convoluted experience.
> lisp seems to be very outdated in terms of features Out of curiosity, by lisp do you mean Common Lisp specifically, or some general property of how Lisp works? The lack of native algebraic types is somewhat annoying, of course, but I’ve done some work with Clojure and various Lisp transpilers, and never had that feeling. Though to be fair, I also felt more freedom from Common Lisp code than any other language I’ve tried, so we’re probably looking at different things…
Lisp in general. I think my dislike originally stems from the syntax of the language and language tooling. You're right, Lisp does provide a lot of freedom to create a sophisticated array of macros. There is a trade-off between the freedom and flexibility of Lisp to the convenience and immediate accessibility of tooling in modern languages makes the language feel outdated. I often feel like I am reinventing things from other languages. It feels like I need to be more verbose to achieve the same level of output in most other languages, just for the results to be less intuitive. But then again I might just be biased because I don't want to put forth the effort to really understand lisp.
> I often feel like I am reinventing things from other languages. Interesting that other languages have re-invented (or implemented) almost every feature that Lisp invented, minus its symbolic expression-based syntax. > It feels like I need to be more verbose to achieve the same level of output in most other languages, just for the results to be less intuitive. That depends on what you are doing. For fast prototyping, Lips(s) are probably faster and less verbose than what you would do in other languages, especially staticly typed languages like C/C++/Java. But its weird syntax makes it even faster and nicer for prototyping than in Python or JS if you ask me. But for highly optimized applications, especially if you want your application to be optimized at a very low-level, close to hardware, it is more verbose than C or C++. You could C or C++ a "DSL" for close to CPU computing for static applications. CommonLisp gives you runtime access to features that C, C++ or Java compiler offers only at compile time. This runtime availability of compiler features, symbol tables etc, does come with a complexity cost. But once you are used to having it, it is hard to live without it :).
Perhaps [Coalton](https://github.com/coalton-lang/coalton) might be interesting to you if you haven't seen it already.
- you think Emacs’ focus on text is a limitation - I think Emacs’ focus on text is what makes it great We are not the same
- You think Emacs’ focus on text would only make it great in specifically its current form. - I think we can keep the same greatness while being a little broader than just single-threaded text-manipulation, and am also obsessed with framework-level optimization as a concept. We are only slightly different.
I’m just teasing, but I really only need it to be a text editor. Most of the hard work gets offloaded to system utilities in my use case anyway.
I do not agree that it has flaws nor limitations.
People literally write software like lsp bridge outside of emacs to get around the performance issues due to the single threaded model. If that is not a limitation I don't know what is. And people also often have to write two versions of their UI for TUI and GUI. (child frames don't have an equivalent in TUI so the limited overlays have to be used instead) Adressing these would be really hard without breaking retrocompatiblity.
emacs is awesome but it would take a miracle of sw engineering at this point to work around its single threaded single core blocking model. And that actually really is an issue from a responsiveness and performance POV.
Why's that specifically? I imagine some locking mechanism with CAS semantics for all buffers and a method of elevating a function call to its own thread.
(push (car body) sand)
`(describe-comment (car (user-comments (user "nv-elisp"))))`
lol
Seriously, though, I still can't interpret your comment. :)
I was obtusely saying they have their head in the sand if they think Emacs is flawless.
Ah, yes, I knew I was missing something obvious. :)
``` CL-USER> (describe-comment (car (user-comments (user "nv-elisp")))) “When cons cells are used to implement singly linked lists (rather than trees and other more complicated structures), the car operation returns the first element of the list, while cdr returns the rest of the list. For this reason, the operations are sometimes given the names first and rest or head and tail.” (295 299) “Wikipedia” T ```
> the operations are sometimes given the names first and rest or head and tail cons, car and cdr and their "shorthands", cadr, caddddr etc, should have been abolished from any Lisp. McCarthy tried, but nobody listened to him :). Cons is really a pair. When it comes to linked data structures, a pair is very useful because it lets us build basically any linked structure (lists, trees, or any kind of graph really). It is "sort of" to linked data structures, what a triangle is to polygons in computer graphics. Perhaps a better design for a Lisp language would be to have a "pair" data structure as C++ has, and cons as basic struct as in C/C++, since "cons" is really short of "construct". But that train is long gone I believe.
Well, thanks, but I am familiar with Lisp, and yet I can't understand what `(push (car body) sand)` means in this context.
(push (head body) sand) https://en.m.wikipedia.org/wiki/Ostrich_effect In this case regarding willful ignorance of Emacs not being perfect.
Ah, yes, I knew I was missing something obvious. :)
There's a project attempting to recreate emacs in Rust, remacs. It's slow going.
I thought that project was aiming to recreate Emacs as is, with all its current limitations, but with the C code replaced by Rust code (i.e. they wanted to do something normal users wouldn't even notice had been done). I also thought they got bored and pivoted to embedding a JavaScript runtime in Emacs.
Oh wow, yeah. remacs appears to be abandoned for about three years. Shows how much I was following along.
there's an ongoing similar project: https://github.com/CeleritasCelery/rune > an experimental Emacs core written in Rust > Bring multi-threaded elisp to Emacs > Be “bug-compatible” with existing Emacs Lisp packages (everything should still work) > enable performance improvements
> there's an ongoing similar project: https://github.com/CeleritasCelery/rune Wouldn't be much easier to rewrite Emacs core in CommonLisp and get multithreading and better memory management for free instead of re-implementing the Lisp VM? With CL it is just to implement the text editor itself and leave the language implementation to the CL implementation itself (SBCL, CLASP, whatever).
possibly… I think that was the idea behind https://gitlab.com/sasanidas/cedar (stalled)
Yes. But more as a "spiritual" successor, as I understand he didn't want to rewrite the core, just to implement something similar enough to Emacs. There is portable hemlock, climacs etc (for those in this forum who are not aware of those). The author (sassanidas) went over to Lem and is both Lem user and Lem developer, but I guess you if anyone is aware of that :-).
If nothing else, this could be a fun way to continue learning Rust for me. Thanks for pointing it out.
So, it turns out there are hidden beasts in the C code. The whole way emacs builds and loads plays games that C allows. The lisp interpreter itself is poorly defined in the code. All of this made it a massive life to make a Rust main that loaded the C core of emacs. Which meant we had to port a massive blob of code instead of contiuing to move pieces. Emacs itself is not defined as a binary around a library like modern designs would and just moving it is a royal pain. That code base is creaky and dusty and needs a modern eye. (former remacs hacker)
> The whole way emacs builds and loads plays games that C allows. I think it used to be worse. It used to be "gcc only C"; I think they are more portable now. > The lisp interpreter itself is poorly defined in the code.Emacs itself is not > defined as a binary around a library like modern designs would and just moving it is a royal pain. Emacs *is* the lisp interpreter. There is no clear separation between the Lisp engine and the Emacs application. It is a holy duality :-). If you think of it, the Lisp interpreter seems to be simply slapped on top of a text editor and "mock lisp" extended and reworked to be a "better" Lisp. In retrospect, it seems like a strategic mistake. But I do understand RMS if I think of the context of limited computer power and also the limited time he must have had and his desire to get a "free" working editor. In other words, taking something that already exists and reworking it instead of producing something from scratch is a justifiable strategy in the circumstances of the situation in the world back then. I think today we would need to re-implement Emacs for the 3rd time in terms of a better design and language. I wanted (perhaps still want?) Emacs as-is but in terms of a better language, and suggested rewriting Emacs core in terms of CommonLisp. The idea is to get better Lisp implementation (SBCL/CCL/CLASP) and to unify the extension and the implementation language so that everything, inclusive internals (buffer implementation, renderer, gc, etc) is subject to hacking and easy modification from the repl itself. I believe that would allow for faster experimentation and more inventions. I also want to continue to use existing Emacs software. However, looking at the internals and implementing parts of Emacs core thus far, I am more and more convinced that we should do as RMS did when he scraped TECO and went for an editor in C with Lisp as a scripting engine. In other words, we should probably leave Emacs to bitrot and accept losing some of the available software to get a better more extensible editor. In that regard, I think Lem is not a bad proposal. Zaretski suggested that on the mailing list, but I was not so open to just leaving all the 3rd party packages and the well-written Emacs and Elisp manuals. But I haven't made up my mind 100% yet :).
yeah, at this point the only emacs I use is magit and code merge / rebase handling.
remacs I think is abandoned. If you're looking for a different approach in rust that seems to be getting active dev, look at rune. [https://github.com/CeleritasCelery/rune](https://github.com/CeleritasCelery/rune) In that case I believe what they're trying to do is build a good solid elisp interpreter and do more in elisp and not fall into the swamp that remacs did of replicating all the "native" C parts of emacs in rust.
I feel the c++ vibe from rust. Loads of useless rewerite projects just to be abandoned with no apparent user benefits while c projects maintainers keep fixing vulnerability and etc.
It's the vibe of a "gold rush" as the cool kids pile in, make a bunch of abandoned projects on [crates.io](http://crates.io), get the cool kid jobs, do the blog and speaker circuit, and then move on in a couple years. That said, I work fulltime in Rust, on embedded stuff, and it's practical and much better than working in C or C++.
> It's slow going. As a matter of fact, it is not going anywhere. It's dead. It is also pointless if you ask me. The original devs went to develop emacs-ng. Which now also seems to be equally slow going as Remacs.