Address #8 and #15

[JayLCypher]

• Fixes a namespace to event_type mismatch.

• Adds some error and nil checking with debug messages.

• Create autocommands on User instead of BufEnter, calling the autocommand on keypress.

• Replace call_original_map with a original mapping rebind with autocommand call appended to:

  • Respect original keymapping with description
  • Better respond to built-in behaviors on yank, paste and undo/redo.
  • Removed uneccessary "map" table in config.

• Relies on some Neovim 0.7 features, might be advisible to add a feature test.

Alternative to the description, the string can be "which_key_ignore", which will make it not pop up in Which_Key plugin.

Issue: It seems that the 'o' and 'O' keymaps (that append or prepend a new line and enters insert mode) calls to the event for highlighting with the event_type "undo". No idea why. Please try it out before merging. I did remap the put key "p" to test, and it preserves the original description, as well as provide pasting with register interaction like it's supposed to.

map("n", "u", "u <cmd>print<CR>")
map("n", "p", "p <cmd>print<CR>", { desc = "lamo gotem"})

Furthermore we should probably advocate for TextPutPost, TextUndoPost and TextRedoPost autocommands provided by Neovim, inline with TextYankPost for better highlighting support. :)

[mei28]

Thank you for your PR. When I tested it, I found the same problem as #7.

I am considering how to address this issue.

[JayLCypher]

Yeah I noticed that too. Seems like the first paste + some lazy-loading of autocommands or buffer changes that affects when the plugin is initialized or something. Don't think it's related to lazy since I've tried VimEnter, BufEnter and lazy = false, and all behavior is the same.

I suspect there are some quirks I'm not aware of, but for now I at least have register put/paste-ing :)

[mei28]

I found that when I added the function, the issue of it not working the first time was resolved.

I'm not sure why this solution works or if it’s the best approach. What do you think?

  if config_module.config.paste.enabled then
    M.attach_bytes_highlight('paste') -- add this code
    api.nvim_create_autocmd('User', {
      pattern = { 'Luminate_paste' },
      group = 'LuminateHighlight',
      callback = function() M.attach_bytes_highlight('paste') end
    })
  end

  if config_module.config.undo.enabled then
    M.attach_bytes_highlight('undo')  -- add this code
    api.nvim_create_autocmd('User', {
      pattern = { 'Luminate_undo' },
      group = 'LuminateHighlight',
      callback = function() M.attach_bytes_highlight('undo') end
    })
  end

  if config_module.config.redo.enabled then
    M.attach_bytes_highlight('redo')  -- add this code
    api.nvim_create_autocmd('User', {
      pattern = { 'Luminate_redo' },
      group = 'LuminateHighlight',
      callback = function() M.attach_bytes_highlight('redo') end
    })
  end

[JayLCypher]

Good thing you didn't merge this, I see now how this works and the flaws of the implementation. Turns out I had no idea what I was doing. :⁾

Just to describe what's happening:

• The autocommand registers M.attach_bytes_highlight, which registers itself on every changetick for a buffer, running the M.on_bytes command.
• All three autocommands attach three different calls to the same M.on_bytes, but they're effectively competing for success to detach the other commands. If it's as I suspect that they're called in sequence, only the final highlight will show up. This makes the inconsistency in the defer_clear_highlights visible.
• So essentially, the highlighting tries to run on every text change for a buffer in comptetitive mode (which is why the duration is inconsistent).

This is sub-optimal. We need some way to differentiate what dispatch to send based on event. The connection to buffer text change needs to be on event, rather than registered all of the time, especially if we want to support pasting in Insert mode eventually. The buffer attachment needs to happen before the changedtick event happens, so that we get the correct columns and rows.

I'm not sure what a good way to do this is yet, an on_key() handler to put a callback on the p, and u keys seems silly, since the keys can change. We'd want to be config-agnostic. I need to think.