What we need next is Rim to start the next phase of the holy wars.
Like the xi editor? https://github.com/google/xi-editor Though I guess it's not actually a port of Vim, just a vi-like editor.
Xi isn't vi-like, although it is on their roadmap.
Remacs – A community-driven port of Emacs to Rust
161–170 of 181 posts
Re: Remacs – A community-driven port of Emacs to Rust
#162Some 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 cent…
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
Re: Remacs – A community-driven port of Emacs to Rust
#163This 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.
In response to the general critiques of "Why rewrite emacs at all!?", I believe there are hidden benefits to an incremental rewrite to Rust executed this way. First is that remacs has been able to reduce the amount of non-Elisp code in the editor needed to implement a number of different features. It was able to do this by replacing hand rolled C functionality with high quality crates from cargo, or code in the stand…
> Disclosure: I am a contributor to this project
Thanks for posting this and thanks for your contributions.
Re: Remacs – A community-driven port of Emacs to Rust
#164Earlier quoted context omitted.
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 d…
>> 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.
> 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.
Re: Remacs – A community-driven port of Emacs to Rust
#165Earlier quoted context omitted.
Really not worth doing there don't appear to be any unique aspects worth copying and its closed source.
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.
Apart from emacs of course. (depending on what you mean by modern...)
Re: Remacs – A community-driven port of Emacs to Rust
#166This 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.
I agree. The attempt to port Emacs in Rust is honorable. However, I believe a successful port does not depend on a safe C backend. I am a long-term everday emacs user, and I didn't have a single segmentation fault in emacs in all those years. Actually, emacs is the most reliable PC software that I ever encountered. Code safety is not an issue at all here. Emacs is heavily based on Lisp which leaves almost no room for segmentation faults.
IMHO, a potentially successful Emacs ports depends on a new plugin system which supports code in other languages (Rust for instance) rather than elisp so that new developers get attracted who dislike Lisp. In other words, don't attempt to clone emacs but develop a completely new editor which uses the successful concepts of Emacs.
Unfortunately, plugins require dynamic code generation, and AFAIK only scripting languages like Lisp, Scheme and Python are able to do that. Emacs has that already. Emacs's plugin system has an unmatched simplicity and reliability, and that's likely the reason why any clone has a very hard time to compete.
Re: Remacs – A community-driven port of Emacs to Rust
#167How 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.
Emacs is relatively pervasive. It runs everywhere, including plenty of platforms that Rust does not support. Either due to current support priorities or lack of LLVM support.
That makes it something less than a drop-in replacement from the overall CEmacs project perspective. I'm sure Rust devs are working on more platform support, and it's possible Emacs devs are open to simply dropping some of the more obscure targets, but it might be a long time before alignment happens on that requirement alone.
Re: Remacs – A community-driven port of Emacs to Rust
#168Earlier quoted context omitted.
Are you talking about requirements.txt? Requirements.txt falls short of cargo or really any other mainstream language's dependency doc (no reproducible builds, for one thing -- effectively almost as bad as undocumented).
Requirements.txt + virtualenv, everything is fine. Really, significantly easier to not screw up in a large org than bundler, because dependencies don't leak by default.
Actually, `bundle exec` is way easier to use than virtualenv.
Re: Remacs – A community-driven port of Emacs to Rust
#169Earlier quoted context omitted.
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 pro…
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 cleanin…
> 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.
Creating new things is better than sitting on a sofa watching TV or playing video games all day. Furthermore, it often opens the door to possible new, unforeseen use cases, concepts, and success. Open source has a natural evolutionary path. Survival of the fittest, rather than survival of the richest.
Re: Remacs – A community-driven port of Emacs to Rust
#170Earlier quoted context omitted.
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.
It's just a snail mail of a single page once and for all. If it helps FSF and GNU, that's no big deal for me. I compiled the form and sent it to US from Turkey, and all it took me was about 5 Lira's and a walk to the post office.
It may be a small thing compared to other things, but relative to a PR on Github, it's a tectonic scale difference in workload.
I know plenty of people who won't bother on plain principle, and that's both people and code which the FSF is missing out on.
New times. New standards. Get with the program FSF.