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".
Remacs – A community-driven port of Emacs to Rust
61–70 of 181 posts
Re: Remacs – A community-driven port of Emacs to Rust
#62Earlier 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.
Re: Remacs – A community-driven port of Emacs to Rust
#63This 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.
STOP/ I just think that before judging remacs everyone had to read this blogpost: http://www.wilfred.me.uk/blog/2017/04/30/remacs-talk-transcr...
"We aim to be a drop-in replacement with bug-for-bug compatibility."
Re: Remacs – A community-driven port of Emacs to Rust
#64Earlier quoted context omitted.
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.
Re: Remacs – A community-driven port of Emacs to Rust
#65Some speculatively useful things that could arise out of this - It may have useful security properties over time. People use emacs for a great deal of arbitrary text reading and transform from things directly from email and the web. Elisp would largely be at fault for security bugs but perhaps this would help in areas. Perhaps a binding to use Alacritty directly for a port to Wayland? Emacs has a pretty terminal cent…
I'm open to be surprised. But I really do want Emacs to have full access to my computer.
Re: Remacs – A community-driven port of Emacs to Rust
#66Earlier quoted context omitted.
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?
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 doesn't have to mine bauxite, extract the aluminium from the bauxite, transport it to the place where its sold, etc...
A classic example of this ground-up view was this example given by Milton Friedman about the pencil. I don't agree with many of his views, but I think he makes a good point in this video:
https://www.youtube.com/watch?v=R5Gppi-O3a8
EDIT: Turns out the source of this example may have been Leonard Read:
Re: Remacs – A community-driven port of Emacs to Rust
#67If it gets faster, I might give it a try again (in evil ofcourse, gotta have them keys).
Re: Remacs – A community-driven port of Emacs to Rust
#68This 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…
I mean, if you have a lot of energy to use and give, and you want to clone something huge, clone one the proprietary tools that have no free/open source equivalent yet in your domain or one of the domains where there are the most serious lacks of FOSS; or clone a web app into a real desktop program; or reverse engineer a proper open driver for whatever device you have which request a proprietary OS, a proprietary driver or a manufacturer specific tool; rewrite a library which only exists in Python or C# into a C or C-compatible library so that every language on Earth can wrap it, etc. Don't go cloning something that is already free multiplatform software just for the purpose of cloning.
We have never had so many people writing open-source programs, taking part in open-source projects, and yet it looks like the progress of open-source over proprietary (and its new form: services) is not what it was in the 90's and 2000's, it stalled, and it regresses in some areas. There has to be a problem somewhere.
Re: Remacs – A community-driven port of Emacs to Rust
#69Doesn'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
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
#70Question to the devs: are you planning on redoing how the gui subsystem works, to work with (for example) the gtk event loop? I've always wanted to try to put a qt frontend on emacs, but have always been horrified away by that subsystem.