4 ms·

For the protocol between core and front-end, did you take any inspiration from mosh's state sync protocol? https://mosh.org/mosh-paper-draft.pdf https://mosh.o

For the protocol between core and front-end, did you take any inspiration from mosh's state sync protocol? https://mosh.org/mosh-paper-draft.pdf https://mosh.org/mosh-paper-draft.pdf

kazinator 9y ago
Text editors shouldn't have a "core" and "front end" and "protocol". Monolithic machine executable that fits into under a meg of RAM and comes up in a fraction of a second from a cold invocation.
- ovao 9y ago
  Separating these concerns doesn’t strictly preclude (or at least needn’t strictly preclude) shipping a single, sub-megabyte binary. The “classic example” of this would be Quake — a single binary implements both a server and a client, which communicate over a simple binary protocol.
- Jyaif 9y ago
  I've got bad news for you: vim and the other editors you are thinking about also have a core (vim), front end (whatever terminal you use), and a protocol to talk in between them.
  - vidarh 9y ago
    Not just that, but many editors have a client/server architecture for the editor itself as well. Quickly scanning Emacs "NEWS" files, the first mention I found of emacsclient dates back to between '86 and '92. I'm pretty sure it's older. This was added as an option exactly because it is more efficient and leaner to start a separate UI than starting a separate editor instance each time, and adds very little bloat (on my system, emacsclient is a 23KB binary), and it adds so little latency as to not be noticeable.
- vidarh 9y ago
  Yes, they should. And here is why: 1. Stability. I'm writing my own editor at the moment, and the text buffers are kept in a server process. Last time I updated the server process it'd been running continuously for a month despite extensive reworking of the frontend. The backed is trivially simple (~300 lines), and easy to keep stable. If the frontend crashes it doesn't take my open buffers with it. 2. Coming up in a fraction of a second with state most of the time. Most of the time I have a ton of buffers in RAM; rather than reloading a ton of files, most of the time when I bring up the frontend, the files I'm working on are already there. Re-establishing an IPC connection to the backend is not noticeable. 3. Faster starts over slow network connections - I can run the backend remotely and not have to transfer a big file other than what is needed to view the bits I care about. 4. Simplicity: I don't need to implement tabs or multiple windows - I got that for free from my window manager. Instead if I want to split the current buffer, I just spawn a new frontend that re-attaches to the same buffer from another process. There should be no need for an editor to re-implement its own window management. A client-server design makes very little difference to memory usage and doesn't require a separate executable.
  - michaelmrose 9y ago
    Even as part of the minority that use window managers on linux I find the idea of merely using the window manager exclusively in place of other forms of UI for multiple documents/pages/buffers within a gui app as fantastically underwhelming. Lets look at firefox as an example. The fact that a vertical tabbar is more useful in this case due to screen shape and size and it being useful to be able to read a bit more of the text when you have a lot of tabs. This could in theory by done by your wm even though I've not seen one that does. Further tree style tabs shows a visual hierarchy of sorts that can't be replicated by your wm because it doesn't know what link was opened from what. Further you can perform operations on groups of tabs, like closing them, bookmarking them, reloading them. Its difficult to see how your wm could infer this hierarchy and how it could allow application specific operations like bookmarking even if it could. Further its useful to sometimes open a number of links in the background before switching to any of the above. This is trivially effected within the browser but challenging outside of it because the action of opening a link happens inside the browser. Within my irc client various channels are arranged according to network and color coded according to activity. Right clicking on individual channels or networks allows specific actions regarding those networks or channels. None of the above would work with a bunch of stacked/tabbed windows. I could make a list for emacs but the complaint is the same wm ends up being an unfixably poorer alternative to dealing with multiple documents in the app. I use i3wm not because its awesome at managing multiple documents but because its simple and straightforward and 90% of workspaces, which span only a single monitor, have only 1-2 windows on them. Rarely 3 or 4 and never more. Window managers are just unfixably mediocre in this respect because the UI doesn't have access to context and can't differ based on use.
- alvil 9y ago
  yeah, just another ugly monster with 50 frontends, with stupid name, unusable for the next 50 years. academic shit. :q!
raphlinus 9y ago
Not specifically, but I did dig deep into the state syncing literature in general, both Operational Transforms and CRDT's. The problem we're trying to solve is a bit different than mosh, because we don't need to compensate for network latency in particular; RPC should be very fast.

