GNU bug report logs - #55163
29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

Previous Next

Full log

Message #52 received at 55163 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: Re: 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 <at> gnus.org, 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com
> From: Paul Eggert <eggert <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.