zellij-org/zellij

A terminal workspace with batteries included

Zellij

[Installation] [Screencasts & Tutorials] [Configuration] [Layouts] [FAQ]

What is this?

Zellij is a workspace aimed at developers, ops-oriented people and anyone who loves the terminal. Similar programs are sometimes called "Terminal Multiplexers".

Zellij is designed around the philosophy that one must not sacrifice simplicity for power, taking pride in its great experience out of the box as well as the advanced features it places at its users' fingertips.

Zellij is geared toward beginner and power users alike - allowing deep customizability, personal automation through layouts, true multiplayer collaboration, unique UX features such as floating and stacked panes, and a plugin system allowing one to create plugins in any language that compiles to WebAssembly.

You can get started by installing Zellij and checking out the Screencasts & Tutorials.

For more details about our future plans, read about upcoming features in our roadmap.

How do I install it?

The easiest way to install Zellij is through a package for your OS.

If one is not available for your OS, you could download a prebuilt binary from the latest release and place it in your $PATH. If you'd like, we could automatically choose one for you.

You can also install (compile) with cargo:

cargo install --locked zellij

Try Zellij without installing

bash/zsh:

bash <(curl -L zellij.dev/launch)

fish/xonsh:

bash -c 'bash <(curl -L zellij.dev/launch)'

How do I start a development environment?

• Clone the project
• In the project folder, for debug builds run: cargo xtask run
• To run all tests: cargo xtask test

For more build commands, see CONTRIBUTING.md.

Configuration

For configuring Zellij, please see the Configuration Documentation.

What is the current status of the project?

Zellij should be ready for everyday use, but it's still classified as a beta. This means that there might be a rare crash or wrong behaviour here and there, but that once found it should be fixed rather quickly. If this happens to you, we would be very happy if you could open an issue and tell us how to reproduce it as best you can.

Roadmap

Presented here is the project roadmap, divided into three main sections.

These are issues that are either being actively worked on or are planned for the near future.

If you'll click on the image, you'll be led to an SVG version of it on the website where you can directly click on every issue

License

MIT

Sponsored by

 

zellij's Issues

What I'm up to this week (Oct 12, 2020)

Hey, so I thought it can be cool to manage me weekly TODO list here. Hopefully it's not too incoherent :)

Things I'd like to get done by EOW:

• Get vim to work, including scrolling, inside a pane
• Fix the corners of the pane separations (-|- should be ┼, etc.)
• Properly handle special character styles inside the terminal (bold, italic, underline, etc.)
• Fix a bug where in vim the status line is never deleted, just overwritten

Bonus points if I finish everything super quick:

