modes.nvim icon indicating copy to clipboard operation
modes.nvim copied to clipboard

feat: handle visual highlight using ModeChanged event

Open fitrh opened this issue 3 years ago • 9 comments

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:

  • ModeChanged *:[vV\x16] for set highlight
  • ModeChanged [vV\x16]:n for reset

fitrh avatar Sep 07 '22 06:09 fitrh

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

fitrh avatar Sep 07 '22 06:09 fitrh

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

TheBlob42 avatar Sep 07 '22 16:09 TheBlob42

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?

fitrh avatar Sep 08 '22 02:09 fitrh

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.

mvllow avatar Sep 08 '22 02:09 mvllow

@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:

TheBlob42 avatar Sep 08 '22 06:09 TheBlob42

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

fitrh avatar Sep 08 '22 06:09 fitrh

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

fitrh avatar Sep 08 '22 07:09 fitrh

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:

TheBlob42 avatar Sep 08 '22 09:09 TheBlob42

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 avatar Sep 08 '22 10:09 fitrh

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

fitrh avatar Oct 10 '22 05:10 fitrh