
A community-driven port of Emacs to Rust - dangom
https://github.com/remacs/remacs
======
melling
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](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.

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

~~~
sjm-yc-acct
There have been some efforts like this (etc.) for Emacs on CL:

[https://common-lisp.net/project/phemlock/](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.

~~~
rjsw
Hemlock was written as part of CMUCL and is still supplied with it. The
portable version is also used as the editor in Clozure CL.

What didn't work for you ?

~~~
sjm-yc-acct
I tried Portable Hemlock from Quicklisp, and IIRC it would not install from
the repos.

On Clozure, the IDE with Hemlock only runs on OS X--I use Linux.

The one in CMUCL might work, but I haven't tried it because they only have 32
bit support for x86.

I wasn't trying to be dismissive--I would really like to run Emacs on CL!

~~~
rjsw
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.

------
girzel
> 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!

~~~
smt88
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
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.

~~~
dmitriid
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...](https://m.facebook.com/notes/daniel-colascione/buttery-smooth-
emacs/10155313440066102/)

~~~
TeMPOraL
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.

~~~
dmitriid
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?

~~~
TeMPOraL
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.

~~~
bitwize
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.

~~~
Tcepsa
"Now that I've SSH'ed into this system I sure wish I couldn't use Emacs!"

\--Nobody, ever

(My point being that I think abandoning the terminal would be a huge loss to
many people and therefore a poor decision)

~~~
TheCoelacanth
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.

[1]
[http://www.gnu.org/software/emacs/manual/html_node/emacs/Rem...](http://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-
Files.html)

~~~
Tcepsa
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.

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

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

~~~
qubex
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_.

------
piinbinary
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!

~~~
rcthompson
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?

~~~
jaccarmac
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.

~~~
rcthompson
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?

~~~
jaccarmac
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.

------
aasasd
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...](https://github.com/remacs/remacs/blob/master/README.md#porting-
elisp-primitive-functions)

~~~
brians
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?

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

~~~
steveklabnik
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.

------
hu3

        "Rust has a fantastic learning curve."
    

Is this some kind of typo?

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

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

~~~
smt88
> _easier to make mistakes_

That sounds like a core part of the definition of "steep learning curve"

~~~
Althorion
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.

~~~
smt88
A few points on that:

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

~~~
saagarjha
> 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.

~~~
pzone
> 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.

~~~
rat9988
And thus the steep learning curve.

~~~
smt88
It doesn't make sense to assess the learning curve of a language when you're
also intermixing learning to code...

It's like saying a plane is "harder to learn to fly than other planes" just
because a beginner can't learn to fly it quickly.

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

~~~
komali2
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.

~~~
rkangel
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.

~~~
komali2
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?

~~~
ryanolsonx
Yes, please.

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

------
lprd
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 :)

~~~
rgoulter
> 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/](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](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....](https://github.com/raxod502/straight.el/blob/develop/README.md)

~~~
lprd
Thanks for the recommendations :)

------
euske
Does it have unexec?

cf.
[http://emacshorrors.com/posts/unexecute.html](http://emacshorrors.com/posts/unexecute.html)

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

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

~~~
geofft
Why doesn't that affect the initial dump/unexec?

(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?)

~~~
tedunangst
Oh, it does. Sorry, I missed the point about the double dump. No clue about
that. I'm happy not knowing.

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

------
pzone
Great to see this project still going strong!

------
chalst
How does compile time compare for GNU Emacs vs remacs?

------
xvilka
Hopefully one day NeoVim will follow their example.

