
Remacs – A community-driven port of Emacs to Rust - sndean
https://github.com/Wilfred/remacs
======
mschaef
This looks like a lot of work for what amounts to very little end-user
benefit.

Honestly, I'd rather see more progress on the Emacs Lisp/Guile migration than
on a putative C/Rust migration. At least with the Guile switch, it's something
that will have an obvious (and probably positive) impact on the people that
use the editor.

~~~
dbaupp
It seems a bit rude to complain about volunteers for doing something they want
to do rather than what you want them to do.

I imagine that this, for the most part, isn't even opportunity cost: the
people working on it probably wouldn't be contributing to full Emacs (or the
Guile effort) anyway. _And_ this sort of effort seems like it could be an on-
boarding experience to improving the original code base, e.g. in the process
of porting, someone notices a bug and so submits a patch upstream, or maybe
the repeated exposure to a variety of the internal components gives someone
enough familiarity with them to contribute if this project peters out.

~~~
achikin
This is one of the main issues of open source - people tend to work on what
seems fun/interesting/rewarding. As a result a lot of people work on different
implementations of the same things instead of coming up with one good solution
and creating new things on top of it.

Moreover, while some people work on the endless clones of the same thing, the
completely different set of contributors is wasting their time cleaning up /
fixing bugs / writing documentation for those endless clones.

Examples are: a lot of Linux distros, which are almost the same but not one of
them comes even close to MacOSX as a desktop OS. Javascript frameworks which
solve the same rendering problem again and again.

On the other side, there is Spacemacs, which tries to provide solid modern
IDE-like experience on top of existing Emacs solution, leaving low-level stuff
to emacs core team.

~~~
pera
This is not something intrinsic in the nature of open source, but in how
humans like to spend their free time. Of course we could all be much more
_efficient_ if we all had the same goals, but that's not how things work in a
free society.

~~~
achikin
As a society we win big by collaboration in the first place. Not by diversity,
disagreeing with other people and doing everything "your way". Imagine 1000
independent people trying to build Boeing in an opensource way.

~~~
always_good
What a bizarre argument. 1,000+ independent people trying their hand in the
business world is ultimately how a Boeing is conceived. That is the extreme
diversity that benefits society.

~~~
achikin
I didn't quite get it. Do you mean that Boeing is built by independent people
who work on whatever they want to and then a plane is assembled of that
independently built parts and no one takes the responsibility of the result?
Or you mean that Boeing is subcontracting particular work to independent firms
serving as architect, coordinator, and sponsor and taking all the
responsibility?

~~~
ZenoArrow
> "Do you mean that Boeing is built by independent people who work on whatever
> they want to and then a plane is assembled of that independently built parts
> and no one takes the responsibility of the result?"

Somewhere in the middle. If you consider the work that goes into making a
plane, you'll see quite a bit of it happens outside Boeing. To give one
example, think of the aluminium that goes into the plane. Boeing doesn't have
to mine bauxite, extract the aluminium from the bauxite, transport it to the
place where its sold, etc...

A classic example of this ground-up view was this example given by Milton
Friedman about the pencil. I don't agree with many of his views, but I think
he makes a good point in this video:

