-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable spinners #2793
Configurable spinners #2793
Conversation
…'file modified' indicator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some comments, but they are without authority, and only my personal feedback.
@BearOve - I think I addressed/resolved all your suggestions. Mind taking another look? Thanks! |
Yes you have. The only thing now is what happens if the frame specified is more than one visible character wide. However, it might even be a feature to have a 3 character spinner? I will leave this for someone more familiar with the inner workings of Helix however. Great work |
I tried this last night and it works up to 3-4 chars before it bumps into the filename. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was curious what you would want to replace the current spinner with but it turns out there isn't a shortage of possible spinners 😄
Some of my favorites:
[editor]
spinner = ["▁", "▂", "▃", "▄", "▅", "▆", "▇", "█", "▇", "▆", "▅", "▄", "▃", "▁"]
spinner = ["▉", "▊", "▋", "▌", "▍", "▎", "▏", "▎", "▍", "▌", "▋", "▊", "▉"]
spinner = ["◴", "◷", "◶", "◵"]
spinner = ["◐", "◓", "◑", "◒"]
spinner = ["◡◡", "⊙⊙", "◠◠"]
Selfishly, I hate things that move erratically - I find them really distracting, and the LSP loading process stops and starts the spinner a few times (there's a CPU lag as well on my lower-performance VM). I replaced it with a single frame of a yellow dot. The single-frame notification also doesn't use But yes - I've been playing around with lots of alternate possibilities. (Won't somebody think of the poor syscalls?) |
Does it make sense for spinner-interval set to 0 to disable spinner display? We already have this functionality if spinner-frames is set to []. Would it not make more sense to change this functionality to keep the previous logic (update when a key-press is made, instead of just removing the spinner)? I prefer this logic, because it prevents a render every time the spinner updates (which is 👍 if you're on a slow connection/ssh'd into a server). |
I'm not sure I understand. The current code doesn't allow you to configure the spinner interval at all, and if you manage to do it by editing the code, if you set it to zero, helix will panic on Because the frame is empty, there will be no significant update - I run helix (and this proposed code) on a small VM over a slow SSH connection and haven't seen any issues. In fact, it's one of the primary reasons I'm submitting this PR, since the current behavior causes the spinner to move erratically. [1] helix/helix-term/src/ui/spinner.rs Line 38 in ad15e7b
|
Ahhh yes, that makes sense. Thanks for the explanation 👍 |
|
@Woolworths - just out of curiosity, are you using mosh? |
@sbromberger I'm not, no 😄 |
Does this PR affect how spinners work internally or just how they are displayed? Though, I've also recently updated rust-analyzer ( |
I've noticed this too, but I also noticed it without the PR, so I don't think it's the code here. The spinner indicator updated to the correct state (went away) when I pressed a key. I didn't change any of the logic relating to spinner start/stop - just how it's displayed. |
Also, it's not consistent. Here's a screen recording I just made with a single-char (yellow dot) spinner: |
Then it's probably an unrelated issue. |
simplify text and offset computation Co-authored-by: Gokul Soumya <gokulps15@gmail.com>
Co-authored-by: lazytanuki <43273245+lazytanuki@users.noreply.github.com>
This would be really awesome to see in helix! |
Refactored for new customizable statusline. Width of spinner is now handled appropriately by the statusline! Ready for review. |
Updates documentation to reflect decision re: defaulting to never showing bufferline.
Update configuration.md to reflect new default.
Been using this branch for some time with a simple one character custom spinner and have seen no obvious glitches. |
Could I get a review on this, please? Thank you :) |
Merged with master - I think this is ready for review. Thank you. |
This PR adds the ability to customize the progress spinners. It changes the way they are created, as well, but this is not a huge issue because they weren't user-customizable beforehand anyway.
In summary:
The spinner can be defined in the config file using two keys under
[editor]
-spinner
andspinner-interval
. The former is aVec<String>
whose elements represent frames. The latter is the maximum update time in ms (equivalent to the interval that already exists in the code). Both default to the existing spinner.This required allowing
EditorView
to take aProgressSpinners
argument, so I've changed the calling convention forEditorView::new
.If the spinner is multi-frame, then the current behavior where
Instant::now()
is repeatedly called still applies. However, for lower-powered systems, if the spinner is a single frame, then we can elide all the calls (and resulting syscalls) and save some performance.The spinner can now be styled using
ui.spinner
in the theme. This allows the use ofrapid_blink
, for example, to simulate motion. (However - If the statusbar is non-black, I don't know yet how to make the background persist when the blink state goes to black.)Anyway - please let me know what you think. I'm still not sure why we're using ProgressSpinners as a collection when it appears there's only ever one spinner. Could we simplify this?