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#73709: 29.4; Doc of `file-newer-than-file-p' Date: Thu, 10 Oct 2024 11:26:19 +0300 Message-ID: <86zfnc1hzo.fsf@gnu.org> References: <86h69msbhi.fsf@gnu.org> <87set6aytj.fsf@web.de> <864j5l4d2x.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29589"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 73709@debbugs.gnu.org, drew.adams@oracle.com To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 10 10:27:17 2024 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 1syoVw-0007Rs-CJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Oct 2024 10:27:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syoVa-0004hG-Fs; Thu, 10 Oct 2024 04:26:54 -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 1syoVX-0004h4-3S for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 04:26:51 -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 1syoVW-0005vj-Rp for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 04:26:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=awstq9QR3hr9ZyAiUXyTTjJT3d/ItZbhHWeoioitJ3k=; b=rtB2ZgO87So5fY0oDWIS5ZwOIWlVo/1K2+kpJQ8QvUBIm3VhEN/yUXTKHPv0v+T/gTXCrw4aoZ+y6/H5pBtt9/C/JsUIlQyI0eKBM7thK9570hQRmdw8MQTx0towbu7IyXxOH8Ex3lF3zRlxkbpN5aMInKpUZ3z6LIJA4EMwrWkqihf/yRj0wN6KJKbYl6Ra9m1+q/JHHfhFdjplv1gedvsmRWt9LdwG27eE6cjLfkjF6aOHjSKMqIv5sEzsTZkPFmbxlMtgvzeDIENsSZJDOTwwWxF9tONfKGHDCsUeHAao4b3UQCSd/IC/SXgaPsfg/BGYkIKlkU+EAaGUNxQ8Rw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1syoVh-0002ma-KR for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 04:27: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, 10 Oct 2024 08:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73709 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug wontfix Original-Received: via spool by 73709-submit@debbugs.gnu.org id=B73709.172854880110667 (code B ref 73709); Thu, 10 Oct 2024 08:27:01 +0000 Original-Received: (at 73709) by debbugs.gnu.org; 10 Oct 2024 08:26:41 +0000 Original-Received: from localhost ([127.0.0.1]:58616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syoVN-0002lz-1p for submit@debbugs.gnu.org; Thu, 10 Oct 2024 04:26:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syoVK-0002lk-2J for 73709@debbugs.gnu.org; Thu, 10 Oct 2024 04:26:40 -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 1syoV3-0005tu-3P; Thu, 10 Oct 2024 04:26:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=awstq9QR3hr9ZyAiUXyTTjJT3d/ItZbhHWeoioitJ3k=; b=F8p9VqFSlbdT HhRueXjhyI7Zpv0KNMnoxeNTrGJ7H29vIfq8u1wSDlmCe7/iP5krk9oQz662bnwu7AWzBo498tkxi HGnqGm+9r3rZaTWtxs7TdHeS9f+IHfKJgDw5jsHV54O+6/Bu2jm/h9uyufdHqry/D4FforOhGktRr jHHtOujLjZuSiXOr8qR7xAMAln3POJ04Tv6rBHhrNvR8PbvHV1IrWbqGMHO+O2vxrwqF5Tcl+PU7D 2+jr53rU++uFjEDV3als91nAx0oSD9vwmEQxdPxt1iVNbJavuPspMRa6s2ELRVfV3AxkeznK8TY8U mjrqeur36lSHadvSo3kPTw==; In-Reply-To: (message from Stefan Kangas on Wed, 9 Oct 2024 23:42:30 +0000) 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:293259 Archived-At: > From: Stefan Kangas > Date: Wed, 9 Oct 2024 23:42:30 +0000 > Cc: 73709@debbugs.gnu.org, drew.adams@oracle.com > > Eli Zaretskii writes: > > > Are you sure this is a good idea? If the user who reads the doc > > string doesn't know the meaning of "the file is newer", how can we be > > sure she knows the meaning of "file's last modification time"? > > On GNU/Linux (actually POSIX) systems, we have atime/ctime/mtime. Actually, modern Posix filesystems have much more than that. > The word "newer" does not make it clear if we mean ctime or mtime. Why does it matter? Emacs Lisp programs should not care about these details. Emacs offers APIs that are not direct channels to calling a Posix system call. Emacs offers additional abstractions that are supposed to protect the caller Lisp programs from too much low-level and system-dependent stuff. Seeping system-dependent details into our documentation goes in the opposite direction. If people want Lisp bindings of system calls, they should use Guile, not Emacs. > The phrasing "last modification time" makes it clear that we're talking > about mtime. This phrase is already used further down in (info "(elisp) > File Attributes"), and should be equally good here. I think you are mistaken, but let's let time judge who is right. > > is "last modification"? does changing the file's mode bits constitute > > "modification"? does renaming the file or moving it to another > > directory constitute "modification"? what is the meaning of "last > > modification time" of a directory? etc. etc. -- do we have now to > > explain all of that in our documentation? > > I don't see a need for the Elisp manual to explain these details. Neither do I, but for different reasons. > Users that need to know such things in detail will have to refer to > other platform-relevant documentation, such as the POSIX standard: > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html#tag_04_12 How do we expect someone to write portable Lisp programs based on that technobabble? If the call to file-newer-than-file-p does not live up to its contract in some situation or doesn't fit people's expectations that are based on the documentation, I expect people to submit bug reports about their expectations not being met, and demand us to fix the implementation. Suppose that on some filesystem FILE1 was created after FILE2, but file-newer-than-file-p does NOT return t for FILE1. With the previous doc string people could tell us the function was broken in that case, whereas with the current "fixed" doc string we could tell them that since the mtime told us FILE1 was not newer, we are okay, and this is not a bug. Does this sound reasonable for Emacs? I think not. IOW, the addition I just made per your request breaks the (useful, IMO) abstraction we had. For what good reasons?