[meta] ergo_term subcrate

[vitiral]

This is a meta issue for the future ergo_term subcrate. This dicussion should find out:

• what features should it support
• what the API of this subcrate should look like
• what crates should it depend on
• should it be included in ergo directly (or should someone need to use it as a separate dependency).

[vitiral]

Also see my comment from the quicli issue killercup/quicli#11

[richard-uk1]

I would suggest that this should be opt-in, since it will be potentially large. I think there might be more work to do on the building blocks before starting to make a TUI crate, but maybe this is a good place to coordinate.

[richard-uk1]

I think that the best inspiration for this should be https://pdcurses.sourceforge.io/doc/index.html. It supports lots of platforms and will have the platform-specific code we need. I'm going to read about it now.

[vitiral]

Also check out the termstyle crate, which I wrote to start to solve this problem.

One of the main goals of termstyle is to make it not only easy to write formatting in code but also write it in a serde syntax. This makes it much easier to test, since you can write out what you expect in fairly short form.

Personally, I feel that treating the terminal as the following is way too complex to be ergonomic:

windows which may be thought of as two-dimensional arrays of characters representing all or part of a terminal's screen. The windows are manipulated using a procedural interface

The majority of CLI applications only need a things (IMO):

• color
• tables
• user input
• progress bars (maybe in parallel)

progress bars are nearly impossible to test, but the others could be pretty trivially tested if there was a simple way to express the format that wasn't copy/pasting raw formatting bytes (which are different on different platforms!)

Doing full terminal interaction is basically a creating a GUI, which is out of scope for the ergo project (I feel). Comments/discussion welcome!

[richard-uk1]

Doing full terminal interaction is basically a creating a GUI, which is out of scope for the ergo project (I feel).

I think it is possible to solve both problems in a single crate, but I agree that this shouldn't be the ergo crate. I way I think it should be structured is: single crate providing terminal functionality (quite complex, call it curses for now), with multiple crates providing abstractions on top of this (of which ergo would be one). Curses would provide 2 modes, 1 for procedures to alter the terminal (form-feed, change color etc.) whilst the other would provide a virtual screen, with an event queue. The second of these wouldn't have to be implemented immediately.

curses would prioritise 0-cost, whist ergo would provide perhaps non-zero cost abstractions on top to make it ergonomic.

What do you think?

[richard-uk1]

Ok my suggestion for making progress is as follows

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.

1. 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.
2. 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.
3. Implement the first round of this functionality for all platforms.
4. 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.
5. In parallel
   1. Make (possibly breaking) changes to the API to make it lower-cost where necessary.
   2. Add more API surface area as specified in the plan.
6. 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.
7. Release 1.0
8. 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.

[vitiral]

Hey, sorry I've been absent. My 6mo old spilled coffee on my laptop a month ago and I'm just getting back up to speed.

I haven't read your comment, but I wanted to leave a couple of additional crates for ergo_term:

• rustyline
• shlex
• docs for how to use the above to re-parse StructOpt structs (it's possible!)

Edit: it's possible this is actually the domain of quicli... that might make more sense!