Subject: bug#61394: 30.0.50; [PATCH] Image-dired thumb name based on content

From: Manuel Giraud <[email-masked]>
Date: Fri, 28 Jul 2023 11:33:19 +0200

Eli Zaretskii <[email-masked]> writes:

[...]

> Thanks, the tests now pass, but I wonder about this part:
>
>>      (should (equal (cdr (file-name-split
>> -                         (image-dired-thumb-name "/tmp/foo.jpg")))
>> -                   '("tmp" ".image-dired" "foo.jpg.thumb.jpg")))
>> +                         (image-dired-thumb-name abs-path)))
>> +                   (list "tmp" ".image-dired" hash-name)))
>
> Does this mean that thumbnail naming under 'per-directory' has
> changed, and it now uses the SHA-1 hash of the base-name?  IOW, does
> this mean your changes for bug#61394 included incompatible changes in
> behavior?

Yes I think it does.  My patch for bug#61394 changes the previous
behaviour of 'image-dired-thumbnail-storage'.  Now
'image-dired-thumbnail-storage' defines where (ie. in which directory)
the thumbnails are stored and I introduce 'image-dired-thumb-naming'
which tells how thumbnail file ared named (ie. the file name part sans
directory).

'image-dired-thumb-naming' is meaning less if
'image-dired-thumbnail-storage' is one of the "standard*" method because
those methods already define storage locations, file names and even
sizes.  But for the "per-directory" method, I'm using
'image-dired-thumb-naming'.  As we are talking about thumbnail I did not
think it was a big deal but if it is I can prepare a patch, on top of
the one in place, and then 'image-dired-thumb-naming' will be used only
for the "image-dired" storage method.  WDYT?
-- 
Manuel Giraud