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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Yep, there's just two - these twins are going hand in hand,
> for example, in image-mode.el in image-toggle-display-image:
>
>                          (not (and (boundp 'archive-superior-buffer)
>                                    archive-superior-buffer))
>                          (not (and (boundp 'tar-superior-buffer)
>                                    tar-superior-buffer))

If there's just two, that's indeed manageable.  I imagined there were a
dozen of these modes, which seemed hopeless...

OK, I think the way forward here is probably to create a couple of
helper functions to abstract away the underlying movement/selection
stuff.  So something like image-mode--{next,prev}-file that will do the
right thing in dired/tar/arc buffers, and also respect the sorting in
those buffers.

I think that should be pretty easy to implement (he said without
actually having looked at it *theme music from Jaws starts playing*).

>>> 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.
>>
>> Hm.  I think that makes sense...  but it would perhaps be a bit
>> surprising?
>
> Maybe when not requested, such Dired buffer should be killed afterwards,
> or its name should start with a space.

Hm...  But what is "afterwards"?  Just leaving the image mode buffer?

Perhaps we can just make this all less surprising, and still have the
functionality, by just notifying the user.  (Or query?)  That is, if you
`n' in an image-mode buffer, and there's no dired (etc) buffer parent,
then just message "Opened dired buffer for <dir>" when doing so?
And...  bury it?  Or not?

Many UX things to tweak. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no