Describe the bug In a Windows command line terminal, colours are not correctly displayed, instead random letters and symbols are (which I assume is the supposed syntax for the colour). This seems to be a problem with the colored crate but I would suggest to at least when using the None option for the colours to add no such syntax at all and just the spinner with the text (looking on how its done in the source code).

To Reproduce Steps to reproduce the behavior:

1. Create any spinner with any color (includine the None option)
2. Open the created binary on a windows command line terminal (not the new Windows Terminal)
3. See error

Expected behavior A colour should be displayed (again, probably an error with the colored crate)

Desktop:

• OS: Windows

Additional info This might not be able to be fixed by you (see above with the colored crate) but I like your crate so the suggested fix would be nice, so I can use the spinners without the colours :)

Is your feature request related to a problem? Please describe. I want to display a spinner while my application is making a blocking IO call. When the call takes longer than expected (say 2 seconds) I would like to update the spinner text. In single-threaded code this is not possible because there is no way of keeping track of the elapsed time and calling the update_text() method on the spinner.

Describe the solution you'd like The spinner itself is able to keep track of the elapsed time. When creating the spinner you pass it a starting text, a duration and an updated text that will be displayed once the duration has passed. Alternatively it could be a sequence of updated texts that it will loop through or even another data structure with multiple texts and for how long they will be displayed.

Describe alternatives you've considered Spawning a separate thread for the blocking IO call so I can keep track of the time and update the spinner manually. The proposed solution would be more convenient though.

Before starting work on https://github.com/ad4mx/spinoff/issues/15, I saw that there was inconsistent formatting applied to the source code, so I added a .rustfmt.toml file and ran cargo fmt. This PR only contains automatically fixed formatting changes.

This was to make sure that any future PRs will contain less formatting "noise" and that all contributors get the same output when we run "cargo fmt"

Hey!

I stumbled across this crate on reddit. I have pretty much the same crate: https://github.com/mainrs/terminal-spinners-rs. I do have a repository that automatically updates spinner definitions based on sindresorphus spinner library.

https://github.com/mainrs/terminal-spinner-data-rs

If you need anything additionally api wise, feel free to open an issue.

Cheers!

Most people only need one or two spinners. Instead of having the user install all 80+ spinners, we can use features so that they only need to install the specific spinner they want.

With this change, iterating over all spinner variants will not be supported out of the box and, instead, will need to be implemented by the user. People installing all 80+ spinners will also have a slightly larger crate to install (due to the individual implementations for each spinner). Still, this crate will be able to drop maplit and strum as dependencies, as they will no longer be necessary.

However, this change has a delightful side effect of allowing SpinnerFrames data to be decoupled with the core of the crate itself. Users, if they so wish to, will now be able to implement and run their custom spinner using a macro provided by this crate while still reaping the ergonomics that this crate offers, allowing for much more extensibility.

We can easily achieve this without changing the interface by using macros and tweaking the library just a bit; We can also have the default feature set to all to ease the transition.

An example of what it could look like:

// The generated code (from the macro) could have an empty struct, a way to
// convert the struct into `SpinnerFrames`, and the actual static value itself.
pub struct Dots;

impl From<Dots> for SpinnerFrames {
    fn from(_: Dots) -> SpinnerFrames {
        DOTS_SPINNER.clone()
    }
}

static DOTS_SPINNER: Lazy<SpinnerFrames> = Lazy::new(|| SpinnerFrames {
    frames: vec!["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"],
    interval: 80
});

// If a user has the `dots` feature enabled, a new spinner could be created 
// with the same interface as the current one
Spinner::new(Spinners::Dots, "Hello world!", None);

What do you think? I already have a fork for https://github.com/FGRibreau/spinners implementing this change, so adjusting it and porting it to this crate should be easy. If you don't have any fundamental objections, I would like to submit a PR, though, I fully understand if you don't want this.

Is your feature request related to a problem? Please describe.

Cannot implement Facade pattern because there is no implementation of the Copy trait 🤕

Describe the solution you'd like

implement copy/clone (I'm new to rust, please forgive me if it doesn't makes sense 🙏 )

Describe alternatives you've considered

using spinners lib for facade (it worked ✅ )

Additional context

use spinoff::{spinners, Color, Spinner as LibSpinner};

pub struct Spinner {
    msg: String,
    sp: LibSpinner,
}

impl Spinner {
    pub fn new(msg: &String) -> Self {
        Self {
            msg: msg.clone(),
            sp: create_standard_spinner(&msg),
        }
    }

    pub fn success(&mut self) {
        self.sp.success(&self.msg);
    }
}

fn create_standard_spinner(msg: &String) -> LibSpinner {
    LibSpinner::new(spinners::Dots2, msg.clone(), Color::Blue)
}

pub fn create_spinner(msg: &String) -> Spinner {
    Spinner::new(msg)
}

but it results in the following error

error[E0507]: cannot move out of `self.sp` which is behind a mutable reference
  --> shared/commands-helper/src/lib.rs:23:13
   |
23 |             self.sp.success(&self.msg);
   |             ^^^^^^^ move occurs because `self.sp` has type `spinoff::Spinner`, which does not implement the `Copy` trait

For more information about this error, try `rustc --explain E0507`.
                 ^^^^

This PR is a rough suggestion of how the proposed changes outlined in #15 could be implemented.

The main difference this PR introduces is moving away from the current implementation of keeping all spinner data in a Hashmap and looking them up by their key, and instead, defining featured gated empty structs which implement a common trait that lets it convert itself into spinner data. This allows users only to include the spinners they want to use via features and allows users to define custom spinners and use them with this crate.

However, in this implementation, the API will change in three non-trivial ways.

1. Iterating through all spinners is not provided out of the box. Users will have to create their own vectors to iterate over.
2. The Spinners enum is replaced with the spinners module, so crate-supplied spinners will now be imported as spinners::Spinner instead of Spinners::Spinner
3. Only the dots spinner is included by default. If you want to use all spinners provided by the crate, you have to now use the all features on import.

#! Cargo.toml
spinoff = { version = "*", features = ["all"] }

Is your feature request related to a problem? Please describe. I'm using this crate in a program I'm building, and I'd like to be able to have the spinner stay at the bottom while a command is running and printing out to stdout. Currently, the command being ran and the spinner end up "z-fighting" in a way.

Describe the solution you'd like The spinner would stay at the bottom of the terminal, while the command streams to stdout above the spinner.

Describe alternatives you've considered I have not found any alternatives at this point.

Fairly new to rust so not sure if this change is appropriate, or if there would be an appetite for it. Currently we are using the library with some work that is happening in a spawned thread. It would be nice if we could share the spinner instance with the thread - as work gets done we can update the text on the fly. Because several function do not take self as a reference this makes it not possible to send the instance to the spawned thread.

Hi there!

I'm currently building a project where I need to show two spinners for two different long-running tasks.

Is there a way to achieve this?

Thanks in advance for your help!