A while ago I looked at making a project for terminal abstraction. I dived into it because that’s what my naive self thought was a good idea. Turns out terminal control is really hard, because there is such variety in how to access various bits of functionality, from over a serial cable right through to powershell, including the possibility of escape sequences over stdout (don’t mix this with system calls).
I lost heart and the project stalled. Because of the talk around the roadmap about ergonomics and ergonomic libraries, I thought this was a good time to talk about this again.
The community is working on creating some ergonomic libraries. A terminal library was mentioned. Whilst I don’t think the base libraries exist for an ergonomic term lib, maybe this is the time to talk about creating those base libs!
Below I cross-post a proposal about how to move forward. It’s not really about the technical stuff, that can come later if there is sufficient interest to make progress.
TL;DR I’m just a community member and whilst I have the enthusiasm, I know I don’t have all the knowledge required to complete this project on my own. Therefore I’m looking for others that consider this a priority and would be willing to lend their expertise to help develop this project.
We should make the first library totally about platform abstraction, with the lowest cost possible. We should focus on providing all the functionality we can, with ideally 0-cost over the system calls. We should always provide the fastest way to do things, even if there is some API overlap. This can be handled in a higher-level ergonomic crate on top that knows how to delegate the the right methods.
- Get more stakeholders. There are people in the community that have better knowledge of this domain than me, and they should be involved at least in an advisory capacity, or this project will struggle to achieve its goals.
- Make an (incremental) plan. What functionality should we have at the end? Can we split this functionality into more deliverable units? I would think using one of the existing term crates as a starting point and pulling out a platform-agnostic API would be the first step. Then implementing this API for lots of backends (platforms). Then increasing the surface area whilst maintaining support for all backends.
- Implement the first round of this functionality for all platforms.
- Advertise that we have done this. Think of a cool pun name for the library (optional). Stress that this is an inclusive project where we need lots of contributors with specialist knowledge of the different platforms. Be open about where we are unsure we have the best approach, and encourage people to contribute if they have a better idea.
- In parallel
- Make (possibly breaking) changes to the API to make it “better” where necessary.
- Add more API surface area as specified in the plan.
- When we have all the APIs we want, plan for 1.0 and stabilization. Let the libs settle without adding new features to see what problems come up. Encourage people to start experimenting writing ergonomic libs on top and see what issues arise.
- Release 1.0.
- Market the library and get other people to make ergonomic libs on top for different use cases (TUI (a-la vim), just colored output, status line (a-la pacman).
It would be good if we could make using a terminal as easy as clap/structopt makes handling command line args. But it’s a harder and more risky goal than CLI parsing because there is more variation between platforms and more platform-specific code is required.