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: Thu, 27 May 2021 19:51:50 +0300 Message-ID: <83pmxc86hl.fsf@gnu.org> References: <83lf8du09t.fsf@gnu.org> <3431d752-559a-7d33-e2fb-2d81dd6cc794@gmx.at> <83y2cds3g9.fsf@gnu.org> <37077232-fdf9-983c-3a34-a2334a7a8f49@gmx.at> <83sg2ho6v1.fsf@gnu.org> <400a3a6d-3fff-2eef-3fb2-0d758184bd46@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31627"; 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 Thu May 27 18:53: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 1lmJFq-00080u-Ks for ged-emacs-devel@m.gmane-mx.org; Thu, 27 May 2021 18:53:06 +0200 Original-Received: from localhost ([::1]:41942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmJFp-0006X1-Gn for ged-emacs-devel@m.gmane-mx.org; Thu, 27 May 2021 12:53:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmJEb-0005XY-OB for emacs-devel@gnu.org; Thu, 27 May 2021 12:51:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53770) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmJEb-0006fG-1i; Thu, 27 May 2021 12:51:49 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4874 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 1lmJEa-0006a2-0q; Thu, 27 May 2021 12:51:48 -0400 In-Reply-To: <400a3a6d-3fff-2eef-3fb2-0d758184bd46@gmx.at> (message from martin rudalics on Mon, 24 May 2021 10:47:29 +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:269948 Archived-At: > Cc: npostavs@gmail.com, emacs-devel@gnu.org > From: martin rudalics > Date: Mon, 24 May 2021 10:47:29 +0200 > > >> (1) The desired width of W's left fringe as set by `set-window-fringes' > >> and stored in a slot w->nominal_left_fringe_width where a value of > >> -1 stands for "take the width from W's buffer", > > > > Side note: could we please NOT call these "nominal" values? "Nominal" > > means "standard", whereas these aren't. How about "desired" or > > "requested"? > > I've been using "nominal" in the sense expressed by Wikipedia as "From a > philosophical viewpoint, nominal value represents an accepted condition, > which is a goal or an approximation, as opposed to the real value, which > is always present.". That sentence expresses well what I'm trying to do > here IMHO. Well, I'm asking you to use a different terminology, because it always trips me, Wikipedia notwithstanding. More to the point: the more I think about what you want to do the less I like it. So I'm going to stop thinking and just say that I don't think we should do it. I understand the motivation, but I think it's a slippery slope towards much more complex and hard to maintain code, with a goal that I believe cannot be reached, only approximated. We will complicate the heck out of the window-resizing functions, and in the end will not be able to promise that any change will be immediately visible through the accessors and variables. E.g., what happens if redisplay decides to resize the mini-window -- you end up with at least one window whose dimensions are not what was before. We don't make such promises now, and with frames AFAIU we cannot even try promising that (because WMs get in the way). So why complicate Emacs so much for such ephemeral reasons? I say let's document that not every change is immediately reflected, until the next redisplay, and move on to more important developments. Having said that, you are the expert on this, so if you decide to do this anyway, I won't fight you or forbid doing that. I just think we shouldn't do this.