bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode
Date: Sun, 01 May 2022 18:42:04 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]