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

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> 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.

> 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:

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 (!),
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.

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).

Michael.