gate image change updates behind option, and limit updates to just image under cursor

[jonboh]

By default image updates are disabled, but when check_image_changes_at_cursor is set to true, it will be possible to check for changes in the image under the cursor.
This way the performance hit from this option even when enabled should be minimal and will not scale with the amount of images displayed in the buffer.
In order to refresh an image an user will need to place its cursor on the image line and force a render (I use :e!)

[3rd]

Thinking about this, not sure if it should be a feature, API-wise if an image is rendered and the file is modified after I wouldn't expect the library to handle that. The document integrations are secondary.

What is your use case? Is it for personal use or a plugin? We can sort something different out that would allow you to hook this in. For the modified check it would probably be enough and faster to compare the file size instead of running a shell command / parsing with magick.

[jonboh]

I see what you mean. I'm primarily using it for note-taking in neorg. I have nvim and krita integrated so that I'm able to make changes to diagrams relatively quickly.
The thing is that now even if I call clear on an image, and then render it again it will still load the cached one. So, maybe it would be enough to be able to manually clear the cache of the renderer for an image id.

[3rd]

Yep, looking into that I realized I forgot we already check for modification time in another place using getftime, forgot about that:
https://github.com/3rd/image.nvim/blob/master/lua/image/image.lua#L288

I think your use case might be shared by others, I'll add a global config flag to invalidate the cached files on render if the original file gets modified, and we can see how it works.

Got some questions:

• Would providing file watching be of any value? To rerender them without depending on a :render()
• Should this be supported as a flag per-image as well?

Working on a full rewrite, and getting closer to the finish line, if you have any ideas for other use cases or better ways to shape the API please pitch in.

[3rd]

@jonboh try this out #153
no config change needed