rune VS vlfi

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

That is essentially what VLF[1] does in Emacs. It reads in discrete chunks of the file at a time and doesn’t load the next one till you try to display it. Doesn’t require any fancy data structures, just some extra book keeping and mechanics.

[1] https://github.com/m00natic/vlfi

That is an issue both related to Emacs' internal representation of buffers and modes working in the background on the data in buffers of very large files, for which there are some workarounds like vlf-mode. See for example (info "(emacs) Long Lines") for similar issues with long lines and a solution more similar to what all those other editors you mention are doing to mitigate the issue of large files and large lines.

You can edit gigabyte-large files with no trouble vlf.el https://github.com/m00natic/vlfi – though it's a bit of a separate universe, you have to use vlf-occur instead of occur to find matches over all gigabytes of the file

;; To have it offered when opening large files:

For arbitrarily large files (think GB) in terms of size of the data stored you may use e.g. vlfi.

You can use vlf package to open large files

You know how "there's an app for that" used to be a thing? Well, there's an elisp package for that: https://github.com/m00natic/vlfi

Theres always: https://github.com/m00natic/vlfi

I’m aware of a few potential solutions including: dired-async and async-shell-command. There’s also https://github.com/m00natic/vlfi for viewing large files, but I don’t know how to address GPG pinentry and TRAMP issues very well.

I think you might enjoy this mode: vlfi. It is available in the standard Elpa package listing.