search

mvllow / modes.nvim

Prismatic line decorations for the adventurous vim user
550 stars 13 forks source link

feat: handle visual highlight using ModeChanged event #38

Closed fitrh closed 1 year ago

fitrh commented 2 years ago

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.~~

Update

We can completely avoid checking key or current_mode for visual highlight by using autocmd on these events:

fitrh commented 2 years ago

@TheBlob42 can you confirm that this doesn't break your use case?

TheBlob42 commented 2 years ago

I'm currently only on my phone, will test it tomorrow

fitrh commented 2 years ago

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.

@mvllow isn't that something we introduced in https://github.com/mvllow/modes.nvim/pull/32?

mvllow commented 2 years ago

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.

TheBlob42 commented 2 years ago

@TheBlob42 can you confirm that this doesn't break your use case?

Works fine with vim-cutlass or any other similar mappings for me :+1:

fitrh commented 2 years ago

@mvllow @TheBlob42 using autocmd on ModeChanged event seems more reliable than using key or current_mode variable

fitrh commented 2 years ago

The autocmd filter is taken from the example in :h ModeChanged, *:[vV\x16] means every time you enter VISUAL{LINE,BLOCK} mode

TheBlob42 commented 2 years ago

Now that you mention the ModeChanged event: Is there anything speaking against moving ALL logic from the vim.on_key function to appropriate "ModeChange autocommands" instead? :thinking:

fitrh commented 2 years ago

Is there anything speaking against moving ALL logic from the vim.on_key function to appropriate "ModeChange autocommands" instead?

@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

fitrh commented 1 year ago

I'm going to merge this since I haven't had any issues using it until now