Introduce a layer of indirection between Terminal and CharGrid, using the Screen type, which allows a Terminal to contain multiple CharGrids in different sections of the visible screen.

Prior to this commit, a single Terminal contained a stack of CharGrids, which each filled the entire size of the Terminal window.

Now, a single Terminal contains a single Screen, which is divided into ScreenSections. Each ScreenSection is a rectangular section of the screen. They are formed by splitting an existing section into two along a horizontal or vertical axis. This means that the relationship between sections that exist is always a binary tree. Each ScreenSection has an unsigned 64-bit tag. One section is identified as the 'active section' - commands that apply to the CharGrid are applied to the grid contained in this section.

Each section contains a non-empty stack of Panels. A Panel can take one of two forms: either it contains a CharGrid, or it is split into two parts, each of which contains a ScreenSection. As a result, there is a mutually recursive relationship between the definition of ScreenSection and Panel, which allows for considerable flexibility in adjusting the layout screen, while still maintaining a certain level of restraint.

This commit and its associated commit to notty-encoding add or modify several commands to the notty protocol:

• PUSH BUFFER is now PUSH PANEL, and takes as an argument the tag of the screen section being pushed to. If no argument is passed, a panel is pushed to the active section. The panel that is pushed always contains a single character grid. It also takes a boolean argument, which determines whether or not the grid retains offscreen data as it scrolls.
• POP BUFFER is now POP PANEL, and also takes as an argument the tag of screen section to pop from. If no argument is passed, the top panel of the active section is popped. A stack with 1 member cannot be popped from.
• SPLIT PANEL describes splitting a panel into two. It takes arguments defining the axis and position of the split, which panel the contents should be saved to, how resizing of child sections should be handled, and whether or not the grid in the new panel should retain offscreen data as it scrolls. Panels which are already split can be split again; the existing split sections are resized into the identified saved sections.
• UNSPLIT PANEL describes removing the split from a panel. It takes an argument identifying which of the two sections in this panel should be saved. The stack of the saved section will be pushed to the top of the section this panel is on top of; the stack of the unsaved section will be destroyed.
• ADJUST PANEL SPLIT allows an existing split panel's split to be moved or adjusted. It takes arguments defining the axis and position of the split, and how resizing of the child sections should be handled. It performs no action it the section's top is a unsplit panel.
• ROTATE SECTION DOWN rotates down the stack, putting the top of the stack on the bottom.
• ROTATE SECTION UP rotates up the stack, putting the bottom of the stack on the top.
• SWITCH ACTIVE SECTION switches which section is active. It will only perform a switch if the top panel of the target section is a single character grid.

@withoutboats here's what I've got so far.

Currently I am working to remove all usage of Config::default() as the source of configuration other than in scaffolding and the tests in various modules since I'm not sure how else we would make use of configuration with the approach I've taken so far of replacing default() methods with new(config: Config) for all structs that need to be passed configuration data.

The problem I am running into currently is what appears to be overgeneralization of the Grid class: https://github.com/withoutboats/notty/blob/master/src/terminal/char_grid/grid.rs#L24

Looking through the rest of the source code I only see two specific types of Grid: Grid<CharCell> and Grid<i32>. The reason I think of this as problematic is because there are a number of T::default() calls used to construct Grid elements--which sort of enforces the need for CharCell structs to call Config::default() in CharCell::default() to obtain configuration data, which makes it difficult for me to imagine a way to pass the Terminal-owned Config down to the CharCell. Here are a couple possiblities I am considering:

• Create a Configurable trait that requires a configure(&self, config: Config) method, add that to the Grid type constraints; then use this to configure the CharCell created by T::default().
• Remove generics from Grid entirely since the only specific type used in this library is Grid. I think this is my preferred approach, unless you anticipate new specific types of Grid in the near future.

Specifically set up a GTK main timeout function to periodically check an Arc value that indicates whether a read on the pty in the listening thread fails--this failure is taken to mean that the process on the other side of the pseudoterminal has exited.

Also improve error handling in CommandApplicator. Also decrease timeout for CommandApplicatior::apply() calls to improve responsiveness to keystrokes (notice difference between 125 and 25 milliseconds when holding down a character in scaffolding)

I cloned the repo and ran cargo build, but I see:

