Hi there,

I just tried your library on 2021 and it is thowing an error when running the shown example.

thread '' panicked at 'called Result::unwrap() on an Err value: NotSupported', C:\Users\exfho.cargo\registry\src\github.com-1ecc6299db9ec823\spinner-0.5.0\src\lib.rs:164:37

I thought I'd let you know.

Running with current Rust, this happens

 ❤ (azedes) ~/P/c/spinners> cargo run --example simple
   Compiling spinners v1.0.1-alpha.0 (/home/spacekookie/Personal/clones/spinners)
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s
     Running `target/debug/examples/simple`
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:355:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.
^C⏎                                                                                                       (130)  ❤ (azedes) ~/P/c/spinners> rustc -V
rustc 1.32.0-nightly (6acbb5b65 2018-11-25)

The problem seems to be in the spinner library, that fails to lock stdout. Not really sure how to debug past that but :woman_shrugging:

Love the package - but didn't want the spinner outputs to get written to stdout when piping results outside of the program.

Simple as replacing all print! and println! to eprint! and eprintln!

This is just Spinner::new() with the boxed closure as a third parameter. I'm not sure this is the prettiest solution possible. Example complex_spinner created.

To consistently stop printing after a call to stop and it's variants, we must join the spawned thread. To support the implementation of the Drop Trait, we store the JoinHandle as an Option in the Spinner struct. This allows us to explicitly join the thread when the Spinner is dropped if it hasn't been explicitly stopped, otherwise it does nothing.

Fixes #26

Edited stop_inner to delete the spinner and text when called. This also means the stop_with_newline function isn't necessary anymore. I also updated some documentation to include the new functions like stop_and_persist.

Only problem I can't find a way to solve is that deleting the spinner and text leaves an empty line behind.

Closes #28

I have added a stop_and_persist function that stops the spinner and then shows a symbol and a message. I have also added succeed, fail, warn, info, and unknown functions that use the stop_and_persist function with a pre-defined symbol (with color and, theoretically, support for windows terminals).

Note: I might also push out some more features in this pr if it is going to take time (so that there arent many prs from me that sit unmerged). Do let me know if I should use any other approach

I'm facing a regression in spinners in version 3.1.0. In my application I call spinner.stop() and then clear the previous line using crossterm:

spinner.stop();
execute!(std::io::stdout(), Clear(ClearType::CurrentLine), cursor::Show);

The line is successfully cleared, but as of version 3.1.0, the spinner will produce output even after being stopped. This behavior is new in 3.1.0 and worked as expected in 3.0.1 (no output is produced after the stop call).

Additions:

• Option to have a timer as part of the spinner.
• Option to replace the spinner with an alternative symbol when stopping (for signaling success/failure for example).
• Join the thread when stopping.

Regarding the joining, in the examples, the thread would most frequently be killed by drop of the Spinner rather than the stop message sent through the channel. This was fine before, but now it's important that the stop method is run before the thread is killed since the stop message carries the timing and replacement symbol. This probably should be integrated with #24 too.

Stops the spinner when it goes out of scope.

Effectively runs the stop function when the spinner variable is dropped, allowing for it to be freed from memory, without calling any extra functions.

Especially helpful with unforeseen exceptions where the stop function is not manually called, in which case the spinner would continue forever without this trait.

Implemented the feature from #18

• Fixed an issue with Rust edition 2021 (Unsure what caused the issue, but it is from the base spinner package and happened to me with 2021 and on Windows)
• Removed dependency on base Spinner package
• Removed necesity for referencing Spinner enum (Replaced with cloning)
• Added documentation to the main methods
• Added a method to stop with new line
• Added a method to stop and print a message afterwards
• Changed re-exports

Things you might wanna check:

• [x] Changed re-exports
• [x] Removed necesity for referencing Spinner enum (Replaced with cloning)

Hey, thanks for the library! I made a GIF to show all spinners because I want to have an easy way to see/compare which spinner to use. Hope it helps others with same need.

Added colors for spinners. I didn't really like the termcolor library you recommended, and instead went with a simpler variant. Everything is tested and examples are updated.

This commit adds an on_drop method to Spinner, the method is a "Builder method" (called on a Spinner taking ownership and returns a new Spinner instance). The existing Spinner API therefore continue to work as they did before with no changes to methods or their parameters.

By default, i.e. when on_drop is not used to set the default behavior of a Spinner, its behavior remains the same as prior to this commit. When on_drop is called on a Spinner, a new Spinner instance is returned. If this instance is dropped without any of its stop* methods having been called, then the StopBehavior set in the on_drop call is triggered.

This change allows the following simple construction:

{
   let sp = Spinner::new(...).on_drop(StopBehavior::Message("Failed!".into()));
   do_something_fallible()?;
   sp.stop_with_message("Yay, it worked".into());
}

If do_something_fallible() returns a Result::Ok the Spinner is stopped with the "success" message. Conversely, if do_something_fallible() returns a Result::Err, the Spinner is stopped with the "Failed!" message when it is dropped.

All feedback is very welcome!

Hi,

Say, the second console column, instead of the first one by default. It looks like SpinnerBuilder is responsible for customization, but it is unavailable in the spinners context. Or is it just my lack of experience?

This example does precisely what I want:

extern crate spinner;

use std::time::Duration;
use std::thread;

use spinner::SpinnerBuilder;

fn main() {
    let sp = SpinnerBuilder::new("Long Running op!".into()).
        format(|sp, status|{
            format!("   {spin} -- Currently working on: \'{status}\' -- {spin}",
                    spin = sp, status = status)
        }).start();
    thread::sleep(Duration::from_millis(2000));
    sp.message("Updating...".into());
    sp.update("Fixing things...".into());
    thread::sleep(Duration::from_millis(2000));
    sp.message("Done!".into());
    sp.close();
}

The line

            format!("   {spin} -- Currently working on: \'{status}\' -- {spin}",

Is all I need.

Would you be interested in having GA workflows being added to the repository? I could provide you these workflows:

• CI workflow triggered on PRs:
  • Does formatting checking
  • Runs clippy
  • Runs tests
• CD workflow triggered when pushing a git tag:
  • Pushes a new version to crates.io

Additionally, the following could be done:

• CI workflow for scheduled spinner updates:
  • Runs a cron job to update the spinners automatically. If updates do take place, a new patch version is published.

An alternative to the last workflow would be to turn the update_spinners script into a build script. That way, the files are always up-to-date. Compilation would be longer though (maybe 2sec-5sec, depending on the internet connection).