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: Sun, 13 Oct 2024 21:30:31 +0300 Message-ID: <868qurua7s.fsf@gnu.org> References: <86h69msbhi.fsf@gnu.org> <87set6aytj.fsf@web.de> <864j5l4d2x.fsf@gnu.org> <87v7y0kgl7.fsf@web.de> <861q0o2xbe.fsf@gnu.org> <87cyk7trma.fsf@web.de> <86y12vyygh.fsf@gnu.org> <87jzee88m9.fsf@web.de> <86ttdhyarp.fsf@gnu.org> <87jzed6iql.fsf@web.de> <867cacvb3k.fsf@gnu.org> <86h69gt3xt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="344"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 73709@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 13 21:26:00 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 1t04E4-000AQj-I5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Oct 2024 21:26:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t04Ds-00041x-Vb; Sun, 13 Oct 2024 15:25:49 -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 1t04Dq-00041C-8M for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2024 15:25:46 -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 1t04Dp-0000hY-Vu for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2024 15:25:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=SJsa+2ailkyl2Gef9+QCcrz7fZepeMvORhrJZoCIjUw=; b=q2k1wqgGVbRQSVjtobG8XdzNPnGfYdhvHTKn7g14DJLHIhm+4gEsvbNam9LFZpHXgCaMru1Miar4u25XHSpU/+JOnLyKfQHSMHWKrfTESLAtoG53To0rL3fizIw2XG2li0Bzvrwt51hQ7VEbzqbVe5IBk/Ap0mMjY7kXXeogvh1fF3k/kmie+s72kRK1PpJ9CanL4Sv32WB4wTaLYjz4lomo1dVVYXLqj2SRHZnpPrMpX7ltSTHV8SOm7bFjM+CODfszNl4kSFI1Je7gcOp4fmOb4uOF4cl5KaZi/5g3onH8MIogNHWUWmLZ+jBIRWixx1Qhyp+rKA70mpEYfMCi6Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t04E5-00072g-Ny for bug-gnu-emacs@gnu.org; Sun, 13 Oct 2024 15:26: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: Sun, 13 Oct 2024 19:26: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.172884751326460 (code B ref 73709); Sun, 13 Oct 2024 19:26:01 +0000 Original-Received: (at 73709) by debbugs.gnu.org; 13 Oct 2024 19:25:13 +0000 Original-Received: from localhost ([127.0.0.1]:56081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t04DJ-0006sg-80 for submit@debbugs.gnu.org; Sun, 13 Oct 2024 15:25:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t03Ox-0003al-5w for 73709@debbugs.gnu.org; Sun, 13 Oct 2024 14:33:12 -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 1t03MV-0000eB-8q; Sun, 13 Oct 2024 14:30:39 -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=SJsa+2ailkyl2Gef9+QCcrz7fZepeMvORhrJZoCIjUw=; b=qDC0obgDH3QR4TV5YTTI EAIL4Rm0BlxduAAJVqs4X+KJnDJwBePDYvF72vjtzgn4NYrx0p4rcIyObGTUAyQZLSQDdizX8qp14 rLVcZ+fwXYnEZNVPg6Zmsmo27NfAJgHki/gZHt0JrUkR27fjO+Fe4yZPzceSZ5JUgybCFEEX0Tefk jkZZbFG9XpE7ISyVxSnxyO+2VKQjkD7//XVca874C5bInxwna9Z4H42kdxwG19S/+fISfjZ8/aIGw uwtrE7eZbxGapBF5Gez0+sYrBACAPLpwi+stM9YO/xzFabd+indRhXF4kzE9RntVmgfaEBQ7Tz9TP DYWHA0KD/xiLfQ==; In-Reply-To: (message from Drew Adams on Sun, 13 Oct 2024 17:01:04 +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:293549 Archived-At: > From: Drew Adams > CC: "michael_heerdegen@web.de" , > "73709@debbugs.gnu.org" <73709@debbugs.gnu.org> > Date: Sun, 13 Oct 2024 17:01:04 +0000 > > > It's short and clear, but it's inaccurate. E.g., how to define > > "content newer" when both files have the same content (like if one of > > them is a copy of the other)? > > That and other details should be available from > `file-attribute-modification-time', if important at > all (which is why it can be good to point to the doc > of that attribute). Except that we also have set-file-times, which can make the file seem as if it was "last modified" at a different time. > (elisp) `File Attributes': > 5. The time of last modification as a list of four integers > (as above) ('file-attribute-modification-time'). This > is the last time when the file's contents were modified. > ^^^^^^^^^^^^^^^ The problem here is with the term "contents were modified". It is not explained, and its naïve interpretation will lead to inaccurate conclusions, for example when a file was copied. You can deny the complexity as much as you want, and you can quote text from documentation as long as you want, but the simple fact is that the concept of being "newer" is not easy to explain in detail. Alluding to file's attributes doesn't solve the problem; instead, it makes it more complicated and harder to explain without going into a very low level of how filesystems work (and that's even before we consider the differences in how the different filesystems supported by Emacs work in this regard). > You repeat that it's ALL OR NOTHING, claiming both (1) > the current doc is fine - clear enough and (2) anything > other than 100% complete information/clarity/details is > no better. I do? Then how come I changed the doc string at least twice in the recent days?