• Start working on scrolling inside a pane implement scrolling inside a pane (easier than I thought)
• Fix flickering when resizing panes (I guess some sort of render priority for panes so they don't override each other?)

What Brooks is up to this week (19/10/2020)

I'll be a tad busy, but I'll try for the following things:

• Push my work to Git somewhere
• Implement an "event-loop" system for module calling
• Write a very small "client" library that makes writing plugins trivial and abstracts away the WASM interface for plugin developers

What Aram is up to this week (19/10/2020)

• implement IPC bus
• implement closing a pane

Extras after I've eaten my vegetables:

• improve performance of opening a pane
• fix vim scrolling issue when its lines get wrapped through mosaic
• get htop to work

(fyi @qballer, @TheLostLambda )

Color resetting issues in Starship prompt

This was discovered by @TheLostLambda. What happens is that when the prompt has multiple colors, they are not always reset properly (eg. to the default terminal color). I think this happens because there's a bit of a mess right now when we reset named/ansi-code colors (somewhere we probably reset one and not the other).

Hotkeys are a usability problem

The reason I never use tmux is because I can never remember the hotkeys.
It'd be useful to have a command which reminds you what to do.

In addition, it'd be useful to have commands which you can type to perform an action.

Compatibility neovim, open up a new line following the current line and add text there, delete current line

• open neovim
• open a file
• go to any line
• press o to open a new line following the current line
  Moves the line down, hides the line number.
  EDIT: Happens if you delete the current line as well
  

When splitting multiple times vertically or horizontally, the app crashes

This is likely due to us not setting a minimum size for new panes.

reset causes an unhandled error

When running reset in a new mosaic session, we get an unhandled error:

0: rust_begin_unwind
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
1: core::panicking::panic_fmt
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
2: core::option::expect_none_failed
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
3: core::result::Result<T,E>::unwrap
    at /home/kyle/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:973
4: <mosaic::pty_bus::VteEventSender as vte::Perform>::osc_dispatch
    at ./src/pty_bus.rs:140
5: vte::Parser::osc_dispatch
    at vte-0.8.0/src/lib.rs:195
6: vte::Parser::perform_action
    at vte-0.8.0/src/lib.rs:276
7: vte::Parser::perform_state_change
    at vte-0.8.0/src/lib.rs:165
8: vte::Parser::advance
    at vte-0.8.0/src/lib.rs:128
9: mosaic::pty_bus::stream_terminal_bytes::{{closure}}
    at ./src/pty_bus.rs:190
10: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
    at /home/kyle/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:79
11: <async_std::task::builder::SupportTaskLocals<F> as core::future::future::Future>::poll::{{closure}}
    at async-std-1.6.2/src/task/builder.rs:198
12: async_std::task::task_locals_wrapper::TaskLocalsWrapper::set_current::{{closure}}
    at async-std-1.6.2/src/task/task_locals_wrapper.rs:60
13: std::thread::local::LocalKey<T>::try_with
    at /home/kyle/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:265
14: std::thread::local::LocalKey<T>::with
    at /home/kyle/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:241
15: async_std::task::task_locals_wrapper::TaskLocalsWrapper::set_current
    at async-std-1.6.2/src/task/task_locals_wrapper.rs:55
16: <async_std::task::builder::SupportTaskLocals<F> as core::future::future::Future>::poll
    at async-std-1.6.2/src/task/builder.rs:196
17: async_task::raw::RawTask<F,R,S,T>::run
    at async-task-3.0.0/src/raw.rs:502
18: async_task::task::Task<T>::run
    at async-task-3.0.0/src/task.rs:265
19: smol::multitask::Worker::tick::{{closure}}
    at smol-0.1.18/src/multitask.rs:333
20: scoped_tls::ScopedKey<T>::set
    at scoped-tls-1.0.0/src/lib.rs:137
21: smol::multitask::Worker::tick
    at smol-0.1.18/src/multitask.rs:333
22: smol::run::run::{{closure}}::{{closure}}
    at smol-0.1.18/src/run.rs:124
23: scoped_tls::ScopedKey<T>::set
    at scoped-tls-1.0.0/src/lib.rs:137
24: smol::run::run::{{closure}}
    at smol-0.1.18/src/run.rs:116
25: smol::context::enter
    at smol-0.1.18/src/context.rs:8
26: smol::run::run
    at smol-0.1.18/src/run.rs:115
27: async_std::task::builder::Builder::blocking::{{closure}}::{{closure}}
    at async-std-1.6.2/src/task/builder.rs:170
28: async_std::task::task_locals_wrapper::TaskLocalsWrapper::set_current::{{closure}}
    at async-std-1.6.2/src/task/task_locals_wrapper.rs:60
29: std::thread::local::LocalKey<T>::try_with
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/thread/local.rs:265
30: std::thread::local::LocalKey<T>::with
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/thread/local.rs:241
31: async_std::task::task_locals_wrapper::TaskLocalsWrapper::set_current
    at async-std-1.6.2/src/task/task_locals_wrapper.rs:55
32: async_std::task::builder::Builder::blocking::{{closure}}
    at async-std-1.6.2/src/task/builder.rs:167
33: std::thread::local::LocalKey<T>::try_with
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/thread/local.rs:265
34: std::thread::local::LocalKey<T>::with
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/thread/local.rs:241
35: async_std::task::builder::Builder::blocking
    at async-std-1.6.2/src/task/builder.rs:160
36: async_std::task::block_on::block_on
    at async-std-1.6.2/src/task/block_on.rs:33
37: async_std::rt::RUNTIME::{{closure}}::{{closure}}
    at async-std-1.6.2/src/rt/mod.rs:30
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Create a --debug flag that would help communicate compatibility issues

When used, this flag would log all STDOUT bytes received on the pty of each pane to a separate log file. This will help debug compatibility problems (eg. things not displaying or behaving correctly in the terminal) without having to replicate the environment in which they were created.

Feature: Design and implement a status bar

The status bar can be something like airline, or it can be a new concept. For the time being it should display the shortcuts for the current input mode (showing the user what they can press right now in order to perform actions on the screen and updating itself accordingly).

In the future, it can also contain things like:

• Minimized panes that don't fit on screen
• List of tabs
• System information (through a plugin)
• Other ideas?

What Aram is up to this week (02/11)

This week I'm going to concentrate on making Mosaic usable in my day-to-day development. For me this means connecting it to an externally running instance or ranger (for now I'll be running it in a different terminal window) that would send Mosaic commands through the IPC bus to open files in new panes.

