RE: [External] : Re: master a7c65fc666: Allow nil value for filter-buffer-substring-function

[Drew Adams <drew.adams@oracle.com>]

> > The argument that allowing a nil value for such
> > a variable "breaks" the use of `add-function' is
> > no more than a re-assertion that the variable
> > shouldn't have a nil value.
> 
> I don't think this is true.  You are missing an,
> or even the, important point IMO.

I don't think that point was given.  My point was
that an argument that nil should be disallowed for
variables whose names end in `-function' is wrong
(misguided).  It may be reasonable for variable
`filter-buffer-substring-function', and for some
other so-named variables.  But as a general rule
it's misguided, IMO.
 
> > And in particular, the use of function `ignore'
> > is not the same thing as the use of nil to mean
> > "NO function" or "NOT a function" - not at all.
> >
> > No good argument exists for a blanket rule that
                                ^^^^^^^^^^^^^^
> > a var whose value can be a function shouldn't
> > also be allowed other, non-function values - in
> > particular the value nil.  At least we've seen
> > no good argument so far.
> 
> > (eq var 'ignore) or (eq var #'ignore) is more,
> > not less, problematic than (null var).
> >
> > You can certainly use (when var (add-function...))
> > instead of just (add-function...).  Or instead of
> > `apply' or `funcall'.  Not a problem -- or if you
> > think it is then please show the problem.
> 
> I don't think testing the value directly for equivalence
> to some given value is not an important use case:

You don't think it's _not_ an important use case?
Or was that a typo?  I'm guessing the latter,
based on the rest of what you say.

In any case, it may not be important to you, and
it may not be general enough for you or for
everything.  But it can be an important use case
for some code - for some `-function' vars, IMO.

I see no reason that a convention for naming vars
`-function' should be limited to variables whose
value can _only_ be a function.

I'm speaking to the blanket assertion that a
variable whose name ends in `-function', per our
convention, must be expected to only have a
function as its value.  I'm not speaking about
`filter-buffer-substring-function' specifically.

I disagree that that's what this naming is, or
should be, about.  Certainly any so-named var
whose value _must_ always be a function should
have that called out in its doc, and preferably
the code should support/enforce that requirement.
(_Does_ the doc call it out for this var?)

But from there to proclaim that all vars with
names that end in `-function' must only have
function values, I think is inappropriate, and
unnecessary.

It's a naming convention - to help human readers.
It's not a programming declaration - something
that controls code (e.g. byte-compilation), and
it shouldn't be.  (We _could_ have a declaration
for that, if it's helpful/needed.  Or we can
just communicate such things to humans in a doc
string.)

> I think the idea behind this treatment is: we want to allow different
> modes/features, plus the user and/or buffer local configurations etc, to
> push their behavior changes into that variable at the same time (!),
                                   ^^^^^^^^^^^^^

If you mean only `filter-buffer-substring-function'
then I have no objection.  I wasn't speaking about
that variable, or any particular variable.  I was
speaking to a general "rule" about variables with
such a name suffix.

I see now that I could have been clearer about that.
But I did say:

  I don't think that, in general, variables whose
                      ^^^^^^^^^^
  names end in `-function' should be disallowed a
  non-function value - in particular a value of nil.

I was talking about what the naming convention, in
itself, should be expected to mean.  I don't think
it should be expected that all such vars must have
only function values.

> namely by advising it, by wrapping different layers around the value.
> That's only possible if the value is always guaranteed to be a function
> - so this is a requirement per se to allow this kind of approach, not an
> excuse to disallow non-function values.

If you mean that only for this variable, I have no
problem with it.  For instance, I depend on the
same kind of thing you mention, in my code, wrt
`isearch-filter-predicate'.

Of course some vars should be required to have only
function values. And they (too) can benefit from
applying the `-function' naming convention to them.
But they shouldn't "own" (appropriate, pwn) that
convention.

> In this scenario, plain (equal var some-value) tests are quite useless
> because you don't know which modes and features or whatever already
> installed their modifications into the value (changing it).

Of course.

Speaking of which - I think it's a mistake BTW for
function `advice--p' to be "internal".  It's fine
that its implementation might change.  But it's a
fine function for user code to use.  There's no real
alternative, other than directly using the code that
implements it.  (Likewise for `advice--car' etc.)