rune VS vscode-mail

Two projects that may be of interest, related to this topic:

- Rune (https://github.com/CeleritasCelery/rune) - A re-implementation of Emacs but in Rust (like Remacs, but actively developed)

- Pimacs (https://github.com/federicotdn/pimacs) - Same, but using Go (created by me, but developed in a very slow pace)

[2] https://github.com/CeleritasCelery/rune/issues/17#issuecomme...

I second this ! I had trouble finding the github link, but here is is https://github.com/CeleritasCelery/rune

> How is anything rooted here? The lifetime changed from 'arena to 'root but I don't see a root being created.

In this example, the Vec has been rooted previously. So pushing an object into the Vec will make it "transitively" rooted (accessible from the root). You would root a struct with the root_struct![1] macro, which works very similar to the root! macro shown in the post.

However you made you realize one error; The rooted `Vec` in the example you pointed is a by value type, but in the implementation you can only get references to rooted structs, so that example needs to be updated.

> But later we see roots not obeying a LIFO order, under "Preventing escapes" where roots are dynamically created and destroyed in an arbitrary order.

Objects are just a copyable wrapper around a pointer, so they are not the part that has the LIFO semantics. inside the root! macro[2] there is a `StackRoot` type that is the actual "root". The object just borrows from that so that is has a 'root lifetime and is valid post gc. The actual root struct is not exposed outside of the macro.

I hope this makes the distinction between "roots" and "objects" clearer. Objects are just pointers to heap data. When we root an object we store the data it points to on the root stack and create a new `StackRoot`. Then we say this object is rooted. But the struct that "does the rooting" is inside the macro and not exposed. Rooting a struct works similarly.

[1] https://github.com/CeleritasCelery/rune/blob/5a616efbed763b9...

Hack on Rune

> It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there?

One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before that Sublime, but it was under protest, the details don't matter here but there were features I needed and no task budget for provisioning them in Emacs.

Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode. For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

"Emacs does everything" is an aesthetic, and it has many decades of refinement, and people like it. That's fine.

> Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"

This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

There's such a thing as a like-for-like comparison. Emacs has org-mode, it has SLIME, it has paredit and parinfer. Those are all edges over VSCode, whereas checking email isn't. This conversation piqued my curiousity, and indeed, there's a plugin for that[0], a few actually, and yes, I'm sure Emacs does a better job, for some value of better. But I'll never know, because I don't intend to use either tool for that job.

[0]: https://github.com/buhe/vscode-mail