> What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.
Thanks, I think that would work fine in most cases if you can open your editor with the 'prev' version and the current version in 2 panes (or in diff mode).
This is nonsensical, there is nothing textual about the UIs being shown here. It doesn't stop being a GUI if you have a 1:1 representation of the concept within character cells.
The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
It does 2 things that are very important, 1: reviewing should not be done last, but during the process and 2: plans should result into verifyable specs, preferably in a natural language so you can avoid locking yourself into specific implementation details (the "how") too early.
While I like the concept, the side-effect pattern might be difficult for the average developer to understand (without fp-pack knowledge) in a shared codebase:
What are popular charm/bubbletea based TUIs? I use TUIs often, but for some reason none of them are based on charm/bubbletea? Might be coincidence though.
While I appreciate Charm's aesthetics, I worry it leans too heavily on GUI paradigms, like popovers and buttons, rather than prioritizing the optimal keyboard efficiency used in traditional text-based interfaces.
https://github.com/rochus-keller/OberonSystem3Native