You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This idea started as an idea for a fun little personal project: Make a terminal text editor that had a language-agnostic plugin system as a first-class citizen from the start.
This idea started gravitating towards zellij, I'll come back to that later.
Naturally, I was thinking about WASM/WASI as the primary means of doing this. Compile your plugin to wasm/wasi, and dynamically load/unload the plugins as they are needed.
Naturally, that means having to deal with the challenges associated with this, such as having to copy data in/out of the WASM runtime.
Then the idea hit me to think about this in the context of zellij. Why not just piggy back off zellij as a plugin itself? All the architecture should already be there, but now you start adding in the benefit of a text editor that can be fully integrated into the UI that it's hosted on.
For example, consider the bacon program. My workflow has nvim open in one pane, bacon in another, and I just watch for warnings/errors. If there was an nvim-like plugin for zellij (zeddit, zelldit?), you would start it in one pane. in another pane, you would start a bacon plugin. Because it's a zellij plugin, and not a stand-alone terminal app, the bacon plugin is seen to be started in the context where the zeddit plugin is running, and that would allow you, for example, to use have bacon plugged into your running instance of zeddit
I think this might be very interesting, if for no other reason than as a technology demonstrator.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This idea started as an idea for a fun little personal project: Make a terminal text editor that had a language-agnostic plugin system as a first-class citizen from the start.
This idea started gravitating towards zellij, I'll come back to that later.
Naturally, I was thinking about WASM/WASI as the primary means of doing this. Compile your plugin to wasm/wasi, and dynamically load/unload the plugins as they are needed.
Naturally, that means having to deal with the challenges associated with this, such as having to copy data in/out of the WASM runtime.
Then the idea hit me to think about this in the context of zellij. Why not just piggy back off zellij as a plugin itself? All the architecture should already be there, but now you start adding in the benefit of a text editor that can be fully integrated into the UI that it's hosted on.
For example, consider the
bacon
program. My workflow has nvim open in one pane, bacon in another, and I just watch for warnings/errors. If there was an nvim-like plugin for zellij (zeddit
,zelldit
?), you would start it in one pane. in another pane, you would start a bacon plugin. Because it's a zellij plugin, and not a stand-alone terminal app, the bacon plugin is seen to be started in the context where thezeddit
plugin is running, and that would allow you, for example, to use havebacon
plugged into your running instance ofzeddit
I think this might be very interesting, if for no other reason than as a technology demonstrator.
What does everyone think?
ETA: just found this conversation on discord: https://discord.com/channels/771367133715628073/771367133715628076/797908703797313587
Beta Was this translation helpful? Give feedback.
All reactions