add option to edit fire events

[daUnknownCoder]

Is your feature request related to a problem? Please describe. currently the update events are (idk but might be) CursorMoved, CursorMovedI, i want to add TextChanged because i use text editing plugins which can do something like: change from true to false and vice versa so if the text is changed there is no chunk for that part

[shellRaining]

in fact I have set TextChanged autocmd, code here

https://github.com/shellRaining/hlchunk.nvim/blob/dcf9a4ec7bb71806962fe3f6ba0a93119da0d272/lua/hlchunk/mods/chunk/init.lua#L211-L222

if some plugin not compatible with hlchunk, please feel free to append an issue

[daUnknownCoder]

im getting this weird issue pls check:

Error executing vim.schedule lua callback: ...NeutronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/cFunc.lua:47: wrong number of arguments for function call
stack traceback:
    [C]: in function 'ml_get_buf'
    ...NeutronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/cFunc.lua:47: in function 'get_line'
    ...tronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/position.lua:21: in function 'get_char_at_pos'
    ...ronVim/lazy/hlchunk.nvim/lua/hlchunk/mods/chunk/init.lua:101: in function 'get_chunk_data'
    ...ronVim/lazy/hlchunk.nvim/lua/hlchunk/mods/chunk/init.lua:131: in function 'render'
    ...ronVim/lazy/hlchunk.nvim/lua/hlchunk/mods/chunk/init.lua:187: in function 'fn'
    ...NeutronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/timer.lua:64: in function 'fn'
    ...NeutronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/timer.lua:16: in function <...NeutronVim/lazy/hlchunk.nvim/lua/hlchunk/utils/timer.lua:15>

i dont think so but this could be relevant: kevinhwang91/nvim-hlslens#70 (it happens when i have this plugin enabled)

[shellRaining]

Has this issue been resolved? I checked the error call stack, but couldn't figure out how to reproduce this bug.

[daUnknownCoder]

Has this issue been resolved? I checked the error call stack, but couldn't figure out how to reproduce this bug.

yes idk why it was happening but it was due to that plugin now its solved, thanks for ur time

[miversen33]

Just checking in to say that I updated from commit 882d1bc to commit d5e4580 and I am now seeing this issue as well. That was the only plugin I updated in my config.

I am seeing if I can get a reproducible config put together for it. I did a bit of digging and it seems to be falling over on utils/cFunc.lua:47

---@param bufnr number
---@param lnum number 0-index
---@return string
function M.get_line(bufnr, lnum)
    local line_cnt = vim.api.nvim_buf_line_count(bufnr)
    if lnum >= line_cnt or lnum <= 0 then
        return ""
    end
    local handler = C.find_buffer_by_handle(bufnr, ffi.new("Error"))
    return ffi.string(C.ml_get_buf(handler, lnum + 1))
end

I had never heard of ffi before but a bit of digging tells me its an interface to talk to c functions from lua JIT

I do also use hlslens, I wonder if that plugin is doing some fuckery with the ffi mod?

[miversen33]

Turns out I wasn't as up to date with hlslens as I thought. Updating it to this commit fixed the issue for me :)

Don't mind my rambling

[shellRaining]

still not sure why this issue is occurring, I haven't looked into the hlslen plugin in depth 😂

[miversen33]

It is because both hlslens and hlchunk were setting the exact same function in ffi.C, but with different arguments.

-- hlslens
    char_u *ml_get_buf(buf_T *buf, linenr_T lnum, bool will_change);

-- hlchunk
    char *ml_get_buf(buf_T *buf, linenr_T lnum); // fn.getbufline

C doesn't do "function overloading", so whichever declaration happens last is likely the signature that is being used in the JIT.

Because you both defined the exact same function with differing signatures and (assuming) that the hlslens function is defined after yours, that means that anytime you try to call ml_get_buf, you are missing the final argument will_change as defined in the version of this function defined by hlslens.

I don't know the first thing about ffi.C but if its possible, I would consider changing your C functions to be prepended with hlchunk so the risk of overlap like this is nullified.

[shellRaining]

What confuses me the most is that the signature of the ml_get_buf in hlslens is different from the signature in the neovim repository.

// hlslens
char_u *ml_get_buf(buf_T *buf, linenr_T lnum, bool will_change);

// neovim
static char *ml_get_buf_impl(buf_T *buf, linenr_T lnum, bool will_change) {...}
char *ml_get_buf(buf_T *buf, linenr_T lnum)
{
  return ml_get_buf_impl(buf, lnum, false);
}

and it seems that ml_get_buf_impl signature is the function what hlslens actually want to call, I'm not sure why the author wrote it this way.

[miversen33]

It has since been corrected in their most recent commit so this problem should be gone :)