Specific tasks:

• Fix the OpenFile API call so that it opens files more intelligently (look for the largest pane and split it horizontally/vertically along its longest side)
• Provide an option to have "max panes" so that any new pane added would close a previous pane
• Provide a "full screen" control that would have one pane temporarily occupy the whole screen.

MVP - making mosaic public

exposing mosaic to public development, trying to commit to 01.11.2020:

Primary Goals

• running raw mode application like bandwhich in mosaic
• scrolling inside a pane
• IPC bus
• fix borders
• possibility to close a pane

Secondary goals:

• github action
• WIP Readme.
  • Roadmap
  • Plugin research goals
• Org Icon - Done!

error thread screen panicked at cursor out of bounds when calling git log

When calling both git log and git log --oneline

Originating Thread(s):
1. stream_terminal_bytes: AsyncTask
2. screen_thread: HandlePtyEvent

Error: thread 'screen' panicked at 'cursor out of bounds': src/terminal_pane/scroll.rs:381
   0: mosaic::errors::handle_panic
             at src/errors.rs:15:21
   1: mosaic::start::{{closure}}
             at src/main.rs:187:13
   2: std::panicking::rust_panic_with_hook
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:530:17
   3: rust_begin_unwind
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:437:5
   4: core::panicking::panic_fmt
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libcore/panicking.rs:85:14
   5: core::option::expect_failed
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libcore/option.rs:1261:5
   6: core::option::Option<T>::expect
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:344:21
   7: mosaic::terminal_pane::scroll::Scroll::add_character
             at src/terminal_pane/scroll.rs:378:28
   8: <mosaic::terminal_pane::terminal_pane::TerminalPane as vte::Perform>::print
             at src/terminal_pane/terminal_pane.rs:362:9
   9: mosaic::terminal_pane::terminal_pane::TerminalPane::handle_event
             at src/terminal_pane/terminal_pane.rs:101:17
  10: mosaic::tab::Tab::handle_pty_event
             at src/tab.rs:376:13
  11: mosaic::start::{{closure}}
             at src/main.rs:276:29
  12: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
  13: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/thread/mod.rs:475:17
  14: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panic.rs:318:9
  15: std::panicking::try::do_call
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:348:40
  16: __rust_try
  17: std::panicking::try
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:325:15
  18: std::panic::catch_unwind
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
  19: std::thread::Builder::spawn_unchecked::{{closure}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/thread/mod.rs:474:30
  20: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ops/function.rs:233:5
  21: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/sys/unix/thread.rs:87:17
  22: start_thread
  23: clone

mosaic-3.log

Compatibility, neovim, nerd tree

So if you open neovim and then nerd_tree with e .

• select a file
• open it(won't show from line 1)
• open nerd_tree again(glitch happens)

If you scroll up and down, it updates and you see nerd_tree normally
Happens with files that have long lines

mosaic-3.log

Closing a pane that's in fullscreen results in an error

Steps to reproduce:

• Open a new pane
• Toggle to full screen
• Try to close with either ctrl-x or 'exit'
  results in:

thread 'screen' panicked at 'called `Option::unwrap()` on a `None` value', src/screen.rs:355:59                                                           
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace                                                                         
thread 'async-std/runtime' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/pty_bus.rs:251:18                                        
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any', src/main.rs:420:31

Bug: Panic while trying to paste a multiline command into the shell

Continuing from #93

Steps to reproduce:
Trying to paste this multiline command into fish shell causes a panic.

echo -ne (\
        df -l -h | grep -E 'dev/(xvda|sd|mapper)' | \
        awk '{printf "\\\\t%s\\\\t%4s / %4s  %s\\\\n\n", $6, $3, $2, $5}' | \
        sed -e 's/^\(.*\([8][5-9]\|[9][0-9]\)%.*\)$/\\\\e[0;31m\1\\\\e[0m/' -e 's/^\(.*\([7][5-9]\|[8][0-4]\)%.*\)$/\\\\e[0;33m\1\\\\e[0m/' | \
        paste -sd ''\
    )

With error:

Error: thread 'screen' panicked at 'swap_remove index (is 36) should be < len (is 1)': library/alloc/src/vec.rs:979

I don't think the issue is with escaping the newline character, because I have tried other simple multiline echo command and it seems to work properly.

Mosaic doesn't react to terminal window size change events

It should react to these by listening to the SIGWINCH event (https://en.wikipedia.org/wiki/Signal_(IPC)#SIGWINCH)

As a start, it should resize all panes on the screen relative to their previous size. In the future we might do this more intelligently (eg. remove some panes with a priority and show them as 'minimized' or some such).

Panic: cursor out of bounds

I'm not sure what's causing the panic, but it happens when I try to run my react server. A point to note is that it doesn't panic when there's a single pane.

Panic message:

Originating Thread(s):
1. stream_terminal_bytes: AsyncTask
2. screen_thread: HandlePtyEvent

Error: thread 'screen' panicked at 'cursor out of bounds': src/terminal_pane/scroll.rs:380
   0: mosaic::errors::handle_panic
   1: std::panicking::rust_panic_with_hook
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:581:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484:9
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18
   4: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483:5
   5: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85:14
   6: core::option::expect_failed
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1226:5
   7: mosaic::terminal_pane::scroll::Scroll::add_character
   8: mosaic::terminal_pane::terminal_pane::TerminalPane::handle_event
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
  10: core::ops::function::FnOnce::call_once{{vtable.shim}}
  11: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042:9
      <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys/unix/thread.rs:87:17
  12: start_thread
  13: clone

Logfile:
mosaic-3.log

What Aram is up to this week (09/11)

I'm happy to report this I'm now using Mosaic as part of my IDE. Works great so far :)

This week I plan to:

• Fix the Starship prompt line break issue
• Fix the Starship prompt colour resetting issue
• Fix the hang on exit issue
• Make cmd on mac work like ctrl (hopefully I can steal @qballer for some help debugging this)
• Start laying down the groundwork for a layout engine

Layouts: warn of Percentage is more than 100 or less than 100

When defining layouts (for example with the --layout path/to/layout.yaml flag), we can define them using percentage. For example like this:

---
direction: Horizontal
parts:
  - direction: Vertical
    parts:
      - direction: Horizontal
        split_size:
          Percent: 20
      - direction: Horizontal
        split_size:
          Percent: 80
    split_size:
      Percent: 80
  - direction: Vertical
    split_size:
      Percent: 20

When parsing this file, we should get an error if the sum of a certain parts array is larger or smaller than 100%.

mac use-ability

I've been testing (playing?) with Mosaic in my mac machine in the last couple of days. I even created silly #11 to workaround mosaic not running in mac and I've seen several issues:

• arrow keys don't seem to work inside vim
• vim rendering looks somewhat worse from what is shown in @imsnif working machine.
• I get a few exceptions here and there
• htop issue while running it, which is common to Linux as well.

This makes sense in the early phases of the project. I'm going to try and work on mac and will document the process here.
there is also the question of making the CMD key the default leader. I'm amazed it run with such little changes, which is very cool. I'm mainly communicating here because some errors are general and some not, some concerns are more of UX rather than anything else.

Feature: Implement persistent sessions

Mosaic should be able to run in the background regardless of whether a terminal window is open or not. New terminal windows should be able to 'attach' to existing sessions or create new ones.

Mosaic reacts to "move focus" commands when one pane is maximized

To reproduce:

• open 4 panes
• make the focused pane occupy the whole screen (at the time of writing this is done with ctrl+e)
• move focus (at the time of this writing this is done with ctrl+p)
• see that the mouse cursor moves to its location on the other panes that are not visible

This command should be blocked when there is a pane in full focus.

Feature: implement directional change focus

Implement commands for changing the focus of the pane up/down/right/left.
If there are multiple panes in that direction, it should move to the pane with the most overlapping space.

Starship multi-line prompt doubles up when line wrapping

I think this is an issue with the current implementation of line wrapping and should hopefully be fixed in the refactoring of the very same area in the code that I'm doing right now. @TheLostLambda, I'll ping you to give this another shot once it's done - thanks!

Feature: Shortcut for opening a new pane in current working directory

The new pane should be opened with the current working directory of the active pane instead of the default directory (/home/user in case of Linux)

use std::env;
let path = env::current_dir()?;

This should be helpful while implementing this feature.

htop up and down arrow keys don't work and cause wierd side affect

OS: mac os
terminal app: iterm/Alacritty

Issue:

When opening HTOP in mac (confirmed both in Alacritty and iterm2) HTOP doesn't respond to up and down arrow keys.
After exiting HTOP with the q key any typing renders unclear output. The issue only occur if you attempt the up/down keys beforehand

.

refactor Terminals to be panes

In the screen module, there is a terminal BTreeMap attribute which is a collection of all terminal panes, it should be refactored to panes where the id is either RawFd or BuiltInPaneId (connected to #71 ), in the future, this enum will have another option called plugin id.

Refactor: In Screen (src/screen.rs) change internal Winsize to PositionAndSize

In our Screen, we use libc's Winsize to track the full screen size (as an attribute on screen itself). Now that we have our own struct to track this (PositionAndSize) we should use it instead.

Once we do that, we can merge the two methods on Screen that change its size (namely change_size and change_size_p).

Bug: Deleting a multiline command deletes the previous line.

This is on bash.

Bug, Compatibility: neovim switching modes

switching between modes in neovim results in weird glitches.
Steps to reproduce:

• open a file in neovim
• move cursor anywhere in the file
• switch to Insert mode

mosaic-3.log

Mosaic doesn't expand when resizing the terminal window and it panics

OS: mac-os
terminal: alacritty

When I run Mosaic inside Alaacritty, I get into a situation where mosaic pane size is stuck (and sometimes panics).

Reconstruct:

• Open Alacritty to not take full-screen area.
• run mosaic
• resize alacritty to full screen
• notice that Mosaic is still somewhat in original size and doesn't reflow.
• notice that vim didn't stretch after the resize.

Planning meeting 17/09

Agenda:

• Refactoring + testing of horizontal/vertical split and horizontal/vertical resizing

htop isn't working

At the moment, when we start htop inside a mosaic pane, it panics (because of an unhandled CSI).

Planning meeting 10/09

Agenda:

• Demonstrate POC with vertical+horizontal splits and resizes

Fish + Starship Predictive Autocomplete is Mistyled

Expected

Actual

We are missing the blue and the dimmed prediction part!

Excitingly, (and perhaps expectedly?) the predicted bit doesn't show up in any logs. The cat does, and is blue when I cat the log outside of mosaic, but white inside.

Here is the log with the miscoloured cat:
mosaic-3.log

I honestly have no idea what Fish / Starship is doing to render that predicted region...

Implement Error handling

Right now we panic when there's an error. Since we do that inside a thread, it's very hard to tell what caused the error. This is especially true if the error we end up getting is an error from another thread that fails to send a message to the panicked thread.

We need some system that would (among other things) allow us to get proper errors across our threads. This will greatly ease development.

Feature: Implement tabs

One should be able to tab between several Screens in an existing session. Each screen can be split into multiple panes.

Planning meeting 24/09

Agenda:

• Progress report on terminal compatibility (bandwhich+diskonaut running inside panes)
• idea: create layouts by "drawing" with the mouse, save those layouts as box-ui plain text so that it can be read by a Human too
• idea: built-in feature: the pane-box, if panes have no room (eg. resized terminal window or resized another pane "over" them), they appear inside a portion of the ui just as their title (box with a list of them? bold if they have activity? red if they crashed/errored?)

Starship multi-line prompt doesn't play nice with resizes

I started working on this issue and then realized it's a little bit of a rabbit hole, so I'm going to update on my progress here.

Initial issue:

• When rendering the prompt in a pane, it renders properly but the cursor is at the beginning of the line rather than two spaces after it.

I fixed this by properly responding to the 'C' csi dispatch. 'C' is "Cursor forward", using the first parameter as the count to move forward. But like with other dispatches, 0 means 1 (just 0 though, 1 also means 1, and 2 means 2... it's fun like that :) ). So I fixed it to treat 0 as one and then the cursor appeared in the right place.

Then it broke when we opened another pane with a "cursor out of bounds". This was because we didn't properly change the cursor position when wrapping lines if its line was already wrapped (this is how starship operates, it doesn't create a new line but rather a new wrap by filling the first line with spaces). So, I fixed that in our line wrapping methods and we now treat it properly.

Now, it crashes when we resize the pane to a smaller size than the first starship line. I'm debugging this now.

Document various concepts in the code-base

There are various concepts from the "terminal world" in the codebase that are not very trivial for developers to immediately understand. It would be good to have a sort of "cheat sheet" document where one could look them up and understand what they mean, as well as where they fit in with the Mosaic project.

@alekspickle - since you rightfully pointed out this issue, I hope you'd be willing to briefly review this document once I write it (hopefully today or tomorrow) and let me know if it makes sense to you.

Bug: Spacing issue in rendering

Expected:

Actual:

Log:
mosaic-3.log

cating the log file outside of mosaic gives expected output, so the bug seems to be in the rendering.

Also, this issue doesn't happen with normal files containing tabs/spaces.

This is the relevant part of the greeting prompt.

echo -ne (\
        df -l -h | grep -E 'dev/(xvda|sd|mapper)' | \
        awk '{printf "\\\\t%s\\\\t%4s / %4s  %s\\\\n\n", $6, $3, $2, $5}' | \
        sed -e 's/^\(.*\([8][5-9]\|[9][0-9]\)%.*\)$/\\\\e[0;31m\1\\\\e[0m/' -e 's/^\(.*\([7][5-9]\|[8][0-4]\)%.*\)$/\\\\e[0;33m\1\\\\e[0m/' | \
        paste -sd ''\
    )

NOTE: Pasting this directly to mosaic is also causing a panic, so for now, we need to create a shell script and run it with fish to test.

Fullscreen command should be blocked when there is only 1 pane open

To reproduce:

• Start the app
• Toggle full-screen (currently with ctrl-e)
• Open another pane - see that things start to get messy (eg. no borders are drawn)

To fix this, the full-screen command should be a no-op when there is only one pane open.

arrow keys are not working

This happens because we get STDIN in a rather hacky way right now, and do not interpret the arrow keys properly. It should be resolved when we have a better solution for the controls.

Feature: WASM Plugins

WASM-based plugins, called Mosaic "Tiles", have been successfully prototyped here, and now the long road to integration begins! I'll be keeping a list of ongoing tasks here so that progress can be tracked 🙂

Tasks Remaining:

• Modify the layout file to load plugins
• Upstream the stdio pipes (optional)
• Change the TerminalPane struct to handle plugins (non-terminal panes)
• Call the draw() function of the plugin on a timer, displaying to the screen
• Parse input into something plugin-understandible

ctrl+l doesn't clear pane

Description:: ctrl+l doesn't work within Mosaic
Expected behavior: Clear screen
Terminal Application: Iterm2

Mosaic seems to be capturing the ctrl+l but doesn't clear the screen. Could be cool to look into that.

Bug: ctrl-c closes a pane

Need to investigate why. My guess is that we interpret it as SIGINT and then send a SIGINT to the pane rather than sending it ctrl-c and letting it decide what to do with it. But it's just a guess :)

What Aram is up to this week (26/10)

• Write an initial README for the project
• Refactor TerminalOutput - specifically, the way we hold the characters for the pane so it's more developer friendly but still as performant.

Extras:

• Fix the vim scrolling bug (if the refactor itself doesn't address it)
• Make htop work

Bug: Long Commands overwrite text on same line (bash/zsh)

A long command overwrites the characters in the starting of the same line, instead of the new line.

Steps to reproduce-
Type a long enough text in the bash shell.

Compatibility: neovim commands

Hitting backspace when trying to enter a command results in a crash.
Steps to reproduce:

• Open neovim
• start entering a command by pressing :
• hit backspace

Originating Thread(s):
1. stream_terminal_bytes: AsyncTask
2. screen_thread: HandlePtyEvent

Error: thread 'screen' panicked at 'swap_remove index (is 1) should be < len (is 1)': src/liballoc/vec.rs:975
   0: mosaic::errors::handle_panic
             at src/errors.rs:15:21
   1: mosaic::start::{{closure}}
             at src/main.rs:186:13
   2: std::panicking::rust_panic_with_hook
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:530:17
   3: rust_begin_unwind
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:437:5
   4: core::panicking::panic_fmt
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libcore/panicking.rs:85:14
   5: alloc::vec::Vec<T>::swap_remove::assert_failed
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/vec.rs:975:13
   6: alloc::vec::Vec<T>::swap_remove
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc/vec.rs:980:13
   7: mosaic::terminal_pane::scroll::WrappedFragment::add_character
             at src/terminal_pane/scroll.rs:231:13
   8: mosaic::terminal_pane::scroll::Scroll::add_character
             at src/terminal_pane/scroll.rs:379:13
   9: <mosaic::terminal_pane::terminal_pane::TerminalPane as vte::Perform>::print
             at src/terminal_pane/terminal_pane.rs:362:9
  10: mosaic::terminal_pane::terminal_pane::TerminalPane::handle_event
             at src/terminal_pane/terminal_pane.rs:101:17
  11: mosaic::screen::Screen::handle_pty_event
             at src/screen.rs:395:13
  12: mosaic::start::{{closure}}
             at src/main.rs:248:29
  13: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
  14: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/thread/mod.rs:475:17
  15: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panic.rs:318:9
  16: std::panicking::try::do_call
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:348:40
  17: __rust_try
  18: std::panicking::try
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:325:15
  19: std::panic::catch_unwind
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panic.rs:394:14
  20: std::thread::Builder::spawn_unchecked::{{closure}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/thread/mod.rs:474:30
  21: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /home/denis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ops/function.rs:233:5
  22: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/sys/unix/thread.rs:87:17
  23: start_thread
  24: clone