File delete should by default work in the
tagged-files-or-current-file-if-none-tagged way that copy/move do. It
would still prompt to say what's going to happen, so there's probably
no need to continue to allow the current file-at-cursor-only delete.


The TIFF support (based on using system()) can be made to run an
arbitrary command if given a sufficiently funky filename, or if
`tifftopnm' isn't what's expected. This is pretty crap, but I don't
think it's a security problem due to root permissions having long
since been irretrievably dropped by the time this could happen (see
SECURITY for more on such things), and don't forget only a user
currently logged in at the console would ever get into zgv anyway.
Still, I should do TIFF support via libtiff at some point.


It would be nice if the smaller/bigger mode keys ([,]) worked in the
selector too. Could even use the same code to do it
(change_mode_size() in vgadisp.c) if hacked slightly (would need to
remove dependence on pixelsize, effectively 1 in the selector).


readgif.c should cope with files with more than 256 images.
(Technically it does *cope* with more images, but it doesn't load
them.)


Should probably have right-button-menu options for GIF animation,
auto-mode-fit, and smaller/bigger mode.


It might be nice to have a further `act like xzgv' option for reversed
mouse movement in the viewer (dragging the picture around, rather
zgv's dragging the screen around).


Copy over any handy build changes from xzgv. Most already dealt with,
but the stuff about /usr/local/info/dir in config.mk hasn't been, nor
has doc/Makefile been changed to use gzipped info files and chmod a+r
the dir file (important if install-info created one from scratch, for
example). And want to add uninstall target.

Also, consider making /usr/local the default installation point. This
would be hairy as uninstall would then have to blast any possible zgv
installation under /usr as well, but I think it's the Right Thing to
do.


Mouse support isn't really finished - the goto-dir dialog should have
ok/cancel buttons, and currently you can't interrupt file loading and
thumbnail updates. The latter two would need a custom mouse event
handler temporarily installed, so that we could avoid losing any
clicks. Actually it might not be too bad an idea to always use a
custom handler; that would be easier. After all, on a slow machine you
can already lose clicks during a file-selector screen redraw!


File move should probably delete any existing thumbnail for the file
if the file itself is moved successfully.
