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, monnier <at> IRO.UMontreal.CA
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sat, 30 Apr 2022 08:40:32 +0300

> Date: Fri, 29 Apr 2022 18:44:54 -0700
> Cc: 55163 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>  Vincenzo Pupillo <v.pupillo <at> gmail.com>,
>  Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> For consistent naming, we could borrow names from GNU/Linux and POSIX, 
> which have CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID. 
> For example, we could have:
> 
> * (clock-realtime) returns the system-wide clock. It acts like 
> (time-convert nil t), i.e., like (current-time) but returning (TICKS . 
> HZ) form.
> 
> * (clock-process-cputime) returns the Emacs process's CPU-time clock; it 
> would replace the recently-added current-cpu-time (except the obvious 
> implementation would be less likely to wrap around).
> 
> * (clock-monotonic) is like (clock-realtime) except it cannot have 
> negative clock jumps and its origin is unspecified. Emacs has nothing 
> like this now; it would be useful for apps that keep event timestamps 
> and want to know whether event A occurred before event B (current-time 
> doesn't do that).
> 
> GNU/Linux has seven other kinds of clocks that could be useful, plus 
> dynamic clocks, but we don't need to support them all, at least not 
> until there's a demonstrated need.
> 
> Alternatively, if we'd rather not add one Lisp primitive per clock, we 
> could add just one primitive (clock-time CLOCK) where CLOCK specifies 
> the type of clock desired.

Creeping featurism alert!

As I already said up-thread: let's not introduce APIs for which we
don't have clear and frequently-needed use cases in Emacs.  Emacs is
not a general-purpose programming platform, it's mainly a platform for
writing text-processing applications.  We don't need to provide
interfaces to every OS-level facility under the sun, only to those
which matter to Emacs's important uses.  Thinking about this from the
OS-level POV, as opposed to the POV of Lisp programs which could use
those facilities, will facilitate introduction of APIs that are hard
to discover, understand, and use, unless one is familiar with these
OS-level concepts and the related system calls -- which is not who
most Emacs Lisp programmers are.

IMO, this is the wrong way of introducing features into Emacs.

Previous Next

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