➜  notty git:(master) cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/withoutboats/notty-encoding`
 Downloading unicode-width v0.1.3
 Downloading mime v0.1.3
 Downloading base64 v0.1.1
 Downloading serde v0.6.15
 Downloading libc v0.2.7
 Downloading log v0.3.5
 Downloading num v0.1.31
   Compiling unicode-width v0.1.3
   Compiling libc v0.2.7
   Compiling base64 v0.1.1
   Compiling num v0.1.31
   Compiling notty-encoding v0.1.0 (https://github.com/withoutboats/notty-encoding#671ce83f)
   Compiling log v0.3.5
/home/patrick/.cargo/git/checkouts/notty-encoding-f90d2d7580660013/master/src/args/movement.rs:16:9: 16:44 error: expected type, found `/// Direction of the tab character.`
/home/patrick/.cargo/git/checkouts/notty-encoding-f90d2d7580660013/master/src/args/movement.rs:16         /// Direction of the tab character.
                                                                                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Build failed, waiting for other jobs to finish...
Could not compile `notty-encoding`.

To learn more, run the command again with --verbose.

Is this a regression introduced by https://github.com/withoutboats/notty-encoding/commit/91d7e8c0b31ce3b23d96c3d96ddc0b791263e742, or is there something wrong with my environment? I've never used Rust before so I may be missing something obvious.

Hi, one thing that was always bothering me about unix terminals is that cat /dev/urandom and similiar could corrupt the display.

It seems to me that "untyped stream of bytes" was never the right abstraction for communication between processes and interactive terminals.

I have not give it too much thought yet, and I'm looking for opinions and resources, but it seems to me that if every stream of bytes was typed (with some default), like eg. prefixed with mime type (defaulting to binary data stream) or simper-http-like protocol, then both communication between processes and between process and terminal could be much robust.

Eg. legacy process like cat, streaming bunch of bytes would output bunch of binary adta and notty would know that all data sent contains no escape codes, displaying eg. hex dump of it, and responding with no "type header" on cat's stdin.

New-world interactive processes, when outputting anything would start with a \0notty/v1\0 header, or something like that, to which terminal would respond with \0notty/v1\0 on stdin, confirming that process is attached to tthe terminal.

The scheme could be completely different.

As of writing this issue, config information is stored on a global constant called CONFIG, which is imported into several scopes, both in notty and in notty-cairo. Because configuration info is stored on a constant, the only way to reconfigure notty is to recompile it. This is not a great user experience.

There are several steps that need to be taken to make notty configs convenient to change, this issue is only the first step. Here is a broad roadmap of the whole process to making notty configured dynamically:

1. The Terminal holds a Config struct, from which all the configurable values for that terminal are accessed. At first, all terminals can be instantiated with the CONFIG constant for this. This is what this issue is about.
2. This Config struct is made into an argument, and the config info in src/cfg.rs is moved into the scaffolding terminal (though the Config type definition will stay inside of notty).
3. Add a way for scaffolding to create a Config struct at runtime from some source (probably a TOML file). This way, users can configure the scaffolding terminal without recompiling notty.

This is a great task for someone to pick up to learn the notty code base better (and probably also Rust). It doesn't interact much with the core logic of notty, but it does require you to explore how it is structured. I am glad to provide guidance and answer any questions about this task.

To sort of restate the issue, once this is done, cfg::CONFIG should be invoked in only one location, stored somewhere on the Terminal struct, and everywhere it is invoked now should instead invoke the value stored on the Terminal.

Please drop a note here if you start to work on this and I will assign the issue to you.

This is intended as a temporary fix to the "can't quit without Ctrl-C in the original terminal" problem. A more complete solution probably catches EOF in the parser and starts the shutdown there, but this works apart from the misleading error message.

Trying to quit the shell with Ctrl-D out of habit, I got the following stack trace:

