From 43f605fa5cc427efc8ef6a1a3d11a55508dabe06 Mon Sep 17 00:00:00 2001 From: Timon Date: Sat, 23 Jun 2018 20:32:12 +0200 Subject: [PATCH 1/5] Update README.md --- README.md | 55 +++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 43 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index a6b07b6..c8421ed 100644 --- a/README.md +++ b/README.md @@ -2,21 +2,45 @@ Things where I am working on now: -I have inplemented the alternate and raw screen features for unix systems. Now I am trying to get this also to work for windows with WINAPI. +I have implemented the alternate and raw screen features for unix systems. Now I am trying to get this also to work for windows with WINAPI. -The next version will have api braking changes. Why I needed to do that is essential for the functioning of these above features. +In the new version you must provide the Context type to the function calls `cursor(), color(), terminal()`. This type is used by Crossterm for managing the state of the terminal and for futures like `AlternateScreen` and `Rawscreen`. -- At first: -I needed to create some `Context` types withs can manage the terminal state. So that when changes are made to the terminal the can be reverted. This is handy when using raw terminal mode and enabling some mode on the terminal like ansi escape codes for windows. When the `Context` dispposes all changes made will be reverted so that the user terminal is back in its starting state. +Like described above the next version will have api braking changes. Why I needed to do that is essential for the functioning of these above features. -When in unix sytems you want to execute some ANSI escape code you have to write it to terminal stdout (screen ouput). +- At first `Terminal state`: +Because this is an terminal manupulating library there will be made changes to terminal when running an proccess with my libaray. If you stop the process you want the terminal back in it's original state. This is why I need to track the changes made to the terminal. This is done in the `Context` struct so that they can be undone in the end. + +- At second `Handle to the console` + +In rust we can call `stdout()` to get an handle to the current default console handle. For example when in unix sytems you want to execute some ANSI escape code you have to write it to terminal. I can write it to stdout (screen ouput) withs is the main screen. //like write!(std::io::stdout(), "{}", "some ANSI code". -But when using `std::io::stdout` you will have an handle to the current screen. And not the alternate screen. And when using alternate screen you don't want to write to the mainscreen stdout. But to the alternate screen stdout. For this we also have the `Context` type withs has contains an type to manage the screen. +But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or altenate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. + +To solve the problem we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program. This handle is stored in an subtype of the Context type. + +The user has to create an `Context` type for this libary. + + //like + let context = Context::new(); + + let cursor = cursor(&context); + let terminal = terminal(&context); + let color = color(&context); + +Now that we have on global `Context` type which can be used to register terminal state changes, and in with we can manage the terminal stdout (screen output). When this `Context` disposes we run code to cleanup the changes that are made. + +Maybe I am going to make a wrapper for the function calls `cursor, terminal, color` so that whe can avoid passing the context all over the place which makes to code more unreadable to my opinion. I realy did not want to make api braking changes, bur for the sake of the futures I want to implement it needed to be done. + + // maybe I am going to create some Envoirment type which can be used for getting acces to diffrent modules that this libary provides. + let envoirment = Envoirment::new(); + envoirment.color(); + envoirment.cursor(); + envoirment.terminal(); -So that is why I have created the `Context` type. To mange the terminal state changes and to run cleanup code. And for managegin the screen output. ## Features crossterm 0.1 @@ -41,7 +65,7 @@ So that is why I have created the `Context` type. To mange the terminal state ch - Storing the current cursor position and resetting to that stored cursor position later. - Resizing the terminal. -### fixes in crossterm 0.2.1 +## fixes in crossterm 0.2.1 - Default ANSI escape codes for windows machines, if windows does not support ANSI switsh back to WINAPI. - method grammer mistake fixed [Issue 3](https://github.com/TimonPost/crossterm/issues/3) @@ -50,11 +74,18 @@ So that is why I have created the `Context` type. To mange the terminal state ch - The terminal state will be set to its original state when process ends [issue7](https://github.com/TimonPost/crossterm/issues/7). - Get position unix fixed [issue 8](https://github.com/TimonPost/crossterm/issues/8) +## fixes in crossterm 0.2.2 +- Bug see [issue 15](https://github.com/TimonPost/crossterm/issues/15) -## TODO Features crossterm 0.3 -- Raw state implementation [Issue 5](https://github.com/TimonPost/crossterm/issues/5). -- Alternate screen implementation. -- Tests +## Features crossterm 0.2.3 +- Alternate screen for windows and unix systems. +- Rawscreen for unix systems maybe windows. +- Hiding an showing the cursor. +- Control over blinking of the terminal cursor. + +## TODO Features crossterm 0.2.2 +- Raw state implementation for windows [Issue 5](https://github.com/TimonPost/crossterm/issues/5). +- Alternate screen for windows ## Tested terminals From d9e8caaa3a8eae921e1dcdfcc4f546984d768cec Mon Sep 17 00:00:00 2001 From: Timon Date: Sat, 23 Jun 2018 20:35:08 +0200 Subject: [PATCH 2/5] Update README.md --- README.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index c8421ed..51ae07b 100644 --- a/README.md +++ b/README.md @@ -2,23 +2,25 @@ Things where I am working on now: -I have implemented the alternate and raw screen features for unix systems. Now I am trying to get this also to work for windows with WINAPI. +I have implemented the alternate and raw screen features for Unix systems. Now I am trying to get this also to work for windows with WINAPI. In the new version you must provide the Context type to the function calls `cursor(), color(), terminal()`. This type is used by Crossterm for managing the state of the terminal and for futures like `AlternateScreen` and `Rawscreen`. Like described above the next version will have api braking changes. Why I needed to do that is essential for the functioning of these above features. - At first `Terminal state`: -Because this is an terminal manupulating library there will be made changes to terminal when running an proccess with my libaray. If you stop the process you want the terminal back in it's original state. This is why I need to track the changes made to the terminal. This is done in the `Context` struct so that they can be undone in the end. + + Because this is a terminal manipulating library there will be made changes to terminal when running an process with my library. If you stop the process you want the terminal back in its original state. Therefore, I need to track the changes made to the terminal. This is done in the `Context` struct so that they can be undone in the end. + - At second `Handle to the console` -In rust we can call `stdout()` to get an handle to the current default console handle. For example when in unix sytems you want to execute some ANSI escape code you have to write it to terminal. I can write it to stdout (screen ouput) withs is the main screen. + In rust we can call `stdout()` to get an handle to the current default console handle. For example when in unix sytems you want to execute some ANSI escape code you have to write it to terminal. I can write it to stdout (screen ouput) withs is the main screen. - //like - write!(std::io::stdout(), "{}", "some ANSI code". - -But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or altenate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. + //like + write!(std::io::stdout(), "{}", "some ANSI code". + + But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or altenate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. To solve the problem we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program. This handle is stored in an subtype of the Context type. From 0c898288b1726cf9076ef986dea33b3e0eefa743 Mon Sep 17 00:00:00 2001 From: Timon Date: Sat, 23 Jun 2018 20:36:38 +0200 Subject: [PATCH 3/5] Update README.md --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 51ae07b..e1b26d3 100644 --- a/README.md +++ b/README.md @@ -20,11 +20,11 @@ Like described above the next version will have api braking changes. Why I neede //like write!(std::io::stdout(), "{}", "some ANSI code". - But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or altenate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. + But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or alternate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. -To solve the problem we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program. This handle is stored in an subtype of the Context type. +To solve the problem, we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program. This handle is stored in a subtype of the Context type. -The user has to create an `Context` type for this libary. +The user must create an `Context` type for this library. //like let context = Context::new(); @@ -33,9 +33,9 @@ The user has to create an `Context` type for this libary. let terminal = terminal(&context); let color = color(&context); -Now that we have on global `Context` type which can be used to register terminal state changes, and in with we can manage the terminal stdout (screen output). When this `Context` disposes we run code to cleanup the changes that are made. +Now that we have on global `Context` type which can be used to register terminal state changes, and in with we can manage the terminal stdout (screen output). When this `Context` disposes we run code to clean up the changes that are made. -Maybe I am going to make a wrapper for the function calls `cursor, terminal, color` so that whe can avoid passing the context all over the place which makes to code more unreadable to my opinion. I realy did not want to make api braking changes, bur for the sake of the futures I want to implement it needed to be done. +Maybe I am going to make a wrapper for the function calls `cursor, terminal, colour` so that when can avoid passing the context all over the place which makes to code more unreadable to my opinion. I really did not want to make API braking changes, bur for the sake of the futures I want to implement it needed to be done. // maybe I am going to create some Envoirment type which can be used for getting acces to diffrent modules that this libary provides. let envoirment = Envoirment::new(); From 9ab55cc350ffeecfcf3c8503c43a36f20545da79 Mon Sep 17 00:00:00 2001 From: Timon Date: Sat, 23 Jun 2018 20:46:21 +0200 Subject: [PATCH 4/5] Update README.md --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index e1b26d3..4ccfea3 100644 --- a/README.md +++ b/README.md @@ -6,11 +6,11 @@ I have implemented the alternate and raw screen features for Unix systems. Now I In the new version you must provide the Context type to the function calls `cursor(), color(), terminal()`. This type is used by Crossterm for managing the state of the terminal and for futures like `AlternateScreen` and `Rawscreen`. -Like described above the next version will have api braking changes. Why I needed to do that is essential for the functioning of these above features. +Like described above the next version will have api braking changes. Why I needed to do that is essential for the functioning of the above features. - At first `Terminal state`: - Because this is a terminal manipulating library there will be made changes to terminal when running an process with my library. If you stop the process you want the terminal back in its original state. Therefore, I need to track the changes made to the terminal. This is done in the `Context` struct so that they can be undone in the end. + Because this is a terminal manipulating library there will be made changes to terminal when running an process. If you stop the process you want the terminal back in its original state. Therefore, I need to track the changes made to the terminal. This is done in the `Context` struct so that they can be undone when the process ends. - At second `Handle to the console` @@ -18,13 +18,13 @@ Like described above the next version will have api braking changes. Why I neede In rust we can call `stdout()` to get an handle to the current default console handle. For example when in unix sytems you want to execute some ANSI escape code you have to write it to terminal. I can write it to stdout (screen ouput) withs is the main screen. //like - write!(std::io::stdout(), "{}", "some ANSI code". + write!(std::io::stdout(), "{}", "some ANSI code"). - But things change when we are in alternate screen. If I execute the code above the ANSI escape code will be written to the main handle and not or alternate handle. This causes things to be written to the main screen and not the alternate screen, and this is not wat we want. + But things change when we are in alternate screen. If I execute the code above the ANSI escape code to the current stdout it will be written to the main handle and not or alternate handle, and this is not what we want. -To solve the problem, we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program. This handle is stored in a subtype of the Context type. +To solve the problem, we need to have one place to store the handle to the console screen. So that we can write to this handle during the lifetime of the program in the different modules like `cursor, terminal and color`. This handle is stored in a subtype of the Context type. -The user must create an `Context` type for this library. +Now the user must create an `Context` type for this library. //like let context = Context::new(); @@ -33,9 +33,9 @@ The user must create an `Context` type for this library. let terminal = terminal(&context); let color = color(&context); -Now that we have on global `Context` type which can be used to register terminal state changes, and in with we can manage the terminal stdout (screen output). When this `Context` disposes we run code to clean up the changes that are made. +Now we have one global `Context` type which can be used to register terminal state changes, and in with we can manage the terminal stdout (screen output). When this `Context` disposes we run code to clean up the changes that are made to the terminal. -Maybe I am going to make a wrapper for the function calls `cursor, terminal, colour` so that when can avoid passing the context all over the place which makes to code more unreadable to my opinion. I really did not want to make API braking changes, bur for the sake of the futures I want to implement it needed to be done. +Maybe I am going to make a wrapper for the function calls `cursor, terminal, colour` so that when can avoid passing the context all over the place which makes to code more unreadable to my opinion. I really did not want to make API braking changes, but for the sake of the features I needed to do it. // maybe I am going to create some Envoirment type which can be used for getting acces to diffrent modules that this libary provides. let envoirment = Envoirment::new(); @@ -81,7 +81,7 @@ Maybe I am going to make a wrapper for the function calls `cursor, terminal, col ## Features crossterm 0.2.3 - Alternate screen for windows and unix systems. -- Rawscreen for unix systems maybe windows. +- Rawscreen for unix systems maybe windows [Issue 5](https://github.com/TimonPost/crossterm/issues/5).. - Hiding an showing the cursor. - Control over blinking of the terminal cursor. @@ -105,7 +105,7 @@ If you have used this library for an terminal other than the above list without ## How it works -Crossterm is using `WINAPI` for windows systems and `ANSI escape codes` for unix systems. Crossterm provides one base trait with can be implemented for a platform specific instance. For example, there is an implementation for windows (`WINAPI`) and unix(`ANSI`) for the `cursor module`. To call the platform specific implementation there is one module that rules them all. Thrue this module the client calls some action and the module will deside what to do based on the current platform. And it will execute that action. +Crossterm is using `WINAPI` for windows versions lower than windows 10 and `ANSI escape codes` for unix systems. Crossterm provides one base trait with can be implemented for a platform specific instance. For example, there is an implementation for windows (`WINAPI`) and unix(`ANSI`) for the `cursor module`. To call the platform specific implementation there is one module that rules them all. Thrue this module the client can call some action and the module will deside what to do based on the current platform. And it will execute that action. ## Notice This library is library is stable. There will not be changed mutch in the code design so do not worry to mutch. If there are any changes that affect previous versions I will describe what to change when upgrading crossterm to an newer version. From 56ed082bf369c3f8dea64dd5b7cee7d2d9f68592 Mon Sep 17 00:00:00 2001 From: Timon Date: Mon, 25 Jun 2018 18:37:46 +0000 Subject: [PATCH 5/5] Fixed unix code after working on windows --- .idea/workspace.xml | 602 ++++++++++++-------------- src/cursor/cursor.rs | 2 +- src/kernel/unix_kernel/terminal.rs | 8 +- src/manager/manager.rs | 6 +- src/shared/functions.rs | 4 +- src/shared/screen.rs | 8 +- src/state/commands/shared_commands.rs | 22 +- src/state/commands/unix_command.rs | 15 +- src/state/commands/win_commands.rs | 3 +- src/style/styles/styledobject.rs | 4 +- 10 files changed, 310 insertions(+), 364 deletions(-) diff --git a/.idea/workspace.xml b/.idea/workspace.xml index a416570..325ca54 100644 --- a/.idea/workspace.xml +++ b/.idea/workspace.xml @@ -3,21 +3,15 @@ - - - - - - - + + + + - - - - + - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + @@ -103,17 +46,80 @@ - - + + - - + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -129,7 +135,6 @@ - conte terminal_cursor term ScreenManager @@ -150,7 +155,6 @@ get_to_alternate_screen_command &context cursor - context Mutex WriteConsoleOutputW CONSOLE_CURSOR_INFO @@ -159,6 +163,8 @@ fmt STD_OUTPUT_HANDLE data + context + WinApiScreenManager crossterm_cursor @@ -187,7 +193,6 @@ @@ -272,7 +278,7 @@ - + @@ -285,33 +291,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -334,7 +313,7 @@ - + @@ -392,7 +371,7 @@ - + @@ -471,19 +450,6 @@ - - - - - @@ -595,10 +561,10 @@ - - + @@ -607,15 +573,15 @@ - + - + - + @@ -623,25 +589,47 @@ + + + + + + + - - + + + + + + + + + + + + + + + + + - + + - @@ -652,7 +640,7 @@ - + @@ -674,45 +662,10 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + @@ -727,20 +680,6 @@ - - - - - - - - - - - - - - @@ -748,24 +687,6 @@ - - - - - - - - - - - - - - - - - - @@ -780,38 +701,8 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + @@ -826,13 +717,6 @@ - - - - - - - @@ -840,24 +724,10 @@ - - - - - - - - - - - - - - - - + + @@ -882,24 +752,7 @@ - - - - - - - - - - - - - - - - - - + @@ -928,20 +781,6 @@ - - - - - - - - - - - - - - @@ -953,26 +792,6 @@ - - - - - - - - - - - - - - - - - - - - @@ -990,13 +809,6 @@ - - - - - - - @@ -1046,6 +858,130 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/cursor/cursor.rs b/src/cursor/cursor.rs index 938edc4..8ee03ad 100644 --- a/src/cursor/cursor.rs +++ b/src/cursor/cursor.rs @@ -26,7 +26,7 @@ impl TerminalCursor #[cfg(not(target_os = "windows"))] let cursor = Some(AnsiCursor::new(context.clone()) as Box); - TerminalCursor { terminal_cursor: Some(WinApiCursor::new()), context} + TerminalCursor { terminal_cursor: cursor, context} } /// Goto some position (x,y) in the terminal. diff --git a/src/kernel/unix_kernel/terminal.rs b/src/kernel/unix_kernel/terminal.rs index a44a2cc..2dff600 100644 --- a/src/kernel/unix_kernel/terminal.rs +++ b/src/kernel/unix_kernel/terminal.rs @@ -41,13 +41,13 @@ pub fn terminal_size() -> (u16,u16) { } /// Get the current cursor position. -pub fn pos(terminal: &Context) -> (u16, u16) +pub fn pos(context: Rc) -> (u16, u16) { use std::io::{ Write,Read }; - let mut command_id = NoncanonicalModeCommand::new(&terminal.state_manager); + let mut command_id = NoncanonicalModeCommand::new(&context.state_manager); - CommandManager::execute(terminal, command_id); + CommandManager::execute(context.clone(), command_id); // This code is original written by term_cursor credits to them. use std::io; @@ -97,7 +97,7 @@ pub fn pos(terminal: &Context) -> (u16, u16) // Expect `R` let res = if c == 'R' { (cols as u16, rows as u16) } else { return (0, 0) }; - CommandManager::undo(terminal, command_id); + CommandManager::undo(context.clone(), command_id); res } diff --git a/src/manager/manager.rs b/src/manager/manager.rs index dafa94d..080e477 100644 --- a/src/manager/manager.rs +++ b/src/manager/manager.rs @@ -1,6 +1,6 @@ //! This module provides an interface for working with the sceen. With that I mean that you can get or wirte to the handle of the current screen. stdout. //! Because crossterm can work with alternate screen, we need a place that holds the handle to the current screen. And this module provides this place. -use super::{AnsiScreenManager, WinApiScreenManager, IScreenManager }; +use super::*; use super::super::shared::functions; use std::any::Any; @@ -24,11 +24,11 @@ impl ScreenManager let screen_manager = functions::get_module::>(Box::from(WinApiScreenManager::new()), Box::from(AnsiScreenManager::new())).unwrap(); #[cfg(not(target_os = "windows"))] - let screen_manager = Box::new(AnsiScreenManager::new()); + let screen_manager = Box::from(AnsiScreenManager::new()) as Box; ScreenManager { - screen_manager: Box::from(WinApiScreenManager::new()) + screen_manager: screen_manager } } diff --git a/src/shared/functions.rs b/src/shared/functions.rs index a9d015c..58514bd 100644 --- a/src/shared/functions.rs +++ b/src/shared/functions.rs @@ -21,10 +21,10 @@ pub fn get_terminal_size() -> (u16, u16) } /// Get the cursor position based on the current platform. -pub fn get_cursor_position(screen: Rc) -> (u16, u16) +pub fn get_cursor_position(context: Rc) -> (u16, u16) { #[cfg(unix)] - return pos(&screen); + return pos(context.clone()); #[cfg(windows)] return pos(); diff --git a/src/shared/screen.rs b/src/shared/screen.rs index f40f2a8..251688d 100644 --- a/src/shared/screen.rs +++ b/src/shared/screen.rs @@ -95,9 +95,9 @@ impl Drop for AlternateScreen // Get the alternate screen command to enable and disable alternate screen based on the current platform fn get_to_alternate_screen_command(context: Rc) -> u16 { -// #[cfg(target_os = "windows")] -// let command = functions::get_module::>(win_commands::ToAlternateScreenBufferCommand::new(), shared_commands::ToAlternateScreenBufferCommand::new(), context).unwrap(); + #[cfg(target_os = "windows")] + let command = functions::get_module::>(win_commands::ToAlternateScreenBufferCommand::new(), shared_commands::ToAlternateScreenBufferCommand::new(), context).unwrap(); -// #[cfg(not(target_os = "windows"))] - win_commands::ToAlternateScreenBufferCommand::new(context) + #[cfg(not(target_os = "windows"))] + shared_commands::ToAlternateScreenBufferCommand::new(context.clone()) } \ No newline at end of file diff --git a/src/state/commands/shared_commands.rs b/src/state/commands/shared_commands.rs index f838207..122f866 100644 --- a/src/state/commands/shared_commands.rs +++ b/src/state/commands/shared_commands.rs @@ -2,6 +2,8 @@ use Context; use super::{IStateCommand}; +use std::rc::Rc; + pub struct EmptyCommand; impl IStateCommand for EmptyCommand @@ -18,19 +20,27 @@ impl IStateCommand for EmptyCommand } /// This command is used for switching to alternate screen and back to main screen. -pub struct ToAlternateScreenBufferCommand<'a> +pub struct ToAlternateScreenBufferCommand { - context: &'a Context + context: Rc } -impl<'a> ToAlternateScreenBufferCommand<'a> +impl ToAlternateScreenBufferCommand { - pub fn new(context: & 'a Context) -> Box < ToAlternateScreenBufferCommand > { - Box::from(ToAlternateScreenBufferCommand {context: context}) + pub fn new(context: Rc) -> u16 { + + let mut state = context.state_manager.lock().unwrap(); + { + let key = state.get_changes_count(); + let command = ToAlternateScreenBufferCommand {context: context.clone()}; + + state.register_change(Box::from(command), key); + key + } } } -impl<'context> IStateCommand for ToAlternateScreenBufferCommand<'context> +impl IStateCommand for ToAlternateScreenBufferCommand { fn execute(&mut self) -> bool { diff --git a/src/state/commands/unix_command.rs b/src/state/commands/unix_command.rs index 32a3cd5..d9f1f96 100644 --- a/src/state/commands/unix_command.rs +++ b/src/state/commands/unix_command.rs @@ -19,14 +19,14 @@ pub struct NoncanonicalModeCommand impl NoncanonicalModeCommand { - pub fn new(state: &Mutex) -> u16 + pub fn new(state_manager: &Mutex) -> u16 { - let key = 1; - - let mut state_manager = state.lock().unwrap(); + let mut state = state_manager.lock().unwrap(); { - let command = Box::from(NoncanonicalModeCommand { key: key }); - state_manager.register_change(command, key); + let key = state.get_changes_count(); + let command = NoncanonicalModeCommand { key: key }; + + state.register_change(Box::from(command), key); key } } @@ -84,11 +84,12 @@ pub struct EnableRawModeCommand impl EnableRawModeCommand { pub fn new(state_manager: &Mutex) -> u16{ - let key = 2; let mut state = state_manager.lock().unwrap(); { + let key = state.get_changes_count(); let command = EnableRawModeCommand { original_mode: None, command_id: key }; + state.register_change(Box::from(command), key); key } diff --git a/src/state/commands/win_commands.rs b/src/state/commands/win_commands.rs index e95c523..cab2dcc 100644 --- a/src/state/commands/win_commands.rs +++ b/src/state/commands/win_commands.rs @@ -158,10 +158,9 @@ impl ToAlternateScreenBufferCommand { pub fn new(context: Rc) -> u16 { - let key = 2; - let mut state = context.state_manager.lock().unwrap(); { + let key = state.get_changes_count(); let command = ToAlternateScreenBufferCommand {context: context.clone()}; state.register_change(Box::from(command), key); diff --git a/src/style/styles/styledobject.rs b/src/style/styles/styledobject.rs index 33325c5..8d3cd9a 100644 --- a/src/style/styles/styledobject.rs +++ b/src/style/styles/styledobject.rs @@ -135,7 +135,7 @@ macro_rules! impl_fmt let mutex = self.context.screen_manager; { let mut screen = mutex.lock().unwrap(); - screen.write_ansi_str(format!(csi!("{}m"), *attr as i16)).expect("Flush failed"); + screen.write_ansi_str(format!(csi!("{}m"), *attr as i16)); } reset = true; } @@ -146,7 +146,7 @@ macro_rules! impl_fmt { let mut screen = mutex.lock().unwrap(); - screen.flush().expect("Flush failed"); + screen.flush(); } if reset