bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time brok


From: Eli Zaretskii
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 08:29:24 +0300

> Date: Fri, 29 Apr 2022 15:45:44 -0700
> Cc: larsi@gnus.org, 55163@debbugs.gnu.org, v.pupillo@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> >   Taking the file's modification
> > time as an example, are there any important use cases except
> > determining if a file is older or newer than another?
> 
> Yes, for example lots of Lisp code takes a file timestamp, keeps it 
> somewhere, then examines it later to print or to compare to another 
> timestamp. See, for example, how ido-file-name-all-completions compares 
> ctime (the cached timestamp) to mtime (the file timestamp).

Such code cannot take advantage of this particular proposal, it will
have to be rewritten to be able to do that.  When it _is_ rewritten,
it can easily use the existing primitive, perhaps after we extend it
(see below).

> > we already have a primitive for that
> 
> Sure, but file-newer-than-file-p is not adequate for many routine 
> calculations involving file timestamps. It can't do the sort of caching 
> described above, for example.

We can easily extend it to be able to receive a time object instead of
one of the file names.  (Or maybe I don't understand what kind of
"caching" you have in mind.)

But since we were talking about something more general, what are the
use cases for the other file attributes that would be much better
served by having separate primitives for those attributes?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]