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

Previous Next

Package: emacs;

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


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Vincenzo Pupillo <v.pupillo <at> gmail.com>, 55163 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 14:03:55 -0700
On 4/30/22 02:15, Lars Ingebrigtsen wrote:
>> * (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- as a prefix does make a lot of sense, but I think I'd interpret
> that as "realtime" as something having to do with scheduling

Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
Perhaps we should use "universal" instead, since it's Universal Time.

Another thought is that instead of a new Lisp function, we could extend 
current-time. E.g., (current-time 'universal) would return the current 
time in seconds since the EPOCH, (current-time 'process-cpu) the 
process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
Although this wouldn't let us reorganize the time API in a major way, it 
would let us add the needed functionality in a way that follows existing 
practice pretty closely, and there's benefit to that.




This bug report was last modified 3 years and 20 days ago.

Previous Next


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