Re: Change in files.el

[Stefan Monnier]

>> >> - More generally, so that you can slightly change its behavior without
>> >> having to re-implement the default behavior by hand.
>> >> - Also, so as to make sure that it is *possible* to reimplement
>> >> the default behavior by hand (i.e. to make sure the predicate has
>> >> access to all the info it needs to reproduce the default
>> >> behavior).
>> > 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.

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?

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.
The situation is often worse when the code is written in C, where the
fix sometimes involves exporting new vars to Elisp, an that sometimes
proves problematic because that var was not designed to be accessible to
random code.

>   (defcustom save-some-buffers-default-predicate #'some-func
>   ...)
>
>   (if save-some-buffers-default-predicate DO-SOMETHING)

[ Side note: "(if save-some-buffers-default-predicate ...)" is already
  a bad idea.  the only thing you should do with such a var is pass it to
  `funcall` or `apply`.  ]

> requires me to go and look at some-func, which is "one more level of
> indirection".

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,
and indeed it might require some extra instrumentation step to get
Edebug to enter `some-func`, but that hasn't been terribly annoying
(otherwise, I'd have gotten around around to making `i` work on funcall
to automate the extra step).  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 and the same problem shows up if the
(funcall save-some-buffers-default-predicate) is replaced by

    (if save-some-buffers-default-predicate
        (funcall save-some-buffers-default-predicate ..args..))
      ..do-the-default-thing..)


-- Stefan