From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: master a7c65fc666: Allow nil value for filter-buffer-substring-function Date: Wed, 21 Sep 2022 08:58:02 +0200 Message-ID: <87pmfpb4ed.fsf@web.de> References: <166359943394.15847.12726646376922950024@vcs2.savannah.gnu.org> <20220919145714.5036DC00872@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13675"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:DFbloueK6BXrpkPS9ACmEUBRHgE= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 21 09:03:03 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oatl9-0003SF-6E for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 09:03:03 +0200 Original-Received: from localhost ([::1]:34830 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oatl7-0005zY-SW for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 03:03:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oatgU-0003m8-Dm for emacs-devel@gnu.org; Wed, 21 Sep 2022 02:58:15 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:48172) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oatgS-0007uq-Si for emacs-devel@gnu.org; Wed, 21 Sep 2022 02:58:14 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oatgR-0008DD-6Y for emacs-devel@gnu.org; Wed, 21 Sep 2022 08:58:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:295860 Archived-At: Drew Adams writes: > The argument that allowing a nil value for such > a variable "breaks" the use of `add-function' is > no more than a re-assertion that the variable > shouldn't have a nil value. I don't think this is true. You are missing an, or even the, important point IMO. > And in particular, the use of function `ignore' > is not the same thing as the use of nil to mean > "NO function" or "NOT a function" - not at all. > > No good argument exists for a blanket rule that > a var whose value can be a function shouldn't > also be allowed other, non-function values - in > particular the value nil. At least we've seen > no good argument so far. > (eq var 'ignore) or (eq var #'ignore) is more, > not less, problematic than (null var). > > You can certainly use (when var (add-function...)) > instead of just (add-function...). Or instead of > `apply' or `funcall'. Not a problem -- or if you > think it is then please show the problem. I don't think testing the value directly for equivalence to some given value is not an important use case: I think the idea behind this treatment is: we want to allow different modes/features, plus the user and/or buffer local configurations etc, to push their behavior changes into that variable at the same time (!), namely by advising it, by wrapping different layers around the value. That's only possible if the value is always guaranteed to be a function - so this is a requirement per se to allow this kind of approach, not an excuse to disallow non-function values. In this scenario, plain (equal var some-value) tests are quite useless because you don't know which modes and features or whatever already installed their modifications into the value (changing it). Michael.