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

[Drew Adams]

> > 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.
>       
> Is that written somewhere, or did only say someone that we have that
> rule, or people should, if possible, follow that rule?

I don't know of any rule/convention that says
that vars named `*-function' must never have
a non-function value.  (I would argue against
any such rule, in any case.)

> In (info "(elisp) Coding Conventions") I read
> 
>    • If the purpose of a variable is to store a single function, give it
>      a name that ends in ‘-function’.  If the purpose of a variable is
>      to store a list of functions (i.e., the variable is a hook), please
>      follow the naming conventions for hooks.  *Note Hooks::.
> 
> It doesn't tell anything about the other direction (name -> restriction
> to certain values).

Right.

> In the Emacs Elisp sources I find over hundred `defvar's of symbols
> named "*-function" that default to nil.  Doesn't seem to be a very
> strict thing.

Right.

That's maybe one reason to not now claim a rule
against that.  On the other hand, that doesn't
mean that maybe some of those vars shouldn't
have `ignore' as their default value - nothing
wrong with that.

My points are (1) nil is at least sometimes not
an unreasonable value, (2) there shouldn't be,
at least just with this naming convention, any
restriction to have only a function value.

> Maybe a good rule would be "[now that we have nadvice] please think about
> whether someone or somecode might want to advice that binding before
> allowing arbitrary values for *-function named variables".  Maybe it
> would a good idea to spell that hint out in the manual if it isn't yet
> (didn't check).

I'm OK with that.  Except NOT "for *-function
named variables".  IMO the advice to users here
should be to advise them to either try (by code)
to control the value, to not let it be a
non-function, or to document that the value
_needs_ to be a function.

And this is the case _regardless_ of the var
name.  Don't ever rely on a variable name for
something as important as a need for the value
to satisfy some property.  At least _document_
that need clearly.  And maybe try to code some
control/check, to enforce that need.

> > 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 agree it should not be a strict must.  More a guideline to follow when
> no reasons speak against it.  There are cases where other value types
> and a *-function name fit.

We shouldn't count on the variable name for a
lot.  If the value needs to satisfy a condition
(being a function is just one such possibility)
then that condition should be spelled out in the
doc, and maybe some code should try to enforce it.

BTW, this is one reason that I've argued in the
past for the ability to add a :type declaration
to a defvar, and not just to a defcustom.

A :type declaration gives you a lot of control
over the value, and it communicates the kind of
value expected/needed to users/coders.

I've also argued for better, tighter :type specs.
Both in vanilla Emacs code, if needed, and as
advice/recommendation for users.  You can do a
lot with a `restricted-sexp' type spec.

Unfortunately, both my proposal/patch to allow
:type etc. for defvar and my recommendation to
not discourage `restricted-sexp' were summarily
dismissed.  But give it another decade or two...

> > 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.)
> 
> Dunno if `advice--p' has non-internal use cases.  We have some related
> "public" functions in nadvice that might suffice: `advice-mapc' and
> `advice-member-p'.

I use it in two of my libraries, help-fns+.el
and isearch+.el.  Likewise other `advice--'
functions.  Those are extensions of standard
libraries help-fns.el and isearch.el.  But
isearch.el doesn't use such functions at all.

isearch+.el lets users interactively add &
remove advice to `isearch-filter-predicate':

https://www.emacswiki.org/emacs/DynamicIsearchFiltering

There's little, if any, reason for Emacs to
declare this or that Lisp code as "internal".

Why?  Because Free Software.

It's fine to let Emacs users know that
function XYZ might be more inclined to be
modified in the future than most functions.

There's no good reason to do that by way of
a naming convention.  And in particular, it's
unproductive to label XYZ as "internal".
(The use of the "--" convention is relatively
recent.  It's an unnecessary obstacle.)

Just one opinion.