linutil
linutil copied to clipboard
ChrisTitusTech
Feat: confirmation prompts
Add confirmation prompt to prevent accidental command execution
Type of Change
- [x] New feature
- [x] 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 #686
Checklist
- [x] My code adheres to the coding and style guidelines of the project.
- [x] I have performed a self-review of my own code.
- [x] I have commented my code, particularly in hard-to-understand areas.
- [x] I have made corresponding changes to the documentation.
- [x] My changes generate no errors/warnings/merge conflicts.
Confirmation prompt doesn't need its own focus variant, we can use the generic float variant with slight refactoring. https://github.com/lj3954/linutil/commit/0a17f4272397964719f73d1cba2a06eac00c63e0.
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.
I think the focus specialization is fine there, it prevents us from needing to polute the FloatContent interface for other implementors
I think the focus specialization is fine there, it prevents us from needing to polute the
FloatContentinterface 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.
@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
