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

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/29/22 02:54, Lars Ingebrigtsen wrote:

> Off the top of my head, we could have
> (file-attribute file 'modification-time) (i.e., have a &rest to specify
> the attributes, and don't return a list if there's one attribute, which
> is common).

Yes, one possibility is to generalize file-attributes's existing 
ID-FORMAT argument. For example, if (file-attributes "/") currently 
returns (t 20 0 0 (25196 16750 33564 745000) (25175 34183 905318 398000) 
(25175 34183 905318 398000) 4096 "dr-xr-xr-x" t 2 2053), then 
(file-attributes "/" '(mtime size dev)) would return just 
((1649902983905318398000 . 1000000000000) 4096 2053) - that is, just the 
requested components. And (file-attributes "/" 'size) would return just 
4096 as you suggest.

file-attributes's existing ID-FORMAT args 'integer' and 'string' would 
continue to have their current meaning for backward compatibility.


>  And we could have `time' instead of `current-time', with
> (time 'float) instead of `float-time' and even (time 'decoded) instead
> of `decode-time'.  Or `time-float', `time-decoded' with no parameters...

It sounds like the idea here is to use the prefix 'time' for 
time-related functions. Although I prefixed 'time-' to names of the time 
functions I added a few years ago (e.g., time-convert) I'm a bit leery 
about using the very-generic name 'time' for a new function. It's 
probably better to use a hyphenated name.


> introduce efficient functions with consistent
> naming, and then obsolete the old ones after a while.
For consistent naming, we could borrow names from GNU/Linux and POSIX, 
which have CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID. 
For example, we could have:

* (clock-realtime) returns the system-wide clock. It acts like 
(time-convert nil t), i.e., like (current-time) but returning (TICKS . 
HZ) form.

* (clock-process-cputime) returns the Emacs process's CPU-time clock; it 
would replace the recently-added current-cpu-time (except the obvious 
implementation would be less likely to wrap around).

* (clock-monotonic) is like (clock-realtime) except it cannot have 
negative clock jumps and its origin is unspecified. Emacs has nothing 
like this now; it would be useful for apps that keep event timestamps 
and want to know whether event A occurred before event B (current-time 
doesn't do that).

GNU/Linux has seven other kinds of clocks that could be useful, plus 
dynamic clocks, but we don't need to support them all, at least not 
until there's a demonstrated need.

Alternatively, if we'd rather not add one Lisp primitive per clock, we 
could add just one primitive (clock-time CLOCK) where CLOCK specifies 
the type of clock desired.