
Continued progress porting Emacs to Rust - ealhad
http://db48x.net/rust-remacs-2018/
======
ealhad
To anyone wondering _why_ this might be a good idea, there are some
interesting comments in a GitHub issue
([https://github.com/Wilfred/remacs/issues/305](https://github.com/Wilfred/remacs/issues/305)):

> For users, I hope Remacs will be faster (it's easier to optimise), more
> robust (we have stronger type checks and the ability to add unit tests),
> better documented (see #262) and somewhat more featureful (we have some
> ideas for solving the dumper problem that would allow users to dump their
> instance as an image) than GNU Emacs.

> I think we will get problems when the current generation of emacs devs
> retire and there's a better chance that emacs will survive if we try to make
> it more appealing to young developers. Rust seems to be a good option.

~~~
flurrything
> For users, I hope Remacs will be faster

The main reason my emacs is painfully slow is that most elisp code blocks.
Stuff like hitting tab for auto-completion might perform a blocking query from
a language server hanging emacs for multiple seconds. Opening a file tries to
start a language server and blocks the editor in the process. Etc.

Making emacs itself faster won't make the experience of working with emacs any
better.

~~~
ams6110
Emacs does block on many operations, but I've never had it be really
noticeable on tab-completion type stuff.

Though I only use auto-complete on emacs commands, so maybe I've just missed
it.

~~~
db48x
It depends quite a lot on what kind of autocompletion you're using, for which
language. It's a mixed bag.

------
tom_mellior
The author misunderstands some parts of the C language, in particular related
to static variables. "In fact, these aren't just file globals accessible to
only one translation unit, these are static variables that are accessible
across the whole program." gets the meaning of C's static exactly backwards: C
file-scope static variables are _only_ accessible (by name) in their
translation unit; all other file-scope variables are extern by default.

More importantly, they write:

    
    
        static struct Lisp_Objfwd o_fwd;
    

"... creates an (uninitialized) static variable called o_fwd". No. C static
variables are implicitly initialized to zero of the appropriate type, in this
case, apparently a struct containing only a null pointer. This also means that
their

    
    
            unsafe {
                #[allow(const_err)]
                static mut o_fwd: ::hacks::Hack<::data::Lisp_Objfwd> =
                    unsafe { ::hacks::Hack::uninitialized() };
    

"a lot more typing to get a proper uninitialized value in a Rust program" is
just useless voodoo.

~~~
db48x
You are entirely correct, and I should perhaps have been more precise.
However, because Lisp_Objfwd is basically a pointer, zero-initialized is
pretty much as good as uninitialized. It's not a useful value.

~~~
danaliv
It fails a NULL check, where an uninitialized value (probably) won’t. That
seems like a pretty important distinction, no?

~~~
db48x
In C, yes, that's a useful distinction. One of the goals of Rust is that
you'll never have to check that manually. You'll never encounter a pointer
that points to an invalid, uninitialized, or unallocated object. Since we're
writing some unsafe code here, we can operate outside that restriction as long
as we promise to put things right before the end of the unsafe block. This can
be simplified somewhat once everything is written in Rust.

------
OskarS
When I first heard of this project I thought "Well, that's insane, it will
never be finished, and will surely be abandoned in six months". Glad to hear
that it's making good progress! I love it when I'm wrong about stuff.

~~~
bjornedstrom
Remember that most of Emacs is written in Emacs Lisp. If you take the entire
source code distribution, around 15% of it is written in C. Those 15% are of
course fairly complex, however it's at least less code than you may think.

~~~
db48x
Yes. The last time I looked, it was about a million lines of elisp, and only
about a hundred thousand of C. We'll have it cleaned up in no time.

------
nazri1

        DEFUN ("atan", Fatan, Satan, 1, 2, 0,
    

Hah I couldn't read that with a straight face!

~~~
db48x
Agreed! It's a great example.

------
wscott
And there are related efforts to upgrade the lisp used in emacs to a more
modern and standardized version.

I think it is GuileEmacs I am remembering.

I hope to two efforts are compatible.

~~~
rauhl
Although Scheme has a standard, I wouldn’t really call Guile ‘more modern and
standardised’: _Guile_ has no standard (it extends the Scheme standard in
incompatible ways), and ‘modern’ is hard to define. Emacs Lisp added lexical
scope in the past couple of years, probably more recently than Guile added a
new language (as opposed to library) feature — is that modern enough?

I wouldn’t imagine that the two efforts are compatible, because they are both
efforts to rewrite the Emacs Lisp _engine_ in another language, one in Rust &
one in Guile Scheme. It’s possible that one might be able to call over to the
other, through its CFFI.

I’d like to see Emacs rewritten in Common Lisp, and so I’d prefer a Rust
engine to a Guile engine: Rust is a static language, and a Rust engine is
unlikely to lead to Rust-extensible Emacs code, while a Guile engine is
likelier to lead to Guile-extensible Emacs code, which is completely the wrong
direction IMHO.

~~~
dkarl
_it extends the Scheme standard in incompatible ways_

What does "incompatible" mean here? Incompatible with the Scheme language
reports, or incompatible with other Schemes' extensions?

~~~
qbrass
Guile includes a bunch of functions that aren't part of the standard, and have
been around before Scheme's standard thought to implement libraries.

------
snazz
Remacs’s README is really well written. More projects should try this hard to
sell their ideas. This totally beats the GNU Emacs website at selling me on
why I should use Emacs.

------
ams6110
Emacs rather famously has a build process that involves first compiling a
minimal elisp environment (written in C and maybe some assembly) that then
loads all the editing routines (which are written in elisp) and then dumps
itself out as a binary (to save the load time, which is substantial, on
subsequent start-ups).

I assume the Rust-based emacs would do the same thing?

~~~
wiz21c
not sure, but I guess that process is to make sure Emacs can be built from
scratch, ie without relying on proprietary software.

~~~
db48x
The build process of Emacs doesn't rely on any proprietary software. But it is
quite complex :)

------
mrec
Not an Emacs user, so forgive me if I'm being dense, but is this (from the
README) really true?

    
    
      Emacs will change how you think about programming.
    
      Emacs is an incremental programming environment. There's no 
      edit-compile-run cycle. There isn't even an edit-run cycle. You can 
      execute snippets of code and gradually turn them into a finished 
      project. There's no distinction between your editor and your 
      interpreter.
    

I'm assuming what it means is "Emacs will change how you think about
programming _Emacs Lisp_ ". Which is a rather narrower proposition, and much
less of an incentive to switch, since I doubt many non-Emacs users are
particularly interested in programming Emacs Lisp.

~~~
rauhl
Yes, it’s true — and it’s not just true of elisp (which is a decent language)
but also of Common Lisp, Python, Scheme and others. It’s probably _most_ true
of elisp, because the editor itself is written in elisp, but one gets
something of the same tight edit-execute cycle in those other languages too.

Once you’ve been there, you’ll probably never want to go back. My only wish is
that emacs were written in an even better language than elisp (like Common
Lisp).

~~~
ealhad
> My only wish is that emacs were written in an even better language than
> elisp (like Common Lisp)

There are a lot of bad things in CL too, unfortunately. I wonder if a Lisp
will become really popular in the near future. Maybe Racket?

~~~
lispm
There are 'bad things' in any programming language.

Common Lisp is actually quite a bit more advanced out of the box than Emacs
Lisp: lexical binding, excellent error handling, good support for compilation,
extensive object-oriented features, it has multiple implementations with
independet code bases, implementations with threading, ...

CL has been used to develop Emacs editors already.

But the thing is a non-starter. There are a few million lines of Emacs Lisp
for a specific editor, which nobody will rewrite.

~~~
rauhl
Emacs Lisp has lexical binding these days.

I’d like to see an Emacs with a Common Lisp core, and an elisp execution
engine to run all the legacy elisp code.
[https://github.com/blindglobe/clocc/blob/master/src/cllib/el...](https://github.com/blindglobe/clocc/blob/master/src/cllib/elisp.lisp)
looks like a decent first start, although it supports an older version of
elisp.

Someday if I have the free time I’d love to spend time working on such a
thing. Maybe when I’m retired!

~~~
lispm
> Emacs Lisp has lexical binding these days

sure, but you need to support legacy software, too. Which is most Emacs Lisp
ever written.

------
fangyuanziti
Neovim vs Remacs now.

