Subject: RE: [External] : Re: bug#73709: 29.4; Doc of `file-newer-than-file-p'

From: Drew Adams <[email-masked]>
Date: Sat, 12 Oct 2024 01:13:46 +0000

> > No, the request was explicitly to add specific technical details about
> > how we implement the abstraction.  Which is what we have now, and I
> > think it's a step in the wrong direction.
> 
> Drew, would it be acceptable for you if we tried to describe the
> abstraction without relying on file-system related details?  And how
> could that look like?

I don't care how you describe the meaning that what's
more recent is the time/date of the last _content_
change.

(Of course, it's a bit more nuanced than that, since
you can `touch' a file without changing its content.
But at a first approximation it's conceptually about
a change in content.)

You don't have to refer to the file attribute that has
that meaning (`file-attribute-modification-time').
What's important is to convey the meaning - that's the
thing (aspect/attribute/dimension) whose relative
recentness is measured/compared.

Do I think it would be a _good_ thing to actually refer
to that attribute by name?  Yes, because it's described
rigorously and carefully (in the same node, no less).
And even if you want to repeat the description, making
the connection with the attribute that has that meaning
helps users - it doesn't hurt them.

That's what I think, but I don't say that's what you
need to do.

If you prefer to describe that meaning without
referring to that attribute (because you think doing
so gets into the "implementation"), go for it.  To me,
that makes Occam gag a bit, but it gets the job done.

"Last modification" by itself doesn't describe it.
"Last content modification" comes close.