unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mathias Dahl" <mathias.dahl@gmail.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Small change in image-dired.el
Date: Sun, 30 Mar 2008 01:55:43 +0100	[thread overview]
Message-ID: <7dbe73ed0803291755j6d7a3a06l8ac07282fd608961@mail.gmail.com> (raw)
In-Reply-To: <jwv3aq9s2hf.fsf-monnier+emacs@gnu.org>

>  What is the rationale for such a "feature"?

See below.

>  Generally, modifying a file
>  and then changing its timestamp back to what it was is a good way to get
>  in trouble (many programs assume that if the timestamp hasn't changed,
>  then the file hasn't changed).

Yes, I agree, mostly.

>  I'm not necessarily opposed to it, but I'd first like a compelling
>  evidence that this is really the right way to solve the
>  original problem.

I think the only "problem" was that Stefan R was used to work in a
certain way with his photos, and the rotation messed up with his
scheme. I suspect for him that a rotation is an operation that can be
neglected from a change viewpoint.

Here is our original conversation:

----

from	Stefan Reichör
to	Mathias Dahl
date	Sat, Jun 17, 2006 at 10:31 PM
subject	Improvement for tumme-rotate-original
mailed-by	utanet.at
		
Hi Mathias!

I try to use tumme to organize/view my photo collection.
My photos all keep the timestamp when they were shot.

I modified tumme-rotate-original in a way that the time stamp is
preserved. It would be nice, if you could add this functionality!

Stefan.

[patch removed]

from	Mathias Dahl
to	Stefan Reichör
date	Sun, Jun 18, 2006 at 8:53 AM
subject	Re: Improvement for tumme-rotate-original
mailed-by	gmail.com
	
Thanks for the patch, I'll think about it. Personally I never trust
the timestamp of a file because I have found out too many times that
it has been modified in transit, when copying, moving, FTPing,
zipping, whatever... What I do instead is trust the EXIF data in it,
make sure that it is always preserved (tumme does that by default). I
also rename all the photos I take with my camera using the internal
timestamp so that the names will be unique and sorted in the correct
order in dired etc. Tumme has a command for this,
`tumme-copy-with-exif-file-name'. Maybe that is something you would
like to try?

Also, the touch command is not available on w32 so this would have to
be an option or we would have to find a suitable replacement command
that works there.

I suggest you keep your fix in your .emacs and I *might* try merge it
into tumme.el when I have the time.

Again, thanks for the suggestion!

from	Stefan Reichör
to	Mathias Dahl
date	Mon, Jun 19, 2006 at 6:23 AM
subject	Re: Improvement for tumme-rotate-original
	
Hi Mathias!

> Thanks for the patch, I'll think about it. Personally I never trust
> the timestamp of a file because I have found out too many times that
> it has been modified in transit, when copying, moving, FTPing,
> zipping, whatever... What I do instead is trust the EXIF data in it,
> make sure that it is always preserved (tumme does that by default). I
> also rename all the photos I take with my camera using the internal
> timestamp so that the names will be unique and sorted in the correct
> order in dired etc. Tumme has a command for this,
> `tumme-copy-with-exif-file-name'. Maybe that is something you would
> like to try?

Thanks for your ideas. I try to keep the date correct for my pictures.
And that works for me. Thanks for the hint about the EXIF data.

I also have a small python script to rename my pictures, using the
date. It is nice to see that date on the back of the pictures when I
order them from a photo shop.

> Also, the touch command is not available on w32 so this would have to
> be an option or we would have to find a suitable replacement command
> that works there.

You could try, if touch is available and use it only then. Something
like tumme-has-touch-command.

> I suggest you keep your fix in your .emacs and I *might* try merge it
> into tumme.el when I have the time.

That is fine with me. I think most users will prefer this behaviour.

----

As you can see, I too think EXIF should be trusted rather than the
timestamp. Still, I thought the feature sounded OK to have and should
not hurt anything, especially with the new variable
introduced. Granted, even if the change is quite small, it increases complexity,
so I won't argue about it being included.

/Mathias




      parent reply	other threads:[~2008-03-30  0:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-29 20:08 Small change in image-dired.el Mathias Dahl
2008-03-29 20:27 ` Stefan Monnier
2008-03-29 21:27   ` Reiner Steib
2008-03-29 21:38     ` Stefan Monnier
2008-03-30  0:55   ` Mathias Dahl [this message]

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=7dbe73ed0803291755j6d7a3a06l8ac07282fd608961@mail.gmail.com \
    --to=mathias.dahl@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).