bug#51523: 29.0.50; gnus-mime-view-part-externally very slow

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 01 Nov 2021 15:20:38 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 51523@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> 
> > . it uses the literal file name without even expanding it to an absolute file name, so the same FILE might mean different files if default-directory changes
> > . file names are generally not reliable enough for unique identifiers of files (think symlinks on all systems, letter-case and numerical tails on Windows, etc.), so we should at least use file-truename
> > . interning the file names could produce many unnecessary symbols in the global obarray
> >
> > Can we make the implementation more robust by fixing these?
> >
> 
> Sure, I'll do that.  Am I right that the first two points are fixed by 
> using file-truename, and that the third one would be fixed by using 
> (intern ... nil)?

Yes for the first two, but I don't understand the last one: using nil
as the 2nd argument is the same as omitting it, and they both stand
for the global obarray.  You need to specify a different obarray to
avoid "polluting" the global one.

> > The name of the function also doesn't reflect what it does: it only 
> > looks at the file's last modification time, so maybe at least "time" 
> > should be in the name?
> 
> Perhaps we could also check the file size?

If what we really want is to detect changes in contents, yes, I think
we should also check the size.

> > I also question the decision of testing modification time for equality: 
> > why not check if the time stamp is newer, and disregard the changes to 
> > an older time stamp?
> 
> This wouldn't be right I think, because the user might replace a file with 
> another one with an older modification time.

What would be the purpose of replacing with an older file, but keeping
the old time stamp?  And why is Gnus obligated to support such strange
use cases?  We can always tell the users to bump the file's time stamp
by 'touch'ing it, no?

> > When looking this way at this function, I ask myself whether extending 
> > file-newer-than-file-p to do this job would be a better idea?
> 
> You mean, using file-newer-than-file-p with two identical arguments? 

No, that'd be silly.  I mean something like

   (file-newer-than-file-p FILE t)

should have the special meaning of doing what file-has-changed-p does
now.

> > Or maybe I don't understand the general use case for this function.
> 
> The use case is the one of this bug: check whether a file has changed 
> since the last invocation of file-has-changed-p.

But then the time stamp and the size might not be enough.  What if the
inode changed, for example?

> It's used to solve this bug: mailcap-parse-mailcaps parses the
> mailcap files again only when at least one of them has changed.

Yes, but the function is supposed to be more general than just this
one case, and I'm asking about the more general use of it.