GNU bug report logs - #32902
Add support for (TIMESTAMP . RESOLUTION) Lisp timestamps

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Tue, 2 Oct 2018 01:02:02 UTC

Severity: wishlist

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #16 received at 32902 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 32902 <at> debbugs.gnu.org
Subject: Re: bug#32902: Add support for (TIMESTAMP . RESOLUTION) Lisp
 timestamps
Date: Thu, 04 Oct 2018 19:08:27 +0300
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 32902 <at> debbugs.gnu.org
> Date: Wed, 3 Oct 2018 11:45:12 -0700
> 
> > Doc strings only send to
> > the manuals for additional details and explanations, not for the basic
> > facts such as these.
> 
> The attached proposed additional patch fixes this by referring to 
> format-time-string, and by adding the description of time values to 
> format-time-string's doc string. (This is better than the old practice 
> of referring to current-time-string, which does not deal with subsecond 
> info.) It also fixes some minor doc nits I noticed in additional reading.
> 
> > This makes an impression the function doesn't support more than 2
> > arguments, which is incorrect.  Can we provide a more accurate 'usage' form?
> 
> Yes, and I gave that a shot in the attached patch.
> 
> > I think it would be good to add tests for the functions being
> > modified, otherwise we might be breaking something without paying
> > attention.
> 
> Good point, and done in the attached.

Thanks.

> > Is it feasible to leave the time-related code in editfns.c?
> 
> It's feasible, and I could prepare a patch along those lines. However, 
> the time code has has nothing to do with edit functions and is growing 
> significantly: the proposed src/systime.c is 56 KiB, which is above the 
> median size for src/*.c files. Also, this patch changes the time code so 
> much that moving it to a new file won't be that much more of a forensics 
> annoyance than leaving it in editfns.c. To my mind the clarity in having 
> the time code in its own module outweighs the forensics annoyance.

OK, but can we call the new file something like timefns.c?  systime.c
sounds wrong to me (these isn't system-dependent stuff).




This bug report was last modified 6 years and 231 days ago.

Previous Next


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