Announcing Remacs: Porting Emacs to Rust
The example seems to be wrong <a href="https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;remacs#porting-c-functions-to-rust-walkthrough" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;remacs#porting-c-functions-to-rus...</a><p>fn Fnumberp(object: LispObject) -&gt; LispObject {
    if lisp::SYMBOLP(object) {
        unsafe {
            Qt
        }
    } else {
        Qnil
    }
}<p>It uses SYMBOLP instead of NUMBERP. Highlighting the risk of introducing new bugs.<p>Which leads to the question, why Remacs can&#x27;t just auto-wrap the lisp::* functions, which I assume are the Rust versions of the C Macros. If you look at Emacs&#x27; C code there are a lot of functions and macros that implement Elisp primitives in a C way. E.g., NUMBERP(x) will return 1 if x is a number or else 0. So you can use this function to deal with lisp objects in C code. The function that exports this primitive to elisp is Fnumberp. Rust has a better type system than C and supports meta-programming. So why not have a simple wrapper that can take a (LispObject) -&gt; bool and turn it into a (LispObject) -&gt; LispObject. Similar for other Elisp&lt;-&gt;Rust types.<p>However unless GNU Emacs is willing to accept the Rust replacement code I don&#x27;t think this will succeed. It is a lot of work and it takes quite some time until it actually pays off. It seems simpler to do what GCC and GDB have done and switch from C to (a strict subset of) C++ to simplify at least some of the more painful C hackeries.<p>And the reasoning given in the announcement are rather weak:<p>* &quot;We can leverage the rapidly-growing crate ecosystem.&quot; Emacs recently added module support allowing leveraging all kinds of ecosystems<p>* &quot;We can drop support legacy compilers and platforms (looking at you, MS-DOS).&quot; how is that an opportunity when it effectively removes support for platforms.