Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remacs – A community-driven port of Emacs to Rust

github.com

Post reply on HN
Print view View original

151–160 of 181 posts

Re: Remacs – A community-driven port of Emacs to Rust

#151

Post by abhi18av »

mschaef wrote: post #5

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.

Actually, I did raise an issue towards that direction.

https://github.com/Wilfred/remacs/issues/66

I mean why not do it properly if it's not an hostile fork.

But sadly, the lead-dev seems to have made up his mind. Being a nOOb with emacs I'm in a position to judge the reasons though.

Re: Remacs – A community-driven port of Emacs to Rust

#152

Post by Narishma »

gkya wrote: post #149

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.

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

Re: Remacs – A community-driven port of Emacs to Rust

#153

Post by phkahler »

db48x wrote: post #125
phkahler wrote: post #113

Earlier quoted context omitted.

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.

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.

Re: Remacs – A community-driven port of Emacs to Rust

#154

Post by pjmlp »

bluejekyll wrote: post #106
chongli wrote: post #91

Earlier quoted context omitted.

language specific repositories worrying What is the alternative? Every major Linux distro has its own repository, as do all the BSDs. The picture on Windows and macOS is even more convoluted. Are developers in all these languages supposed to support the packaging of their software in half a dozen different repositories? Maybe all programmers should get together and build "one repository to rule them all"? I have no i…

FPM is at least a step in the right direction to reduce the overhead of creating all of these. At a minimum, Linux should have a common packaging system; though there may never be agreement. It's hard to see macOS and windows endingnup with a common one. But maybe we could do a third party option that is independent of each OS? Those rarely work out well though.

And that is forgetting that are many more OSes out there than just those three.

Re: Remacs – A community-driven port of Emacs to Rust

#155

Post by gkya »

Narishma wrote: post #152
gkya wrote: post #149

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.

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

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

Re: Remacs – A community-driven port of Emacs to Rust

#156

Post by ajross »

eklitzke wrote: post #44
DDSDev wrote: post #22

Earlier quoted context omitted.

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…

There is a huge amount of C code in Emacs that already isn't using the standard C library. As an example, the other day I noticed that Emacs has its own hand rolled implementation of mkstemp(). Unsurprisingly, the Emacs version uses a less secure implementation, so the custom implementation is of no value. A lot of people have already written about the difficulty of getting changes to fix things like this (or elimina…

To be fair: emacs was written in an era where the idea of a "standard" C library was kind of a joke. Those functions provide "no value" today on systems that have been POSIX-valid for decades. They certainly did in the mid-80's when Unix portability was the biggest hassle of the day.

That said, though: wouldn't that argue for things like "remove custom mkstemp" and not "rewrite it all in rust?"

Re: Remacs – A community-driven port of Emacs to Rust

#157

Post by krakensden »

urethrafranklin wrote: post #140
Walkman wrote: post #122

Earlier quoted context omitted.

> Python has/had a terrible packaging story though. As you said, dependencies weren't really documented. I wonder where have you lived? I rarely found (if ever) an undocumented dependency list for any serious Python project in the last couple of years.

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.

Re: Remacs – A community-driven port of Emacs to Rust

#159

Post by torrent-of-ions »

josteink wrote: post #147
gnuvince wrote: post #89

Earlier quoted context omitted.

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.

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.

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.

Re: Remacs – A community-driven port of Emacs to Rust

#160

Post by BeetleB »

coolsunglasses wrote: post #124
BeetleB wrote: post #3

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 ) 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 every…

Page loads fast and does the job though. Seriously underrated way to do the web.

Yeah, but unfortunately the content is not very helpful. Too many quotes on how it is the best editor in the world, yet too little showing it.
Post reply on HN