Live data from Hacker News

Remacs – A community-driven port of Emacs to Rust

github.com

31–40 of 181 posts

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

#31
post #24
post #16

Earlier quoted context omitted.

Sublime uses a Python API, though the docs are also not extensive

>Sublime uses a Python API, though the docs are also not extensive But how extensible is Sublime itself? For example, in Emacs I can do network connections (e.g. Gnus). Will Sublime allow this? Can I make a Tetris clone in Sublime? Both are doable in Leo.

AFAIK Sublime gives you a full Python, including network access. The problem is that you're limited to a few predefined hooks where you can integrate into Sublime's UI, so good luck making it do something that doesn't boil down to editing text.

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

#33
post #21
post #6

Earlier 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 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.

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

#34
post #33
post #21

Earlier quoted context omitted.

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 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.

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.

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

#35
post #11
post #6

Earlier 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…

I intended it more as a friendly suggestion or observation than anything else. Looking at the Github README, I see a lot of enthusiasm for Emacs and Rust, but not much justification for the (tremendous) effort of a port. Losing site of the value produced in the end result seems like the kind of 'software engineer mistake' I've made myself (many times) in the past. In any event, I think we would do volunteers a disser…

As an Emacs user one could see zero gain in this effort. But new languages like Rust do benefit (I believe) from this kind of projects: new libraries may be create for this port that could be useful for completely new applications. Also, it's more users/testers for Rust, which is always a good thing for their community.

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

#36
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…

As more of an admin kind of guy, i find this explosion of language specific repositories worrying. I have already had to deal with python code that do little to no dependency documentation, that just carpet bomb my system with stuff pulled from the net at the install stage.

(I hope I'm not misunderstanding your concern), but a quick search reveals that Rust prefers to statically link, so in this case, remacs would distribute as a 'single' binary. Only the developers (of remacs) would need all the dependencies/crates.

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

#37
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.

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

#38
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…

As more of an admin kind of guy, i find this explosion of language specific repositories worrying. I have already had to deal with python code that do little to no dependency documentation, that just carpet bomb my system with stuff pulled from the net at the install stage.

[deleted]

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

#39
post #6
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.

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…

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

It is, a little, but then again it's par for the course for Open Source projects, which are both volunteer AND seeking to engage a larger community.

It's not like its just some people doing what they like and keeping it to themselves or just offering it as-is. Open Source projects that want to become larger communities and attract more developers AND end users, have to accept external opinion and criticism.

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

#40
post #17
post #6

Earlier 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…

>the people working on it probably wouldn't be contributing to full Emacs >in the process of porting, someone notices a bug and so submits a patch upstream I find it a little bit controversial.

You probably meant conflicting.

But it's not: one might very plausibly not care to hack on C emacs, but care to hack on a Rust emacs.

And at the same time, the same person, might be able to spot a bug while porting C code to the Rust emacs, that will also help fix C-emacs.

Post reply on HN