For the protocol between core and front-end, did you take any inspiration from mosh's state sync protocol? https://mosh.org/mosh-paper-draft.pdf https://mosh.org/mosh-paper-draft.pdf

kazinator 9y ago

Text editors shouldn't have a "core" and "front end" and "protocol". Monolithic machine executable that fits into under a meg of RAM and comes up in a fraction of a second from a cold invocation.

ovao 9y ago
Separating these concerns doesn’t strictly preclude (or at least needn’t strictly preclude) shipping a single, sub-megabyte binary. The “classic example” of this would be Quake — a single binary implements both a server and a client, which communicate over a simple binary protocol.
Jyaif 9y ago
I've got bad news for you: vim and the other editors you are thinking about also have a core (vim), front end (whatever terminal you use), and a protocol to talk in between them.
- vidarh 9y ago
  Not just that, but many editors have a client/server architecture for the editor itself as well. Quickly scanning Emacs "NEWS" files, the first mention I found of emacsclient dates back to between '86 and '92. I'm pretty sure it's older. This was added as an option exactly because it is more efficient and leaner to start a separate UI than starting a separate editor instance each time, and adds very little bloat (on my system, emacsclient is a 23KB binary), and it adds so little latency as to not be noticeable.
vidarh 9y ago
Yes, they should. And here is why: 1. Stability. I'm writing my own editor at the moment, and the text buffers are kept in a server process. Last time I updated the server process it'd been running continuously for a month despite extensive reworking of the frontend. The backed is trivially simple (~300 lines), and easy to keep stable. If the frontend crashes it doesn't take my open buffers with it. 2. Coming up in a fraction of a second with state most of the time. Most of the time I have a ton of buffers in RAM; rather than reloading a ton of files, most of the time when I bring up the frontend, the files I'm working on are already there. Re-establishing an IPC connection to the backend is not noticeable. 3. Faster starts over slow network connections - I can run the backend remotely and not have to transfer a big file other than what is needed to view the bits I care about. 4. Simplicity: I don't need to implement tabs or multiple windows - I got that for free from my window manager. Instead if I want to split the current buffer, I just spawn a new frontend that re-attaches to the same buffer from another process. There should be no need for an editor to re-implement its own window management. A client-server design makes very little difference to memory usage and doesn't require a separate executable.
- michaelmrose 9y ago
  Even as part of the minority that use window managers on linux I find the idea of merely using the window manager exclusively in place of other forms of UI for multiple documents/pages/buffers within a gui app as fantastically underwhelming. Lets look at firefox as an example. The fact that a vertical tabbar is more useful in this case due to screen shape and size and it being useful to be able to read a bit more of the text when you have a lot of tabs. This could in theory by done by your wm even though I've not seen one that does. Further tree style tabs shows a visual hierarchy of sorts that can't be replicated by your wm because it doesn't know what link was opened from what. Further you can perform operations on groups of tabs, like closing them, bookmarking them, reloading them. Its difficult to see how your wm could infer this hierarchy and how it could allow application specific operations like bookmarking even if it could. Further its useful to sometimes open a number of links in the background before switching to any of the above. This is trivially effected within the browser but challenging outside of it because the action of opening a link happens inside the browser. Within my irc client various channels are arranged according to network and color coded according to activity. Right clicking on individual channels or networks allows specific actions regarding those networks or channels. None of the above would work with a bunch of stacked/tabbed windows. I could make a list for emacs but the complaint is the same wm ends up being an unfixably poorer alternative to dealing with multiple documents in the app. I use i3wm not because its awesome at managing multiple documents but because its simple and straightforward and 90% of workspaces, which span only a single monitor, have only 1-2 windows on them. Rarely 3 or 4 and never more. Window managers are just unfixably mediocre in this respect because the UI doesn't have access to context and can't differ based on use.
alvil 9y ago
yeah, just another ugly monster with 50 frontends, with stupid name, unusable for the next 50 years. academic shit. :q!

raphlinus 9y ago

Not specifically, but I did dig deep into the state syncing literature in general, both Operational Transforms and CRDT's. The problem we're trying to solve is a bit different than mosh, because we don't need to compensate for network latency in particular; RPC should be very fast.