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: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: v.pupillo <at> gmail.com, eggert <at> cs.ucla.edu, 55163 <at> debbugs.gnu.org
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 13:00:21 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  55163 <at> debbugs.gnu.org,
>   v.pupillo <at> gmail.com
> Date: Sat, 30 Apr 2022 11:10:18 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> It's common to get a list of files (including modtime) and then offer to
> sort the files in various ways.

That might mean we want a primitive that returns a list of files
sorted by modtime, not necessarily that we want a primitive that
returns just a modtime of a file.

> My overall point here was simply: If we're going to institute some
> interface changes in how we deal with time (in general, and I think we
> probably should because of resolution and efficiency issues), it's an
> opportunity to look at the wider ecosystem of functionality in this
> area, and see whether we can improve other things at the same time.
> `file-attributes' seems like an obvious low-hanging fruit.

I agree with the general idea, but we should consider each related
functionality on a case-by-case basis, and refrain from introducing
new APIs just because we can, or because they could be useful in some
theoretical situations.  Because if we don't make these judgments, we
will risk adding gobs of new APIs that rarely if ever used in
practice, and the net result will be a fatter Emacs that is not more
useful.

Previous Next

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