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: Mon, 02 May 2022 20:58:10 +0300

> Date: Mon, 2 May 2022 10:27:14 -0700
> Cc: 55163 <at> debbugs.gnu.org, v.pupillo <at> gmail.com, larsi <at> gnus.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > What's the difference, for the purpose of this discussion, between
> > having the code in C and having it in internal Lisp functions?
> 
> The internal Lisp function would need an efficient way to get a file's 
> timestamp. It can't do that if there's no C primitive to do it.

And this is relevant to this discussion because...?

The discussion, to remind you, was whether we should provide _public_
APIs to obtain individual attributes, as opposed to providing more
high-level public APIs that serve specific important use cases of
using those attributes, without exposing those attributes.

> > What we have established is that Emacs apps need to be able to measure
> > time intervals, not that they need a monotonic clock.  Functions for
> > measuring time intervals can be built on functions that return
> > monotonic clock time, but they can also be built on other bases that
> > have very little with actual time stamps.
> 
> What other bases would these be? Monotonic clocks are relatively 
> portable; other methods that come to mind are not.

As long as such a method exists on a platform, that platform can make
do without high-resolution wallclock time.

Previous Next

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