[https://www.youtube.com/watch?v=R5Gppi-O3a8](https://www.youtube.com/watch?v=R5Gppi-O3a8)

EDIT: Turns out the source of this example may have been Leonard Read:

[https://en.wikisource.org/wiki/I,_Pencil](https://en.wikisource.org/wiki/I,_Pencil)

~~~
achikin
Great video, thank you! Yes, most of the work is done outside of Boeing, but
it is done specially for Boeing, not that people work on whatever sort of
aluminum they want but they know Boeing demand and supply them with the
particular sort. On the other side Boeing pay them money so they can proceed
to mine. This is what I mean under the collaboration.

~~~
ZenoArrow
Glad you liked the video.

Regarding...

"On the other side Boeing pay them money so they can proceed to mine."

Perhaps you know more about Boeing's business arrangements than me, but I
certainly couldn't verify that that's true. From what little I know, it's
possible Boeing's aluminium suppliers work exclusively for Boeing, but it's
also possible these same aluminium suppliers have multiple customers. The
point being, there could be people who work as part of the chain to produce
and transport the aluminium who have no idea who will eventually use it.

------
BeetleB
Not intended to be a port, but I occasionally search for an editor that is
customizable in Python to the extent Emacs is.

Leo Editor ([http://leoeditor.com](http://leoeditor.com)) fits that bill. It's
been around since the 90's (and the web page looks like it's from the 90's).
Even though it has many users, the documentation is quite poor. If I had
another life to live, I would learn it well and improve the docs - and then
port over everything I like in Emacs to it.

It is sorely in need of more tutorials. You'll find some in various people's
blog posts, but not enough. I know enough of it to know that it is very
powerful, but not enough to use it well day-to-day.

~~~
Philipp__
That looks interesting thanks for sharing. Too bad it wasn't meant to be run
on macOS.

~~~
BeetleB
>Too bad it wasn't meant to be run on macOS. ￼

What makes you say that?

￼

~~~
Philipp__
It is stated in their _install-readme_ on github.

~~~
BeetleB
Interesting - I wonder what dependency they could have that prevents its use
on MacOS. I run it on both Linux and Windows just fine. At the end of the day,
it's just a Python program.

------
kronos29296
Looks promising. First neovim and now this. Even if it doesn't replace emacs
(which it won't) if it can enrich the community and maybe bring more users
while fixing archaic code bases of hard to find errors and UBs then it is
still a win. Neovim pushed vim (Vim suddenly became more active around the
time neovim gained traction atleast according to github graphs and releases).
So I hope this project brings new life to the core C code in emacs and fixes
the problems that it never had (according to the core dev knowledge). When I
tried emacs I found it to be a bit like atom at startups. Couldn't get into
the keybindings coming from vim.

If it gets faster, I might give it a try again (in evil ofcourse, gotta have
them keys).

~~~
cies
> Even if it doesn't replace emacs (which it won't)

I dunno. First of all it wants to replace the C-bits of Emacs, not all that is
in elisp land. Second of all, why not? I do not think the goals of Remacs are
overly ambitious: port the C-platform under Emacs's elisp env to Rust. This
will probably result in a much healthier and hackable codebase for that
functionality, as it: is a more modern language, has less legacy (platforms)
to support, is fully open source (Rust) to the level RMS would approve of.

------
njharman
Makes sense. Rust is systems language and emacs is an OS replacement.

------
Myrmornis
The README doesn't say much about whether and how the rewrite would differ
from the main Emacs implementation in terms of threading architecture. A major
problem (I think this is an uncontroversial statement) with the main Emacs
implementation is that it is fairly common, in every day use, to block the
main thread responsible for accepting keyboard input and repainting the screen
etc. This (again, uncontroversial I think) is embarrassing in such an
otherwise great bit of software in 2017.

~~~
somedudetbh
IMHO, as someone who absolutely loves emacs, this is the biggest problem with
emacs.

------
flavio81
As one poster here said, "Makes sense. Rust is systems language and emacs is
an OS replacement."

If anything, it could be great if Rust is used to implement a faster Emacs
Lisp compiler/interpreter, thus preserving all of Emacs Lisp source (and
saving some implementation time.)

And make it fully multitasking so there are no more problems of key input
getting stuck because of a process.

~~~
nieve
Rejoice, if you look at the repository you'll see that's exactly what they're
doing - replacing the runtime/C underpinnings and keeping the elisp.

------
hammerandtongs
Doesn't seem to have a copyright assignment policy in place so this can't be
upstreamed as is.

[https://www.gnu.org/software/emacs/manual/html_node/emacs/Co...](https://www.gnu.org/software/emacs/manual/html_node/emacs/Copyright-
Assignment.html)

So opened -
[https://github.com/Wilfred/remacs/issues/238](https://github.com/Wilfred/remacs/issues/238)

~~~
josteink
I wish one day the FSF would actually show genuine _trust_ in their GPL and
ditch their requirement for people to provide copyright assignments.

God knows how many GPLed lines of code has _not_ been submitted back upstream
to them over this minor technicality, and that's such a shame.

I honestly think this is for the FSF to fix, not everyone else.

~~~
gnuvince
As I understand it, it's not lack of trust, but rather that if a legal dispute
occurs, it's easier if only one party is the copyright holder rather than
having to find hundreds of developers scattered around the world.

~~~
josteink
Let's say that argument is fair enough, at least in theory.

How many legal disputes have the FSF had recently, in practice, where this
turned out crucial?

More specifically: how much have they gained by this vs how many contributions
have they lost?

Until proven otherwise, I'd expect them to clearly be in the negative here.

~~~
torrent-of-ions
So you'll wait until the FSF finds it cannot defend the GPL in court and
_then_ try to get copyright assignments from thousands of programmers? That's
downright stupid.

If there was evidence that some third party could enforce GPL compliance on
behalf of the copyright holder(s) then maybe the FSF should consider relaxing
the requirements.

Do you recall that Sony failed to comply with the GPL when they used LAME? The
LAME community wasn't prepared to actually do anything about it. That's the
kind of shit that would happen, especially to smaller projects. There are big
companies out there that want to use your hard work without compensation and
shit all over the GPL. Never forget that.

~~~
josteink
> So you'll wait until the FSF finds it cannot defend the GPL in court and
> then try to get copyright assignments from thousands of programmers?

I'll rather have code which is harder to defend than defense for code I never
got.

------
hammerandtongs
Some speculatively useful things that could arise out of this -

It may have useful security properties over time. People use emacs for a great
deal of arbitrary text reading and transform from things directly from email
and the web. Elisp would largely be at fault for security bugs but perhaps
this would help in areas.

Perhaps a binding to use Alacritty directly for a port to Wayland? Emacs has a
pretty terminal centric view of its UI output as is.

A tight binding to Servo allowing a serious upgrade to Emacs visual and ui
capabilities.

~~~
moosingin3space
A while ago, when this project had just started, I filed an issue to discuss
the windowing/GUI system:
[https://github.com/Wilfred/remacs/issues/25](https://github.com/Wilfred/remacs/issues/25)

------
Tomte
I guess every language needs an Emacs port to grow up.

None of those ports ever see even the tiniest beginning of something actually
usable (heck, even Climacs faltered), but I'm still all for it!

~~~
db48x
One of the cool things about Rust is that it's compatible with C. You can
rewrite individual C functions in Rust, compile both halves of the program and
link them together into your executable. This lets you incrementally move from
a pure-C program to a hybrid, to a pure-Rust program over time.

Also, 90+% of Emacs is written in Lisp which doesn't need to be ported at all.

I just built it, and it's fully functional. It'll be a perfect replacement for
Emacs at every stage of the port, which is really cool.

~~~
phkahler
The most (debatably) useful thing they could do is write the LISP in Rust.
That might have some use. As it is, this project just creates an Emacs with
_more_ dependencies.

~~~
db48x
No, rewriting all of that Lisp code would be impossible. It's also
unnecessary. The primary advantage of Rust is safety; the compiler ensures
that either your code follows the rules or that it doesn't compile at all. The
Lisp code, on the other hand, already has that safety. No manipulation of
conses or vectors or other lisp data structures will ever result in a buffer
overflow, or a null-pointer dereference, or in doubly-freed memory, or any of
a hundred other of C's pitfalls. On top of that, Lisp is extremely fast to
write, test, and debug.

But of course, that safety only exists to the extent that the Lisp
interpreter/compiler is bug-free. The C side of Emacs's code base is
alternatively great and terrible, depending on how you look at it. On the one
hand, 30 years of continuous development has resulted in code that works
really well. On the other hand, it is very hard to extend this code to support
new features (good multi-threading support has been in the works for ages,
moving to lexical scoping and away from dynamic scoping has taken years, etc).
This is because it's difficult to maintain quality and compatibility while
also navigating such an old project.

Once enough of this old C code is rewritten in Rust, it'll be possible to
leverage the memory safety features (and the type system) of Rust to innovate
much more quickly. Not as quickly as you can innovate on code that's written
in Lisp, but much more quickly than you can innovate on the C code.

Besides, the number of libraries that a program uses is only a detriment if it
means that the developers have to spend more time installing and maintaining
those libraries. Cargo makes this comparatively painless.

~~~
phkahler
>> No, rewriting all of that Lisp code would be impossible.

I thought the lisp was written in C and so moving it to Rust would be useful.
Perhaps it's written in itself. If that's the case then my bad. I did not mean
rewrite the list parts in rust.

~~~
mijoharas
> I thought the lisp was written in C

I am unclear about what you mean by this? The lisp in emacs is elisp ([0]
emacs lisp). More generally, Lisp is the name given to a class of languages
including Guile, Racket, Scheme, Common Lisp that generally feature
homomorphism, functional style and parentheses to enable the homomorphism.

[0]
[https://en.wikipedia.org/wiki/Emacs_Lisp](https://en.wikipedia.org/wiki/Emacs_Lisp)

~~~
phkahler
I checked wikipedia:

[https://en.wikipedia.org/wiki/Emacs_Lisp](https://en.wikipedia.org/wiki/Emacs_Lisp)

The LISP interpreter is written in C. I was trying to suggest that it may be
useful to rewrite that in Rust. That is a necessary step in getting rid of the
C dependencies for emacs.

------
Blackthorn
What a lovely idea!

Question to the devs: are you planning on redoing how the gui subsystem works,
to work with (for example) the gtk event loop? I've always wanted to try to
put a qt frontend on emacs, but have always been horrified away by that
subsystem.

~~~
aaptel
I'd say its unlikely to happen as they are aiming for bug-for-bug
compatibility.

------
coldtea
I'd like to see a community-driven port of Sublime Text to Rust, with a basic
ST3 like cross-platform UI, and offering a base set of UI primitives (buttons,
panels, dropdown, inline styled annotations, etc) available for plugins, and
first class support for JS plugins/extensions.

~~~
frou_dh
Doesn't port imply having access to the original sourcecode?

There are many unrelated editors that have cloned aspects of Sublime to
varying degrees in the 2010s.

~~~
coldtea
Well, cleanroom re-implementation if you prefer.

~~~
michaelmrose
Really not worth doing there don't appear to be any unique aspects worth
copying and its closed source.

~~~
coldtea
It's not about having unique aspects. The Plan 9 editor is unique -- and
nobody cares for it.

It's about having useful aspects. And ST3 is the best example we have of a
native, fast, modern, cross platform, plugin-able editor.

~~~
mijoharas
Apart from emacs of course. (depending on what you mean by modern...)

------
gkya
How hard would it be for the existing developers of _CEmacs_ to get on board
with Rust if they decided to make this the upstream core? I did not study Rust
ever but did follow its evolution, and the language seems complicated to me,
compared to c.

~~~
Narishma
I think only a few bits of emacs are in C. The vast majority of it is elisp.

~~~
gkya
Yes but the maintainers will have to learn Rust for those little bits, no? And
those bits are the most complex ones.

------
comradesmith
What we need next is Rim to start the next phase of the holy wars.

~~~
wtetzner
Like the xi editor? [https://github.com/google/xi-
editor](https://github.com/google/xi-editor)

Though I guess it's not actually a port of Vim, just a vi-like editor.

~~~
moosingin3space
Xi isn't vi-like, although it is on their roadmap.

------
NoGravitas
This is only topic-adjacent, but here is my number one emacs wish: for the GTK
frontend to be pure GTK with no X, so that it can be run directly as a Wayland
client.

------
0xbear
Prediction: within a year this project will be dead due to the lack of uptake.
It doesn't solve any real problems and uses a relatively obscure programming
language. There's no way it will ever reach anything close to a critical mass.

------
0x7a69
As an avid emacs user... I would never use this.

~~~
db48x
Why not?

