Add term support #19
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Products/FastWave2.0#19
Loading…
Reference in a new issue
No description provided.
Delete branch "add_term_support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
FastWave 2.0 now has a built in terminal using Rust Alacritty as the backend.
All you need to do is click on
Open Terminal
in the header bar.Some Notes:
remove
if
instead ofmatch
makers format
orcargo fmt --all
please add more context so we both know what should be implemented here without trying to read all related code
.chars basically brakes non-ASCII chars. It means when you try to format path like
C:\nová složka\můj nový soubor
(C:\new folder\my new file
in Czech) then if fails. You should be able to use https://crates.io/crates/unicode-segmentation(only applies if the
term
can be a user-defined text)if
.chars().count()
is really what you want (see the previous review comment) then you can replace theif
's body with something like:Perhaps you can use methods like is_ascii_alphabetic or is_ascii_lowercase or even is_ascii_control
@ -0,0 +46,4 @@
"Term not yet started!".to_string()
},
TerminalDownMsg::BackendTermStartFailure(msg) => {
format!("Error: BackendTermStartFailure: {}", msg)
@ -0,0 +62,4 @@
}
fn send_char(
s : &str,
can we use
c: char
instead? Ideally everywhere where it makes sense instead of String allocation and passing strings in the methods calledsend_char
.@ -0,0 +66,4 @@
has_control : bool,
) {
match process_str(s, has_control) {
Some(c) => {
Replace
match
+Some
withif let Some...
(https://doc.rust-lang.org/rust-by-example/flow_control/if_let.html)Remove or rewrite
Why are we waiting?
Typo
I guess it's also worth noting that the terminal feature will probably not work on windows. I will have to think about an acceptable long term solution.
We wait in case the frontend starts slightly after the backend. We, don't want the frontend to miss the first term update.
Fully addressing NFC vs NFD unicode behavior will open a can of worms that is non-trivial to resolve. Hopefully, most users have keyboards that input a single unicode point instead of base followed by diacritic.