6 ms·

1. I would like higher-level datatypes for key abstractions, such as (1.1) Marks -> StableRegions - reference specified text within a buffer - continue to re

1. I would like higher-level datatypes for key abstractions, such as (1.1) Marks -> StableRegions - reference specified text within a buffer - continue to reference same text despite insertions or deletions (1.2) Strings & characters -> StringBuffers - lightweight immutable buffers (no branches or versions) - able to hold any content a subset of a buffer can hold - could be StableRegions of an Arena Buffer (1.3) AbstractBuffers - immutable buffers + a tree of deltas - some special delta types for, e.g. indentation - AbstractBuffers support transactions and versioning - can support collaborative editing - specific versions can be written to textfiles - all versions can be stored in git or in relational database 2. Use WebAssembly instead of a specific programming language. - This was the vision for Guile. - Scheme one of several languages. - ELisp supported but Emacs port efforts keep failing! - The Racket ecosystem has captured this pretty well - if only it supported ELisp! 3. Prefer languages at least as simple as Scheme, but with monotonic semantics! Non-mutable operations would appear as transactions appearing as branches/versions. An editing session would automatically follow the latest transaction in the current branch. Concurrent edits of the same "file" create different branches as with git, et al. 4. Separate monolithic Emacs process into SessionProcesses, DisplayProcesses and WorkerProcesses. Multiple DisplayProcesses would allow for tightly-coupled collaborative editing. A WorkerProcess would interface buffers with processes, files, git repositories, etc. on a specific account@host giving functionality like Tramp. A user would start with one DisplayProcess connected to a SessionProcess. A SessionProcess would provide the interface between DisplayProcesses, WorkerProcesses and any co-SessionProcesses of collaborators. WorkerProcesses could be scripted without any other overhead.

celeritascelery 2y ago
Are all these “higher-level datatypes for key abstractions” trying to achieve first-class collaborative editing? That sounds a lot like Zed.
- GregDavidson 2y ago
  I want ALL of what Emacs provides, much more than any other "editor" - actually text-centric programmable productivity platform. And I want more than what Emacs provides, e.g. non-destructive editing and collaboration. So yes, there are other interesting editors out there such as Zed. And no, it's not about adding 1 important feature. I'm greedy!

celeritascelery 2y ago

Are all these “higher-level datatypes for key abstractions” trying to achieve first-class collaborative editing? That sounds a lot like Zed.

GregDavidson 2y ago
I want ALL of what Emacs provides, much more than any other "editor" - actually text-centric programmable productivity platform. And I want more than what Emacs provides, e.g. non-destructive editing and collaboration. So yes, there are other interesting editors out there such as Zed. And no, it's not about adding 1 important feature. I'm greedy!