CMUCL will run on 64-bit Linux, that is how it is built. There would obviously be a smaller limit to file sizes than if Hemlock were running in a 64-bit Lisp.
I would also be willing to donate although the project would not be very viable. It's a lot of work, Common Lisp is not a currently fashionable language like Rust, it would not have support from RMS.
It would probably die out soon. XEmacs is one of the longest living Emacs forks and even that is dead(ish).
Minor addition, Guile Emacs is a dead project since not a single person from the core Emacs development group cares enough about it to work on it.
Emacs Lisp is getting better all the time feature-wise, is portable to all main operating systems (good luck running Guile on Windows and macOS without issues) has enormous user base and is rock solid.
> Code written in Rust easily interoperates with C. This means we can port to Rust incrementally, and having a working Emacs at each step of the process.
This seems really important, and crucial to preventing the project from getting stuck at the pie-in-the-sky stage. Start it going, and dog-food it as it comes!
Why? Other than an academic exercise, what's the point? One could make plenty of arguments for why Rust is a better language than C, but...if it ain't broke, etc. This seems like an enormous exercise with little if any payoff, and unless the core Emacs community decides to jump on board, it's just a pointless fracturing.
I don't have an opinion on the way it does that, but the fact that it does think/work it's a text program is actually a feature, not a bug. Something like 99% of built-in features and 95% of features added by plugins work identically in terminal frames over SSH.
I fear if Emacs was remade with graphics at the forefront and text as a secondary concern, we'd lose a lot of interoperability this "text program" thinking brings to the table. Being able to work with an UI in a way you would with text files - jumping, copy-pasting, editing the UI itself, all with the exact same shortcuts and conveniences you use for programming - is incredibly powerful and something not really replicated elsewhere. I mean, number one complaint against TUIs and GUIs is that the data is locked inside, and you can't easily take it out and send elsewhere. With Emacs UIs, it's not true - if need be, you can select, copy and paste the whole thing, UI included, and it looks good in a text file and can be operated on programmatically.
--
Further improving performance of elisp and enabling true multithreading/async: that would be a huge breath of fresh air in Emacs.
Which part of ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering” is a feature?
That is an implementation detail. The feature is "witness the firepower of this fully armed and operational battle station/editor, of which 99% works and looks the same both in GUI and terminal, at zero extra effort from feature developers". Whether or not the implementation is truly necessary to achieve the feature, that I don't know.
It’s not an implementation detail. It’s decades of technical debt, and it’s very strange to see it defended.
When a simple task of making a program not flicker (a solved, well understood and fairly trivial problem) requires quite a sizable effort, it’s no longer just an “implementation detail”.
LOL at people decrying the bloat and inefficiency of Electron apps and calling this a perfect program with just implementation details:
— start quote —
GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.
Don't focus in the mechanism. People aren't defending the mechanism. They are defending the benefit, which is currently a side effect of the mechanism: feature invariance with respect to render target, whether GUI or terminal.
My own use is about 50:50 of each. Only a few things don't work the same way in the terminal and that's extremely valuable.
Let me rephrase my thoughts. I'm not defending this cruft per se. I'll be glad to see it gone iff it doesn't affect the text-orientedness of Emacs UI, as this specific style of text UI is a feature.
No, it's not really. In order to get window toolkit independence, and terminal- or GUI-independence, Emacs pretty much has to pretend to be a deprecated system pretending to be an even more deprecated system pretending to be an obsolete system.
It needs a rewrite with modern tools and frameworks. And it needs to abandon the terminal (the obsolete system) altogether.
Up until about a year ago, I used emacs exclusively from a terminal. The only reason I switched was because I usually have a number of tmux sessions open (with multiple “windows” in each one), and I kept losing emacs :). Having it in its own window made it easier to jump back to.
I’ll still often SSH home from a Chromebook and edit remotely. The fact that everything still works exactly the same is awesome. If you want to make an editor that doesn’t support that, you’re welcome to, but it won’t become my editor :)
Why would you SSH into a system and use Emacs there when you can just have Emacs handle SSH for you[1]? What do you gain by running the whole UI over SSH when you can just send the reads and writes instead? Especially since Emacs might not even be installed on the remote machine.
Tried again just now to use Remote File access from my Windows desktop to my Linux (Ubuntu) cloud VM. I'm using Helm, and if I do C-x C-f (helm-find-file) and then type /ssh:me@remote: it opens a new buffer called "C:/ssh:me@remote:".
There was a suggestion on a Reddit thread to use Dired instead: C-x d /ssh:me@remote: which I also tried. This appeared to get further but subsequently failed with the error "ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory".
So I figured I'd try launching Emacs from within a Git Bash prompt to see whether that would provide the extra commands it was looking for, and it failed to locate my dotfiles (must have a different $HOME in that context...). However, when I attempted to open a remote file it did actually prompt me for a password! ...but then the LDAP authentication failed after timing out.
I'm out of gumption for now, but hopefully that helps to illustrate why I still want to be able to SSH into a machine and launch Emacs from the terminal.
Because I can. I've tried TRAMP a few different times in the past and, for whatever reason, I bounced off of it pretty hard every time. They were long enough ago that I can't remember what went wrong, but I have a pretty deep and lingering feeling of frustration whenever I contemplate giving it another go. Compared to the effort needed for me to shell into the remote machine and start Emacs there, I just haven't bothered.
I think it's great that the capability exists and that others find value in it; it's just not for me (or maybe vice versa). One of the great things about Emacs is that it can still work for both sets of people: folks who like TRAMP and folks who like to SSH in and run it locally.
I routinely SSH to my home desktop, where an instance of Emacs is always running, to work from e.g. a bus, or a queue to the doctors', etc. Since I'm normally working on my desktop, which runs GUI Emacs, when I SSH in I have all my files and processes opened as I left them, and I can pick up working via interface that's 99% indistinguishable, sans the smaller screen size.
It's actually important that emacs is a text program and also has a gui version. All the time I use a program on the command line that needs me to edit something, so it pops up a textmode (vt100 ui forever) emacs that I can edit a file in. Sometimes in other contexts this can happen where it's an xwindows gui. When I'm on a windows machine I can do either also.
Ok. Let’s say we remove this: ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering”.
How will it make Emacs not a text program with a GUI component?
I don't care about the implementation (if elisp works the same and the experience is the same), it just needs to be a text mode only editor and a gui editor.
This fork aims to replace the C parts with Rust. I didn't read they intend to redesign Emacs itself. Emacs is a programming environment so changing such fundamentals would make it a different editor. There are existing apps and libraries that depend on the way Emacs works now.
Wow. If any program had ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering”, HN would crucify it.
The page mentions some reasons: "Forking is a longstanding tradition in the Emacs community...By forking, we can explore new development approaches. We can use a pull request workflow with integrated CI. We can drop legacy platforms and compilers."
This was my first thought. As a user of remacs I'll never notice any tangible difference to emacs if the remacs folks are doing their job well. At least not for a few more years perhaps.
This may have a payoff for maintainers. If they can convince enough of the core developers to join them or build a large enough community. If their theory is right it's easier to develop and maintain Rust code than C code and if it makes more people happy we may see remacs able to forge ahead with more/better features, faster than upstream emacs.
But from my experience with projects like this it's going to take them a long time to catch up and then someone down the line is going to have to make the decision about whether to break from upstream or to follow it.
I do not want to throw away emacs, I just think a python port would be enjoyable, for me.
I find python very expressive.
When I work in elisp, I seem to find it cumbersome to do many of the mundane things, like using a local variable, and if/then/else with multiple statments, loops (continue? break?), oo stuff, etc.
To be clear, yes, I know how to do these things, and I've written elisp for many years. Everything I can do in python, I can also do in lisp. It's just that python seems to read and write easily for me.
> When I work in elisp, I seem to find it cumbersome to do many of the mundane things, like using a local variable, and if/then/else with multiple statments, loops (continue? break?), oo stuff, etc.
That's, frankly, because you don't know the language. It doesn't take much to learn it, though, and lisps tend to be similar, so you'll learn a bit of CL and Clojure at the same time :). I would similarly struggle with Python, for a short while at least, if you sat me in front of PythonMacs.
... which already looks like Python code, except supports arbitrary number of branches (cond is if/else if/else).
Lisp has a slightly different style of writing than in Python, which yields comparably tight and readable code... and then you can use macros, which Python doesn't have, dynamic binding, which Python doesn't have either (and while a pain most of the time, they're a life-saver in some cases, and the type of code you write for a text editor has lots of those).
Elisp isn't a bad language. It can handle all the stuff Python does and then some. I get the preference for syntax you're already familiar with, but individually, it might be worth it to just bite the bullet and learn some new syntax. If that's your first exposure to Lisp, then it'll be especially rewarding, for all the "code is data is code" and "code that writes code that writes code" enlightenment that comes with it.
You are correct when you say "Lisp has a slightly different style of writing than in Python"
Maybe I was trying too hard to use "if" as common ground in my contrived example. I generally use if for simple conditions and cond for multiple conditions (python would use elif, and has no case statement).
But in the same vein, your example doesn't look like python, at all :)
The point of my comment is not to put down elisp, but instead to say that the translation of ideas in my head to working code seems to go smoother for me using python than lisp, both reading and writing.
Your example is not necessarily contrived, but it is not very representative, either. Throw in a couple of proper lambdas in there, and suddenly python won't look as nice.
Fair, "different strokes" and all of that. I'm not going to try and argue you out of the opinion, since, well, we are free to disagree. :)
Not surprisingly, I have not had to maintain large blocks of elisp. I have had to deal with chunks of python from folks, and I just can't find it a language that is pleasant. Certainly not stable. Though, I am probably tainted in the whole python 3 debacle.
When did the word ‘porting’ lose its notion of reusing similar code on another architecture and become synonymous with “rewriting in another language”?
This isn't a port at all. It represents a more major bifurcation than does even a traditional ‘fork’. It's very imprecise use of language.
Can't port be used to mean both changing platforms or languages?
You have a project. You want to change one thing about it, and as little else as possible. If you're porting to platforms maybe that's pretty easy these days, porting to languages is harder and you'll have to make more incidental changes along the way.
That’s why I was very specific in mentioning ‘architecture’ in my original question. What you’re mentioning is more akin to the definition of a platform.
I just downloaded and built that. I was presently surprised to find that it "just worked." It picked up my .emacs, my color theme, my extensions and all the associated data. The only observable difference between it and real emacs was that it ran significantly slower. Presumably that will go away with time.
I'm surprised there would be a significant speed difference. My understanding is that they're mostly rewriting the C parts in Rust, which shouldn't change the speed much. Maybe byte-compilation is disabled for remacs or something? Or perhaps some debug options are enabled by default?
Byte-compilation isn't disabled. The slowness is due to a couple things. First is the bindgen layer between Rust and C slowing down certain calls. Porting so far has been wide rather than deep, so Rust code ends up having to call C sooner rather than later. In addition most of the ported functions have been rewritten in a pretty naive style that doesn't take full advantage of Rust. There was some discussion in Gitter or issues about this a couple weeks back, but I cannot seem to find it tonight. Apologies.
This is something I've been wondering about. Porting from C to Rust one function at a time sounds nice, but presumably the end result would be a Rust program with an identical program structure to the original C, which as a result doesn't take very much advantage of Rust's features. Is the goal to port all the way to Rust and then refactor to actually make the code Rust-ish?
Yep! Even now it's not quite as bad as identical program structure. I mean, the high-level is fairly similar, but even now individual functions can look significantly different.
Emacs' C is already largely written in a high-level, macro-rich style to deal with Lisp objects (tagged pointers). So Rust already gives wins there w.r.t. more explicit types and From/Into impls over macros.
And over the last couple weeks there has been discussion about replacing xml.c with a native Rust backend for XML parsing.
Can you expand on that? The rust example looks like pattern matching and dispatch into a standard library. The C looks like some macros and tests, and dispatch into a standard library.
But I’m much more comfortable with ML than with C; What do you see that is magic?
Well, I'm not sure what the “y.atan2(x)” thing is reasoned to be in Rust, but it sure doesn't look like C's manual unboxing and plain function calls. Not magic, I guess―just looks pretty much like good old OOP, which I'm being told it's not.
I suppose the “Same(x)” thing caught me by surprise―dunno, though, if it's built-in magical syntax or again something OOPy: in Python, ‘Some’ would likely be a class implementing a special method ‘__match__’.
Method calls are syntax sugar in Rust; it compiles to the same code as atan2(y, x). The only difference is it will auto ref for you in the method style. You can call it either way if you prefer. Those are just regular floats, not objects.
Some is an enum constructor that’s in the prelude, so it’s just automatically imported. It’s a library type, nothing specially built into the language.
It's not OOP, it's pattern matching, which is functional more than anything.
The other thing is generics (Option<EmacsDouble>) which is not necessarily OOP either and the option type itself which is functional (https://en.wikipedia.org/wiki/Option_type).
I doubt it. Rust's learning curve is much better than C/C++ (assuming your target is "reasonably competent at writing code other people would want to use" and not "can make a linked list").
It's way easier to learn to write correct Rust code than correct C code. Correct as in not leaking memory or reading uninitialized memory or segfaulting, which probably everyone who first started writing C spent time wrestling with and learning how to use Valgrind and so on.
Yes, of course; I'm pretty much of the opinion that it's basically impossible to write correct C code because it's so easy to make mistakes in. However, it is easy to write code that generally works, more so than in Rust, which puts up abstractions designed to prevent every single kind of mistake, some of which you might not even know exist because you've just started learning programming.
Which approach is better? Not sure. But that's a different question.
I don’t know… I’d rather say that learning curve is more of a journey from ‘I can write code’ through ‘I can write code that compiles’, ‘I can write code that works’, ‘I can write code that works well’ to ‘I can write code that works well and is readable’ and certainly the first few steps are much harder in Rust than in C or even C++, so I’d call that a steeper learning curve.
One thing to note is that the claim wasn't "shallower" but "fantastic". A sufficient response to this is that it's "fantastic" because the vertical distance between "can write code that compiles and looks reasonable" to "can write code that is reasonably correct" is small. I doubt you would find many other languages where that area is so small in fact (Idris comes to mind).
I'd also argue though that while the learning curve for rust is initially steeper, it is shallower when you look at the curve up to the point where you want contributors to be. C/C++ has an insanely steep cliff to go from "can write reasonable looking code" to "can write reasonable correct code".
The first argument is in some sense better because it doesn't restrict me to talking about C/C++.
- Rust skips (or almost skips) some of those steps. If you can write code that compiles, you can also write code that works. It forces you to be very specific about your intentions, which isn't possible in language with less-thorough type systems and compile-time checks.
- I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.
> Rust skips (or almost skips) some of those steps. If you can write code that compiles, you can also write code that works. It forces you to be very specific about your intentions, which isn't possible in language with less-thorough type systems and compile-time checks.
Forcing new programmers to be specific about intentions they may not even know they are supposed to have doesn't necessarily work.
> I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.
I don't agree with your analysis of "works wells and is readable". It's not too to write C code that works well and is readable. Sure, your code might occasionally break–but the point is that it works most of the time. This isn't necessarily a good mindset to have as a software engineer, but with regards to the specific claim that Rust is easier than C: it's not, because it enforces better practices, which is mental overhead and complexity that C doesn't need to deal with.
> Forcing new programmers to be specific about intentions they may not even know they are supposed to have doesn't necessarily work.
Rust is not a good language for new programmers. Neither is C for that matter. You shouldn't start learning Rust before you have solid intuitions of programming concepts like ownership, scope and mutability.
It is also easy to make a program that compiles in C, and somewhat easy to make it work in some case from there. The real tough part is learning all the tooling required to do anything complex reliably in C.
I think it is quite easy to do simple things like opening and closing files reading writing. String manipulation and working with vectors can be similar to python at times..
The ownership concept is a bit harder to grasp, it took me maybe a day to get the initial understanding and a year to really feel comfortable in all situations.
The thing is, now that I understand it it is not only very powerful, but it allows you to think about your code differently: because of the strict ownership rules you tend to be aware at all times of the impact of the code you are looking at in any given moment. Combine this with the strong type system and you really feel in control.
When I moved from python to Rust I probably wouldn’t recommend Rust to beginners. In hindsight I am not so sure about that anymore. It is hard, but it is teaching some concepts every programmer in any language could use and it is incredibly consistent.You rarely find any weird edge cases that are the way the are because of some arbitrary decision. Most language design decisions have been extremely careful considered and you can feel that. This is contrary to many traditional beginner languages, whkch are often filled to the brim with weird edge cases.
The cargo environment is incredible.I wish I had something like this for python
I feel similarly, I'm not sure it would be success, but I think it would have a good chance.
I'm very tempted to try and design a "learn programming via rust" course and then find some guinea pigs (err ... students) to see how it works. If I had infinite free time I definitely would.
I learned programming mostly with processing (https://processing.org/) For beginners the huge benefits would be:
- instant visual feedback: Loops make much more sense when you can see them
- easy to get running (I’d argue rust is the same)
- Limited enough to learn basic concepts and not get overwelmed
The hardes thing about teaching any traditional language is probably explaining why it is mostly a command line/terminal thing without huge efforts.
It's very smooth after you climb the initial brick wall :-).
EDIT: Let me say something of substance. There's a steep learning curve for getting past Rust's borrow checker. But the language documentation and compiler error messages are the best I've seen of any language. I wouldn't say that Rust is an easy language to pick up, but it's surprisingly easy to learn for what it does.
I'm playing around with emacs, slowly trying to get it to feature parity with vscode to see if I could one day use it as a main editor. One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all, the time it takes to get from launch to accepting commands is way higher than vscode, scrolling with the mousewheel is gross, and worst of all, there's input delay on text input. Maybe it's the chrome effect - vscode seems faster because it's hogging my ram? I wish I had checked the memory usage before posting this.
It's a shame because I like the idea of emacs, but I simply can't seem to get it anywhere near as good as vscode.
I came the other way very recently (emacs to VSCode). It wasn't performance that was the issue, it was the level of effort required to get the same level of experience between VSCode and Emacs.
I have used Emacs for about 10 years, and have days upon days of effort invested in my emacs config. Despite this, it took 5 minutes of setup to get a significantly superior setup for the languages I'm using currently (Elixir, Rust, ReasonML, Python). I had more features available (e.g. better highlighting and listing of current errors), and the core ones like auto-complete and go-to-definition worked much more reliably. It took an hour of tweaking some keybindings and settings to remove some UI cruft and navigate between splits and I have something that performs at least as well as Emacs in every regard. It's only been a couple of weeks, but it's promising so far.
Nice to hear you've managed to get stuff you liked in emacs working in vscode, that's something I'm constantly tweaking as well. Mind sharing your vscode keybindings/settings.json?
This doesn't seem right. I'm running it on a five year old computer and it feels way snappier than VSCode. I run on both Windows and OS X and don't have performance issues.
It could be some a rogue package or something with a wonky config?
Also, you should start it with emacsclient (I alias it to a shortcut). Run the emacs server/daemon in the background, and everytime you type your alias with a file name, it'll open almost instantly.
I went through some stack overflow again and a lot of people are suggesting it could be linum-mode? I have it on everywhere cause I like being able to jump to a line number. But I have emacs 26 which is supposed to have fast, C written linum mode.
The modern, Emacs 26+ mode is: display-line-numbers-mode. This (put in config) will enable it for you globally:
(global-display-line-numbers-mode 1)
linum mode (and the faster contrib, nlinum mode) were used prior to Emacs 26, and sometimes had some performance issues in large files.
Also, all of those are for displaying line numbers on the left margin. Jumping to a particular line in code works always.
(And if you want to go totally oldschool, use column-number-mode and line-number-mode to see the column and line numbers of your current position displayed in the modeline. Or (shameless plug) install nyan-mode ;).)
"M-x goto-line which is bound to M-g g, or M-g M-g."
Naming the function "goto-line" in full can make it easier to remember for a reader, providing a fallback for when the key-chord isn't part of muscle-memory yet, and provides an easy way to look up the binding in emacs itself:
But how would I know the line number of what I wanna jump to without display line number on? I.e I'm on line 100, want to pop down to a function on 202 (a line I haven't visited yet).
Along with interactive search (C-s forwards, C-r backwards), you can jump to the definition of a symbol (including a function) with ‘M-.’. These would be the idiomatic ways of moving around. There are multiple ways of maintaining up-to-date symbols depending on your context, which you can look up in the documentation for ‘M-.’.
Some macros can be very slow but something simple should never be noticeably slower than in any other editor. But what does a macro do to scroll a single line?
About smoothness, maybe, but I don't have any editor to compare it with now, except vim. I remember that NetBeans, Eclipse and some JetBrains editor where not any different on my hardware last time I had to use them.
Startup time, it's a non issue for me because I start it up after boot and keep it running. I load files into it with emacsclient [1] and save the desktop to a file to pick up from where I was after a boot. Surely, with hundreds of buffers it takes a little to finish loading but I don't reboot every month.
> One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all
That's super interesting, because the main reason I don't use VSCode at all is that whenever I hold down a key, it seems like the key events happen faster than the editor can handle, and it ends up continuing moving well after I've stopped pressing it (which is most annoying when it's the delete key).
I put some serious effort into trying to use Emacs a few years ago and had the same experience. It's not so bad in the default configuration, but by the time you've installed enough LISP code to reach feature parity with modern editors it slows down annoyingly. Eclipse is noticeably faster.
You definitely had something misconfigured then...
Not saying that's your problem, emacs could do a lot more to be friendlier to newcomers. I'm just saying, don't be so quick to judge it until you've gotten with your local emacs nerd to see what's wrong with your setup.
Are you an emacs nerd willing to peek? Maybe it's just spacemacs by definition is fucky, but my machine is a beast so I feel like other people would be complaining about slow spacemacs if that were the case and I can't find much of that out there.
Yeah it's spacemacs. Any soup to nuts emacs distribution like this is going to be slow. I experience it all the time in doom. You don't have anything misconfigured.
Features like helm, ivy, projectile, etc cost. Linters and autocomplete can really make emacs jank. All this stuff is configured out the gate in these distributions.
> Nice operating system, but it really needs a good editor, amirite? ;)
You're rite :). True Emacs enlightenment comes when you realize that this is not a joke - that Emacs really is a kind of OS, and that it offers a much better experience than traditional OSes for any task that's mostly about text (whether linear or 2D). Which is quite a lot of tasks, actually.
AFAIK GNU Emacs is written using a completely 100% FOSS GPLed stack, preferring GNU components over others when alternatives exist.
So how does Rust play into this? Is the Rust-stack “compatible”?
For this to succeed long term they will have to get their changes mainlined, and it would be a shame if anything as petty as licensing or political over GNU/non-GNU should stop it.
I don't think this is the objective. It would certainly never happen - for political reasons, there is no way Emacs would ever depend on a non-GNU compiler.
> as petty as licensing or political over GNU/non-GNU should stop it
For any substantial project, licensing is a matter of make it or break, for philosophical and economic reasons. If you think one's philosophy of life or economic approach is pity, you're out of your damn mind.
I'm a vim user but I would really love to take a peek into the emacs realm (also interested in Rust development). Is this a good project to start with? Also, I use vim-plug to manage my plugins, is there an equivalent in the emacs world?
There is also Doom Emacs [1] which provides Vim experience out-of-the-box. It also comes with a fantastic theme.
I've been using Vi/Vim for more than two decades now. Doom made me feel at home. I used to envy Emacs all these nice features such as Org Mode, Magit and even the ability to use Lisp to configure your environment. Now it's the best of both worlds.
I just wish Emacs' onboarding process / cohesiveness was as good as in VS Code. It would be a dream come true. ;)
PS. I've recorded a short Doom screencast for newcomers [2]
This looks really interesting. How does it compare to something like spacemacs? I'm confused by all the different "flavors" of emacs. I think I would prefer something like doom to spacemacs since, from the looks of it, you stay inside the terminal. If I want a gui, I'll just use VS Code.
Emacs has finally gotten rid of unexec. It's replaced by the portable dumper which which essentially serialised the state of the application using its own format.
(Or in other words - if the answer is that ASLR is turned off for either initial exec or reexec, why not keep it turned off so that a third exec works?)
https://www.emacswiki.org/emacs/GuileEmacs
Emacs with a better Lisp option would be a big improvement. With a faster Lisp, perhaps less of Emacs would need to be written in C/Rust.