zellij-org / zellij Goto Github PK
View Code? Open in Web Editor NEWA terminal workspace with batteries included
Home Page: https://zellij.dev
License: MIT License
A terminal workspace with batteries included
Home Page: https://zellij.dev
License: MIT License
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!
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.
Agenda:
switching between modes in neovim results in weird glitches.
Steps to reproduce:
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.
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...
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).
Log:
mosaic-3.log
cat
ing 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.
One should be able to tab between several Screens in an existing session. Each screen can be split into multiple panes.
Extras after I've eaten my vegetables:
(fyi @qballer, @TheLostLambda )
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:
Hitting backspace when trying to enter a command results in a crash.
Steps to reproduce:
:
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
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).
This is likely due to us not setting a minimum size for new panes.
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:
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
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:
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.
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.
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).
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.
To reproduce:
To fix this, the full-screen command should be a no-op when there is only one pane open.
TerminalOutput
- specifically, the way we hold the characters for the pane so it's more developer friendly but still as performant.Extras:
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:
-|-
should be โผ
, etc.)Bonus points if I finish everything super quick:
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.
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.
So if you open neovim and then nerd_tree with e .
If you scroll up and down, it updates and you see nerd_tree normally
Happens with files that have long lines
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.
exposing mosaic to public development, trying to commit to 01.11.2020:
Primary Goals
Secondary goals:
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.
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:
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:
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.
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.
Agenda:
To reproduce:
This command should be blocked when there is a pane in full focus.
I'll be a tad busy, but I'll try for the following things:
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:
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.
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:
TerminalPane
struct to handle plugins (non-terminal panes)draw()
function of the plugin on a timer, displaying to the screenThere 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.
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.
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 :)
Agenda:
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
Steps to reproduce:
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
At the moment, when we start htop inside a mosaic pane, it panics (because of an unhandled CSI).
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%.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.