bug#38647: 26.3; image-next-file does not consider archived images

[Juri Linkov]

>>> When viewing archived images(zip or tar) with image-mode,
>>> typing 'n' does not show the next image in the archive.
>>> Similar for 'p'.
>>
>> Sounds like a missing feature which would be good to have, thanks.
>>
>> Any takers?
>
> There's some difficulty knowing how to approach this -- the different
> archive modes do so many different odd things.
>
> For instance, if you open the file "guide.png" from a zip buffer,
> buffer-file-name ends up being:
>
> "/home/larsi/tmp/images.zip:guide.png"
>
> In a tar file buffer, you end up with:
>
> "/home/larsi/tmp/images.tgz!./guide.png"
>
> So that has to be regularised first...  but will that break stuff?
>
> Secondly, there doesn't seem to be any general "what's the next file in
> this archive buffer" function?  Or am I missing something?
>
> This seems like a trivial request, but I'm not sure we have the
> infrastructure to make it happen...

All this indicates that instead of using 'directory-files',
'image-next-file' should rely on 'archive-next-line' if the file
is opened from an archive, and on 'dired-next-line' otherwise.

When using 'dired-next-line' the image navigation order will be
exactly the same as the file sorting order in the dired buffer,
thus allowing the users to change the image order from dired.

Also this means that if there is no corresponding dired buffer
already visited, then 'image-next-file' should create an internal
dired buffer just for the sake of file image navigation.