GNU bug report logs -
#55163
29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Previous Next
Reported by: Vincenzo Pupillo <v.pupillo <at> gmail.com>
Date: Thu, 28 Apr 2022 10:55:01 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #49 received at 55163 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 3 years and 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.