GNU bug report logs - #61394
30.0.50; [PATCH] Image-dired thumb name based on content

Previous Next

Full log

Message #77 received at 61394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: contovob <at> tcd.ie, stefankangas <at> gmail.com, 61394 <at> debbugs.gnu.org
Subject: Re: bug#61394: 30.0.50; [PATCH] Image-dired thumb name based on
 content
Date: Fri, 28 Jul 2023 15:20:35 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: stefankangas <at> gmail.com,  contovob <at> tcd.ie,  61394 <at> debbugs.gnu.org
> Date: Fri, 28 Jul 2023 11:33:19 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> 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?

I don't think I understand all the aspects of this, as I use neither
image-dired nor the thumbnails.  But it sounds like an incompatible
change in behavior wrt what we have in Emacs 29?  If so, how do we
expect this to work for users who will have configured their Emacs for
some particular storage type, and then upgrade to Emacs 30 when that
is released?  Will the existing thumbnails still work for them?  Will
Emacs 30 now start storing thumbnails under differently-formatted
names, even though the user didn't change his/her configuration?

In general, any incompatible change in behavior (if there is indeed
such a change caused by this changeset) is undesirable.  So I'd like
first to discuss why there was a need for the behavior change in the
first place.

(I'm sorry that I didn't realize there was a change in behavior before
installing the changeset.  It seems we never discussed that aspect in
the bug#61394 discussion thread.)

Previous Next

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