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#65251: 30.0.50; Duration in compilation buffer Date: Thu, 17 Aug 2023 08:33:19 +0300 Message-ID: <83h6oy6xnk.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14200"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattias.engdegard@gmail.com, 65251@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 17 07:34:23 2023 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 1qWVeI-0003UK-8S for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Aug 2023 07:34:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qWVe0-0002LB-3O; Thu, 17 Aug 2023 01:34:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWVdy-0002Kk-D9 for bug-gnu-emacs@gnu.org; Thu, 17 Aug 2023 01:34:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qWVdy-0006G7-53 for bug-gnu-emacs@gnu.org; Thu, 17 Aug 2023 01:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qWVdx-0002Hb-Vc for bug-gnu-emacs@gnu.org; Thu, 17 Aug 2023 01:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Aug 2023 05:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65251 X-GNU-PR-Package: emacs Original-Received: via spool by 65251-submit@debbugs.gnu.org id=B65251.16922504018714 (code B ref 65251); Thu, 17 Aug 2023 05:34:01 +0000 Original-Received: (at 65251) by debbugs.gnu.org; 17 Aug 2023 05:33:21 +0000 Original-Received: from localhost ([127.0.0.1]:42557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWVdJ-0002GU-5a for submit@debbugs.gnu.org; Thu, 17 Aug 2023 01:33:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWVdH-0002GF-1N for 65251@debbugs.gnu.org; Thu, 17 Aug 2023 01:33:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWVdB-0005R3-LN; Thu, 17 Aug 2023 01:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=AUKy5Wn5gmtpQdySvCq2XD8RVuAC1x5EBa7Fr0WGo3c=; b=YwkEWv9NMvxycU6Y3z0h F5QCSzETiuytiFqdHhIakSI3U2keJPpej9s64Csw8ANHIKAPmhsYDam5f1h8/YC2M3rCPGjo473nI 5+Oe8vMl0n+hhgn8B/2OF9fYe177K1YNihcaP61lHTRuaY9Wz8ypv+deNcyt6vPQCNogy+ovrVBw/ acW+LFMKBNPDVMmNB0/pDj30w76avQiayLsXrk9OZTEdSdTYomlwdjQzx0Sz4nzBIn252javiTdtY MapiaRQxmphXNmjCd7aITNz77a7CQbZHd1wI0I0UHhpVdnUoLNIoo7ISOIco3fQU7lD93SYFmgEPH mvXW7Ph6fpzGow==; In-Reply-To: (message from Helmut Eller on Thu, 17 Aug 2023 00:36:52 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267630 Archived-At: > Cc: 65251@debbugs.gnu.org > From: Helmut Eller > Date: Thu, 17 Aug 2023 00:36:52 +0200 > > On Wed, Aug 16 2023, Mattias Engdegård wrote: > > >> +;; The time when the compilation started. > >> +(defvar compilation--start-time nil) > > > > What about using defvar-local? Then... > > > >> + (setq-local compilation--start-time (current-time)) > > > > can use plain setq. > > Seems to be a matter of taste. I don't know what the Official Style > Guide says about it. > > > And if you use (float-time) here, then... > > > >> + (let* ((secs (float-time (time-since compilation--start-time)))) > > > > ...this becomes a simple subtraction: (- (float-time) compilation--start-time) > > > > But then we couldn't use bignums. And representing time values as a > pair of bignums is cool. So cool that it was worth to require libgmp > for Emacs. Oh wait, current-time still doesn't use bignums. But when > it switches, it will be sooo cool. > > Anyway, ERT uses current-time for ert--stats-start-time and I followed > that example. > > >> + (cond ((< secs 1) (format "%.0fms" (* secs 1000))) > >> + ((< secs 10) (format "%.2fs" secs)) > >> + ((< secs 60) (format "%.1fs" secs)) > >> + (t (format-seconds "%hh%mm%z%ss" secs))))) > > > > First of all, proper style is to separate the number and unit by a space. > > The 'ms' case isn't very important -- 745 ms is no more readable than > > 0.745 s, probably less so. > > The last case is also less than readable. Something like 3:45:58 would > > be better. > > Seems to be a matter of taste. I copied the style used by Go's Duration > type: https://pkg.go.dev/time#Duration.String > > > The reader would also like to know what this new time indication > > means. What about > > > > ..., duration 34.5 s > > > > or > > > > ..., 34.5 s elapsed > > > > ? > > Seems to be a matter of taste. ERT prints it like > > Ran 10 tests, 10 results as expected, 0 unexpected (2023-08-17 00:29:48+0200, 0.813428 sec) > > and nobody seems to complain. It sounds like you reject all of Mattias's comments? That's somewhat unusual around here. Does that above mean that you insist on submitting your original patch with no further changes, or will you be sending an updated patch?