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

Previous Next

Full log

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

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: Re: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for
 current-time broke lsp-mode
Date: Fri, 29 Apr 2022 22:53:31 +0300

> Date: Fri, 29 Apr 2022 12:38:19 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 4/29/22 04:10, Eli Zaretskii wrote:
> > Then why again would we want to come up with new functions for
> > handling timestamps? just because the existing ones have names that
> > make discovery difficult, or are there other reasons?
> 
> I think Lars is saying both, though the other reasons are more important.
> 
> Lars makes a good point that common idioms like 
> (file-attribute-modification-time (file-attributes F)) generate 
> unnecessary garbage. And it's more than just GC overhead: at a lower 
> level, 'statx' on GNU/Linux can be significantly more efficient than 
> plain 'stat' when retrieving just a subset of stat info (such as, just 
> the file timestamp).

This is (almost) unrelated to timestamps.  The same case can be made
about almost every individual file attribute, at least theoretically.

But before we implement a separate primitive for each attribute, we
should ask ourselves: what are the use cases where a Lisp program
would want to use such a primitive.  Taking the file's modification
time as an example, are there any important use cases except
determining if a file is older or newer than another?  Because we
already have a primitive for that.

Previous Next

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