-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
More informative VI mode indicator #625
Comments
@rbpatt2019 I was able to add an indicator by adding this to my
|
Would be great to be able to chose colors as well as the character change |
@seanag0234 As was I! To clarify, what I'm looking for is an indicator not for Insert or command/normal mode (which I was able to achieve), but an indicator for visual mode and replace mode. Right now visual, replace, and insert mode are all indicated by the same symbol - " [I] >>>>" in my .toml - and there isn't an option to differentiate between the three. |
I didn't get it to work ... Character stays the same in every VI-Mode... |
As an update, I'm now using zsh on my work laptop and cannot find a way to add a visual/replace mode indicator there either. |
@Adrian-Grimm & @rbpatt2019 - I was able to replicate the issue on bash and didn't see a bug filed for this, so I created one: #1171 Worth noting that |
After an hour of fiddling it seems that zsh does not report clear information regarding it's mode. When inspecting Based on this code that is in charge to identify the current mode, let mode = match (&context.shell, keymap.as_str()) {
(Shell::Fish, "default") | (Shell::Zsh, "vicmd") => ShellEditMode::Normal,
_ => ASSUMED_MODE,
}; it is not possible to know if the mode is different than Normal and Insert :( As I was writing this message, I found a very informative comment on a SO thread which states:
|
My issue is solved: #1171 (comment) |
Unlike in fish, this didn't update in realtime, only when drawing a new prompt. I can get most of the vi-mode behavior from [starship's `character` settings](https://starship.rs/config/#character) and there's some open PRs and issues about the rest: - starship/starship#1679 - starship/starship#625
I'm hitting this right now in fish. starship only has two modes: "normal" and "insert". It maps Fish's "default" mode or Zsh's "vicmd" mode to "normal", and everything else to "insert". starship/src/modules/character.rs Lines 34 to 37 in af43aee
But fish has 6 different modes (default, insert, paste, replace, replace_one, and visual). "paste" can generally be ignored, it's just for bracketed paste mode (even FWIW anyone who wants to restore the original mode prompt can do so by just redefining it after sourcing the starship init. The simplest way is probably |
I'd love to see a fix for this as well |
It's there any way to add this behaviour on PowerShell at moment? |
Feature Request
Is your feature request related to a problem? Please describe.
Recognise this might be a Fish-specific problem. Delving onwards...
Migrating from SpaceFish, where the vi-mode indicator gave feed back on whether you were in replace, visual, insert or normal mode, as described here. I must admit, I'm a big fan of the character switching between insert and normal mode! But it gives me confusing information on visual or replace mode.
If you are in normal mode and then switch into either visual or replace mode, the prompt character switches back to insert mode. This is incredibly confusing, as there is now no clear indication of whether you are in insert, replace, or visual. When you then exit visual/replace mode, it switches back to the normal mode character, as expected.
Describe the solution you'd like
Solution A: Allow custom configuration of characters for each mode. Basically, the currently implementation expanded to have a character for visual and replace modes.
Solution B: Allow inclusion of the default
fish_mode_prompt
, though I suspect this would be more complicated.Describe alternatives you've considered
I have manually configured
fish_mode_prompt
, but this is blocked/disabled by Starship.The text was updated successfully, but these errors were encountered: