search

rust-crates / ergo

the ergo crate ecosystem: making rust's ecosystem more ergonomic, therefore more fun.
Other
58 stars 3 forks source link

[meta] ergo_term subcrate #9

Open vitiral opened 6 years ago

vitiral commented 6 years ago

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

vitiral commented 6 years ago

Also see my comment from the quicli issue https://github.com/killercup/quicli/issues/11

richard-uk1 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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):

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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