I don't know if this feature is documented, but
imv seems to "reload" a file that's already opened after is changed, i.e some writes to it.
This seems to work fine for a while, but eventually the window becomes black.
I first encountered this issue when using
plantuml for generating diagrams:
I would open
imv with some file and then overwrite said file with
plantuml every time a new diagram version is generated.
An easier way to reproduce this is using
cp, like this:
while true; do cp -v foo.png target.png && cp -v bar.png target.png; done
It's very weird, because adding some sleep time between the
cp's doesn't reproduce the issue:
while true; do cp -v foo.png target.png && sleep 0.01 && cp -v bar.png target.png && sleep 0.01; done
but I can easily reproduce the issue in one shot when using:
plantuml -pipe < test.puml > target.png
while true; do cat foo.png > target.png && sleep 0.01 && cat bar.png > target.png && sleep 0.01; done
Seems to work fine.
# This generates target.png plantuml target.puml
Doesn't reproduce it immediately but after a couple of runs.
I seem to have the same issue when I recreate the PNG currently visualized (I'm using gnuplot to regenerate a plotted diagram). After a while the PNG does not show up anymore, just a black canvas.
FWIW as a "workaround" I use the slideshow feature:
imv -t1 file.png. Doesn't cover all cases, though. If my image generation script breaks and imv tries to reload an empty file, then it's "stuck" again and I need to restart imv.
I'll try using the slideshow. For now I'm using
imv's IPC mechanism to workaround this, I'm using that in my Neovim plugin.
It's also worth mentioning that other "minimal" image visualizers like
fehdon't have this issue.
I tried using
imv -t 0 file.pngand
imv -t 1 file.pngwithout success, I always get a black canvas eventually.
LIke I mentioned previously, the best workaround sor far is to run
imvas a server, and then do
imv <PID> close allfollowed by
imv <PID> open <FILE>.