From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: window-buffer-change-functions Date: Fri, 23 Sep 2022 23:13:37 +1200 Message-ID: References: <83o86hyild.fsf@gnu.org> <877d1ycbom.fsf@gnus.org> <835yhivx39.fsf@gnu.org> <83v8piuh5k.fsf@gnu.org> <2f85eda92184de27e10572e6b2320885@webmail.orcon.net.nz> <83pmfpv4fs.fsf@gnu.org> <7110e0330e878c144a6364a8e6ad651c@webmail.orcon.net.nz> <83fsgkszcv.fsf@gnu.org> <1a6028ed-73bd-7d5f-c206-8061bdc9edd0@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Orcon Webmail Cc: martin rudalics , eliz@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 23 13:15:08 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 1obgeC-0006tu-8g for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Sep 2022 13:15:08 +0200 Original-Received: from localhost ([::1]:56452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1obgeB-00026Y-2P for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Sep 2022 07:15:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obgd2-0001JN-44 for emacs-devel@gnu.org; Fri, 23 Sep 2022 07:13:56 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:53979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obgcz-0003ru-FS; Fri, 23 Sep 2022 07:13:55 -0400 Original-Received: from [10.253.37.70] (port=11569 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1obgcj-000222-Hu; Fri, 23 Sep 2022 23:13:37 +1200 Original-Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 23 Sep 2022 23:13:37 +1200 In-Reply-To: X-Sender: psainty@orcon.net.nz X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.34; envelope-from=psainty@orcon.net.nz; helo=smtp-1.orcon.net.nz X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:296036 Archived-At: On 2022-09-23 15:19, Richard Stallman wrote: > A variable is supposed to have one value at any given time. It might > be the default binding, or a something-local binding. But regardless > of why that binding is current at any time, its value is _the value_ > of the variable at that time. The other bindings shouldn't affect > what the variable stands for when they are not current. Although the case in question is still unusual, it's worth noting that most hooks might use both the buffer-local and default values when they run, if both values are defined. Quoting `add-hook': The optional fourth argument, LOCAL, if non-nil, says to modify the hook's buffer-local value rather than its global value. This makes the hook buffer-local, and it makes t a member of the buffer-local value. That acts as a flag to run the hook functions of the global value as well as in the local value. Therefore, in a majority of cases, running a hook with a buffer-local value processes both the buffer-local list *and* the global list for that variable. As this behaviour is under the control of the buffer-local value, it's still not the same as both values being used automatically for two different purposes; but I just wanted to point out that there has long been an established mechanism by which both the buffer-local binding and the default binding of a hook variable are used together, so the window hooks aren't unique in that regard. The window hooks are different in other ways of course, but they are reacting to window and frame changes rather than buffer changes, so it probably wouldn't ever make sense for a buffer-local value to take precedence over the default value for these hooks. Splitting each of them into two separate hooks wouldn't really gain anything in terms of functionality then? -Phil