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…
Remacs – A community-driven port of Emacs to Rust
81–90 of 181 posts
Re: Remacs – A community-driven port of Emacs to Rust
#82This 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.
Re: Remacs – A community-driven port of Emacs to Rust
#83Re: Remacs – A community-driven port of Emacs to Rust
#84This 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.
Re: Remacs – A community-driven port of Emacs to Rust
#85This 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.
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?
Re: Remacs – A community-driven port of Emacs to Rust
#86Earlier quoted context omitted.
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?
> "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…
Re: Remacs – A community-driven port of Emacs to Rust
#87Earlier quoted context omitted.
I don't know if it's a priority but it would be cool to see rendering speed improved.
That's an odd expectation to have. I would think rendering speed would stay the same or increase a bit; a lot of hand optimizations are going disappear.
Re: Remacs – A community-driven port of Emacs to Rust
#88Earlier quoted context omitted.
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.
"It's a neat language, but no one has used it to make anything that isn't a toy" is a really common mindset for the people who make such decisions.
The only way to change that mindset is for the evangelists to write software and show that yes, it is possible to write For Realsies software in that language. If that happens to be a rewrite of a successful project, fine - it's still a large project, and it'll inspire more development than someone coming out of nowhere with a project.
Re: Remacs – A community-driven port of Emacs to Rust
#89Doesn't seem to have a copyright assignment policy in place so this can't be upstreamed as is. https://www.gnu.org/software/emacs/manual/html_node/emacs/Co... So opened - https://github.com/Wilfred/remacs/issues/238
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.
Re: Remacs – A community-driven port of Emacs to Rust
#90Earlier 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.
Part of me feels like a better solution is to maintain older branches to give distributions opportunity to catch up.