From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "after" variable watchers Date: Mon, 17 May 2021 13:23:26 +0300 Message-ID: <83lf8du09t.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29751"; mail-complaints-to="usenet@ciao.gmane.io" Cc: npostavs@gmail.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 17 12:26:16 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 1liaS0-0007T6-GK for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 12:26:16 +0200 Original-Received: from localhost ([::1]:33186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liaRz-0008Ez-Hy for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 06:26:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liaPF-0003Y4-DN for emacs-devel@gnu.org; Mon, 17 May 2021 06:23:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33990) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liaPE-0004BF-QW; Mon, 17 May 2021 06:23:24 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4652 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liaPE-00027c-9q; Mon, 17 May 2021 06:23:24 -0400 In-Reply-To: (message from martin rudalics on Mon, 17 May 2021 10:27:40 +0200) 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:269399 Archived-At: > From: martin rudalics > Date: Mon, 17 May 2021 10:27:40 +0200 > > 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. But the watcher function already gets the new value, so why do we need to be able to call it after the variable's value was changed? > 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. I don't think I understand the use case, and so cannot follow your "awkward" argument. In general, this is a debugging feature, while you seem to be describing a use case where the watcher will be a constant part of an implementation of some feature, is that right? > Objections, suggestions, comments? First, I'd like to better understand the need for this. If indeed this could be useful enough, I think I'd prefer 2 separate list of watchers and 2 bits to indicate which one of the 2 possible lists of watchers should be scanned to find the watcher function. The way you implemented it will slow down Emacs in one of its most sensitive places: where we bind symbols to values, because we now need to scan the same list twice, and call Fget for each symbol to see if it's a "before" or an "after" watcher. A few minor comments follow. > -@defun add-variable-watcher symbol watch-function > +@defun add-variable-watcher symbol watch-function after This doesn't say AFTER is an optional argument. > -@defun remove-variable-watcher symbol watch-function > +@defun remove-variable-watcher symbol watch-function after Neither does this. > This function removes @var{watch-function} from @var{symbol}'s list of > -watchers. > +watchers. The third argument @var{after} should match the same argument > +used by the previous @code{add-variable-watcher} call. This should be reworded to be more oriented towards the Lisp programmer who wants to use this function. What the text does now is describe the implementation, from which the reader will have to glean what that means in terms of which watchers will be removed. > @@ -1659,55 +1671,86 @@ DEFUN ("add-variable-watcher", Fadd_variable_watcher, Sadd_variable_watcher, > WHERE is a buffer if the buffer-local value of the variable is being > changed, nil otherwise. > > +Third argument AFTER, if non-nil, means to call WATCH-FUNCTION after > +SYMBOL has been set. In that case, the second argument for > +WATCH-FUNCTION will be the value of SYMBOL before it was set to the > +current value. This doesn't say what will be that old-value if the variable wasn't bound (and neither does the manual text). > + > All writes to aliases of SYMBOL will call WATCH-FUNCTION too. */) > - (Lisp_Object symbol, Lisp_Object watch_function) > + (Lisp_Object symbol, Lisp_Object watch_function, Lisp_Object after) > { > + CHECK_SYMBOL (symbol); I don't think I understand why you added CHECK_SYMBOL here. There's one such call right after that. Thanks.