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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: larsi <at> gnus.org, v.pupillo <at> gmail.com, 55163 <at> debbugs.gnu.org
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sun, 01 May 2022 08:38:39 +0300

> Date: Sat, 30 Apr 2022 13:51:24 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com,
>  Lars Ingebrigtsen <larsi <at> gnus.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> 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.

In those cases, a Lisp program usually doesn't know whether it will
sort files by time or by some other attribute, so we generally need
the list of files with all their attributes anyway.

> 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.

Please show at least 3 examples of such "common" situations.  I think
it is rather UN-common.

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

Really? what's the problem to describe and support a primitive that
returns a sorted list of files?

> > 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.

That's your opinion, not mine.  I will object to introducing such
"simple" primitives as long as the use cases for them aren't common
enough, or are better served by dedicated primitives that address
the specific use cases we care about.

People who want a general-purpose Lisp environment for writing
system-level applications should use Guile, not Emacs Lisp.

> 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.

I challenge you to present even half a dozen of such uses.

> 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.

That's a separate issue, and again: please present the use cases for
that which are relevant to Emacs applications.

Previous Next

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