unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: 73709@debbugs.gnu.org, drew.adams@oracle.com
Subject: bug#73709: 29.4; Doc of `file-newer-than-file-p'
Date: Fri, 11 Oct 2024 08:56:30 +0300	[thread overview]
Message-ID: <86y12vyygh.fsf@gnu.org> (raw)
In-Reply-To: <87cyk7trma.fsf@web.de> (message from Michael Heerdegen on Fri, 11 Oct 2024 02:23:09 +0200)

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 73709@debbugs.gnu.org,  drew.adams@oracle.com
> Date: Fri, 11 Oct 2024 02:23:09 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Apart from that: if it is hard or not practical to describe what the
> > > function returns in every case, we can instead try to describe major
> > > use cases.
> >
> > That'd mean a lot of text to write to describe what should be clear
> > enough, at least as far as Emacs is concerned.  I don't think it's our
> > job to describe how the various filesystems work.
> 
> This is not what I suggested.  My suggestion was to tell something like
> "For example, this function is used to check whether a file should be
> restored from an auto-safe file, or needs to be recompiled".  This is
> possible without describing how filesystems work, or how quantum
> chromodynamics work.

I'm okay with adding examples that people think might be useful, if
all we do is mention them without going into details too much.  To me,
the 2 examples you mention sound almost trivial, but I nevertheless
won't object to add some short text with such examples, if they help
someone better understand the purpose of the function.

> > Very well, but please remember your opinions in this matter, because
> > if someone comes up asking for more details about "last modification
> > times" (perhaps even Drew himself, e.g. because someone asked some
> > question on SE), I will defer to you and Stefan to deal with the
> > fallout.
> 
> When you say "[...] should be clear enough": are you sure that the
> misinterpretation as "file creation time" only can happen to me and to
> Drew - because we are exceptionally stupid Emacs users?

There's nothing stupid about that.  Moreover, in some subtle
situations this will be the exact meaning of "file newer".  My point
is different: that Lisp programmers should not think about this in
terms of file attributes returned by the 'stat' system call, but as a
higher-level abstraction.

> If not: do you have any better idea?

Better idea about what?

> And: Sure can you ask for my help, but, with all respect, please not in
> such a way, Eli.

Sigh.  Why do you have to interpret what I write in the worst possible
way?  It's possible that my dry humor is sometimes too dry, but
there's nothing other than dry humor in what I wrote above.  I'd
expect everyone here would recognize that by now, but I guess not...





  reply	other threads:[~2024-10-11  5:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 17:56 bug#73709: 29.4; Doc of `file-newer-than-file-p' Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-08 18:20 ` Eli Zaretskii
2024-10-08 18:40   ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-09  0:45     ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-09 13:31       ` Eli Zaretskii
2024-10-09 16:32         ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-09 23:21         ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-10  8:09           ` Eli Zaretskii
2024-10-10 11:08             ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-11  0:23             ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-11  5:56               ` Eli Zaretskii [this message]
2024-10-12  0:31                 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-12  8:40                   ` Eli Zaretskii
2024-10-12 22:48                     ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-13  5:13                       ` Eli Zaretskii
2024-10-13 14:51                         ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-13 15:31                           ` Eli Zaretskii
2024-10-13 17:01                             ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-13 18:30                               ` Eli Zaretskii
2024-10-13 22:23                                 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-14  2:28                                   ` Eli Zaretskii
2024-10-15  1:10                             ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-09 23:42         ` Stefan Kangas
2024-10-10  1:47           ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-10  8:26           ` Eli Zaretskii
2024-10-11  0:41             ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-11  6:03               ` Eli Zaretskii
2024-10-12  0:38                 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-12  1:13                   ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors

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=86y12vyygh.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=73709@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=michael_heerdegen@web.de \
    /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).