feat: handle visual highlight using ModeChanged event #38
Conversation
cb54e80 introduce changes to check visual mode highlight using `current_mode`, this changes causes a bug with `Shift + v` (visual line mode) where the cursor highlight still uses the default `Visual` highlight until pressing the second key. Checking visual mode highlights Using `key` (and checking it inside `current_mode == 'n'`) is more reliable than using `current_mode`.
|
@TheBlob42 can you confirm that this doesn't break your use case? |
|
I'm currently only on my phone, will test it tomorrow |
There was a problem hiding this comment.
This looks fine to me. I did notice this odd behaviour that isn't necessarily because of this PR but happens one keystroke sooner now. Hard to explain, so here's a screenshot before pressing v...
...and after:
Notice the sign column is highlighted immediately after pressing v. This happened before this PR, although not until moving the visual selection by one first.
This shouldn't be a blocker and probably warrants a new issue but I don't find it bothersome enough to make that issue.
|
Yea, I think with visual mode it's a little strange (since your current line isn't always highlighted like the other modes) but not a big deal. More of a feature request if anything but also would add more complexity. |
Fix behaviour when creating new split windows using `CTRL-W_v` where modes.nvim treats `v` keypress as visual mode.
lua/modes.lua
Outdated
| end | ||
| end | ||
|
|
||
| if key == utils.replace_termcodes('<esc>') or key == current_mode then |
There was a problem hiding this comment.
I guess you introduced key == current_mode here in case the user presses v in visual mode to exit? But unfortunately this breaks other modes and their highlighting:
For example in insert mode if I press the character i or if I press the character r in replace mode (if using R, see :h Replace) the highlighting is reset, but I'm still in the respective mode.
There was a problem hiding this comment.
My proposal would be to limit this special exit condition (key == current_mode) to visual mode only as I don't know any other mode that can be exited by pressing the same "key" again (if I'm forgetting one please correct me). The general check for <esc> however makes perfect sense to me 👍
There was a problem hiding this comment.
For example in insert mode if I press the character i or if I press the character r in replace mode (if using R, see :h Replace) the highlighting is reset, but I'm still in the respective mode.
You are right, I never realized it since I disabled the cursor line in insert mode
There was a problem hiding this comment.
Thanks, I think I got a more robust solution
Works fine with vim-cutlass or any other similar mappings for me 👍 |
fitrh
changed the title
key to check visual mode highlight
|
@mvllow @TheBlob42 using autocmd on |
|
The autocmd |
|
Now that you mention the |
This handles the case where leaving visual mode without `<Esc>` or `vim.on_key` doesn't catch mode switching like toggling comments in visual mode.
@TheBlob42 you can take a look into https://github.com/fitrh/modes.nvim/tree/feat/modechanged-autocmd, maybe we can discuss this in another issue |
|
I'm going to merge this since I haven't had any issues using it until now |
cb54e80 introduce changes to check visual mode highlight using
current_mode, this changes causes a bug withShift + v(visualline mode) where the cursor highlight still uses the default
Visualhighlight until pressing the second key.
Checking visual mode highlights Using
key(and checking it insidecurrent_mode == 'n') is more reliable than usingcurrent_mode.Update
We can completely avoid checking
keyorcurrent_modefor visual highlight by using autocmd on these events:ModeChanged *:[vV\x16]for set highlightModeChanged [vV\x16]:nfor reset