➜  scaffolding git:(master) RUST_BACKTRACE=1 cargo run
     Running `target/debug/scaffolding-terminal`
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 5, message: "Input/output error" } }', ../src/libcore/result.rs:746
stack backtrace:
   1:     0x7ffb5339f240 - sys::backtrace::tracing::imp::write::h7af3c3cfd3e65a783bv
   2:     0x7ffb533a1b2b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44497
   3:     0x7ffb533a1798 - panicking::default_handler::h75ebcc0c8bcd1085rRz
   4:     0x7ffb53397eac - sys_common::unwind::begin_unwind_inner::hcec45e84262f1855m0t
   5:     0x7ffb533982f8 - sys_common::unwind::begin_unwind_fmt::h62c174e37e54c321sZt
   6:     0x7ffb5339e6b1 - rust_begin_unwind
   7:     0x7ffb533d0e7f - panicking::panic_fmt::h5f920bbc722cd548lcM
   8:     0x7ffb532e106b - result::unwrap_failed::h14713097509445665626
                        at ../src/libcore/macros.rs:29
   9:     0x7ffb532ee0cb - result::Result<T, E>::unwrap::h4578224278132733853
                        at ../src/libcore/result.rs:687
  10:     0x7ffb532e288a - main::_$u7b$$u7b$closure$u7d$$u7d$::closure.10320
                        at src/main.rs:67
  11:     0x7ffb532e21c0 - std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::closure.10309
                        at ../src/libstd/thread/mod.rs:277
  12:     0x7ffb532e2169 - sys_common::unwind::try::try_fn::h14296686403988533152
                        at ../src/libstd/sys/common/unwind/mod.rs:127
  13:     0x7ffb5339e63b - __rust_try
  14:     0x7ffb5339c20d - sys_common::unwind::inner_try::h27915955daa5bb0coXt
  15:     0x7ffb532e20ce - sys_common::unwind::try::h12233384044057444796
                        at ../src/libstd/sys/common/unwind/mod.rs:123
  16:     0x7ffb532e1f40 - std::thread::Builder::spawn::_$u7b$$u7b$closure$u7d$$u7d$::closure.10284
                        at ../src/libstd/thread/mod.rs:277
  17:     0x7ffb532e2c0c - boxed::F.FnBox<A>::call_box::h7394299706424739120
                        at ../src/liballoc/boxed.rs:541
  18:     0x7ffb533a06a9 - sys::thread::Thread::new::thread_start::h47cad50136a0a353LOy
  19:     0x7ffb50770181 - start_thread
  20:     0x7ffb50f9247c - __clone
  21:                0x0 - <unknown>

It looks like the issue is in scaffolding/src/main.rs at:

    thread::spawn(move || {
        let output = Output::new(BufReader::new(tty_r));
        for cmd in output {
            tx_out.send(cmd.unwrap()).unwrap();
        }
    });

Because I suppose in src/output/mod.rs, Output::next is returning None.

running 2 tests test cfg::toml::tests::test_default ... FAILED test cfg::toml::tests::test_update_from_file ... FAILED

failures:

---- cfg::toml::tests::test_default stdout ---- thread 'cfg::toml::tests::test_default' panicked at 'assertion failed: (left == right) (left: "Monospace 10", right: "Inconsolata 10")', src/cfg/toml.rs:244 note: Run with RUST_BACKTRACE=1 for a backtrace.

---- cfg::toml::tests::test_update_from_file stdout ---- thread 'cfg::toml::tests::test_update_from_file' panicked at 'assertion failed: (left == right) (left: "Monospace 10", right: "Inconsolata 10")', src/cfg/toml.rs:244

failures: cfg::toml::tests::test_default cfg::toml::tests::test_update_from_file

We need to know the dimensions of the visible area of the terminal in terms of characters for a variety of use cases. Currently, we attempt to derive this information from the FontExtents struct of the cairo library, which has several fields.

However, the information presented by this struct is not the information we actually want, and it results in weird dimensions in several ways - opening vim in the scaffolding terminal is a good demonstration of the issue.

If someone could figure out how to derive from a cairo canvas or a font the actual dimensions of a character in that font, that would be really helpful. Assuming a monospace font is fine.

I was able to build and run the demo terminal by changing line 25 in image_renderer.rs from 'as i64' to 'as i32'.

I know very little about Rust... possible to automatically infer that type?

I realize this project had very lofty goals from the start, and that it would take a tremendous amount of time and effort. That being said, the latest commit was nine months ago. I'm not trying to complain about this as I realize people have busy lives, but I am wondering if you plan on picking this back up or if it is abandoned.

Joyful compiler errors

error[E0038]: the trait `cmds::EscCode` cannot be made into an object
 --> /home/seunlanlege/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:6:5
  |
