Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor extension architecture #26

Open
sagebind opened this issue Mar 9, 2020 · 0 comments
Open

Editor extension architecture #26

sagebind opened this issue Mar 9, 2020 · 0 comments

Comments

@sagebind
Copy link
Owner

sagebind commented Mar 9, 2020

As someone who used to be heavily involved in the development of projects like Oh My Fish! for many years, I've learned a lot about shells, package distribution, plugins, and themes, and various pitfalls that should be avoided. One such area that we must be careful with are ways of customizing and augmenting the terminal editor (prompt) itself.

When a "plugin" is simply a bundle of scripts that can hook into just about anything it means that plugin authors can do whatever they want, which is nice from one perspective, but it also causes a slew of other problems for the shell itself:

  • Since plugins can hook into anything, they are almost always stateful, and adding and removing plugins can often require you to exit all your terminals and re-open them to get everything working properly.
  • Plugins that hook into the same functionality can sometimes accidentally conflict with each other and cause things to break.
  • Plugins that hook into things like changing directories or rendering a prompt synchronously do work inside a callback, which can hamper user experience. It isn't uncommon for your shell to become painfully slow just by adding a few plugins and themes, especially on slower hardware.
  • Since plugins run in-line with the script code that powers the prompt, a rogue or broken plugin can render your shell completely unusable until the plugin is identified and removed.
  • "Plugins" become a bucket for basically any sort of script targeting your shell, which means that useful CLIs that could be standalone cross-shell tools instead become siloed and duplicated to take advantage of the ease of use of your plugin system.
  • Plugins must be implemented in script, and are almost impossible to test.

In attempt to avoid some of these, here's what I'd like Riptide's extensibility to look like:

  • Themes: Make themes a totally separate concept from everything else. Themes should be simple, declarative JSON files that configure things such as colors and prompt characters, and nothing else. Switching themes becomes easy and just always work.
  • Extensions: A means of extending the behavior of the terminal editor (prompt, display, hooks, etc) and not designed for creating commands (command should be standalone scripts).
    • Extensions are run asynchronously and can't block user input.
    • Basically everyone reimplements some sort of powerline-type prompt, so have it be a built-in shell feature. Extensions can then provide "prompt items" -- live strings that the shell will display along the prompt on an extension's behalf.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant