From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: "after" variable watchers Date: Mon, 17 May 2021 07:57:55 -0700 Message-ID: <878s4dwgp8.fsf@rfc20.org> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21508"; mail-complaints-to="usenet@ciao.gmane.io" To: martin rudalics , emacs-devel , Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 17 17:00:01 2021 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 1lieit-0005If-8p for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 16:59:59 +0200 Original-Received: from localhost ([::1]:38232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lieis-0003sw-6s for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 10:59:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liehB-0000eD-5v for emacs-devel@gnu.org; Mon, 17 May 2021 10:58:14 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:46485) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lieh5-0000tr-6j for emacs-devel@gnu.org; Mon, 17 May 2021 10:58:12 -0400 Original-Received: (Authenticated sender: matt@rfc20.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 475E84000A; Mon, 17 May 2021 14:58:01 +0000 (UTC) Original-Received: from matt by mdeb with local (Exim 4.94) (envelope-from ) id 1liegt-000Lev-6Q; Mon, 17 May 2021 07:57:55 -0700 In-Reply-To: Received-SPF: pass client-ip=217.70.183.194; envelope-from=matt@rfc20.org; helo=relay2-d.mail.gandi.net 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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.23 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:269408 Archived-At: martin rudalics writes: > I'd like to install the attached patch which expands on the existing > variable watching mechanism in the sense that the variable whose value > gets changed has already the new value assigned to within the body of > the watch function. Such a feature is useful when the watch function > calls already existing functions which act upon the variable's new value > in a possibly deeply nested fashion. > > Consider the following example: A user wants to set `right-margin-width' > of a buffer and I want to decide whether that margin really fits. The > mechanism whether it fits would be nested in a common function that > decides whether any decoration (fringe, scroll bar, margin) fits into > any window showing that buffer based on the minimum sizes of that window > and the sizes of the remaining decorations. Passing a "this is the > requested new value of the right margin" setting to such a function is > awkward at the very least. > > Objections, suggestions, comments? I haven't seen vary many truly useful designs based on such a mechanism. It would be good to understand why. I think the basic problem is that the "deeply nested fashion" you mention is often quite complex, and many times ends up depending on other variables that are not yet modified. Consider your example: what if the new value for `right-margin-width' makes sense only after some other variables are also changed. Say, variables controlling fringe or scroll bar width, etc. If those variables are set by code after `right-margin-width' then the "valid right-margin-width" predicate would reject the value even though it will soon be valid. What we end up with is a situation where not only the final state must be valid (from the point of view of the watch function), but all transient states too. I have personally found systems like this to be difficult to deal with. The solution I most often I see is designs based on "dirty" state, where some point in the future code is triggered to validate state state. For that I think the current watch mechanism is sufficient to track which variables have changed?