Re: Gnus: Thread notes?

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> The only remaining issue is, I think it would be confusing to allow
>>>  `gnus-alter-articles-to-read-function' to be either a single function
>>>  value, or a list of functions. That makes it harder for consumers to
>>>  manipulate, as they have to check its current value first. What do
>>> you think about requiring a list?
>>
>> I wouldn't find that good (it would be an unnecessary restriction for
>> users ability to configure stuff), and I think then also the variable
>> name would really not fit anymore the semantics.  I think it would then
>> be cleaner to introduce a new variable
>> `gnus-alter-articles-to-read-functions' (note the added "s").  Make it
>> so that
>>
>>  - gnus-alter-articles-to-read-function (without "s") defaults to a new
>>  named function that would process the elements of the new variable
>>  which should be bound to a list (of functions), default nil.  That
>>  would be backward compatible.
>>
>>  - People like me could use `add-function' on
>>  `gnus-alter-articles-to-read-function'.
>>
>>  - People preferring a list could add their functions to the new
>>  variable binding.
>>
>> I would still prefer a solution with only one variable, but given what
>> we currently have, and what you want, two variables may be better.  But
>> it's not really nice.
>>
>> If I were you, I would tell people to use `add-function', it's not that
>> hard, and I heard most of Gnus users even use Emacs ;-)
>>
>> BTW, I would expect that when the default value of
>> `gnus-alter-articles-to-read-function' is changed to a no-op function,
>> most people would just setq that variable to a function defined in their
>> config, there is no need to use `add-function' to configure things.  So
>> for users who don't like to use `add-function', nothing would change.
>> But OTOH, packages would be able to use `add-function' to change the
>> behavior (though, with a certain risk that the user inadvertently erases
>> that when setting the variable after a package has used `add-function'
>> on the binding).
>>
>> Anyway, I expect that we are talking about very few users here.  But I
>> would hate a solution where I have to redefine a Gnus function just
>> because the provided means of configuration don't suffice.
>
> Okay, you've convinced me. The only thing that seems weird is having it
> run as as a no-op function by default, but I guess that's what
> docstrings are for. I agree it would be a bad idea to change the
> variable name (or make it inaccurate), or to introduce another variable
> that does nearly the same thing as the first. I'll push this at some
> point soon.

Okay, there it goes.