GNU bug report logs - #38647
26.3; image-next-file does not consider archived images

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38647 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, ynyaaa <at> gmail.com
Subject: bug#38647: 26.3; image-next-file does not consider archived images
Date: Tue, 04 Aug 2020 02:50:12 +0300

>>> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.