Re: Gnus: Thread notes?

[Eric Abrahamsen]

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.

Eric