unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Manuel Giraud <manuel@ledu-giraud.fr>
Cc: contovob@tcd.ie, stefankangas@gmail.com, 61394@debbugs.gnu.org
Subject: bug#61394: 30.0.50; [PATCH] Image-dired thumb name based on content
Date: Fri, 28 Jul 2023 15:20:35 +0300	[thread overview]
Message-ID: <83bkfwjkh8.fsf@gnu.org> (raw)
In-Reply-To: <877cqkcrds.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 28 Jul 2023 11:33:19 +0200)

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





  reply	other threads:[~2023-07-28 12:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 19:06 bug#61394: 30.0.50; [PATCH] Image-dired thumb name based on content Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-10 15:13 ` Basil Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-10 18:46   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-11  9:50     ` Eli Zaretskii
2023-02-11 12:30       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-11 14:53         ` Eli Zaretskii
2023-02-11 22:33           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-11 23:06           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-12  3:02             ` Stefan Kangas
2023-02-12 21:53               ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-15 14:19                 ` Stefan Kangas
2023-02-15 15:35                   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-19 14:06                     ` Stefan Kangas
2023-02-19 14:43                       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-19 16:19                         ` Stefan Kangas
2023-02-20  9:20                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-25 18:45                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-26 19:18                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-27  7:04                               ` Eli Zaretskii
2023-07-27 13:52                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-27 14:16                                   ` Eli Zaretskii
2023-07-27 21:30                                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-28  6:55                                       ` Eli Zaretskii
2023-07-28  9:33                                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-28 12:20                                           ` Eli Zaretskii [this message]
2023-07-28 16:00                                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-28 18:44                                               ` Eli Zaretskii
2023-07-29  9:51                                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-29 10:34                                                   ` Eli Zaretskii
2023-07-29 16:50                                                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03  8:43                                                       ` Eli Zaretskii
2023-07-29 10:47                                                   ` Michael Albinus
2023-07-31 15:53                                                   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-01 17:05                                                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-02 11:42                                                       ` Eli Zaretskii
2023-08-02 18:00                                                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-02 18:16                                                           ` Eli Zaretskii
2023-08-03 11:10                                                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 11:38                                                               ` Eli Zaretskii
2023-08-03 16:51                                                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 18:30                                                                   ` Eli Zaretskii
2023-08-04  7:44                                                                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-04 10:55                                                                       ` Eli Zaretskii
2023-08-04 13:37                                                                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-04 14:05                                                                           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83bkfwjkh8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=61394@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=manuel@ledu-giraud.fr \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).