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

[Gregory Heytings]

> . 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)?

> 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?  This is IIRC what rsync does 
for example (by default), it considers that a file has changed if its 
modification time or size has changed.

> 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.  In which case the file has 
changed, too.

> 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? 
That would always return nil, I guess.

> 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.  It's used to solve this 
bug: mailcap-parse-mailcaps parses the mailcap files again only when at 
least one of them has changed.  Without this, when mailcap-parse-mailcaps 
is called in a loop, the mailcap files are parsed again and again, which 
is slow and unnecessary.