[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?
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, (continued)
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Lars Ingebrigtsen, 2022/04/28
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Lars Ingebrigtsen, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Lars Ingebrigtsen, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Paul Eggert, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Paul Eggert, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode,
Eli Zaretskii <=
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Lars Ingebrigtsen, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Paul Eggert, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Paul Eggert, 2022/04/29
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Vincenzo Pupillo, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Vincenzo Pupillo, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Eli Zaretskii, 2022/04/30
- bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode, Vincenzo Pupillo, 2022/04/30