docs: update roadmap

docs/src/roadmap.md

@@ -1,17 +1,14 @@
 # Roadmap
 
-`cy` is slowly starting to emerge from the proof-of-concept stage. The core features are solid, but it is not quite ready to be an alternative to `tmux` for most users. This document outlines the features I plan on implementing before `cy`'s 1.0 release. Features denoted with "\*" are tentative and may not make the cut.
+This document outlines the features I plan on implementing in the next few months. Features denoted with "\*" are tentative and may not make the cut.
 
-- [x] [`v0.4.0`](https://github.com/cfoust/cy/releases/tag/v0.4.0) **Layouts:** Many users rely on being able to see multiple panes at once. `cy`'s approach to this will differ from `tmux`'s: users will be able to define layouts using a declarative layout API.
-  - [x] [`v0.4.0`](https://github.com/cfoust/cy/releases/tag/v0.4.0) **Proportional splits:** A layout akin to `tmux`'s default. Panes can be split horizontally and vertically and sized according to percentages or number of cells on the split axis.
-  - [x] [`v0.5.0`](https://github.com/cfoust/cy/releases/tag/v0.5.0) **Borders:** The borders of each window should be configurable independently of the layout.
-  - [x] [`v0.8.0`](https://github.com/cfoust/cy/releases/tag/v0.8.0) **Bars:** Users should be able to configure styled bars that appear above or below each window. These could be used to show the pane's current command, directory, time, et cetera. Ideally users would be able to provide a Janet function that could do anything they wanted.
-  - [ ] **Floating panes\*:** It should be possible to spawn temporary layers that show a single pane that appears to float over all of the rest.
-- [x] [`v0.10.3`](https://github.com/cfoust/cy/releases/tag/v0.10.3) **Searching through all recorded sessions:** Right now {{api replay/open-file}} is not very useful. There should be a mechanism for searching all recorded `.borg` files for a string.
-- [x] [`v0.9.0`](https://github.com/cfoust/cy/releases/tag/v0.9.0) **Command-line API access:** Users should be able to run Janet code with something like `cy -c '(some-code)'` to control `cy` programmatically just like they can control `tmux`. The result of this code could be written to standard output as JSON for easy interoperability.
-  - [ ] **fzf-cy\*:** `cy` literally uses `fzf`'s algorithm and its fuzzy finder should be able to be used as a drop-in replacement for `fzf` just like in [fzf-tmux](https://github.com/junegunn/fzf/blob/master/bin/fzf-tmux). In other words, `cy`'s fuzzy finder should support everything (within reason) that `fzf` does.
-- [x] [`v0.9.0`](https://github.com/cfoust/cy/releases/tag/v0.9.0) **Using the output of previous commands:** Similar to a Jupyter notebook, users should be able to access the output of previously executed commands from the command line. In essence, you could run `grep` on the output of a command you just ran without rerunning it: `cy -1 | grep 'some string'` where `-1` refers to the most recently executed command.
-- [x] [`v0.11.0`](https://github.com/cfoust/cy/releases/tag/v0.11.0) **Command history replacement\*:** The eventual goal of `cy` is to be able to replace `ctrl+r` in Bash (and other shells) with a command browser that not only lets you fuzzy-find a command among all of the commands you've ever run, but also see its output. Replaying a `.borg` file to find all the commands run inside it is an expensive operation, so it's likely that this would involve some kind of SQLite caching mechanism.
-- [ ] **Client session replay:** `cy` should record _everything_ that happens on screen and let users open replay mode for the whole session, not just for individual panes. It is up for debate whether this should be saved to disk.
-  - [ ] **Smarter rendering algorithm:** `cy` uses a "damage" algorithm to detect what parts of the screen have changed and only rerender those portions. This is intended to minimize the burden on the client's terminal emulator. Unfortunately, the current approach will break searching the screen in client session recordings, so it needs to be rewritten to preserve the byte order of sequential cells that share the same styling.
-- [ ] **Theme system:** Users should be able to configure all of the visual aspects of `cy`'s interface from Janet, preferably using parameters.
+- [ ] **Performance**: cy is not slow, but there's still room for improvement in rendering speed.
+  - [ ] **Smarter rendering algorithm:** `cy` uses a "damage" algorithm to detect what parts of the screen have changed and only rerender those portions. This is intended to minimize the burden on the client's terminal emulator. The current version is inefficient, since the algorithm still emits escape sequences for styles for every cell, even if adjacent cells have the same styling.
+  - [ ] **Automated performance measurement:** In addition to testing functionality, cy should have a system for measuring the performance of [Screens](/architecture.md#screens-and-streams). This could happen in CI as well.
+  - [ ] **Benchmarking against other terminal multiplexers:** It would be simple enough to design tests for checking cy's performance against other commonly used multiplexers.
+- [ ] **Plugin system**: Ideally this would be nothing more than something like [vim-plug](https://github.com/junegunn/vim-plug) or [lazy.nvim](https://github.com/folke/lazy.nvim), but there are several things we need in order for this to be possible.
+  - [ ] **API functions for executing external commands**
+  - [ ] **Progress bars\*:** It would be nice for Janet code to be able to show the user the progress of some long-running operation.
+  - [ ] **tmux emulation:** This would be the first proof-of-concept cy plugin. Some people really like tmux, and I intentionally built cy's layout functionality so that it would be flexible enough to emulate tmux's user interface. This does not have to be that comprehensive, it could just mimic most of tmux's common keybindings.
+- [ ] **Persistent parameter store:** This would add another target for {{api param/set}} called `:persist` (name pending) which would be a key-value store backed by an SQLite database stored in `$XDG_STATE_HOME`. Any serializable Janet value could be written to this parameter store. This persistent parameter store could be used for things like saving and restoring layouts from previous sessions, reopening frequently used projects, et cetera.
+- [ ] **fzf-cy\*:** `cy` literally uses `fzf`'s algorithm and its fuzzy finder should be able to be used as a drop-in replacement for `fzf` just like in [fzf-tmux](https://github.com/junegunn/fzf/blob/master/bin/fzf-tmux). In other words, `cy`'s fuzzy finder should support everything (within reason) that `fzf` does.