A community-driven port of Emacs to Rust

https://github.com/remacs/remacs

by dangom • 7 years ago

230 143 7 years ago

github.com

purplezooey• 7 years ago

Anybody else remember when it was Eight Megs and Constantly Swapping... good times..

pmiller2• 7 years ago

Nice operating system, but it really needs a good editor, amirite? ;)

In all seriousness, see https://news.ycombinator.com/item?id=14826070 and http://wiki.c2.com/?EmacsAsOperatingSystem

TeMPOraL7• 7 years ago

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.

komali25• 7 years ago

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.

mrob• 7 years ago

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.

saghm• 7 years ago

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).

taude• 7 years ago

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.

See more on the EmacsWiki page [1]

[1] https://www.emacswiki.org/emacs/EmacsClient

pmontra• 7 years ago

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.

[1] https://www.emacswiki.org/emacs/EmacsClient

jeofken• 7 years ago

In my experience this comes from fancy plugins that do work. ELisp sadly lacks parallelism. Emacs was for me an acquired taste

agumonkey2• 7 years ago

scrolling and mouse is probably not important in that culture; that said .. text input delay is super sad

throwaway4272• 7 years ago

Are you using a prelude like Prelude, Doom or Spacemacs?

rkangel• 7 years ago

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.

m4636• 7 years ago

maybe that should be: Exa Megs And Constantly Swapping

or Escape Meta Alt Control Shift

NinoScript• 7 years ago

What a nice job they’re doing. I wish them luck

hu32• 7 years ago

    "Rust has a fantastic learning curve."

Is this some kind of typo?

justinpombrio• 7 years ago

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.

wwright• 7 years ago

Much better than C++’s “climbing the stairs to Moria”

gpm5• 7 years ago

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").

hu32• 7 years ago

Easier than C/C++ doesn't mean much and certainly doesn't grant a language "fantastic learning curve" status.

saagarjha3• 7 years ago

C isn't really that complicated; it just makes it a lot easier to make mistakes.

geofft3• 7 years ago

"A minute to learn... a lifetime to master."

opan• 7 years ago

It might be an effort to use the more correct meaning, in that a steep learning curve means learning ramps up very fast.

melling• 7 years ago

Much of Emacs is written in its own version of Lisp. There has been some effort to use Scheme, using GNU Guile

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.

cnasc• 7 years ago

Minor correction: guile Emacs doesn’t replace Emacs lisp with scheme. It just uses guile as a backend for Emacs lisp.

microcolonel2• 7 years ago

Minor addition, Guile Emacs does allow you to use Scheme in addition to elisp, AFAIK.

girzel2• 7 years ago

What would make most sense is just to have it Lisp all the way down. SBCL, top to bottom!

z3phyr• 7 years ago

That should be the goal. To please rms, one can always use a GPL language implementation too..

sjm-yc-acct3• 7 years ago

There have been some efforts like this (etc.) for Emacs on CL:

https://common-lisp.net/project/phemlock/

I have never been able to get one to work, though.

MIT Scheme also has an Emacs 18 compatible editor called edwin written in Scheme.

na853• 7 years ago

Is there a serious project working on this? I'd contribute to it.

Ericson2314• 7 years ago

Yeah I feel like guile-emacs, then rust-guile, is the proper migration path.

euske• 7 years ago

Does it have unexec?

cf. http://emacshorrors.com/posts/unexecute.html

geofft3• 7 years ago

Wait, what's the reason for preventing a dumped and reloaded emacs from being re-dumped?

tedunangst3• 7 years ago

As linked, it's mostly incompatible with ASLR. If you were to undump to a different address, all the pointers break.

lokedhs• 7 years ago

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.

testcross2• 7 years ago

If I remember correctly, the same kind of hack is used by atom to allow fast startup.

gpm5• 7 years ago

Assuming this issue is up to date - yes, but it's on the todo list to remove:

https://github.com/remacs/remacs/issues/105

xvilka• 7 years ago

Hopefully one day NeoVim will follow their example.

aasasd2• 7 years ago

The “Porting Elisp primitive functions” section in the readme is impressive for a passerby. Rust code looks like OOP magic instead of C's straightforward struct-juggling: https://github.com/remacs/remacs/blob/master/README.md#porti...

brians• 7 years ago

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?

aasasd2• 7 years ago

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__’.

oblio• 7 years ago

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).

girzel2• 7 years ago

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!

smt884• 7 years ago

Partial/staged rewrites have become the only way to rewrite many mature projects.

Facebook (PHP/Hack), Firefox (whatever/Rust), and large web projects (JS/TypeScript) could only be rewritten piecemeal.

caymanjim• 7 years ago

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.

dmitriid5• 7 years ago

Oh. Emacs is broken. For example:

“Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit.” [1]

If this fork removes all the legacy cruft and hacks, it’s only for the better.

[1] https://m.facebook.com/notes/daniel-colascione/buttery-smoot...

tedunangst3• 7 years ago

What is it about rust that makes it impossible to pretend Xt is a text terminal?

Latteland2• 7 years ago

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.

TeMPOraL7• 7 years ago

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.

yason• 7 years ago

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.

m4636• 7 years ago

I've always thought that if emacs lisp were replaced with python, I would be very happy.

taeric2• 7 years ago

I'd wager there are a fair number of us that are quite glad not to have python as the main language.

I am curious if there are specific things about elisp that you dislike.

agentultra• 7 years ago

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.

DennisP• 7 years ago

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."

josteink• 7 years ago

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.

Athas• 7 years ago

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.

omeid2• 7 years ago

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.

piinbinary• 7 years ago

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.

Great work!

rcthompson2• 7 years ago

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?

jaccarmac2• 7 years ago

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.

adito• 7 years ago

Is it release build or debug build?

lprd3• 7 years ago

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?

Any tips or recommendations are welcome :)

midgetjones• 7 years ago

http://spacemacs.org/

zaiste• 7 years ago

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]

[1] https://github.com/hlissner/doom-emacs [2]: https://www.youtube.com/watch?v=rCMh7srOqvw

lprd3• 7 years ago

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.

Thank you for the recommendations!

rgoulter• 7 years ago

Is this a good project to start with?

Probably not. You'd be better off looking at an Emacs distribution to see what's available.

Sacha Chua's Visual Guide to Emacs is excellent. http://sachachua.com/blog/series/a-visual-guide-to-emacs/

There's also an awesome list for it. https://github.com/emacs-tw/awesome-emacs

I'd suggest looking at Magit or Org-Mode. These are often cited as "killer features"/"gateway drugs" for Emacs.

... what's the equivalent of vim-plug ...

I liked the discussion on straight.el's readme: https://github.com/raxod502/straight.el/blob/develop/README....

lprd3• 7 years ago

Thanks for the recommendations :)

pzone2• 7 years ago

Great to see this project still going strong!

chalst• 7 years ago

How does compile time compare for GNU Emacs vs remacs?

qubex2• 7 years ago

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.

ses1984• 7 years ago

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.

alexozer• 7 years ago

I've taken "porting" to equally mean either. Besides, porting to another language is in a good sense "porting to another platform".

qubex2• 7 years ago

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.

A community-driven port of Emacs to Rust

Related Stories