bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Vincenzo Pupillo]

Hi,
the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
expression (/ (nth 2 (time-since before-send)) 1000) to
calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.

Thank you.
Ciao



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-04-28 built on 3-191.divsi.unimi.it
Repository revision: 9c70045f674b31db7a640d8a59939ce8df7ed37b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 35 (KDE Plasma)

Configured using:
 'configure --with-cairo --with-x-toolkit=gtk3 --with-xwidgets
 --without-pop --without-imagemagick --prefix=/opt/emacs_x11
 --with-file-notification=inotify --enable-link-time-optimization
 --with-native-compilation --with-xinput2 'CFLAGS=-DMAIL_USE_LOCKF -O3
 -fno-strict-aliasing -g -march=native -mtune=native -D_FORTIFY_SOURCE=2
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fstack-clash-protection
 -fcf-protection''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: it_IT.UTF-8
  locale-coding-system: utf-8-unix

Major mode: JavaScript[JSX]

Minor modes in effect:
  lsp-ui-mode: t
  lsp-ui-doc-mode: t
  dap-tooltip-mode: t
  dap-ui-mode: t
  dap-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  global-semanticdb-minor-mode: t
  global-git-gutter-mode: t
  git-gutter-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  auto-revert-mode: t
  shell-dirtrack-mode: t
  which-key-mode: t
  projectile-mode: t
  lsp-mode: t
  yas-minor-mode: t
  company-quickhelp-mode: t
  company-quickhelp-local-mode: t
  global-company-mode: t
  company-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  persp-mode: t
  vertico-mode: t
  override-global-mode: t
  electric-pair-mode: t
  which-function-mode: t
  save-place-mode: t
  winner-mode: t
  minibuffer-electric-default-mode: t
  savehist-mode: t
  delete-selection-mode: t
  recentf-mode: t
  xterm-mouse-mode: t
  semantic-idle-completions-mode: t
  global-semantic-idle-completions-mode: t
  global-semantic-idle-scheduler-mode: t
  global-semantic-idle-summary-mode: t
  semantic-idle-summary-mode: t
  semantic-idle-scheduler-mode: t
  semantic-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/opt/emacs_x11/share/emacs/29.0.50/lisp/transient hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/transient-20220425.1314/transient
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/build/src/irony
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony-cdb-json hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-cdb-json
/home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/irony-iotask hides /home/vincenzo/Projects/Emacs/newconfig/emacs.d/elpa/irony-20220110.849/server/test/elisp/irony-iotask

Features:
(shadow sort mail-extr emacsbug cl-print debug backtrace
semantic/decorate/mode semantic/decorate semantic/imenu semantic/sb
semantic/db-typecache lsp-ui lsp-ui-flycheck lsp-ui-doc xwidget
goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline lsp-ui-util lsp-zig
lsp-steep lsp-svelte lsp-sqls lsp-yaml lsp-xml lsp-vimscript lsp-vhdl
lsp-volar lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v lsp-typeprof
lsp-ttcn3 lsp-toml lsp-terraform lsp-tex lsp-sorbet lsp-solargraph
lsp-rust lsp-rf lsp-remark lsp-r lsp-purescript lsp-pylsp lsp-pyls
lsp-pwsh lsp-php lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml
lsp-magik lsp-nix lsp-nim lsp-nginx lsp-markdown lsp-lua lsp-kotlin
lsp-json lsp-javascript lsp-java request lsp-idris lsp-haxe lsp-groovy
lsp-hack lsp-graphql lsp-go lsp-completion lsp-gdscript lsp-fsharp
lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elixir lsp-elm
lsp-dockerfile lsp-dhall lsp-dart lsp-dart-commands
lsp-dart-flutter-widget-guide lsp-dart-flutter-fringe-colors
lsp-dart-flutter-colors lsp-dart-outline lsp-dart-code-lens
lsp-dart-test-tree lsp-dart-test-output lsp-dart-test-support
lsp-dart-dap lsp-dart-devtools lsp-dart-flutter-daemon dap-utils
dap-mouse dap-ui gdb-mi bindat gud bui bui-list bui-info bui-entry
bui-core bui-history bui-button bui-utils lsp-lens dap-mode dap-launch
posframe dap-overlays lsp-dart-closing-labels lsp-dart-utils
lsp-dart-protocol lsp-d lsp-css lsp-csharp lsp-crystal lsp-cmake
lsp-clojure lsp-treemacs lsp-treemacs-themes treemacs
treemacs-header-line treemacs-compatibility treemacs-mode
treemacs-bookmarks treemacs-interface treemacs-extensions
treemacs-mouse-interface treemacs-tags treemacs-persistence
treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering
treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse treemacs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture
treemacs-logging treemacs-customization treemacs-macros
lsp-semantic-tokens lsp-clangd lsp-beancount lsp-bash lsp-ansible
lsp-angular lsp-ada lsp-actionscript semantic/db-find semantic/db-ref
semantic/db-file data-debug cedet-files semantic/wisent/javascript-jv
semantic/wisent/js-wy semantic/wisent semantic/wisent/wisent
semantic/java semantic/doc js-mode-expansions js vc-git vc-dispatcher
company-web-html company-web company-css web-completion-data
web-mode-expansions semantic/db-mode web-mode shortdoc help-fns
radix-tree mule-util cal-move misearch multi-isearch ol-eww eww xdg
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file url-dired svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader range
ol-docview doc-view jka-compr image-mode exif ol-bibtex ol-bbdb ol-w3m
ol-doi org-link-doi the-org-mode-expansions org-element avl-tree org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-java ob-sql ob-js ob-C cc-mode-expansions cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs ob-python ob-shell ob-awk ob ob-tangle org-src ob-ref ob-lob
ob-table ob-exp ob-comint ob-core ob-eval org-table oc-basic bibtex ol
org-keys oc org-compat org-macs org-loaddefs cal-menu calendar
cal-loaddefs git-gutter google-translate-smooth-ui
google-translate-core-ui facemenu popup google-translate-core
google-translate-tk google-translate-backend magit-bookmark
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
diff git-commit log-edit message sendmail yank-media dired
dired-loaddefs rfc822 mml mml-sec epa derived gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
magit-git magit-base magit-section crm compat-27 compat-26 compat vterm
tramp tramp-loaddefs trampver tramp-integration tramp-compat parse-time
iso8601 time-date ls-lisp format-spec face-remap term disp-table shell
pcomplete ehelp vterm-module term/xterm xterm expand-region
text-mode-expansions python-el-fgallina-expansions er-basic-expansions
expand-region-core expand-region-custom dired-launch which-key
projectile-speedbar sr-speedbar speedbar dframe projectile lisp-mnt
ibuf-ext ibuffer ibuffer-loaddefs add-log init custom-rust custom-dart
custom-java mvn custom-go custom-sql sql view custom-clojure custom-web
custom-ruby custom-python elpy elpy-rpc pyvenv eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
elpy-shell elpy-profile elpy-django elpy-refactor diff-mode python
hideshow grep files-x cus-edit cus-start cus-load custom-php
custom-markdown custom-c irony irony-iotask lsp-modeline lsp-mode
lsp-protocol yasnippet spinner network-stream puny nsm rmc markdown-mode
color noutline outline lv inline ht filenotify f s ewoc epg rfc6068
epg-config compile comint company-quickhelp pos-tip company-yasnippet
company-keywords company-etags etags fileloop generator
company-dabbrev-code company-dabbrev company-files company-semantic
company-template company-capf company pcase consult-flycheck flycheck
ansi-color dash consult-imenu consult-xref xref project consult-vertico
consult bookmark text-property-search perspective comp comp-cstr
warnings advice thingatpt ido vertico rx edmacro kmacro cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source password-cache json map url-vars
elec-pair which-func imenu saveplace winner ring minibuf-eldef hl-line
savehist delsel recentf tree-widget wid-edit xt-mouse custom-function
custom-variable semantic/idle semantic/analyze semantic/sort
semantic/scope semantic/analyze/fcn semantic/db eieio-base cl-seq
semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt
semantic/util-modes semantic/util semantic pp semantic/tag semantic/lex
semantic/fw eieio seq subr-x byte-opt bytecomp byte-compile cconv
eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib mode-local
find-func cedet iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice simple cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 825540 79395)
 (symbols 48 59651 1)
 (strings 32 278778 26200)
 (string-bytes 1 11022323)
 (vectors 16 122356)
 (vector-slots 8 2826624 108417)
 (floats 8 1092 841)
 (intervals 56 3189 489)
 (buffers 992 28))

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Vincenzo Pupillo <v.pupillo@gmail.com> writes:

> the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
> expression (/ (nth 2 (time-since before-send)) 1000) to
> calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.

Paul, it seems like this change is just breaking too much code out
there, so I think it'll have to be reverted.

Eli, what do you think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 55163@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii
>  <eliz@gnu.org>
> Date: Thu, 28 Apr 2022 14:10:57 +0200
> 
> Vincenzo Pupillo <v.pupillo@gmail.com> writes:
> 
> > the recent patch 4a1f69ebca broke the lsp-mode logging code. The logging code uses the expression
> > expression (/ (nth 2 (time-since before-send)) 1000) to
> > calculate the time of the event to be logged. lsp-mode starts the lsp-server, but is unable to work.
> 
> Paul, it seems like this change is just breaking too much code out
> there, so I think it'll have to be reverted.
> 
> Eli, what do you think?

I tend to agree.

I actually didn't expect Paul to make such changes, given the recent
discussion on emacs-devel, where he seemed to agree with my argument
against this kind of changes.  But he did make this change regardless.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On 4/28/22 05:10, Lars Ingebrigtsen wrote:
> Paul, it seems like this change is just breaking too much code out
> there, so I think it'll have to be reverted.

Yes, I came to pretty much the same conclusion. I installed the attached 
patch to revert the effect of the change. Instead, this patch adds a new 
variable current-time-list that lets you try out the new timestamp 
behavior, with the default being the longstanding behavior.

This was separate from the long thread we had about exposing 
clock_getres results to the user, as it doesn't involve calling 
clock_getres; it's merely about timestamp format.

Also, I notice that current-cpu-time was recently added; I'll try to 
spring some time free to look into it and will follow up on Bug#44674.

