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

131–140 of 181 posts

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

#131

Post by Evelyn533 »

mixedCase wrote: post #58
eklitzke wrote: post #44

Earlier quoted context omitted.

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.

$85 an hour! Seriously I don't know why more people haven't tried this, I work two shifts, 2 hours in the day and 2 in the evening…And whats awesome is Im working from home so I get more time with my kids. Heres where I went, ====http://ow.ly/P0wk30aVXfN

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

#133

Post by lispm »

fiddlerwoaroof wrote: post #115
SkyMarshal wrote: post #54

Earlier quoted context omitted.

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.

Fwiw, lisps have a somewhat interesting third way: you distribute everything in a single image like a statically linked program. But, since that image includes the compiler, it can upgrade itself.

Or they include a loader and can load code, code which may be compiled somewhere else.

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

#134

Post by ZenoArrow »

achikin wrote: post #86
ZenoArrow wrote: post #66

Earlier quoted context omitted.

> "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?" Somewhere in the middle. If you consider the work that goes into making a plane, you'll see quite a bit of it happens outside Boeing. To give one example, think of the aluminium that goes into the plane. Boeing d…

Great video, thank you! Yes, most of the work is done outside of Boeing, but it is done specially for Boeing, not that people work on whatever sort of aluminum they want but they know Boeing demand and supply them with the particular sort. On the other side Boeing pay them money so they can proceed to mine. This is what I mean under the collaboration.

Glad you liked the video.

Regarding...

"On the other side Boeing pay them money so they can proceed to mine."

Perhaps you know more about Boeing's business arrangements than me, but I certainly couldn't verify that that's true. From what little I know, it's possible Boeing's aluminium suppliers work exclusively for Boeing, but it's also possible these same aluminium suppliers have multiple customers. The point being, there could be people who work as part of the chain to produce and transport the aluminium who have no idea who will eventually use it.

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

#135

Post by coldtea »

michaelmrose wrote: post #130
coldtea wrote: post #47

Earlier quoted context omitted.

Well, cleanroom re-implementation if you prefer.

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.

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

#136

Post by dotemacs »

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.

> This looks like a lot of work for what amounts to very little end-user benefit.

Oh, but how wrong you are.

At London Emacs meetup Wilfred gave a talk about his motivations for this work. One of the big and most obvious benefits is this:

while porting some feature to Rust, he discovered a bug in Emacs, fixed it and got given commit access for his work.

You can read the transcript of his presentation here:

http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...

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

#137

Post by dotemacs »

31h wrote: post #76
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.

This looks like a lot of work for what amounts to very little end-user benefit. The sons of Hermes love to play And only do their best when they Are told they oughtn't; Apollo's children never shrink From boring jobs but have to think Their work important.

Brilliant. Thank you

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

#138

Post by lispm »

dbaupp wrote: post #103
e12e wrote: post #85

Earlier quoted context omitted.

My initial thought was that if you want to rewrite emacs, why not rewrite it in common lisp? Apparently there are a few cl editors/ides - along the "original emacs" path - but like all things GNU I gather GNU Emacs is more than "just" (a) Free Emacs. Now, there's a fairly recent (and active) project for implementing a common lisp in c++[clasp] -- perhaps making a real common lisp in rust would make sense? [clasp] htt…

It's touched on elsewhere in this thread, but one of the benefits of doing the port in the style of remacs is that one has a completely functional editor the whole time: things can get rewritten one small piece at a time because Rust and C have similar binary models. It's easy and fast to call from one language to the other, so one can rewrite a a single C function to Rust and have the rest of the C code call it, and…

The idea would be:

* replace the GNU Emacs runtime written in C/Rust with one which is already provided by a Common Lisp implementation. Each Common Lisp implementation has its own runtime already, but those are not application specific to an editor. Several Common Lisp runtimes for example support multi-threaded Lisp code, native Lisp code, various GCs, support for more data types, better error handling, ... plus they support much of the basic Lisp stuff which is in the GNU Emacs runtime (evaluating code, loading code, ...)

* move some C/Rust code into Common Lisp, since Common Lisp compilers make it possible to write a wider range of code directly in Lisp.

* provide some low-level C code to Common Lisp via it's FFI. That way the C code does not need to be a part of the runtime.

But the topic is dead, because the expertise to do something like that is rare and the GNU Emacs community has no interest moving in this direction.

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

#139

Post by kyberias »

BeetleB wrote: post #53
Nullabillity wrote: post #31

Earlier quoted context omitted.

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.

Sublime is C++.

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

#140

Post by urethrafranklin »

Walkman wrote: post #122
bennofs wrote: post #62

Earlier quoted context omitted.

Python has/had a terrible packaging story though. As you said, dependencies weren't really documented. Rust, on the other hand, documents all dependencies in Cargo.toml. And dependencies can easily be parsed from Cargo.toml without the need to execute any code (as would be required in the case of python)

> 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).
Post reply on HN