unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: larsi@gnus.org, v.pupillo@gmail.com, 55163@debbugs.gnu.org
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	[thread overview]
Message-ID: <83pmkx5kfn.fsf@gnu.org> (raw)
In-Reply-To: <3bcf4527-426a-b3ae-317a-a9a0e521fc6a@cs.ucla.edu> (message from Paul Eggert on Sun, 1 May 2022 08:00:05 -0700)

> 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	other threads:[~2022-05-01 15:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 10:53 bug#55163: 29.0.50; master 4a1f69ebca (TICKS . HZ) for current-time broke lsp-mode Vincenzo Pupillo
2022-04-28 12:10 ` Lars Ingebrigtsen
2022-04-28 13:38   ` Eli Zaretskii
2022-04-28 20:15   ` Paul Eggert
2022-04-28 20:42     ` Vincenzo Pupillo
2022-04-28 21:55       ` Lars Ingebrigtsen
2022-04-28 21:51     ` Lars Ingebrigtsen
2022-04-29  9:54       ` Lars Ingebrigtsen
2022-04-29 10:54         ` Eli Zaretskii
2022-04-29 10:59           ` Lars Ingebrigtsen
2022-04-29 11:10             ` Eli Zaretskii
2022-04-29 19:38               ` Paul Eggert
2022-04-29 19:53                 ` Eli Zaretskii
2022-04-29 22:45                   ` Paul Eggert
2022-04-30  5:29                     ` Eli Zaretskii
2022-04-30  9:10                   ` Lars Ingebrigtsen
2022-04-30 10:00                     ` Eli Zaretskii
2022-04-30 20:51                       ` Paul Eggert
2022-05-01  5:38                         ` Eli Zaretskii
2022-05-01 15:00                           ` Paul Eggert
2022-05-01 15:42                             ` Eli Zaretskii [this message]
2022-05-01 16:17                               ` Paul Eggert
2022-05-01 16:43                                 ` Eli Zaretskii
2022-05-02 17:27                                   ` Paul Eggert
2022-05-02 17:58                                     ` Eli Zaretskii
2022-05-02 23:17                                       ` Paul Eggert
2022-05-03  2:32                                         ` Eli Zaretskii
2022-05-03  2:52                                           ` Paul Eggert
2022-04-30  1:44         ` Paul Eggert
2022-04-30  5:40           ` Eli Zaretskii
2022-04-30 11:21             ` Vincenzo Pupillo
2022-04-30 11:25               ` Eli Zaretskii
2022-04-30 12:32                 ` Vincenzo Pupillo
2022-04-30 12:50                   ` Eli Zaretskii
2022-04-30 13:22                     ` Vincenzo Pupillo
2022-04-30  9:15           ` Lars Ingebrigtsen
2022-04-30 21:03             ` Paul Eggert
2022-05-01  5:40               ` Eli Zaretskii
2022-05-01 15:08                 ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pmkx5kfn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=55163@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=larsi@gnus.org \
    --cc=v.pupillo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).