[-- Attachment #2: 0001-Change-current-time-back-to-list-form.patch --]
[-- Type: text/x-patch, Size: 11935 bytes --]

From 083d2708f9ec7f09712488a99fc9eedd3d594ff6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 28 Apr 2022 12:50:39 -0700
Subject: [PATCH] Change current-time back to list form

Change current-time and related functions back to using the
traditional list form.  Also, add a new boolean variable
current-time-list that lets people try out (TICKS . HZ) form,
with the goal of smoothing the transition.
* src/timefns.c (CURRENT_TIME_LIST): Change default back to true.
(current-time-list): New boolean Lisp variable, which defaults to
CURRENT_TIME_LIST.  All uses of CURRENT_TIME_LIST changed to
use current_time_list, and all documentation changed.
---
 doc/lispintro/emacs-lisp-intro.texi |  9 ++++--
 doc/lispref/files.texi              | 24 +++++++++------
 doc/lispref/intro.texi              |  4 ++-
 doc/lispref/os.texi                 | 29 +++++++++++++----
 etc/NEWS                            | 15 +++++----
 src/timefns.c                       | 48 +++++++++++++++++++----------
 6 files changed, 87 insertions(+), 42 deletions(-)

diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
index afaed10cdf..049c8a65a8 100644
--- a/doc/lispintro/emacs-lisp-intro.texi
+++ b/doc/lispintro/emacs-lisp-intro.texi
@@ -15343,9 +15343,12 @@ Files List
 100
 @end group
 @group
-(1351051674579989697 . 1000000000)
-(1173477761000000000 . 1000000000)
-(1351050967734791805 . 1000000000)
+(20615 27034 579989 697000)
+(17905 55681 0 0)
+(20615 26327 734791 805000)@footnote{If @code{current-time-list} is
+@code{nil} the three timestamps are @code{(1351051674579989697
+. 1000000000)}, @code{(1173477761000000000 . 1000000000)}, and
+@code{(1351050967734791805 . 1000000000)}, respectively.}
 13188
 "-rw-r--r--"
 @end group
diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi
index 4394f64a32..75905658e6 100644
--- a/doc/lispref/files.texi
+++ b/doc/lispref/files.texi
@@ -1423,9 +1423,9 @@ File Attributes
 @group
 (file-attributes "files.texi" 'string)
      @result{}  (nil 1 "lh" "users"
-          (1351023123050040152 . 1000000000)
-          (1310720023000000000 . 1000000000)
-          (1351023659902289872 . 1000000000)
+          (20614 64019 50040 152000)
+          (20000 23 0 0)
+          (20614 64555 902289 872000)
           122295 "-rw-rw-rw-"
           t 6473924464520138
           1014478468)
@@ -1449,14 +1449,20 @@ File Attributes
 @item "users"
 is in the group with name @samp{users}.
 
-@item (1351023123050040152 . 1000000000)
-was last accessed on October 23, 2012, at 20:12:03.050040152 UTC.
+@item (20614 64019 50040 152000)
+was last accessed on October 23, 2012, at 20:12:03.050040152 UTC@.
+(This timestamp is @code{(1351023123050040152 . 1000000000)}
+if @code{current-time-list} is @code{nil}.)
 
-@item (1310720023000000000 . 1000000000)
-was last modified on July 15, 2001, at 08:53:43.000000000 UTC.
+@item (20000 23 0 0)
+was last modified on July 15, 2001, at 08:53:43.000000000 UTC@.
+(This timestamp is @code{(1310720023000000000 . 1000000000)}
+if @code{current-time-list} is @code{nil}.)
 
-@item (1351023659902289872 . 1000000000)
-last had its status changed on October 23, 2012, at 20:20:59.902289872 UTC.
+@item (20614 64555 902289 872000)
+last had its status changed on October 23, 2012, at 20:20:59.902289872 UTC@.
+(This timestamp is @code{(1351023659902289872 . 1000000000)}
+if @code{current-time-list} is @code{nil}.)
 
 @item 122295
 is 122295 bytes long.  (It may not contain 122295 characters, though,
diff --git a/doc/lispref/intro.texi b/doc/lispref/intro.texi
index d1a3fef7a4..975215d697 100644
--- a/doc/lispref/intro.texi
+++ b/doc/lispref/intro.texi
@@ -503,9 +503,11 @@ Version Info
 @example
 @group
 emacs-build-time
-     @result{} (1650228902637038831 . 1000000000)
+     @result{} (25194 55894 8547 617000)
 @end group
 @end example
+(This timestamp is @code{(1651169878008547617 . 1000000000)}
+if @code{current-time-list} was @code{nil} when Emacs was built.)
 @end defvar
 
 @defvar emacs-version
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 89ddf164a1..20b6c1cec6 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -1359,6 +1359,10 @@ Time of Day
 @tex
 $high \times 2^{16} + low + micro \times 10^{-6} + pico \times 10^{-12}$.
 @end tex
+If @code{current-time-list} is @code{t},
+some functions may default to returning two- or
+three-element lists, with omitted @var{micro} and @var{pico}
+components defaulting to zero.
 On all current machines @var{pico} is a multiple of 1000, but this
 may change as higher-resolution clocks become available.
 @end itemize
@@ -1410,15 +1414,28 @@ Time of Day
 @end example
 @end defun
 
+@defvar current-time-list
+This boolean variable is a transition aid.  If @code{t},
+@code{current-time} and related functions return timestamps in list
+form, typically @code{(@var{high} @var{low} @var{micro} @var{pico})};
+otherwise, they use @code{(@var{ticks} . @var{hz})} form.  Currently
+this variable defaults to @code{t}, for behavior compatible with
+previous Emacs versions.  Developers are encourage to test
+timestamp-related code with this variable set to @code{nil}, as it
+will default to @code{nil} in a future Emacs version, and will be
+removed in some version after that.
+@end defvar
+
 @defun current-time
 This function returns the current time as a Lisp timestamp.
-The timestamp has the form @code{(@var{ticks} . @var{hz})} where
+If @code{current-time-list} is @code{nil},
+the timestamp has the form @code{(@var{ticks} . @var{hz})} where
 @var{ticks} counts clock ticks and @var{hz} is the clock ticks per second.
-
-In Emacs 28 and earlier, the returned timestamp had the list form
-@code{(@var{high} @var{low} @var{usec} @var{psec})}.  You can use
-@code{(time-convert nil 'list)} to return the current time in this
-older form.  @xref{Time Conversion}.
+Otherwise, the timestamp has the list form
+@code{(@var{high} @var{low} @var{usec} @var{psec})}.
+You can use @code{(time-convert nil t)} or @code{(time-convert nil 'list)}
+to obtain a particular form regardless of the value of
+@code{current-time-list}.  @xref{Time Conversion}.
 @end defun
 
 @defun float-time &optional time
diff --git a/etc/NEWS b/etc/NEWS
index 70087f2629..9f93c4067f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -203,12 +203,15 @@ use the new 'tamil-itrans-digits' and 'tamil-inscript-digits' input
 methods instead.
 
 +++
-** current-time and related functions now yield (TICKS . HZ) timestamps.
-Previously they yielded timestamps of the forms (HI LO US PS), (HI LO
-US) or (HI LO), which were less regular and less efficient and which
-lacked information about clock resolution.  This long-planned change
-was documented in Emacs 27.  To convert a timestamp X to the old
-4-element list form, you can use (time-convert X 'list).
+** New variable current-time-list governing default timestamp form.
+Functions like current-time now yield (TICKS . HZ) timestamps if this
+new variable is nil.  The variable defaults to t, which means these
+functions default to timestamps of the forms (HI LO US PS), (HI LO US)
+or (HI LO), which are less regular and less efficient.  This is part
+of a long-planned change first documented in Emacs 27.  Developers are
+encourage to test timestamp-related code with this variable set to
+nil, as it will default to nil in a future Emacs version and will be
+removed some time after that.
 
 \f
 * Changes in Emacs 29.1
diff --git a/src/timefns.c b/src/timefns.c
index 651e0760e8..bca9a566e0 100644
--- a/src/timefns.c
+++ b/src/timefns.c
@@ -69,11 +69,11 @@ Copyright (C) 1985-1987, 1989, 1993-2022 Free Software Foundation, Inc.
 # define FASTER_TIMEFNS 1
 #endif
 
-/* current-time etc. generate (TICKS . HZ) timestamps.
-   To change that to the old 4-element list format (HI LO US PS),
-   compile with -DCURRENT_TIME_LIST=1.  */
+/* current-time-list defaults to t, typically generating (HI LO US PS)
+   timestamps.  To change the default to nil, generating (TICKS . HZ)
+   timestamps, compile with -DCURRENT_TIME_LIST=0.  */
 #ifndef CURRENT_TIME_LIST
-enum { CURRENT_TIME_LIST = false };
+enum { CURRENT_TIME_LIST = true };
 #endif
 
 #if FIXNUM_OVERFLOW_P (1000000000)
@@ -568,7 +568,7 @@ lisp_time_seconds (struct lisp_time t)
 Lisp_Object
 make_lisp_time (struct timespec t)
 {
-  if (CURRENT_TIME_LIST)
+  if (current_time_list)
     {
       time_t s = t.tv_sec;
       int ns = t.tv_nsec;
@@ -1171,13 +1171,13 @@ time_arith (Lisp_Object a, Lisp_Object b, bool subtract)
     }
 
   /* Return an integer if the timestamp resolution is 1,
-     otherwise the (TICKS . HZ) form if !CURRENT_TIME_LIST or if
+     otherwise the (TICKS . HZ) form if !current_time_list or if
      either input used (TICKS . HZ) form or the result can't be expressed
      exactly in (HI LO US PS) form, otherwise the (HI LO US PS) form
      for backward compatibility.  */
   return (EQ (hz, make_fixnum (1))
 	  ? ticks
-	  : (!CURRENT_TIME_LIST
+	  : (!current_time_list
 	     || aform == TIMEFORM_TICKS_HZ
 	     || bform == TIMEFORM_TICKS_HZ
 	     || !trillion_factor (hz))
@@ -1716,7 +1716,7 @@ DEFUN ("encode-time", Fencode_time, Sencode_time, 1, MANY, 0,
     time_error (mktime_errno);
 
   if (EQ (hz, make_fixnum (1)))
-    return (CURRENT_TIME_LIST
+    return (current_time_list
 	    ? list2 (hi_time (value), lo_time (value))
 	    : INT_TO_INTEGER (value));
   else
@@ -1747,7 +1747,7 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0,
   struct lisp_time t;
   enum timeform input_form = decode_lisp_time (time, false, &t, 0);
   if (NILP (form))
-    form = CURRENT_TIME_LIST ? Qlist : Qt;
+    form = current_time_list ? Qlist : Qt;
   if (EQ (form, Qlist))
     return ticks_hz_list4 (t.ticks, t.hz);
   if (EQ (form, Qinteger))
@@ -1762,14 +1762,15 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0,
 
 DEFUN ("current-time", Fcurrent_time, Scurrent_time, 0, 0, 0,
        doc: /* Return the current time, as the number of seconds since 1970-01-01 00:00:00.
-The time is returned as a pair of integers (TICKS . HZ), where TICKS
-counts clock ticks and HZ is the clock ticks per second.
-
-In Emacs 28 and earlier, the returned timestamp had the form (HIGH LOW
-USEC PSEC), where HIGH is the most significant bits of the seconds,
-LOW the least significant 16 bits, and USEC and PSEC are the
-microsecond and picosecond counts.  Use \(time-convert nil \\='list)
-if you need this older timestamp form.  */)
+If the variable `current-time-list' is nil, the time is returned as a
+pair of integers (TICKS . HZ), where TICKS counts clock ticks and HZ
+is the clock ticks per second.  Otherwise, the time is returned as a
+list of integers (HIGH LOW USEC PSEC) where HIGH has the most
+significant bits of the seconds, LOW has the least significant 16
+bits, and USEC and PSEC are the microsecond and picosecond counts.
+
+You can use `time-convert' to get a particular timestamp form
+regardless of the value of `current-time-list'.  */)
   (void)
 {
   return make_lisp_time (current_timespec ());
@@ -2025,6 +2026,19 @@ syms_of_timefns (void)
 
   DEFSYM (Qencode_time, "encode-time");
 
+  DEFVAR_BOOL ("current-time-list", current_time_list,
+	       doc: /* Whether `current-time' should return list or (TICKS . HZ) form.
+
+This boolean variable is a transition aid.  If t, `current-time' and
+related functions return timestamps in list form, typically
+\(HIGH LOW USEC PSEC); otherwise, they use (TICKS . HZ) form.
+Currently this variable defaults to t, for behavior compatible with
+previous Emacs versions.  Developers are encourage to test
+timestamp-related code with this variable set to nil, as it will
+default to nil in a future Emacs version, and will be removed in some
+version after that.  */);
+  current_time_list = CURRENT_TIME_LIST;
+
   defsubr (&Scurrent_time);
 #ifdef CLOCKS_PER_SEC
   defsubr (&Scurrent_cpu_time);
-- 
2.35.1

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Vincenzo Pupillo]

In data giovedì 28 aprile 2022 22:15:54 CEST, Paul Eggert ha scritto:
> On 4/28/22 05:10, Lars Ingebrigtsen wrote:
> > Paul, it seems like this change is just breaking too much code out
> > there, so I think it'll have to be reverted.
> 
> Yes, I came to pretty much the same conclusion. I installed the attached
> patch to revert the effect of the change. Instead, this patch adds a new
> variable current-time-list that lets you try out the new timestamp
> behavior, with the default being the longstanding behavior.
> 
> This was separate from the long thread we had about exposing
> clock_getres results to the user, as it doesn't involve calling
> clock_getres; it's merely about timestamp format.
> 
> Also, I notice that current-cpu-time was recently added; I'll try to
> spring some time free to look into it and will follow up on Bug#44674.

Thanks guys, now it works correctly with this patch.

Ciao

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Vincenzo Pupillo <v.pupillo@gmail.com> writes:

> Thanks guys, now it works correctly with this patch.

Thanks for checking; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Yes, I came to pretty much the same conclusion. I installed the
> attached patch to revert the effect of the change. Instead, this patch
> adds a new variable current-time-list that lets you try out the new
> timestamp behavior, with the default being the longstanding behavior.

Thanks; makes sense to me.  And it was worth a try to modernise these
functions, but it doesn't seem like the world is ready yet (and it's
hard to see a practical way forward without deprecating all the current
time-related functions and creating new ones, which we probably don't
want to do).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thanks; makes sense to me.  And it was worth a try to modernise these
> functions, but it doesn't seem like the world is ready yet (and it's
> hard to see a practical way forward without deprecating all the current
> time-related functions and creating new ones, which we probably don't
> want to do).

Thinking about this slightly more, perhaps it's worth doing?  Because we
currently have some interfaces in this area that could be more efficient
or elegant.

The time functions commonly used are don't have particularly
discoverable names -- current-time and float-time are probably the ones
used most.  Another common source of times are
(file-attribute-modification-time (file-attributes ...)), which is
commonly called in loops, and generates a lot of unnecessary garbage.

So perhaps we could come up with a set of new functions in this area
that are more efficient and avoid using the old time formats.

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).  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...

And so on.  That is, I think this might be an opportunity to overhaul
Emacs in this area -- introduce efficient functions with consistent
naming, and then obsolete the old ones after a while.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 55163@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>,  Vincenzo Pupillo
>  <v.pupillo@gmail.com>
> Date: Fri, 29 Apr 2022 11:54:07 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Thanks; makes sense to me.  And it was worth a try to modernise these
> > functions, but it doesn't seem like the world is ready yet (and it's
> > hard to see a practical way forward without deprecating all the current
> > time-related functions and creating new ones, which we probably don't
> > want to do).
> 
> Thinking about this slightly more, perhaps it's worth doing?  Because we
> currently have some interfaces in this area that could be more efficient
> or elegant.
> 
> The time functions commonly used are don't have particularly
> discoverable names -- current-time and float-time are probably the ones
> used most.  Another common source of times are
> (file-attribute-modification-time (file-attributes ...)), which is
> commonly called in loops, and generates a lot of unnecessary garbage.
> 
> So perhaps we could come up with a set of new functions in this area
> that are more efficient and avoid using the old time formats.
> 
> 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).  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...
> 
> And so on.  That is, I think this might be an opportunity to overhaul
> Emacs in this area -- introduce efficient functions with consistent
> naming, and then obsolete the old ones after a while.

I don't understand how this is related to making the time rfesolution
explicit in time objects.  The main problem in that area wa how we can
know the resolution of each timestamp, not how to expose that to Lisp.

In the particular example you mention, how can Emacs know what is the
resolution of a file's last modification time?

What did I miss?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand how this is related to making the time rfesolution
> explicit in time objects.  The main problem in that area wa how we can
> know the resolution of each timestamp, not how to expose that to Lisp.
>
> In the particular example you mention, how can Emacs know what is the
> resolution of a file's last modification time?
>
> What did I miss?

This isn't related to that at all (except tangentially).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  55163@debbugs.gnu.org,  v.pupillo@gmail.com
> Date: Fri, 29 Apr 2022 12:59:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand how this is related to making the time rfesolution
> > explicit in time objects.  The main problem in that area wa how we can
> > know the resolution of each timestamp, not how to expose that to Lisp.
> >
> > In the particular example you mention, how can Emacs know what is the
> > resolution of a file's last modification time?
> >
> > What did I miss?
> 
> This isn't related to that at all (except tangentially).

Then why again would we want to come up with new functions for
handling timestamps? just because the existing ones have names that
make discovery difficult, or are there other reasons?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/29/22 04:10, Eli Zaretskii wrote:
> Then why again would we want to come up with new functions for
> handling timestamps? just because the existing ones have names that
> make discovery difficult, or are there other reasons?

I think Lars is saying both, though the other reasons are more important.

Lars makes a good point that common idioms like 
(file-attribute-modification-time (file-attributes F)) generate 
unnecessary garbage. And it's more than just GC overhead: at a lower 
level, 'statx' on GNU/Linux can be significantly more efficient than 
plain 'stat' when retrieving just a subset of stat info (such as, just 
the file timestamp).

Getting various flavors of the current time is another issue. This 
related to the polishing that Stefan referred to with the new CPU time 
primitive.

I'll try to shake some time free to think about this more.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Fri, 29 Apr 2022 12:38:19 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/29/22 04:10, Eli Zaretskii wrote:
> > Then why again would we want to come up with new functions for
> > handling timestamps? just because the existing ones have names that
> > make discovery difficult, or are there other reasons?
> 
> I think Lars is saying both, though the other reasons are more important.
> 
> Lars makes a good point that common idioms like 
> (file-attribute-modification-time (file-attributes F)) generate 
> unnecessary garbage. And it's more than just GC overhead: at a lower 
> level, 'statx' on GNU/Linux can be significantly more efficient than 
> plain 'stat' when retrieving just a subset of stat info (such as, just 
> the file timestamp).

This is (almost) unrelated to timestamps.  The same case can be made
about almost every individual file attribute, at least theoretically.

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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/29/22 12:53, Eli Zaretskii wrote:

>> Lars makes a good point that common idioms like 
>> (file-attribute-modification-time (file-attributes F)) generate 
>> unnecessary garbage. And it's more than just GC overhead: at a lower 
>> level, 'statx' on GNU/Linux can be significantly more efficient than 
>> plain 'stat' when retrieving just a subset of stat info (such as, just 
>> the file timestamp).
> 
> This is (almost) unrelated to timestamps.  The same case can be made
> about almost every individual file attribute, at least theoretically.

Yes, we could separate the idea. File timestamps are the worst offenders 
for GC, so they provide much of the motivation for this other idea.


>   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?

Yes, for example lots of Lisp code takes a file timestamp, keeps it 
somewhere, then examines it later to print or to compare to another 
timestamp. See, for example, how ido-file-name-all-completions compares 
ctime (the cached timestamp) to mtime (the file timestamp).

> we already have a primitive for that

Sure, but file-newer-than-file-p is not adequate for many routine 
calculations involving file timestamps. It can't do the sort of caching 
described above, for example. My impression is that 
file-newer-than-file-p suffices for less than half of the sort of 
routine things people need to do with file timestamps.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Fri, 29 Apr 2022 15:45:44 -0700
> Cc: larsi@gnus.org, 55163@debbugs.gnu.org, v.pupillo@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> >   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?
> 
> Yes, for example lots of Lisp code takes a file timestamp, keeps it 
> somewhere, then examines it later to print or to compare to another 
> timestamp. See, for example, how ido-file-name-all-completions compares 
> ctime (the cached timestamp) to mtime (the file timestamp).

Such code cannot take advantage of this particular proposal, it will
have to be rewritten to be able to do that.  When it _is_ rewritten,
it can easily use the existing primitive, perhaps after we extend it
(see below).

> > we already have a primitive for that
> 
> Sure, but file-newer-than-file-p is not adequate for many routine 
> calculations involving file timestamps. It can't do the sort of caching 
> described above, for example.

We can easily extend it to be able to receive a time object instead of
one of the file names.  (Or maybe I don't understand what kind of
"caching" you have in mind.)

But since we were talking about something more general, what are the
use cases for the other file attributes that would be much better
served by having separate primitives for those attributes?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  55163@debbugs.gnu.org,
>   v.pupillo@gmail.com
> Date: Sat, 30 Apr 2022 11:10:18 +0200
> 
> Eli Zaretskii <eliz@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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/30/22 03:00, Eli Zaretskii wrote:

> That might mean we want a primitive that returns a list of files
> sorted by modtime

Such a primitive would not be as useful. First, it's common for Emacs to 
look at files opportunistically: that is, Emacs doesn't know in advance 
all the files it will eventually look at, and so it can't give a 
primitive a list of files in advance. Second, it's common for Emacs to 
compare the timestamp of a file at time T1 with the timestamp of another 
(or the same) file at a later time T2. A primitive that accepts a list 
of files can't do that.

In contrast, a primitive that simply gives you a file's timestamp 
handles these use cases, and is considerably easier to describe and support.

> we
> will risk adding gobs of new APIs that rarely if ever used in
> practice

Yes, we don't want to do that. However the case for making improvements 
here is strong enough here that it's worth doing.

There are dozens of potential uses for the proposed (file-attributes 
FILE 'mtime) etc. improvement in Emacs right now, so it's an easy call 
that this API will get used.

There are also cases where the code now uses current-time and assumes 
that the resulting timestamps are issued in numeric order, an assumption 
that is not always true in practice. It'd be better for this code to use 
a monotonic clock instead. Admittedly the resulting misbehavior is rare 
(because it's rare that people adjust their machines' clocks), but Emacs 
shouldn't glitch out on me merely because I've corrected my laptop's 
time-of-day.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Sat, 30 Apr 2022 13:51:24 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com,
>  Lars Ingebrigtsen <larsi@gnus.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/30/22 03:00, Eli Zaretskii wrote:
> 
> > That might mean we want a primitive that returns a list of files
> > sorted by modtime
> 
> Such a primitive would not be as useful. First, it's common for Emacs to 
> look at files opportunistically: that is, Emacs doesn't know in advance 
> all the files it will eventually look at, and so it can't give a 
> primitive a list of files in advance.

In those cases, a Lisp program usually doesn't know whether it will
sort files by time or by some other attribute, so we generally need
the list of files with all their attributes anyway.

> Second, it's common for Emacs to compare the timestamp of a file at
> time T1 with the timestamp of another (or the same) file at a later
> time T2. A primitive that accepts a list of files can't do that.

Please show at least 3 examples of such "common" situations.  I think
it is rather UN-common.

> In contrast, a primitive that simply gives you a file's timestamp 
> handles these use cases, and is considerably easier to describe and support.

Really? what's the problem to describe and support a primitive that
returns a sorted list of files?

> > we
> > will risk adding gobs of new APIs that rarely if ever used in
> > practice
> 
> Yes, we don't want to do that. However the case for making improvements 
> here is strong enough here that it's worth doing.

That's your opinion, not mine.  I will object to introducing such
"simple" primitives as long as the use cases for them aren't common
enough, or are better served by dedicated primitives that address
the specific use cases we care about.

People who want a general-purpose Lisp environment for writing
system-level applications should use Guile, not Emacs Lisp.

> There are dozens of potential uses for the proposed (file-attributes 
> FILE 'mtime) etc. improvement in Emacs right now, so it's an easy call 
> that this API will get used.

I challenge you to present even half a dozen of such uses.

> There are also cases where the code now uses current-time and assumes 
> that the resulting timestamps are issued in numeric order, an assumption 
> that is not always true in practice. It'd be better for this code to use 
> a monotonic clock instead. Admittedly the resulting misbehavior is rare 
> (because it's rare that people adjust their machines' clocks), but Emacs 
> shouldn't glitch out on me merely because I've corrected my laptop's 
> time-of-day.

That's a separate issue, and again: please present the use cases for
that which are relevant to Emacs applications.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/30/22 22:38, Eli Zaretskii wrote:
>> it's common for Emacs to compare the timestamp of a file at
>> time T1 with the timestamp of another (or the same) file at a later
>> time T2.

> Please show at least 3 examples of such "common" situations.  I think
> it is rather UN-common.

auth-source-netrc-parse, semanticdb-synchronize, and dir-locals-find-file.


> what's the problem to describe and support a primitive that
> returns a sorted list of files?

What happens with ties in the timestamps - do we sort stably? What 
happens with files named but not present? What if we want to sort by 
ctime instead of by mtime? What if the user is involved in selecting 
files as we go? How do we specify the files: a list of strings, a 
pattern, or something else? What if we want to look at a tree of files? Etc.

Of course one could come up with answers to those questions, but this 
sort of thing is much better handled in Lisp code than as a C-language 
primitive.


> I challenge you to present even half a dozen of such uses.

I listed three examples above. Here are three more, which makes six: 
multisession-backend-value, eshell-read-passwd, 
nneething-create-mapping. More examples can easily be supplied.


>> There are also cases where the code now uses current-time and assumes
>> that the resulting timestamps are issued in numeric order, an assumption
>> that is not always true in practice.
> 
> That's a separate issue, and again: please present the use cases for
> that which are relevant to Emacs applications.

erc-server-send-ping, progress-reporter-do-update, timer-event-handler. 
I'm sure there are others.


Your point is well taken that if we made changes along the lines being 
discussed, we shouldn't merely add the new primitives: we should *use* 
them. And if we can't find significant use for them then we shouldn't 
add them.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Sun, 1 May 2022 08:00:05 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/30/22 22:38, Eli Zaretskii wrote:
> >> it's common for Emacs to compare the timestamp of a file at
> >> time T1 with the timestamp of another (or the same) file at a later
> >> time T2.
> 
> > Please show at least 3 examples of such "common" situations.  I think
> > it is rather UN-common.
> 
> auth-source-netrc-parse, semanticdb-synchronize, and dir-locals-find-file.

Out of these, only the 3rd one could qualify, because it's the only
one where performance counts.

> > what's the problem to describe and support a primitive that
> > returns a sorted list of files?
> 
> What happens with ties in the timestamps - do we sort stably? What 
> happens with files named but not present? What if we want to sort by 
> ctime instead of by mtime? What if the user is involved in selecting 
> files as we go? How do we specify the files: a list of strings, a 
> pattern, or something else? What if we want to look at a tree of files? Etc.

I see no problems there that are worth talking about.

> Of course one could come up with answers to those questions, but this 
> sort of thing is much better handled in Lisp code than as a C-language 
> primitive.

And then those issues will have to be handled by Lisp application
programmers? who in many cases will not even know these issues exist?
Is that really a good trade-off?

> > I challenge you to present even half a dozen of such uses.
> 
> I listed three examples above. Here are three more, which makes six: 
> multisession-backend-value, eshell-read-passwd, 
> nneething-create-mapping. More examples can easily be supplied.

Only performance-critical examples count.  Any function that involves
user interaction by definition isn't.

> >> There are also cases where the code now uses current-time and assumes
> >> that the resulting timestamps are issued in numeric order, an assumption
> >> that is not always true in practice.
> > 
> > That's a separate issue, and again: please present the use cases for
> > that which are relevant to Emacs applications.
> 
> erc-server-send-ping, progress-reporter-do-update, timer-event-handler. 
> I'm sure there are others.

We don't need wallclock time for those, only elapsed time since some
instant, right?  When elapsed time is used, the monotonicity issue
never arises.

> Your point is well taken that if we made changes along the lines being 
> discussed, we shouldn't merely add the new primitives: we should *use* 
> them. And if we can't find significant use for them then we shouldn't 
> add them.

Yes, that's my point.  So we should look at this from the POV of what
will be used, not what can be provided.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 5/1/22 08:42, Eli Zaretskii wrote:

> Out of these, only the 3rd one could qualify, because it's the only
> one where performance counts.

I'm sure other places can be found like that. And even one such 
occurrence can be enough motivation.


> And then those issues will have to be handled by Lisp application
> programmers?

No, not at all. We could write the code in Elisp and put it into 
files.el or wherever. The point is that this sort of thing need not and 
should not be written in C.


>> erc-server-send-ping, progress-reporter-do-update, timer-event-handler.
>> I'm sure there are others.
> 
> We don't need wallclock time for those, only elapsed time since some
> instant, right?  When elapsed time is used, the monotonicity issue
> never arises.

I'm not sure what is meant by the distinction between a monotonic clock 
and an elapsed-time clock. Either way, current-time does not suffice.

GNU/Linux has many types of monotonic clocks. We don't need to expose 
them all to the user. But Emacs apps do need at least one such clock, 
and POSIX's CLOCK_MONOTONIC is a portable way to get one.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Sun, 1 May 2022 09:17:09 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 5/1/22 08:42, Eli Zaretskii wrote:
> 
> > Out of these, only the 3rd one could qualify, because it's the only
> > one where performance counts.
> 
> I'm sure other places can be found like that. And even one such 
> occurrence can be enough motivation.

No, one such occurrence won't be enough, not in my book.

> > And then those issues will have to be handled by Lisp application
> > programmers?
> 
> No, not at all. We could write the code in Elisp and put it into 
> files.el or wherever. The point is that this sort of thing need not and 
> should not be written in C.

What's the difference, for the purpose of this discussion, between
having the code in C and having it in internal Lisp functions?  The
important conclusion is the same: no need for public APIs that expose
individual attributes.

> >> erc-server-send-ping, progress-reporter-do-update, timer-event-handler.
> >> I'm sure there are others.
> > 
> > We don't need wallclock time for those, only elapsed time since some
> > instant, right?  When elapsed time is used, the monotonicity issue
> > never arises.
> 
> I'm not sure what is meant by the distinction between a monotonic clock 
> and an elapsed-time clock. Either way, current-time does not suffice.

The distinction is that the resolution of the wallclock time doesn't
matter.

> GNU/Linux has many types of monotonic clocks. We don't need to expose 
> them all to the user. But Emacs apps do need at least one such clock, 
> and POSIX's CLOCK_MONOTONIC is a portable way to get one.

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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 5/1/22 09:43, Eli Zaretskii wrote:

> one such occurrence won't be enough, not in my book.

If one such occurrence makes Emacs significantly slower for a 
common-enough use, it can be important enough to improve Emacs. And as I 
wrote, I'm sure there are more occurrences.


> 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.


> 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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Mon, 2 May 2022 10:27:14 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org
> From: Paul Eggert <eggert@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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 5/2/22 10:58, Eli Zaretskii wrote:
>> 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

If the concern is the public nature of the API then yes, we could 
provide a private function file--attributes that would act like 
file-attributes but be able to obtain individual 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.

Sorry, I'm still lost. What methods would these be? Are they methods 
that one can already use in portable Elisp code?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Mon, 2 May 2022 16:17:38 -0700
> Cc: 55163@debbugs.gnu.org, v.pupillo@gmail.com, larsi@gnus.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> >>> 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.
> 
> Sorry, I'm still lost. What methods would these be?

For example, measuring time intervals by looking at CPU counters.

> Are they methods that one can already use in portable Elisp code?

No, because we were talking about APIs that are not yet available in
Emacs.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 5/2/22 19:32, Eli Zaretskii wrote:
> For example, measuring time intervals by looking at CPU counters.

That might be a way to do its, though it sounds a bit complicated since 
these days CPUs often don't run at a constant rate. And not every system 
lets you look at its CPU counters.

I suppose Emacs could use CLOCK_MONOTONIC on systems that have it, and 
fall back on CPU counters on systems that don't.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Fri, 29 Apr 2022 18:44:54 -0700
> Cc: 55163@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
>  Vincenzo Pupillo <v.pupillo@gmail.com>,
>  Stefan Monnier <monnier@IRO.UMontreal.CA>
> From: Paul Eggert <eggert@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.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Vincenzo Pupillo]

In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> 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.

Many packages on melpa/elpa have a custom log function. I'm not familiar with 
the Emacs API, is there a standard way to log events? 
I think a simple log function would be useful for many packages.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Vincenzo Pupillo <v.pupillo@gmail.com>
> Cc: larsi@gnus.org, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sat, 30 Apr 2022 13:21:04 +0200
> 
> In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> > 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.
> 
> Many packages on melpa/elpa have a custom log function. I'm not familiar with 
> the Emacs API, is there a standard way to log events? 
> I think a simple log function would be useful for many packages.

Do you mean logging to the system log?

If not, then generating a log doesn't require any new primitives, I
think, you could just use write-region or something?

Or am I misunderstanding the feature you have in mind?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Vincenzo Pupillo]

In data sabato 30 aprile 2022 13:25:31 CEST, Eli Zaretskii ha scritto:
> > From: Vincenzo Pupillo <v.pupillo@gmail.com>
> > Cc: larsi@gnus.org, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca
> > Date: Sat, 30 Apr 2022 13:21:04 +0200
> > 
> > In data sabato 30 aprile 2022 07:40:32 CEST, Eli Zaretskii ha scritto:
> > > 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.
> > 
> > Many packages on melpa/elpa have a custom log function. I'm not familiar
> > with the Emacs API, is there a standard way to log events?
> > I think a simple log function would be useful for many packages.
> 
> Do you mean logging to the system log?
> 
> If not, then generating a log doesn't require any new primitives, I
> think, you could just use write-region or something?
> 
> Or am I misunderstanding the feature you have in mind?

I mean something that can generate a properly formatted log message, in a 
"standard" way (with log levels, ERROR, WARNING, INFO etc, if possible), for 
both use cases if possible. Something like log4j, but not as monstrous as 
log4j.

Just three examples of different way to generate logging message:  
1. jsonrpc has a function, jsonrpc--log-event, that generates a message 
                          (msg (format "[%s]%s%s %s:\n%s"
                                   type
                                   (if id (format " (id:%s)" id) "")
                                   (if error " ERROR" "")
                                   (current-time-string)
                                   (pp-to-string message))))
2. treemacs (see treemacs-logging.el: one function and six macro)
3. the package log4e (on melpa)

The message format of these three packets is different.
Something more "standardized" may be useful, I think.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> From: Vincenzo Pupillo <v.pupillo@gmail.com>
> Cc: eggert@cs.ucla.edu, larsi@gnus.org, 55163@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sat, 30 Apr 2022 14:32:17 +0200
> 
> > > Many packages on melpa/elpa have a custom log function. I'm not familiar
> > > with the Emacs API, is there a standard way to log events?
> > > I think a simple log function would be useful for many packages.
> > 
> > Do you mean logging to the system log?
> > 
> > If not, then generating a log doesn't require any new primitives, I
> > think, you could just use write-region or something?
> > 
> > Or am I misunderstanding the feature you have in mind?
> 
> I mean something that can generate a properly formatted log message, in a 
> "standard" way (with log levels, ERROR, WARNING, INFO etc, if possible), for 
> both use cases if possible. Something like log4j, but not as monstrous as 
> log4j.

Sure, why not?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Vincenzo Pupillo]

In data sabato 30 aprile 2022 14:50:04 CEST, Eli Zaretskii ha scritto:
> > From: Vincenzo Pupillo <v.pupillo@gmail.com>
> > Cc: eggert@cs.ucla.edu, larsi@gnus.org, 55163@debbugs.gnu.org,
> > monnier@iro.umontreal.ca Date: Sat, 30 Apr 2022 14:32:17 +0200
> > 
> > > > Many packages on melpa/elpa have a custom log function. I'm not
> > > > familiar
> > > > with the Emacs API, is there a standard way to log events?
> > > > I think a simple log function would be useful for many packages.
> > > 
> > > Do you mean logging to the system log?
> > > 
> > > If not, then generating a log doesn't require any new primitives, I
> > > think, you could just use write-region or something?
> > > 
> > > Or am I misunderstanding the feature you have in mind?
> > 
> > I mean something that can generate a properly formatted log message, in a
> > "standard" way (with log levels, ERROR, WARNING, INFO etc, if possible),
> > for both use cases if possible. Something like log4j, but not as
> > monstrous as log4j.
> 
> Sure, why not?
Because log4j does too many things, and I think it's too much for emacs. I 
think something simpler is enough.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> 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.

Yes, `time' as a function name does sound a bit...  dramatic.  On the
other hand, it looks kinda nice in things like (time-less-p thing (time)),
etc.

> 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- as a prefix does make a lot of sense, but I think I'd interpret
that as "realtime" as something having to do with scheduling, and
"clock" perhaps as a localised time (i.e., "the wall clock in time zone
foo").

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/30/22 02:15, Lars Ingebrigtsen wrote:
>> * (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- as a prefix does make a lot of sense, but I think I'd interpret
> that as "realtime" as something having to do with scheduling

Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
Perhaps we should use "universal" instead, since it's Universal Time.

Another thought is that instead of a new Lisp function, we could extend 
current-time. E.g., (current-time 'universal) would return the current 
time in seconds since the EPOCH, (current-time 'process-cpu) the 
process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
Although this wouldn't let us reorganize the time API in a major way, it 
would let us add the needed functionality in a way that follows existing 
practice pretty closely, and there's benefit to that.

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Eli Zaretskii]

> Date: Sat, 30 Apr 2022 14:03:55 -0700
> Cc: 55163@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
>  Vincenzo Pupillo <v.pupillo@gmail.com>,
>  Stefan Monnier <monnier@IRO.UMontreal.CA>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 4/30/22 02:15, Lars Ingebrigtsen wrote:
> >> * (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- as a prefix does make a lot of sense, but I think I'd interpret
> > that as "realtime" as something having to do with scheduling
> 
> Yes, "realtime" is an unfortunate phrase here, even if it's POSIX. 
> Perhaps we should use "universal" instead, since it's Universal Time.

Using "universal" will IMO make the discovery even more difficult,
because no one will think of looking up time functions under
"universal".

> Another thought is that instead of a new Lisp function, we could extend 
> current-time. E.g., (current-time 'universal) would return the current 
> time in seconds since the EPOCH, (current-time 'process-cpu) the 
> process's CPU time, (current-time 'monotonic) a monotonic clock, etc. 
> Although this wouldn't let us reorganize the time API in a major way, it 
> would let us add the needed functionality in a way that follows existing 
> practice pretty closely, and there's benefit to that.

That could be a good idea, but thinking about names, I still don't
understand why we don't want to use "time-" as the prefix of these
APIs.  What did I miss?

bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode

[Paul Eggert]

On 4/30/22 22:40, Eli Zaretskii wrote:

> Using "universal" will IMO make the discovery even more difficult,
> because no one will think of looking up time functions under
> "universal".

Yes, it shouldn't be "universal" by itself. It should be (time-now 
'universal) or something like that, where the context is clear.

I did consider "UTC"; unfortunately something like (time-now 'UTC) would 
imply that the timestamps include leap seconds, which they typically 
don't. "Universal" is a more-general term that includes both UTC and 
POSIX time (the latter omits leap seconds).

..
> I still don't
> understand why we don't want to use "time-" as the prefix of these
> APIs.

Sure, we can stick with "time-" for new functions.