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

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

[ynyaaa]

When viewing archived images(zip or tar) with image-mode,
typing 'n' does not show the next image in the archive.
Similar for 'p'.


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(mode-local find-func thingatpt help-fns radix-tree cl-print debug
ispell network-stream nsm starttls tls gnutls mailalias smtpmail
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs misearch
multi-isearch help-mode pp shadow sort mail-extr emacsbug message rmc
puny seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils elec-pair time-date mule-util japan-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 122843 37538)
 (symbols 48 21555 3)
 (miscs 40 70 379)
 (strings 32 36407 1382)
 (string-bytes 1 934688)
 (vectors 16 17296)
 (vector-slots 8 601335 15884)
 (floats 8 57 548)
 (intervals 56 805 0)
 (buffers 992 17))

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

[Eli Zaretskii]

severity 38647 wishlist
thanks

> From: ynyaaa@gmail.com
> Date: Tue, 17 Dec 2019 16:15:23 +0900
> 
> 
> 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?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

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

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.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

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

`archive-next-line' isn't used in tar mode buffers -- that's the
problem: There's no unified interface across the different archive
modes.  (Although perhaps there's just two?  arc-mode and tar-mode?

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

Yeah, that would be nice.  

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

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

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

[Juri Linkov]

>> 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.
>
> `archive-next-line' isn't used in tar mode buffers -- that's the
> problem: There's no unified interface across the different archive
> modes.  (Although perhaps there's just two?  arc-mode and tar-mode?

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

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

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

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

[Juri Linkov]

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

I thought that after every typing of `n'.

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

Or optionally pop up a new Dired buffer on image navigation.
Or use commands from image-dired.el.  So many options...

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> 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?
>
> Or optionally pop up a new Dired buffer on image navigation.
> Or use commands from image-dired.el.  So many options...

I just made it message.

I've now implemented this, and it seems to work for me in normal
buffers, as well as archive mode and tar mode buffers.  I had to add a
couple helper functions to the latter two modes.

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