Re: Change in files.el

[Mark Oteiza]

Stefan Monnier <address@hidden> writes:

>>> Anyway, I definitely see what you mean.  I just disagree on the
>>> seriousness of the problem, and on the impact of the guideline on it.
>> The issue is not serious enough to prevent people from using the
>> methods you'd like to see, but I question the wisdom of having a
>> project-wide guidelines to _always_ use them is similar situations.
>
> I think the benefits are the following:
> - (eventually) more consistency, such as knowing that you can use
>   `add-function` will work right on any *-predicate or
>   *-function variable.
> - until recently, it was common for such variables to have a nil
>   default value.  Without an active effort to reverse this, we'll always
>   end up with such new variables introduced with a nil default value
>   (especially since it's very common for new such variables to have
>   a trivial default behavior, and only accumulating complexity later
>   on, at which point it's a lot more difficult to change the default to
>   be non-nil).

Wasn't the reason any of these defaults changed simply so that
add-function would work?

Having the default be ignore suggests that one can/should always funcall a
FOO-function, and its arguments (should it have any) will be evaluated.
In order to avoid this we now have to check (as is the case in eldoc) if
FOO-function is equal to nil or ignore.