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


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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <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 13:51:24 -0700
On 4/30/22 03:00, Eli Zaretskii wrote:

> That might mean we want a primitive that returns a list of files
> sorted by modtime

Such a primitive would not be as useful. First, it's common for Emacs to 
look at files opportunistically: that is, Emacs doesn't know in advance 
all the files it will eventually look at, and so it can't give a 
primitive a list of files in advance. Second, it's common for Emacs to 
compare the timestamp of a file at time T1 with the timestamp of another 
(or the same) file at a later time T2. A primitive that accepts a list 
of files can't do that.

In contrast, a primitive that simply gives you a file's timestamp 
handles these use cases, and is considerably easier to describe and support.

> we
> will risk adding gobs of new APIs that rarely if ever used in
> practice

Yes, we don't want to do that. However the case for making improvements 
here is strong enough here that it's worth doing.

There are dozens of potential uses for the proposed (file-attributes 
FILE 'mtime) etc. improvement in Emacs right now, so it's an easy call 
that this API will get used.

There are also cases where the code now uses current-time and assumes 
that the resulting timestamps are issued in numeric order, an assumption 
that is not always true in practice. It'd be better for this code to use 
a monotonic clock instead. Admittedly the resulting misbehavior is rare 
(because it's rare that people adjust their machines' clocks), but Emacs 
shouldn't glitch out on me merely because I've corrected my laptop's 
time-of-day.





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.