6 |     fn write(&mut self, &EscCode) -> io::Result<()>;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
  |
  = note: the trait cannot contain associated consts like `OPCODE`

error[E0038]: the trait `cmds::EscCode` cannot be made into an object
  --> /home/seunlanlege/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:12:5
   |
12 |     fn write(&mut self, code: &EscCode) -> io::Result<()> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
   |
   = note: the trait cannot contain associated consts like `OPCODE`

error: aborting due to 2 previous errors

error: Could not compile `notty-encoding`.
warning: build failed, waiting for other jobs to finish...
error: build failed

rustc version rustc 1.22.0-nightly (f1b5225e8 2017-10-01)

I have a little idea but don't know how it could be done or if it's even doable or not :

The magic wormhole is a fifo between multiple terminal. Let's take an example.

• You open a terminal. You connect to ssh. You then enter a container with "lxc-attach -n foobar".
• You open another terminal. You start another ssh session on another machine which can't reach the lxc container.
• You start/enter/trigger the magic wormhole to bind the two terminal to get data from one term to the other. That way you can transfer files or even pipe commands between the two terminals.

For now you can mimic this with tmux by using buffer copy and all but it's quite complex and not very reliable.

I discussed a bit of this on alacritty's irc channel and was redirected here. What do you think of this ? Is it out of scope ? technically not feasible ?

Some apps like debconf support dialog for drawing various widgets in (traditional) terminals.

If notty can operate as a drop-in replacement for dialog (or whiptale), then it may in that way find some customers!

Hi,

I'm trying to compile notty and have run into an error building the encoding package. Here is the output from my build:

➜  notty git:(master) cargo build --verbose
       Fresh uuid v0.3.1
       Fresh base64 v0.1.1
       Fresh num-traits v0.1.37
       Fresh unicode-width v0.1.4
       Fresh log v0.3.7
   Compiling notty-encoding v0.1.0 (https://github.com/withoutboats/notty-encoding#ba5daba3)
       Fresh num-integer v0.1.34
     Running `rustc --crate-name notty_encoding /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=46ffb3a5a218e748 -C extra-filename=-46ffb3a5a218e748 --out-dir /Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps -L dependency=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps --extern base64=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps/libbase64-21fea01bef6f0feb.rlib --cap-lints allow`
       Fresh num-iter v0.1.33
       Fresh num v0.1.37
       Fresh serde v0.6.15
       Fresh mime v0.1.3
error[E0038]: the trait `cmds::EscCode` cannot be made into an object
 --> /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:6:5
  |
6 |     fn write(&mut self, &EscCode) -> io::Result<()>;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
  |
  = note: the trait cannot contain associated consts like `OPCODE`

error[E0038]: the trait `cmds::EscCode` cannot be made into an object
  --> /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/client.rs:12:5
   |
12 |     fn write(&mut self, code: &EscCode) -> io::Result<()> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `cmds::EscCode` cannot be made into an object
   |
   = note: the trait cannot contain associated consts like `OPCODE`

error: aborting due to 2 previous errors

error: Could not compile `notty-encoding`.

Caused by:
  process didn't exit successfully: `rustc --crate-name notty_encoding /Users/mgrunder/.cargo/git/checkouts/notty-encoding-26bc718f9ba2caca/ba5daba/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=46ffb3a5a218e748 -C extra-filename=-46ffb3a5a218e748 --out-dir /Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps -L dependency=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps --extern base64=/Users/mgrunder/dev/rust-foss-projects/notty/scaffolding/target/debug/deps/libbase64-21fea01bef6f0feb.rlib --cap-lints allow` (exit code: 101)

rustc:

➜  notty git:(master) rustc --version
rustc 1.19.0-nightly (06fb4d256 2017-04-30)

OS Information:

➜  notty git:(master) system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: OS X 10.11.6 (15G1217)
      Kernel Version: Darwin 15.6.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: MG-MBP
      User Name: Michael Grunder (mgrunder)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Disabled
      Time since boot: 2 days 13 minutes

I was able to find a few places on the net mentioning this error but unfortunately I don't know nearly enough about rust to figure out a solution. Hopefully I'm not missing something totally obvious here :smiley:

Edit: I get the same error in Ubuntu.