Feat: confirmation prompts

[cartercanedy]

Add confirmation prompt to prevent accidental command execution

Type of Change

• New feature
• UI/UX improvement

Description

Having an accidental keypress result in a significant environment change sucks. Adding a prompt to confirm the execution of a command makes it less likely that a user will have a destructive command accidentally execute and have to decipher the command source to revert the changes (if they even are revertible).

Testing

locally, tested aborting and confirming command selections

Impact

should prevent accidental neovim config deletions, at least :)

Issues / other PRs related

• Resolves Confirmation prompts #686

Checklist

• My code adheres to the coding and style guidelines of the project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no errors/warnings/merge conflicts.

[lj3954]

Confirmation prompt doesn't need its own focus variant, we can use the generic float variant with slight refactoring. lj3954@0a17f42.
The only thing missing is exiting on q or <C-c>, which could be implemented by implementing a 'can_exit' method for focus & float, or something of the like.

[cartercanedy]

I think the focus specialization is fine there, it prevents us from needing to polute the FloatContent interface for other implementors

[lj3954]

I think the focus specialization is fine there, it prevents us from needing to polute the FloatContent interface for other implementors

I don't think it's "polluting" the trait. All that needs to be changed is to return an enum rather than a boolean, out of the handle_key function. It's probably more clear that way, since the variants can explicitly state what action is occuring ('None', 'Close', etc) rather than having to look at comments in the trait to explain what each boolean value corresponds to.

[koibtw]

Works as expected, no issues.

NIT:
We could add some colors or other "aesthetic" things (like the one i mentioned below for example) to the popup though.

When selecting more than 9 entries, the list looks something like this:

1. Alacritty         
2. Android Debloater 
3. Bash Prompt       
4. Bottles           
5. DWM-Titus         
6. Docker            
7. Fastfetch         
8. Grub Theme        
9. Kitty             
10. Linutil Installer
11. Office Suite     
12. ZSH Prompt

We could make it check for the number of selected entries and add an extra space after the number for every 9/10 so it'd look like this:

9.  Kitty             
10. Linutil Installer

[cartercanedy]

@lj3954 sorry for jumping to conclusions, I do like what you did with FloatEvent and making the handle_key_event api more fluent, but I do think that the confirmation float and other potential features could benefit from specialization of Float for concrete types instead of being limited to accessing a blind FloatContent trait object

[cartercanedy]

how about

 1. ...
 ...
10. ...

[koibtw]

how about

 1. ...
 ...
10. ...

Looks alright.

[ghost]

love it