From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.help Subject: Re: Gnus: Thread notes? Date: Thu, 28 Dec 2017 12:30:35 -0800 Message-ID: <87lghm1tp0.fsf@ericabrahamsen.net> References: <87o9pc359b.fsf@web.de> <874lr3pz2q.fsf@ericabrahamsen.net> <87o9p6zy4f.fsf@web.de> <878tgavoio.fsf@ericabrahamsen.net> <87fu93ulhz.fsf@web.de> <87o9nq50hi.fsf@ericabrahamsen.net> <877eudsj2x.fsf@web.de> <874lpfjgb2.fsf@ericabrahamsen.net> <87indv6iup.fsf@web.de> <87wp2agxo5.fsf@ericabrahamsen.net> <87mv2om8tj.fsf@web.de> <874lovrhl1.fsf@ericabrahamsen.net> <87o9n27q9z.fsf@web.de> <87po7io691.fsf@ericabrahamsen.net> <87po7hlf4p.fsf@web.de> <87ind8q3mk.fsf@ericabrahamsen.net> <87lgi4xlti.fsf@web.de> <87y3m3ooua.fsf@ericabrahamsen.net> <87lgi3rcl2.fsf@web.de> <87wp1nmccy.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1514492962 9111 195.159.176.226 (28 Dec 2017 20:29:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 28 Dec 2017 20:29:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Michael Heerdegen To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 28 21:29:17 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUeng-0001k3-87 for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Dec 2017 21:29:12 +0100 Original-Received: from localhost ([::1]:37529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eUepf-0003VX-7N for geh-help-gnu-emacs@m.gmane.org; Thu, 28 Dec 2017 15:31:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eUep9-0003UW-4k for help-gnu-emacs@gnu.org; Thu, 28 Dec 2017 15:30:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eUep4-0007D2-13 for help-gnu-emacs@gnu.org; Thu, 28 Dec 2017 15:30:43 -0500 Original-Received: from mail.ericabrahamsen.net ([50.56.99.223]:39856) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eUep3-0007CT-Ne for help-gnu-emacs@gnu.org; Thu, 28 Dec 2017 15:30:37 -0500 Original-Received: from localhost (71-212-75-109.tukw.qwest.net [71.212.75.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 725EEC0733; Thu, 28 Dec 2017 20:30:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ericabrahamsen.net; s=mail; t=1514493036; bh=ER1GmF2fnpvcw1oGDCfvNakskt5ACRnLZWfixeOVC/Q=; h=From:To:Cc:Subject:References:Date:From; b=CBICZZygrSMRN3T2k9XuScFMYQVVymGn6o9NdIJYJA1Tfs9d5KfN3s+PgwCmOvVBi nMcMF/GpA1vApj6PDzrS++wpxFyOGQpu2jM+Zj3iQj4OZ42KFN91a1zQsUZVzn6poY qIiEEggXiFfHBGOu1Lo66W3ahDIg20ZLNdqP28Ic= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 50.56.99.223 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115492 Archived-At: Eric Abrahamsen writes: > Michael Heerdegen writes: > >> Eric Abrahamsen 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.