From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Date: Fri, 29 Apr 2022 18:44:54 -0700 Organization: UCLA Computer Science Department Message-ID: <156b848f-0ba3-a2d8-a343-314e24d37934@cs.ucla.edu> References: <87sfpxxyvb.fsf@3-191.divsi.unimi.it> <87zgk5jtm6.fsf@gnus.org> <87o80kj2q1.fsf@gnus.org> <878rroi5a8.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5858"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Cc: Vincenzo Pupillo , 55163@debbugs.gnu.org, Stefan Monnier To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 30 03:46:11 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 1nkcBW-0001Oa-E0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Apr 2022 03:46:10 +0200 Original-Received: from localhost ([::1]:43588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkcBU-0003u1-UO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Apr 2022 21:46:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40116) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkcBN-0003tr-UO for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 21:46:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkcBN-0003Pd-Ks for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 21:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nkcBN-00062N-HO for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 21:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Apr 2022 01:46:01 +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.165128310323130 (code B ref 55163); Sat, 30 Apr 2022 01:46:01 +0000 Original-Received: (at 55163) by debbugs.gnu.org; 30 Apr 2022 01:45:03 +0000 Original-Received: from localhost ([127.0.0.1]:55670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkcAR-000610-50 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 21:45:03 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkcAP-00060C-4k for 55163@debbugs.gnu.org; Fri, 29 Apr 2022 21:45:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 98D1B16006C; Fri, 29 Apr 2022 18:44:55 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vSPVE836Etza; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A7AD916007E; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WJII4EgrIrH7; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66C3316006C; Fri, 29 Apr 2022 18:44:54 -0700 (PDT) Content-Language: en-US In-Reply-To: <878rroi5a8.fsf@gnus.org> 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:230991 Archived-At: On 4/29/22 02:54, Lars Ingebrigtsen wrote: > Off the top of my head, we could have > (file-attribute file 'modification-time) (i.e., have a &rest to specify > the attributes, and don't return a list if there's one attribute, which > is common). Yes, one possibility is to generalize file-attributes's existing ID-FORMAT argument. For example, if (file-attributes "/") currently returns (t 20 0 0 (25196 16750 33564 745000) (25175 34183 905318 398000) (25175 34183 905318 398000) 4096 "dr-xr-xr-x" t 2 2053), then (file-attributes "/" '(mtime size dev)) would return just ((1649902983905318398000 . 1000000000000) 4096 2053) - that is, just the requested components. And (file-attributes "/" 'size) would return just 4096 as you suggest. file-attributes's existing ID-FORMAT args 'integer' and 'string' would continue to have their current meaning for backward compatibility. > And we could have `time' instead of `current-time', with > (time 'float) instead of `float-time' and even (time 'decoded) instead > of `decode-time'. Or `time-float', `time-decoded' with no parameters... It sounds like the idea here is to use the prefix 'time' for time-related functions. Although I prefixed 'time-' to names of the time functions I added a few years ago (e.g., time-convert) I'm a bit leery about using the very-generic name 'time' for a new function. It's probably better to use a hyphenated name. > introduce efficient functions with consistent > naming, and then obsolete the old ones after a while. 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.