Closed PowerUser64 closed 1 year ago
This is because the macro is moving faster than the delay
, so when you move off the reference, the references will be refreshed but they won't be ready for until the duration of delay
has passed (minimum delay of 17ms under the hood).
You can get around this by freezing illuminate with require('illuminate').freeze_buf()
at the start of the macro and require('illuminate').unfreeze_buf()
at the end of the macro. These could be keymapped to something like vim.keymap.set('n', '<a-i>', require('illuminate').toggle_freeze_buf)
which you execute at the start and end of the macro where you want to use illuminate.
Desciption When using
<a-n>
or<a-p>
in macros, the cursor doesn't move to the previous/next result. Doing:lua require('illuminate').goto_next_reference()
inside the macro produces the same result.To Reproduce Minimal
init.lua
:lua/illuminate/goto.lua
from this repositoryb
<a-n>
or:lua require('illuminate').goto_next_reference()
)w
illuminate
can findExpected behavior At the end of the macro presented here, the cursor should be on the word after the next reference to the symbol used in the macro; as seen when performing the steps above when not recording a macro.
Screenshots Here's a short screen recording of the demonstration I describe above, using the minimal
init.lua
:It's a little slow, but you get the picture.
Additional context Creating and running a macro that just does
<a-n>
works fine, but it seems macros that move the cursor off the starting symbol break it. I only talk about<a-n>
here, but this applies to<a-p>
as well.