Road Map to Version 0.2

[withoutboats]

I would like to start versioning these crates instead of just pegging them at 0.1 at some point soon, incrementing them all to 0.2 to distinguish from the phase up until now. After this, any breaking change to a crate's public API would require a minor version increment (because we're still pre-1.0), and any visible change to any command recognized by notty would also require a minor version increment of the notty library. Between 0.2 and 1.0, at least, I don't think its valuable to keep the versions in sync between different crates associated with the project.

At version 0.2, we'll put notty, notty-encoding, and the GTK terminal (under a better name) on crates.io. Any subcrates of these should be bundled up into these three crates by whatever means is most appropriate (thinking of pangocairo and tty).

Here's the roadmap of features I'd like to see before we increment the minor version:

notty

• Multi-grids. This is essential to getting scrolling working properly, and is a major differentiating feature of notty. To elaborate on this, the feature is that you can divide the screen into multiple 'grids', each of which can retain off-screen state as you move around them. You can either divide the screen into two rectangular grids, or you can stack a grid completely over another (so no non-rectangular subdivisions of the screen can be created through this process). Things that can wait: support for adding scrollbars to the subgrids.
• Local echo. I'd like to get line-oriented local echo working properly. This is basically implementing a subset of GNU readline, but on the terminal side of the tty. So left and right arrow keys, home/end, and all of the tty special chars (Ctrl-W, Ctrl-U etc). Things that can wait: setting your own control behaviors in local echo, screen-oriented local echo.
• Full input. notty should have a mode which sends all keyboard input: key releases, pressing modifier keys, etc. This needs to be revised, I don't think its right at the moment, but I really don't remember.

scaffolding

• Basic usability things. Actually get the grid dimensions right, for example. Don't have any known crashes.
• A way to scroll the active grid; this will probably be a keyboard shortcut right now and not visible scrollbars.
• Non-compile time configurations.
• Tabbed terminals. This is the only really big change to scaffolding. Personally, I need this to be willing to start dogfooding the terminal, and I think it would put good organizational pressure on the scaffolding crate, which currently is very poorly organized.
• A better name than scaffolding. I'm currently inclined to use the name anterminal after Gary Bernhardt's presentation.

Reach goals

• Get notty off of nightly. We're mainly on notty because we use the io::Chars iterator for parsing output.
• A build.rs in scaffolding that reliably installs C dependencies like GTK, or at least tells users that they need to install them.

Both of these goals are aimed at getting scaffolding/anterminal's build instructions down to:

1. Download Rust from rust-lang.org or your package manager.
2. cargo install anterminal

[waynr]

I would like to include in this some consideration for the public API offered by notty.

[withoutboats]

I notice that notty has a number of people watching it, so if anyone is following the (decidedly languid) development of notty, here's an update on getting notty into a state that could be called 'usable':

notty (lib)

• Multigrid support has been in for a while, but I've realized it needs one more layer of indirection between a Panel (which contains a character grid) and the character grid itself, to implement the logic for what cells of that grid are drawn into that panel. Currently we just take a square subsection of the grid, but this needs to be more complicated to handle reflow as in implement or document text reflow #38
• I'm having second thoughts about the security implications of local echo and may delay further work on it or even cut it out. The issue is predictive text. If we want predictive text in a local echo, we need an API for the controlling process to transmit its 'suggestion' to the user, which the user then selects. When the program exits, the suggested input may be left in the terminal, enabling a kind of privilege escalation if the user is unattentive.
• Still need to finalize the input protocol, this isn't much coding work, just reaching a decision.

scaffolding/anterminal

• Seems basically usable. I now have two systems to test it on (one OS X and one Linux), which is good. On my Linux box its currently got some rendering issues, on neither of them is setting the shell working correctly.
• This task expanded to be scrolling + copy and paste, and now paste is in. Scrolling will be implemented in connection with the support for reflow mentioned above. Copy is more complicated - we need general support for interacting with the character grid as an area of text, so you can copy a highlighted selection. This gets into design questions with multgrid as well.
• Configs are now managed through TOML files. Thanks @waynr.
• Not going to implement tabbed terminals I don't think; I'd just recommend using tmux for now.
• Going to rename scaffolding to 'anterminal' and publish as a separate package once I think its usable as an ANSI terminal.

Looking beyond 'making this a usable terminal,' I think there the road map bifurcates:

1. The first project is making it feasible for people to write applications that take advantage of notty's features. I have a design in mind for a framework which would take the role of both ncurses and GNU readline, using notty's features on notty terminals and emulating them on non-notty terminals.
2. The second project is creating an adoptable terminal with notty support. scaffolding/anterminal was never really intended to be a widely usable terminal, I built it so I could confirm the notty lib was working. Its occurred to me that rather than add more features to scaffolding, it might be a better approach to try to write a wrapper around notty which implements the API of GNOME VTE, so that any VTE-based terminal (including gnome-terminal, termite, guake, and many more) can be rebuilt against notty.