From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <838rrn9lin.fsf@gnu.org> References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16086"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 30 07:42:22 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nkfs6-00040I-10 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Apr 2022 07:42:22 +0200 Original-Received: from localhost ([::1]:52664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkfry-00018A-7d for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Apr 2022 01:42:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfqo-00016v-TJ for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 01:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33629) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkfqo-0007vR-Is for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 01:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nkfqo-0003nH-B7 for bug-gnu-emacs@gnu.org; Sat, 30 Apr 2022 01:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Apr 2022 05:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55163 X-GNU-PR-Package: emacs Original-Received: via spool by 55163-submit@debbugs.gnu.org id=B55163.165129724214550 (code B ref 55163); Sat, 30 Apr 2022 05:41:02 +0000 Original-Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 05:40:42 +0000 Original-Received: from localhost ([127.0.0.1]:55759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkfqT-0003mb-UU for submit@debbugs.gnu.org; Sat, 30 Apr 2022 01:40:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkfqR-0003mM-Tw for 55163@debbugs.gnu.org; Sat, 30 Apr 2022 01:40:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfqL-0007uR-75; Sat, 30 Apr 2022 01:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=i34iHCTEnPcAQPl1fZrw2XId6ZoC2lrVNyyI+zs07/Q=; b=LFchBFFwL8eX 4S0Nk6odDeVuoVWtDPzd3giTf84RvQD4M2wlxKL+vbkb4GnDUHoASaghSexLihDRlhmDL1lnZYrno HiiK+7Qtdnbi51qUOaoES1wprqRKGSMqpogLfffM9ERhGw5WvrdyBksU/WYDJonMpGASA9iKz7aON jYhu7m3zAUZLX1H3np/jynjugQBThoTOg5krjXhR6isDCgFeP9dfLbd9Ixuk5c0i0QzKQryBtV58c MLrIaDngsXHnugxOUkV8AyqxRGhZ7bYuQrhFhYM7BlDw3bGbHxf/70bUKEPT1va0Od/Sd+lyfTARQ IjeCn2a4ovs44ppaLAEhlA==; Original-Received: from [87.69.77.57] (port=3530 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkfqI-0003IQ-D6; Sat, 30 Apr 2022 01:40:33 -0400 In-Reply-To: <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> (message from Paul Eggert on Fri, 29 Apr 2022 18:44:54 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:230995 Archived-At: > Date: Fri, 29 Apr 2022 18:44:54 -0700 > Cc: 55163@debbugs.gnu.org, Eli Zaretskii , > Vincenzo Pupillo , > Stefan Monnier > From: Paul Eggert > > 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.