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

51–60 of 181 posts

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

#51

Post by znpy »

sillysaurus3 wrote: post #42
melling wrote: post #15

Earlier quoted context omitted.

A large part of Emacs is the Lisp source. It would be great to have another interpreter written in Rust that reads the same Lisp files. What’s the breakout of C vs Elisp? Ideally more of Emacs could be rewritten in Lisp with a smaller interpreter.

349,615 lines of C 1,632,280 lines of elisp

Also... I have dug the emacs sources for a while and i can testify that many times, function have two, three (sometimes more) actual implementations that gets actually built depending on configuration (example: sunos va dos vs linux vs win32 version of function foo).

So... Yeah. The c lines are in a way, "overcounted".

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

#52

Post by BeetleB »

Philipp__ wrote: post #30
BeetleB wrote: post #23

Earlier quoted context omitted.

>Too bad it wasn't meant to be run on macOS.  What makes you say that? 

It is stated in their _install-readme_ on github.

Interesting - I wonder what dependency they could have that prevents its use on MacOS. I run it on both Linux and Windows just fine. At the end of the day, it's just a Python program.

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

#53

Post by BeetleB »

Nullabillity wrote: post #31
BeetleB wrote: post #24

Earlier quoted context omitted.

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

Is Sublime itself written in Python? Or is it mostly C++ with some Python hooks? If the latter, it'll be quite limited.

Leo is all Python, and you have access to all the internals. I'm sure there are design decisions in Leo that will make changing some aspects hard, though.

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

#54

Post by SkyMarshal »

falcolas wrote: post #46
stagger87 wrote: post #36

Earlier quoted context omitted.

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

This creates its own headaches as a fix for the next Heartbleed becomes not "upgrade this one shared library", but "upgrade these dozens of individual programs when an update becomes available".

There has always been war b/t static vs dynamic linking. The debate will continue forever, but it doesn't really matter anymore. Each side understands and has solutions to its deficiencies.

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

#55

Post by barrkel »

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.

For big rewrites, I like to see someone who's been burned by a failed rewrite at the helm. They'll be much more aware of the pros and cons, and at far less risk of underestimating the effort involved, or the value of working code.

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

#56

Post by achikin »

always_good wrote: post #41
achikin wrote: post #34

Earlier quoted context omitted.

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.

What a bizarre argument. 1,000+ independent people trying their hand in the business world is ultimately how a Boeing is conceived. That is the extreme diversity that benefits society.

I didn't quite get it. Do you mean that Boeing is built by independent people who work on whatever they want to and then a plane is assembled of that independently built parts and no one takes the responsibility of the result? Or you mean that Boeing is subcontracting particular work to independent firms serving as architect, coordinator, and sponsor and taking all the responsibility?

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

#57

Post by dman »

agumonkey wrote: post #50
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.

I believe remacs is already having some sort of positive impact, yet not a user visible that is true. But for decades emacs core was somehow a blackhole. Now it's been modeled in another very different language. That's very nice. Also maybe it will help testing emacs, and even improving faster since rust typesystem is said to help refactoring tremendously. We'll see.

I hope that the other side of forking is also being considered - forks have a draining effect on existing contributors and can potentially have a divisive effect on an existing community.

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

#58

Post by mixedCase »

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…

I don't see how it is any more incremental than what Remacs is trying to do. They're doing a parasitic rewrite of GNU Emacs, it's not a from-scratch implementation.

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

#59

Post by RazrFalcon »

coldtea wrote: post #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.

xi-editor looks like the best solution for me.

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

#60

Post by baq »

digi_owl wrote: post #29
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…

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.

with python the rule should to be to run every deployment at least in its own venv.
Post reply on HN