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 19:57:42 +0300 Message-ID: <83y2cds3g9.fsf@gnu.org> References: <83lf8du09t.fsf@gnu.org> <3431d752-559a-7d33-e2fb-2d81dd6cc794@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33288"; 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 18:59:07 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 1ligaB-0008TX-GA for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 18:59:07 +0200 Original-Received: from localhost ([::1]:40316 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ligaA-0000EX-E3 for ged-emacs-devel@m.gmane-mx.org; Mon, 17 May 2021 12:59:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ligYz-0005yL-E1 for emacs-devel@gnu.org; Mon, 17 May 2021 12:57:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51870) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ligYy-000069-Q6; Mon, 17 May 2021 12:57:52 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2074 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 1ligYl-0005a1-Tl; Mon, 17 May 2021 12:57:43 -0400 In-Reply-To: <3431d752-559a-7d33-e2fb-2d81dd6cc794@gmx.at> (message from martin rudalics on Mon, 17 May 2021 18:40:09 +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:269415 Archived-At: > Cc: npostavs@gmail.com, emacs-devel@gnu.org > From: martin rudalics > Date: Mon, 17 May 2021 18:40:09 +0200 > > > 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? > > Because knowing the new value in the watch function is of no practical > use. I'd have to pass it down to all functions called directly or > indirectly by the watch function that make use of that value. Sorry, I don't understand. I really don't, not even after reading your explanations. (Assuming I understood the explanations: they seem to mix what you intend to do with this "after-watcher" and what you would have needed with the current watcher machinery, so it's difficult to figure out which is which.) Perhaps taking a single example and explaining how would this work with today's watchers and with the feature you want to install could help me understand. > > 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? > > Right. In the mold of your `add-variable-watcher' at the end of > frame.el. So if I remove those, you will retract this proposal? And note that the analogy is incomplete at best: the watchers in frame.el watch _variables_ that we used to have forever, so making them modifiable only via accessor functions would be a breaking change. Whereas you are talking about stuff which is done by functions already. > > First, I'd like to better understand the need for this. > > First, it's useful for having a change in a buffer's decorations take > effect immediately. So we get rid of things like > > Setting this variable does not take effect until a new buffer is displayed > in a window. To make the change take effect, call ‘set-window-buffer’. I think this could be a step in the wrong direction. It might be easier for users, but it makes it harder for us to develop Emacs in the long run, for example if we want more threading. That's because all those global and buffer-local variables are part of the huge global state we have, and that gets in the way of some features. > And finally we would get rid of the present mixture of errors thrown at > the user and that of changes that are silently ignored whenever a > decoration does not fit. A user then can set the nominal width of the > right margin to some arbitrary number. When the window is large enough > to accommodate it, it will be displayed that way. When the window gets > too small, it will be temporarily clipped or skipped. So we get silent fixes for all of them? Not sure this is an improvement. I think we already had complaints about silently "fixing" the decorations as we see fit.