Re: Change in files.el

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 28 Jan 2017 11:51:07 -0500
> 
> >> > These sound minor to me (and the last two are also possible without
> >> > the requirement, AFAIU).
> >> Hmm... how do you get the last two without that requirement?
> > Are we still talking about a predicate, i.e. a function that returns
> > either t or nil?  If so, I think the last two are so trivial that I
> > don't know where to begin answering your question.
> 
> I don't see what the form of the return value changes to the problem.

The default behavior is just the value t or nil, so reproducing the
default behavior is trivial.  E.g., in the case in point the default
behavior is to always ask the user about every buffer, i.e. the
default implementation simply always returns t.

> Regarding "More generally, so that you can slightly change its
> behavior without having to re-implement the default behavior by hand":
> - what code would you write which preserves the behavior except that it
>   logs all calls to some global variable?
> - what code would you write which preserves the behavior except that it
>   returns nil for one specific buffer?

Here, everything you write in a non-default implementation belongs to
the new functionality; the original functionality is a constant value
returned unconditionally, and it's trivial to write.

> Regarding "Also, so as to make sure that it is *possible* to reimplement
> the default behavior by hand": in my experience trying to change
> *-function to default to a non-nil value, it often happens that the
> preexisting default behavior *cannot* be implemented faithfully (or
> without a lot of extra gymnastic) because it relies on some local
> variable which is not passed as argument to the predicate.

Once again, the default behavior of a predicate is just t or nil, so I
don't think I understand what you ware talking about here.

> I see what you mean.  Yes, the default behavior ends up moved into its
> own function.  I'm surprised you feel so strongly about it, tho, because
> it never caused me such trouble.
> 
> When debugging a specific execution, I'm usually doing it with Edebug,

Tye need to use a debugger instead of just reading the code is already
a huge annoyance, which tremendously slows down problem-solving, due
to the need to arrange for some reproduction recipe, and then step
through the code.

> And when just reading the code without any specific execution in
> mind, I typically don't look at the value of
> save-some-buffers-default-predicate at all since the code should
> work correctly regardless of that value

Debugging a problem does not necessarily need to consider all possible
values, it typically considers only one -- the one that causes the
problem you are debugging.  So it matters a lot whether you can
understand what happens with that specific value, and indeed what _is_
that value, when the problem hits.  In a vast majority of cases, you
only have the final result in the user report: an error message or
some incorrect output, and need to work your way back from that to the
conditions and the logic which failed.  Each indirection is one more
obstacle in this analysis, and given enough of them the analysis
becomes practically impossible (unless you are already well familiar
with the code in question).